Why the Generalized Data Model Is Not Yet Another Bad CaRMa: Analysis of Four Pitfalls and Measurements on a Live Database

Habr上の記事では、Scott Rosenberg著『Dreaming in Code』（Bad CaRMaという名称で言及）に登場するCRM Visionを例に、汎化データモデルの問題が考察されています。Visionは型指定のない240以上のカラムを持つ1つのテーブルDATAを使用しており、単純な検索に6～10回の自己結合（self-join）が必要で、パフォーマンスが低下し（50GBのデータに対して250GBのインデックスが必要）、1000万ドルの損失を招きました。著者は、自社のモデル（id、up、t、valからなるクワルテット）が、3つのレイヤー（型システム：コアの基本型、ユーザー定義の用語型、真のリレーション；コントローラ：WITH RECURSIVEを用いたSQLを自動生成；インデックス：（t, val）と（up, t）に対する複合カバリングインデックス）により、これらの過ちを繰り返さないと主張しています。Postgres上で133,731クワルテット（168MBのデータ、40MBのインデックス）をベースに、型の完全一致は0.08ミリ秒、レコードの全属性収集は0.16ミリ秒、リレーションのトラバースは0.30ミリ秒で実行されます。対照的に、tとupを指定せずにANNインデックスに対してクエリを実行した場合、Seq Scanで4秒かかりましたが、部分インデックスを追加した後は0.09ミリ秒になりました。著者はまた、正しいEAVの例としてDatomicを挙げていますが、ニッチなものであると指摘しています。結論として、汎化は罪ではないが、型システム、コントローラ、EXPLAINで検証された実際のインデックスが必要であると述べています。