|
我们的数据库体系结构由两个Sql Server 2005服务器组成,每个服务器都有一个相同数据库结构的实例：一个用于所有读取,一个用于所有写入.我们使用事务复制来使读取数据库保持最新.
这两台服务器确实非常高规格(写入服务器有32GB的RAM),并通过光纤网络连接.
在决定使用这种体系结构时,我们认为要复制到读取服务器的数据的延迟大约为几毫秒(显然取决于负载).在实践中,即使是最简单的情况,我们也会看到大约2-5秒的延迟,这是不能令人满意的.在最简单的情况下,我的意思是更新write db上的单个表中的单个行中的单个值,并查看在read数据库中观察新值所需的时间.
我们应该考虑哪些因素来实现低于1秒的延迟？这甚至可以实现吗？
或者,我们应该考虑不同的复制模式吗？数据和日志文件位置的最佳做法是什么？
编辑
感谢大家的建议和见解 – 我相信我们所经历的潜伏期是正常的;我们的数据库托管公司错误地指导了我们期望的延迟时间！
我们正在使用this MSDN article底部附近描述的技术(在“缩放数据库”标题下),我们未能正确处理此警告：
The consequence of creating such specialized databases is latency: a write is now going to take time to be distributed to the reader databases. But if you can deal with the latency,the scaling potential is huge.
我们现在正在考虑实现对我们的缓存机制的更改,当一个数据项被认为是“不稳定的”时,该机制会强制执行来自write数据库的读取.
解决方法
不会.即使使用快速硬件,使用SQL Server事务复制也不可能实现低于1秒的延迟时间.
如果你可以获得1到5秒的延迟,那么你表现得很好.
从here开始：
Using transactional replication,it is
possible for a Subscriber to be a few
seconds behind the Publisher. With a
latency of only a few seconds,the
Subscriber can easily be used as a
reporting server,offloading expensive
user queries and reporting from the
Publisher to the Subscriber.
In the following scenario (using the Customer table shown later in this section) the Subscriber was only four seconds behind the Publisher. Even more impressive,60 percent of the time it had a latency of two seconds or less. The time is measured from when the record was inserted or updated at the Publisher until it was actually written to the subscribing database.
（编辑：李大同）
【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!
|
