具有“开放式架构”的数据库-好还是坏主意？

Question

Reddit的联合创始人就他们在扩展到数百万用户时遇到的问题做了介绍。摘要可用here。

令我惊讶的是第3点：

相反，他们保留了事物表和数据表。 Reddit中的所有内容都是事物：用户，链接，评论，subreddit，奖项等。事物具有共同的属性，例如上下投票，类型和创建日期。数据表具有三列：事物ID，键，值。每个属性都有一行。标题，URL，作者，垃圾邮件票等都有一行。当他们添加新功能时，他们不必再担心数据库了。他们不必为新事物添加新表，也不必担心升级。

对我来说，这似乎是一个可怕的主意，但对于Reddit来说似乎已经解决了。总的来说，这是个好主意吗？还是Reddit的特殊之处恰好为他们解决了？

Answer 1

这是实体属性值的EAV数据模型。它有其用途。一个典型的例子是患者测试数据，由于可以运行成千上万的测试，因此自然稀疏，但通常只有少数几个患者可以使用。具有成千上万列的表是很愚蠢的，但是具有EAV的表很有意义。

Answer 2

大多数真正的大型网站最终都在数据库方面使用了某种难以置信的简单方式。这具有快速且可扩展的优点。它的缺点是，您要使数据库自动（通过触发器等）强制执行的所有关系都改为[[需要强制在客户端代码中强制执行。保持一致性是一件令人头疼的事，并且至少在短期内，几乎总是有一定几率使您的数据不一致。

对于社交网站，这是一个值得折衷的选择。大多数时候大部分正确的数据就足够了（例如，谁真的在乎您收到的商品的上投票数是否真的比发送商品时早了20毫秒），并保持合理的成本，同时进行扩展以支持庞大的数量用户很重要。

Answer 3

[我注意到，他们没有提及有关根据该数据创建报告的难易程度。当在狭窄的环境中使用时，EAV可能是有益的。作为大多数系统的核心部分，当您点击报表时，它将成为一场噩梦。 EAV的问题在于，大多数好处是在项目一开始就完成的，而大部分痛苦则在后期的分析和报告中，尤其是由于严重缺乏数据完整性。对我来说“不必担心外键”听起来像是一排孤立行的噩梦。加上对所有内容都使用替代键，您将有一个混乱的混乱局面，通常以完整的重写结尾]

Answer 4

我们不久前曾在一个类似的问题中工作，起初我可以说这并不容易，但有趣的是，在您适应了这一点之后，它有自己的好处，就像在开发表时开发另一个数据库一样。 ，在某些方面，这是一项过大的任务，但是当您通过这些级别时，它为您提供了许多功能，基本上在一点之后，我们没有创建任何新表，我们只是为所有内容创建了动态表单，甚至为我们自己的编程任务。至于性能，系统没有得到百万行的比较，但是对于日常使用，我从未发现任何差异。我想分享一些问题。

我们没有删除任何行，我们只是隐藏它们并设置一个标志，并且每晚（每周）服务会清理物理行
1. [孤行，我们基本上不关心清理孩子，我们只在父亲上设置“ IsDeleted”，而夜间服务将清理孤儿或不再需要的每一行。

3。您应保持索引为最新，但应尽可能不建立索引（再次夜间服务，应保持索引为最新）

我们提前准备了报告数据（AOT），这意味着我们落后于实际数据了：)）

我们尽力不让用户跳进来，以根据用户需求计算一些值。如果我们准备了它，则可以使用它；如果没有，则不能使用

最后，这种方法有很多独特的挑战，您应该找到一种解决方法，这些都是您在日常工作中从未遇到过的问题，但是毕竟，您将获得更多的灵活性，可以花很多钱。