如何为可伸缩性创建数据库？我在http://www.slideshare.net/vishnu/livejournals-backend-a-history-of-scaling的中间，我无法读取ATM并需要离开。但我想了解更多有关创建可扩展的数据库的信息。它提到并在我脑海中出现的某些事情是
等
答案 0 :(得分：6)
要创建一个可以很好地扩展99.9％用例的数据库，请不要担心任何这些问题。相反，设计一个正确规范化的模式;使用主要，外键和其他约束来确保完整性;索引表很好。研究您的DBMS供应商关于性能和可伸缩性主题的建议，例如分区，不同的表和索引结构等，并使用最适合您的情况（基准选项来证明它们可以提高可伸缩性）。
当然，如果您在谷歌，Ebay或亚马逊工作，那么您可能会陷入0.1％的阵营，需要扔掉规则手册并完成您正在阅读的所有这些疯狂的东西。但是我猜你没有，对吧？
答案 1 :(得分：2)
RDBMS非常适合保留一致性和事务性数据，但它们需要大量专家计划才能扩展到每秒数百个事务处理。我会构建一个nosql云来将从RDBMS构建的文档转储到。
因此，您将RDBMS用于原始数据，将nosql数据库用于RDBMS上的视图
答案 2 :(得分：1)
为了添加Tony的建议，我想说将数据库正确划分为目录（物理数据库服务器内虚拟数据库命名空间的SQL Server术语），并尝试最小化目录之间的依赖关系 - 即查询级依赖。如果有依赖，请确保它们是只读的。
这将允许您在需要时将目录移动到不同的物理服务器。对只读的要求是，如果您将某个目录从某个服务器上移走，该服务器对另一个目录（在同一物理服务器上）具有只读依赖性，那么您可以继续复制有问题的数据要移动某个目录的新物理服务器上的只读目录。
存在只读要求，因为复制通常是单向功能。这意味着您只能将一台服务器作为写主机，其他服务器只接收数据以便在本地读取数据。
关于复制的建议对于最坏的情况非常有用，并且仅用于执行一次。它不是ad-hoc数据库增长的解决方案。如果你不得不以这种方式成长，你应该远离RDBMS。使用正确的数据模型，可以实现目录的无复制移动
答案 3 :(得分：1)
当一台服务器忙（IO或CPU绑定）并且需要两台服务器写入时会发生什么？
如果您正在进行分布式事务，那么您就遇到了麻烦，因此您必须提前计划以确保分布式事务目标服务器上的负载均匀。
我创建多个数据库吗？有用户的clusterId吗？
这是一个非常好的解决方案：P。您必须使共享数据数据模型正确，这样才不会在共享目录中形成瓶颈
将用户迁移到另一个群集时会出现问题吗？
不，胜利的分布式交易。你需要一个kickass程序员来确保事情正确发生。
我可能会对此进行编码，因此群集A中的数据库A中的用户ABC和群集B中数据库B中的DEF具有相同的主键吗？
不，在主RDBMS / LDAP服务器上分配主键。您不希望这种主键冲突。您选择的方法取决于正确完成此操作 - 您需要全局唯一的用户ID。在这种情况下，您将拥有共享数据，如果您没有GU-PK，您将如何将用户与共享数据联系起来？