오류 코드 1117 열이 너무 많습니다. 테이블의 MySQL 열 제한

1699 개의 열이있는 테이블이 있고 더 많은 열을 삽입하려고 할 때

오류 코드 : 1117. 열이 너무 많습니다

이 테이블에는 1000 개의 행만 있습니다. 나에게 가장 중요한 것은 열의 수입니다. 테이블에 제한이 있습니까? 2000 개의 열을 만들고 싶습니다. 가능합니까?

2000 개는 물론 20 개의 열로 테이블을 만들어야하는 이유

승인 된 비정규 화 된 데이터는 많은 데이터 열을 검색하기 위해 JOIN을 수행하지 않아도됩니다. 그러나 열이 10 개를 초과하는 경우 데이터 검색 중에 발생하는 문제를 중지하고 고려해야합니다.

2000 컬럼 테이블에 SELECT * FROM ... WHERE가 발생하면 처리 중에 큰 임시 테이블을 생성하고 불필요한 컬럼을 페치 하며 모든 쿼리 에서 통신 패킷 ( max_allowed_packet )이 푸시 될 많은 시나리오를 작성 합니다.

초기에는 개발자로서 DB2가 주요 RDBMS였던 1995 년 회사에서 근무했습니다. 이 회사는 단일 테이블에 270 개의 열과 수십 개의 인덱스가 있으며 데이터 검색시 성능 문제가있었습니다. 이들은 IBM에 문의하여 컨설턴트가이 단일 모 놀리 식 테이블을 포함하여 시스템 아키텍처를 조사하도록했습니다. "다음 2 년 동안이 테이블을 정규화하지 않으면 DB2는 Stage2 처리를 수행하는 쿼리 (인덱싱되지 않은 열을 정렬해야하는 쿼리)에서 실패합니다." 이것은 270 개의 컬럼 테이블을 정규화하기 위해 수조 달러 규모의 회사에 들었습니다. 2000 컬럼 테이블이 훨씬 더 많습니다.

mysql의 관점에서 DB2 Stage2 처리와 비슷한 옵션을 설정하여 잘못된 설계를 보완해야합니다. 이 경우 해당 옵션은

• max_allowed_packet
• tmp_table_size
• max_tmp_tables
• max_heap_table_size
• max_length_for_sort_data
• max_sort_length
• sort_buffer_size
• myisam_max_sort_file_size
• myisam_sort_buffer_size

RAM이 TB 인 경우 수백 개가 아닌 수십 개의 열을 보충하기 위해이 설정을 Tweeking하면 효과적입니다.

트랜잭션 격리를 통해 각 SELECT, UPDATE 및 DELETE를 사용하여 많은 열을 보호하려는 MVCC (Multiversion Concurrency Control) 를 처리해야하므로 InnoDB를 사용하는 경우이 문제가 기하 급수적으로 증가합니다 .

결론

나쁜 디자인을 보완 할 수있는 대체품이나 반창고는 없습니다. 미래의 정신을 위해 오늘 그 테이블을 정상화하십시오!

데이터 모델이 올바르게 정규화 된 테이블에 2000 개의 열을 합법적으로 포함 할 수있는 것을 상상하는 데 어려움을 겪고 있습니다.

내 생각에 당신은 아마도 일종의 "빈칸 채우기"비정규 화 된 스키마를 수행 할 것이다. 여기서는 실제로 모든 종류의 데이터를 하나의 테이블에 저장하고 데이터를 별도의 테이블로 나누고 관계를 만드는 대신에 지정된 행에 어떤 "유형"데이터가 저장되는지 기록하는 다양한 필드가 있으며 필드의 90 %가 NULL입니다. 그럼에도 불구하고 2000 열에 도달하고 싶다면 ...

문제의 해결책은 데이터 모델을 다시 생각하는 것입니다. 주어진 레코드와 관련된 많은 키 / 값 데이터를 저장한다면, 그런 식으로 모델링하지 않겠습니까? 다음과 같은 것 :

CREATE TABLE master (
    id INT PRIMARY KEY AUTO_INCREMENT,
    <fields that really do relate to the
    master records on a 1-to-1 basis>
);

CREATE TABLE sensor_readings (
    id INT PRIMARY KEY AUTO_INCREMENT,
    master_id INT NOT NULL,   -- The id of the record in the
                              -- master table this field belongs to
    sensor_id INT NOT NULL,
    value VARCHAR(255)
);

CREATE TABLE sensors (
    id INT PRIMARY KEY AUTO_INCREMENT,
    <fields relating to sensors>
);

그런 다음 주어진 "마스터"레코드와 관련된 모든 센서 항목을 얻으려면을 클릭하면 SELECT sensor_id,value FROM sensor_readings WHERE master_id=<some master ID>됩니다. 해당 레코드에 대한 master모든 센서 데이터와 함께 테이블 의 레코드에 대한 데이터를 가져와야하는 경우 조인을 사용할 수 있습니다.

SELECT master.*,sensor_readings.sensor_id,sensor_readings.value
FROM master INNER JOIN sensor_readings on master.id=sensor_readings.master_id
WHERE master.id=<some ID>

그런 다음 각 센서의 세부 정보가 필요한 경우 추가로 조인합니다.

2000 개의 센서가있는 측정 시스템

정규화에 대해 외치는 모든 의견을 무시하십시오-당신이 요구하는 것은 (이상적인 세계에서) 합리적인 데이터베이스 디자인이 될 수 있고 완벽하게 정규화 될 수 있습니다. 매우 비정상적이며 다른 곳에서 지적했듯이 RDBMS는 일반적 으로이 많은 열에 대해 단순히 설계되지 않았습니다 .

MySQL 하드 한계에 도달하지는 않았지만 링크에 언급 된 다른 요인 중 하나가 아마도 더 높은 수준으로 올라가지 못하게하는 것일 수 있습니다.

다른 사람들이 제안했듯이으로 자식 테이블을 사용 하여이 제한을 해결 id, sensor_id, sensor_value하거나 더 간단하게 첫 번째 테이블에 맞지 않는 열만 포함하는 두 번째 테이블을 만들 수 있습니다 (동일한 PK 사용)

MySQL 5.0 열 수 제한 (강조 추가) :

테이블 당 4096 열의 하드 한계가 있지만 유효 최대 값은 주어진 테이블에 대해 더 적을 수 있습니다. 정확한 한계는 몇 가지 상호 작용 요인에 따라 다릅니다.

• 스토리지 엔진에 관계없이 모든 테이블의 최대 행 크기는 65,535 바이트입니다. 스토리지 엔진은이 제한에 추가 제한을 두어 유효 최대 행 크기를 줄입니다.

  모든 열의 총 길이가이 크기를 초과 할 수 없으므로 최대 행 크기는 열 수 (및 가능한 크기)를 제한합니다.

...

개별 스토리지 엔진은 테이블 컬럼 수를 제한하는 추가 제한 사항을 부과 할 수 있습니다. 예 :

• InnoDB는 최대 1000 개의 열을 허용합니다.

먼저 좀 더 화염을 피운 다음 진정한 해결책을 찾으십시오.

나는 이미 당신에게 던져진 불꽃에 동의합니다.

키-값 정규화에 동의하지 않습니다. 쿼리는 끔찍합니다. 성능이 더욱 악화됩니다.

즉각적인 문제 (열 수 제한)를 피하는 하나의 '간단한'방법은 데이터를 '수직으로 분할'하는 것입니다. 예를 들어, 각각 400 개의 열이있는 5 개의 테이블이 있습니다. AUTO_INCREMENT 인 경우를 제외하고 모두 동일한 기본 키를 갖습니다.

아마도 가장 중요한 12 개의 필드를 결정하는 것이 더 좋을 것입니다. '메인'테이블에 넣으십시오. 그런 다음 센서를 논리적으로 그룹화하고 여러 개의 병렬 테이블에 배치하십시오. 올바른 그룹화를 사용하면 항상 모든 테이블에 참여하지 않아도됩니다.

값을 인덱싱하고 있습니까? 그들을 검색해야합니까? 아마 당신은 날짜 시간에 검색?

많은 열을 색인 해야하는 경우-펀트.

몇 개의 색인을 작성해야하는 경우 '기본 테이블에 넣으십시오.

실제 솔루션은 다음과 같습니다 (적용되는 경우) ...

인덱스 된 방대한 센서가 필요하지 않으면 열을 만들지 마십시오! 네, 들었어요 대신 JSON으로 수집하고 JSON을 압축하여 BLOB 필드에 저장하십시오. 많은 공간을 절약 할 수 있습니다. 열 제한 문제가 아닌 하나의 테이블 만 있습니다. 등. 애플리케이션이 압축 해제 된 다음 JSON을 구조로 사용합니다. 맞춰봐? 앱을 원하는대로 센서를 배열, 다중 레벨 항목 등으로 그룹화 할 수 있습니다. 또 다른 '기능'은 개방형입니다. 더 많은 센서를 추가하면 테이블을 변경할 필요가 없습니다. 유연하다면 JSON.

압축은 선택 사항입니다. 데이터 집합이 큰 경우 디스크 공간에 도움이되므로 전체 성능이 향상됩니다.

나는 이것이 빅 데이터의 세계에서 가능한 시나리오라고 생각하는데, 전통적인 선택 유형의 쿼리를 수행하지 않을 수도 있습니다. 우리는 예측 모델링 세계에서 고객 차원에서 수천 차원의 고객을 모델링하는 고객 수준에서이 문제를 처리합니다 (모두 0 또는 1의 값을 가짐). 이러한 저장 방법을 사용하면 같은 행에 위험 요소가 있고 같은 행에 결과 플래그도있을 때 다운 스트림 모델 구축 활동 등이 더 쉬워집니다. 이는 상위 하위 구조가있는 스토리지 관점에서 표준화 될 수 있지만 다운 스트림 예측 모델은 다시 평면 스키마로 변환해야합니다. 우리는 컬럼 스토리지를 수행하는 redshift를 사용하므로 데이터를로드 할 때 1000 컬럼 이상이 실제로 컬럼 형식으로 저장됩니다 ...

이 디자인에는 시간과 장소가 있습니다. 물론. 정규화가 모든 문제에 대한 해결책은 아닙니다.