테이블의 열이 많습니다

Question

스키마의 테이블에 이미 100 개의 열이 있습니다. 수평 데이터 저장 방법을 따르면 600 개의 열을 더 추가해야합니다. 새로운 테이블을 생성하고 100 개의 컬럼을 갖는 테이블로 참조 무결성을 생성하는 수직적 인 데이터 저장을 위해 이동한다면, 100 개의 컬럼을 갖는 테이블이 5,300 만 개의 레코드를 가지며 생성 된 새로운 테이블이 훨씬 더 많아 질 것이기 때문에 테이블 조인에 문제가있을 것입니다 그것보다. 이 경우에 더 나은 방법은 입니다.

여기 흥미로운 테스트 케이스를 추가하고 싶습니다. 나는 이미 87 칼럼과 5300 만 레코드가있는 테이블에 600 칼럼을 추가했습니다. 그때 일괄를 업데이트하려고

1000 개 레코드를 업데이트하는데 걸리는> 시간 >> 10000 개 레코드를 업데이트하는 데 걸리는 2.10 초 B> 시간 >> 1000000 개 레코드를 업데이트하는 데 걸리는 5.57 초 C> 시간 >> 5.42 분 d> 5,300 만 레코드를 업데이트하는 데 걸리는 시간 >> 4. 5 시간 (테이블 공간이 고갈되어 테이블 공간을 확장해야했습니다.)

빠른 업데이트 방법을 제안하는 사람이 있습니까?

Answer 1

데이터의 성격과 사용 방식에 따라 크게 달라집니다.

어쩌면 XML 문서에 데이터를 기록하고 DB에 문서를 저장하는 것이 적절하다 ...

Answer 2

편집 : 이것은 실제로 매우 흥미로운 질문, 지금 그것에 대해 궁금합니다. 가능한 한 많은 데이터를 사용하여 하나의 큰 테이블과 많은 테이블을 비교하여 실제 테스트를 해보는 것이 좋습니다. 그것은 여분의 노력의 가치가있을 수도 있습니다! 심지어 관계형 DB조차도 제대로 설계되지 않았고 수백만 건의 레코드가있는 경우 (이 문제는 이후에 을 수정하는 쉬운 일이 아니라 인수 회사와 계약 한 동안 경험 한 것임을 기억하십시오.) 따라서 원 테이블 디자인도 작동 할 수 있습니다. 테스트의 증거입니다.

5300 만 레코드? MySQL/SQL과 같은 실제 관계형 데이터베이스 엔진을 사용하기를 바랍니다. 큰 테이블을 처리하도록 설계되었습니다.

600+ 하나의 테이블에있는 열은 지나치게 잔인합니다. 나는 one-to-many 레코드 구조가 아니라고 가정합니다. 이것이 당신이 all-in-one-row 접근법을 선택하는 이유입니다. 그렇더라도 데이터가 무엇인지에 따라 별도의 테이블을 갖는 것이 더 좋습니다. 당신이 요구할 필요가

Answer 3

질문 :

• 내 다양한 ​​행 의 필드의 대부분은 기본 또는 빈 값이 있습니까? 이 경우 인 경우 더 적합한 수직 스키마가 일 수 있습니다.
• 쿼리 할 때 행의 모든 ​​필드를 검색하려면 보통 이 필요하거나 자연스럽게 필드를 입력하여 을 그룹으로 분류합니까? 이 경우 가로 스키마가 적합 할 수 있지만 주 테이블을 주 테이블을 하위 테이블로 잘라내어 각각 자연 필드 그룹과 의 1 : 1 관계를 서브 테이블로 잘라야합니다. 메인 테이블.

Answer 4

HBase (http://hadoop.apache.org/hbase/)를 살펴보세요. Google의 큰 테이블을 모델로 한 분산 된 열 기반 저장소입니다.

Answer 5

아무렇지도 않게 ... 100 열에 5,300 만 번 저장된 데이터가 실제로 normalized일까요?

그렇지 않으면 정말로이 작업을 시작해야합니다. 아마도 행 수가 많이 줄어들 수 있습니다 (예를 들어 1000과 1000, 53 개의 레코드로 세 개의 테이블로 나눌 수 있습니다). 이론적으로 볼 수있는 숫자가 얼마나 작은지를 보여주기 쉽습니다. 있다). 아마도 정규화 후 5300만의 레코드 테이블이있을 것입니다.하지만 이것은 작게 유지 될 수 있습니다. 외장 키로 만 구성 될 수도 있습니다. 일반적으로 한 번에 모든 데이터가 필요하지는 않습니다. 이상적으로는 수천 개의 레코드가있는 테이블에 대해 많은 쿼리를 수행 할 수 있습니다.

정상화하면 조인을 너무 두려워하지 마십시오. 결국, 어쨌든 더 빨라질 것입니다. 실제로 예외가 있습니다.