我很好奇如何扩展巨大的数据库，例如 facebook DB。我所知道的是，应用程序以某种方式部署到多个数据中心，这意味着每个数据中心中的每个“节点”都应该能够快速访问该大数据库。
首先，我无法想象他们如何部署，但这是另一个问题（我猜？）。
因此，如果我没记错的话，问题是这么多独立的节点如何访问庞大的数据库，并且一切都一致、稳定、性能良好且可扩展？
小智 4
免责声明：我对这个主题的了解并不像我希望的那样，请随意编辑我的错误；我自愿采取了一些捷径，以避免从头开始重写维基百科
好吧，让我们缩小一点：您是一名成功的应用程序开发者，每天必须面对数千名用户。
这是你进入大男孩世界的第一步，也是最重要的问题：
你在用你的数据做什么？
从这个问题中，你的整个架构将被选择，它可能会决定你的事情进展得有多顺利（还记得pokemonGo 的推出吗？在这一点上它是一个很大的失败）。
- 我们只有几次写入（理解要存储的输入数据），但有大量读取。
然后，您需要一个/小型主数据库集群（大型 R-DBMS或“任何”分布式No S ql）和许多副本作为从属（只读）或全球缓存内容交付网络 - CDN。这非常适合像新闻这样的网站（评论部分在另一个服务上，请参阅下文）。
- 我们有更经典的读/写比例
你排除了第一个选项。缓存会有所帮助，但还不够，而且 R-DBMS 开始变得非常昂贵，因为您需要一个具有分布式写入功能的大型集群（而不是单个主服务器）。您很可能需要一些NoSQL解决方案。您应该仍然能够使用大多数经典的，因为这就是创建它们的原因。您将拥有一个完整主副本池或一个强大的主副本池和一个从属完整副本池。
- 你对你的“读多于写”的说法很有趣，我即将让 Twitter 破产，并且写的几乎比读的多......
好吧，真正的问题来了，这个问题使 R-DBMS 无法实现，并给一群工程师带来了噩梦......“我们如何处理每微秒一次的写入，而对于 Katy Perry 的读取可能为 0 1亿粉丝？”
答案是“并不像我们希望的那么容易”。更严重的是，诀窍是“分布式数据”。你找到了一种方法来区分你的数据，并在每个存储实例中只存储其中的一小部分（请注意，我什至没有真正在这里使用“DB”，这是 NoSql 的阴暗面，它几乎可以生存在它自己的，只是面对这个看起来像“文件系统”的世界。所以现在你有一个规则将你的数据存储在不同的小实例上。很好。有趣的部分是“我们如何取回它们？”这是一件大事。写入很“容易”，但读取意味着您必须使某些服务器成为“事物所在位置的前索引”，即通往正确存储空间的路由网关，但知道数据在哪里并不是最重要的。唯一需要担心的事情。
Katy Perry 回来了，隐藏您的数据库，隐藏您的服务器......您现在可以在整个数据中心保存和检索数据。关键是，现在每一行都被存储为“正常使用”，有 2 个冗余节点，如果这一行像病毒一样传播，那么这还不够。在最终使用烤面包机而不是服务器之前，您必须使用动态缓存和/或节点复制。你问“什么”？好吧，与Ant 算法一样，您必须对数据施加一些权重：
- 谁在发帖？
- 凯蒂·佩里
好吧，至少在接下来的几周内，我们可能会将它们存储在 3 个以上的节点中......
到底什么鬼，这条 2013 年的 D. Trump 推文今天疯传了
即使作者和日期似乎并没有证明比默认分配更多的节点分配是合理的（我刚刚完全政治化了吗？我的错......），流行度将触发缓存机制并临时传播到其他节点以匹配要求。
对于这个解决方案，我一步步解释了它是如何工作的，但是具有良好配置的 DBMS 会为您做到这一点。
正如您所看到的，即使我们只是快速了解一下如何处理“大”，也有很多话要说。请记住，大多数（全部？）这些解决方案都是根据它们解决的问题开发的：每个大公司都根据自己的用例创建自己的 DBMS。NoSQL 产品只是这些公司为解决定制解决方案的需求而开发的产品的公开版本。