5+ 열 기본 키가 큰 (1 억 +) 테이블에 적합하지 않습니까?

나는 실제 DB 문제에 대해 읽었고 한 프로젝트에는 1 억 개의 행과 테이블이 기본으로 5 개의 열이 있습니다. 나는 이것이 나쁘다고 생각하지만 아무도 왜 정확한지 말해 줄 수 있습니까?

이 테이블은 일종의 마이크로 롤업 / 집계 테이블이므로 5 개의 열은 (day, market_id, product_id ...)와 같습니다. 처음에는 5 열 기본 키가 이상적이지 않다고 생각했지만 더 많이 생각할수록 실제로 나쁜 이유를 알 수 없었습니다.

이것은 회사 엔지니어의 절반과 늦은 밤에 논의되었습니다. 누군가 이것이 이것이 나쁜 디자인이라고 언급했고, 한 수석 엔지니어가 동의했지만 아무도 왜 그 이유에 대해 뛰어 들지 않았습니다. 따라서 나 자신을 위해 그 문제를 연구하려고 노력하십시오!

매우 복잡한 기본 키에는 성능 문제가 있습니다. 그리고 그것은 단순한 기본 키뿐만 아니라 복제를 방어하지 않을 수 있습니다.

그러나 6 개 정도의 구성 요소로 구성된 기본 키가있는 테이블을 자주 생성하는 디자인 패턴이 하나 있습니다. 스타 스키마 팩트 테이블입니다. 스타 스키마의 팩트 테이블에 6 개의 차원이있는 경우 기본 키에는 6 개의 구성 요소가 있습니다. 필자는 기본 키가 선언되지 않은 팩트 테이블을 본 적이 없으며 ETL 프로세스를 여전히 신중하게 작성해야하지만 오버 헤드의 가치가 있다고 생각합니다.

일부보고 데이터베이스는 명시 적으로 디자인되지 않았더라도 스타 스키마의 패턴을 모방합니다.

1 억 개 이상의 행이 사실 테이블, 특히 오늘날의 빅 데이터에서 지나치게 크지 않습니다.

문제의 테이블은 롤업 / 집계 테이블입니다.

그렇다면 그것은 옳을뿐만 아니라 "맞습니다".

그리고로 시작하기 때문에 Summary 테이블처럼 냄새가납니다 day.

보조 인덱스가 있습니까? InnoDB를 사용하는 경우 나머지 PRIMARY KEY 열은 보조 인덱스의 끝에 고정됩니다. 다시 말하지만, 이것이 반드시 문제는 아닙니다.

100M 개의 행은 롤업에 적합합니다. 테이블이 너무 세밀한 것처럼 들립니다. 즉, (date, a, b, c, d) 대신 (date, a, b, c), (date, b, c, d), (date, c, d, a), (날짜, d, a, b) (또는 일부 적합한 조합). 그렇게하면 각 행이 10M 행에 불과하므로 보고서의 유연성은 거의 유지하면서 보고서를 더 빠르게 만들 수 있습니다.

또는 (week, a, b, c, d)로 전환하여 1,400 만 행으로 이어질 수 있습니다. (아마도 더)

정리를 촉진하기 위해 PARTITION 사용 --- 고속 수집 --- 데이터웨어 하우스 팁 --- 요약 테이블 . 이것들은 여러 DW 프로젝트에서 개발 한 많은 기술을 요약합니다. 추론 할 수 있듯이 각 프로젝트는 다릅니다. 내 경험상 요약표의 '일반적인'수는 3-7입니다. 요약 대상은 10 개의 사실 행-> 1 개의 요약 행입니다. ( '중앙값'일 수 있습니다.) 드문 경우에 요약표를 요약했습니다. 또 다른 드문 경우에 나는 요약표를 효과적으로 적용했다. 일반적으로 요약 테이블은 충분히 작아서 UI에서 직접 액세스하기에 충분히 빠릅니다.

글쎄, 실제로 5+ 열을 가진 PK를 갖는 것이 그 자체로 반드시 나쁘지는 않습니다.

PK가 클러스터형 인덱스이면 행 식별자로 계산되어 NC 인덱스의 각 행에 추가되므로 PK도 나빠집니다. 이것은 필요한 공간을 크게 증가시킵니다.

현재 테이블과 참조 테이블 모두에 5 개 이상의 열에 대한 데이터가 있어야하기 때문에 다른 FK에서 실제로 PK를 사용하면 나빠질 수 있습니다. 다시 한 번 스토리지를 많이 늘릴 것입니다!

5 개 이상의 열을 포함하는 더 큰 PK- 키는 더 많은 공간을 차지하므로 더 적은 공간을 차지하므로 PK를 인덱스로 사용하면 성능 측면에서 좋지 않습니다. 페이지에 들어가므로 색인을 분석하려면 더 많은 페이지를 읽어야합니다.

즉, 사실 테이블과 같이 실제로 실제로 그렇게하는 좋은 이유가있을 수 있습니다. 따라서 가장 좋은 대답은 실제로 대부분의 경우와 같습니다.

데니스 감사합니다

약 15 년 이상 나는 그런 열쇠가 필요하지 않고 때때로 보았으며 문제를 일으킬뿐이었습니다. 많은 문제가 있습니다. 우선 모든 기본 키는 데이터 무결성을 유지하기위한 것이며 구문 적이어야합니다. 그들은 현실 세계에 구속력이 없어야합니다. 왜 ? 실제 환경이 변경되면 기본 키가 사라지고 키와 모든 관련 정보를 업데이트해야합니다.

한 필드 대신에 다른 테이블 / 데이터베이스 / 서비스에서이 커를 기억해야한다고 상상해보십시오. 여러 필드를 복사하는 것을 잊어 버릴 수 있습니다. 대신 sysntetic 기본 키는 하나의 데이터 일 뿐이며 제공해야합니다. 나는 인덱스의 불일치에 대해서는 언급하지 않았는데, 이는 토론을위한 또 다른 큰 주제가있을 수 있습니다.

짧은 요약, 구문 기본 키 (자동 증가, guid, ..)는 유지 관리, 복사, ...

따라서 구문 기본 키와 언급 한 5 열의 다른 키를 고려합니다.

마지막으로 테이블이 집계되어 있고 누군가가 키로 행을 참조 할 필요가 없다면 (세계 변화, 적어도 나를 위해 영구적으로 바뀔 것이라는 점을 믿으십시오) 아마도 테이블을 그대로 둡니다 (기본 키가 5 행)이지만 이전에 사용했던 경우 항상 많은 문제가 발생합니다. 그래서 나는 당신에게 말했다.