Reddit の共同創設者は、何百万ものユーザーにスケーリングする際に抱えていた問題についてプレゼンテーションを行いました。概要はこちらから入手できます。
私が驚いたのはポイント3です。
代わりに、Thing Table と Data Table を保持します。ユーザー、リンク、コメント、サブレディット、賞など、Reddit のすべてが Thing です。Thing は、賛成/反対の投票、タイプ、作成日などの共通の属性を保持します。Data テーブルには、Thing id、key、value の 3 つの列があります。属性ごとに行があります。タイトル、URL、作成者、スパム投票などの行があります。新しい機能を追加するとき、データベースについて心配する必要はもうありませんでした。新しいもののために新しいテーブルを追加したり、アップグレードについて心配したりする必要はありませんでした。
これは私にはひどいアイデアのように思えますが、Reddit ではうまくいったようです。しかし、それは一般的に良い考えですか？それとも、たまたまうまくいったのは Reddit の特性ですか?
これは、 entity-attribute-value のEAVとして知られるデータ モデルです。それには用途があります。典型的な例は、患者の検査データです。これは、実行される可能性のある検査が数十万あるため、自然にまばらですが、通常、患者にはほんの一握りしか存在しません。数十万の列を持つテーブルはばかげていますが、EAV を持つテーブルは理にかなっています。
非常に大きな Web サイトのほとんどは、データベース側で信じられないほど単純なものを使用することになります。これには、高速でスケーラブルであるという利点があります。データベースが自動的に (トリガーなどを介して) 強制するすべての関係を、代わりにクライアント コードで強制する必要があるという欠点があります。一貫性を維持することは骨の折れる作業であり、少なくとも短期間、データに一貫性がなくなる可能性はほぼ常にあります。
ソーシャル ネットワーキング サイトの場合、妥協する価値はあります。ほとんどの場合、ほとんど正しいデータで十分です (たとえば、アイテムに対して受け取った賛成票の数が送信時に実際に 20 ミリ秒遅れているかどうかなど、誰が本当に気にするでしょうか)。ユーザーは非常に重要です。
私は、彼らがそのデータに対するレポートを作成することの容易さや難しさについて何も言及していないことに気づきました。狭い状況で使用する場合、EAVは有益な場合があります。ほとんどのシステムの中心的な部分として、レポートをヒットすると悪夢になります。EAVの問題は、ほとんどのメリットがプロジェクトの開始時にあり、特にデータの整合性が大幅に不足しているため、ほとんどの問題が分析とレポートの後半にあることです。「外部キーについて心配する必要がない」というのは、孤立した行の悪夢のように聞こえます。すべてに代理キーの使用を追加すると、通常は完全な書き換えで終わる絡み合ったモラスがあります