帮助选择要选择的 SQL Server 2008 横向扩展解决方案（复制，...）
我目前正在穿越 SQL Server 横向扩展技术的丛林，例如复制、日志传送、镜像...我的选择受到以下限制：
- 我希望只读负载分布在主服务器和辅助服务器上（镜像、订阅者）服务器
- 写负载可以直接发送到主服务器
- 该解决方案应该几乎无需维护。架构更改应该只复制到辅助服务器（注意：复制看起来有一些严重的限制）
- 书面数据应该可以在辅助服务器上非常快速地访问（不到 1 秒，但最好是即时访问）
- 在服务器故障时，我可以轻松忍受长达一小时的数据丢失。我更关心简单的可扩展性
以下是我可以选择的一些选项： http: //msdn.microsoft.com/en-us/library/bb510414.aspx。有什么经验可以分享吗？
I am currently crossing the jungle of SQL Server scale-out technologies like replication, log-shipping, mirroring... I have the following constraints on my choice:
- I want the read-only load to be spread accross the primary and the secondary (mirror, subscriber) server
- Write load can be sent directly to the primary server
- The solution should be nearly maintainance free. Schema changes should just replicate to the secondary server (attention: replication has some serious constraints here as it seems)
- Written data should be accessible very quickly (in under 1s, but better would be instantaneously) on the secondary server
- On server failure I can tollerate up to one hour of data loss easily. I am more concerned with easy scalability
Here are some options for what I could pick: http://msdn.microsoft.com/en-us/library/bb510414.aspx. Any experience you could share?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这些都是高可用性解决方案，而不是横向扩展。 SQL Server 没有简单的横向扩展解决方案，任何其他（关系）数据库也没有。使用主从复制可以在主写入扩展可能性允许的范围内进行扩展。使用主主复制会多路复用写入并带来一致性问题。几乎所有尝试过基于复制的解决方案的大规模部署都不得不放弃它。
一种替代方法是根据通过消息传递进行通信的独立数据域来重新考虑您的应用程序，即 MySpace横向扩展。
另一种选择是放弃一些约束（写入一致性、读取一致性、可恢复性、类型化模式、引用完整性），并选择一旦摆脱这些约束就可以自由扩展的 nosql 引擎（Cassandra、HBase、MongoDB）。
最终，横向扩展是一项基本要求，您必须围绕解决方案设计应用程序，并接受横向扩展带来的所有（严格）限制。请注意，尽管所有关系引擎都可以长方式纵向扩展，并且全球范围内需要横向扩展超出数据库可扩展范围的部署数量屈指可数。
Those are all High Availability solutions, not scale-out. SQL Server has no easy scale-out solution, nor do any other (relational) databases. Using master-slaves replication scales as much as allowed by the master write scale-up possibility. Using master-master replication multiplexes the writes and comes with consistency issues. Almost all large-scale deployments that had attempted replication based solutions had to abandon it.
One alternative is to rethink your application in terms of independent data-fiefdoms communicating by messaging, the way MySpace scales out.
Another alternative is to abandon some constraints (write consistency, read consistency, recoverability, typed schemas, referential integrity) and choose a nosql engine that can scale out freely once liberated of these constraints (Cassandra, HBase, MongoDB).
Ultimately scale-out is such a fundamental requirement that you must design your application around the solution and embrace all the (severe) restrictions imposed by scale out. Note though that all relational engines can scale -up a long way and the worldwide number of deployments that require scale out beyond what a a database can scale-up can be counted on your fingers.