Why the Generalized Data Model Is Not Yet Another Bad CaRMa: Analysis of Four Pitfalls and Measurements on a Live Database
The author compares their generalized data model (a quartet of id, up, t, val) with the failed CRM Vision from the book 'Dreaming in Code,' explaining why their approach does not repeat the mistakes of Bad CaRMa. The model implements a type system, a request controller, and indexes, confirmed by measurements: record collection takes 0.16 ms, and link traversal takes 0.30 ms. A concrete example is also shown: without an index, a query took 4 seconds; after adding one, it took 0.09 ms.
Habr의 기사에서는 Скотт Розенберг의 책 'Dreaming in Code'에 나오는 CRM Vision(별칭 Bad CaRMa)을 예로 들어 일반화된 데이터 모델의 문제를 다루고 있습니다. Vision은 240개 이상의 타입 없는 컬럼을 가진 하나의 DATA 테이블을 사용했으며, 이로 인해 간단한 검색에도 6~10개의 self-join이 필요하고, 성능 저하(50GB 데이터에 250GB 인덱스 필요)와 1,000만 달러의 손실이 발생했습니다. 저자는 자신들의 모델(id, up, t, val로 구성된 4중항)이 세 가지 계층 덕분에 이러한 실수를 반복하지 않는다고 주장합니다: 타입 시스템(코어의 기본 타입, 사용자 정의 타입-용어, 실제 관계), WITH RECURSIVE를 사용해 SQL을 자동 생성하는 컨트롤러, 그리고 인덱스((t, val) 및 (up, t)에 대한 복합 커버링 인덱스). Postgres에서 133,731개의 4중항(168MB 데이터, 40MB 인덱스)을 기반으로, 타입별 정확한 일치 항목 검색은 0.08ms, 레코드의 모든 속성 수집은 0.16ms, 관계 탐색은 0.30ms에 완료됩니다. 대조적으로, t와 up을 지정하지 않은 ANN 인덱스에 대한 쿼리는 Seq Scan으로 4초가 걸렸지만, 부분 인덱스를 추가한 후 0.09ms로 단축되었습니다. 저자는 또한 올바른 EAV(Entity-Attribute-Value)의 예로 Datomic을 언급하지만, 이것이 틈새 시장에 국한되어 있다고 지적합니다. 결론: 타입 시스템, 컨트롤러, EXPLAIN으로 검증된 실제 인덱스가 있다면 일반화는 죄가 아니다.
출처: Habr — хаб ИИ —
원문