Reddit 的联合创始人介绍了他们在扩展到数百万用户时遇到的问题。此处提供了摘要。
令我惊讶的是第 3 点：
相反，他们保留了一个事物表和一个数据表。Reddit 中的一切都是事物：用户、链接、评论、subreddits、奖项等。事物保持共同的属性，如赞成/反对票、类型和创建日期。Data 表包含三列：事物 ID、键、值。每个属性都有一行。标题、网址、作者、垃圾邮件投票等有一行。当他们添加新功能时，他们不必再担心数据库了。他们不必为新事物添加新表或担心升级。
这对我来说似乎是一个糟糕的想法，但它似乎对 Reddit 来说已经奏效了。不过，总的来说这是个好主意吗？或者是 Reddit 的一个特性恰好为他们解决了问题？
这是一个称为EAV的数据模型，用于entity-attribute-value。它有它的用途。一个典型的例子是病人测试数据，它自然是稀疏的，因为可能会运行数十万个测试，但通常只有少数几个可供病人使用。具有数十万列的表是愚蠢的，但是具有 EAV 的表很有意义。
大多数真正的大型网站最终都在数据库方面使用了某种令人难以置信的简单方法。这具有快速且可扩展的优点。它的缺点是您需要让数据库自动执行的所有关系（通过触发器等）您需要在您的客户端代码中强制执行。保持一致性是一件令人头疼的事情，而且至少在短时间内，您的数据几乎总是存在不一致的可能性。
对于一个社交网站来说，这是一个值得妥协的选择。大多数情况下大部分正确的数据是足够的（例如，谁真正关心您收到的项目的赞成票数量在发送时是否真的过时了 20 毫秒），并且在扩展以支持大量数据的同时保持成本合理用户很重要。
我注意到他们没有提及根据这些数据创建报告的难易程度。当在少数情况下使用时，EAV 可能是有益的。作为大多数系统的核心部分，当您点击报告时，它将成为一场噩梦。EAV 的问题在于，大部分好处是在项目开始时，而大部分痛苦是在分析和报告的后期，特别是由于严重缺乏数据完整性。“不必担心外键”对我来说听起来像是孤儿行的噩梦。为所有内容添加代理键的使用，您将陷入纠结的泥潭，通常以完全重写而告终
不久前我们也遇到过类似的问题，起初我可以说这并不容易和有趣，但是在你习惯了它之后，它有它自己的好处，就像用你的表开发另一个数据库一样，在在某些领域，这是一项矫枉过正的任务，但是当您通过这些级别时，它为您提供了很多功能，基本上在某一点之后，我们没有创建任何新表，我们只是为所有内容创建了动态表单，即使是我们自己的编程任务。至于性能，系统并没有获得数百万行进行公平比较，但对于日常使用，我从未注意到任何差异。我想分享一些问题。
3.你应该保持你的索引是最新的，但你应该尽可能地跳过构建它们（再次夜间服务保持索引是最新的）
我们努力不跳入行的海洋以根据用户需求计算一些值。如果我们准备好了，你可以使用它，如果没有，那么你不能
最后，这种方法有很多独特的挑战，你应该找到解决方法，在日常工作中从未遇到过的问题，但在所有这些之后，你可以获得更多可以使用的灵活性。