我正在构建一个系统，该系统可能需要支持 500 多个并发用户，每个用户每分钟进行数十次查询（选择、插入和更新）。基于这些要求和具有数百万行的表，我怀疑将来需要使用数据库复制来减少一些查询负载。
过去没有使用过复制，我想知道在架构设计中是否需要考虑什么？
例如，我曾经被告知必须使用 GUID 作为主键来启用复制。这是真的吗？
对于要复制的数据库，有哪些特殊的数据库设计注意事项或最佳实践？
由于项目的时间限制，我不想在可能不需要复制时浪费任何时间。 （我目前有足够明确的问题需要克服，而不必担心必须解决可能的问题。）但是，当/如果将来需要复制时，我不希望进行可能可避免的架构更改。
也将不胜感激有关此主题的任何其他建议，包括学习实施复制的好地方。
【问题讨论】：
标签： sql-server database-design replication
虽然每一行都必须有一个 rowguid 列，但您不需要为您的主键使用 Guid。实际上，您甚至不需要拥有主键（尽管您会因未能创建主键而被石头砸死）。即使您将主键定义为 guid，不将其设置为 rowguid 列也会导致复制服务为您创建一个额外的列。你绝对可以做到这一点，这不是一个坏主意，但这绝不是必要的，也不是特别有利的。
这里有一些提示：
【讨论】：
您可能希望将 GUID 用于主键 - 在复制的系统中，行在整个拓扑中必须是唯一的，而 GUID PK 是实现此目的的一种方法。
【讨论】：
我想说您真正的问题不是如何处理复制，而是如何处理横向扩展，或者至少横向扩展以实现可查询性。虽然这个难题有多种答案，但有一个答案很突出：不使用复制。
复制的问题，特别是合并复制的问题是，写入在复制中成倍增加。假设您有一个每秒处理 100 次查询（90 次读取和 10 次写入）负载的系统。您想向外扩展并选择复制。现在您有 2 个系统，每个系统处理 50 个查询、45 个读取和 5 个写入每个。现在必须复制这些写入，因此实际写入次数不是 5+5，而是 5+5（原始写入），然后是另外 5+5（副本写入），因此您有 90 次读取和 20 次写入。因此，虽然每个系统的负载减少了，但写入和读取的比率却增加了。这不仅改变了 IO 模式，而且最重要的是它改变了负载的并发模式。添加第三个系统，您将有 90 次读取和 30 次写入，依此类推。很快，您的写入量将超过读取量，并且复制更新延迟加上并发问题和合并冲突将使您的项目脱轨。它的要点是“很快”比您预期的要快得多。很快就足以证明考虑扩大规模是合理的，因为无论如何你最多只能从 6-8 个同行中扩大规模，使用扩大规模增加 6-8 倍的容量会更快、更简单，甚至可能更便宜开始吧。
请记住，所有这些都只是纯粹的理论数字。实际上，复制基础设施不是免费的，它会在系统上增加自己的负载。需要跟踪写入，必须读取更改，必须存在分发器来存储更改直到分发给订阅者，然后必须写入更改并调解可能的冲突。这就是为什么我看到很少有部署可以声称使用基于复制的横向扩展策略取得成功的原因。
另一种方法是仅横向扩展读取，并且复制确实工作，通常使用事务复制，但日志传送或使用数据库快照进行镜像也是如此。
真正的替代方案是分区（即分片）。请求在应用程序中被路由到适当的分区并登陆包含适当数据的服务器。一个分区上需要反映在另一个分区上的更改是通过异步（通常基于消息传递）方式传送的。数据只能在分区内连接。有关我正在谈论的内容的更详细讨论，请阅读how MySpace does it。不用说，这样的策略对应用程序设计有重大影响，不能简单地粘在 v1 之后。
【讨论】：