sql-server-2005 - 是否可以通过事务复制获得低于 1 秒的延迟？

Question

我们的数据库架构由两台 Sql Server 2005 服务器组成，每台服务器都有一个相同数据库结构的实例:一台用于所有读取，一台用于所有写入。我们使用事务复制来保持读取数据库是最新的。

这两台服务器的规范确实非常高(写入服务器有 32GB 的 RAM)，并通过光纤网络连接。

在决定这种架构时，我们相信数据复制到读取服务器的延迟将在几毫秒的数量级(显然取决于负载)。在实践中，即使是最简单的情况，我们也会看到大约 2-5 秒的延迟，这并不令人满意。在最简单的情况下，我的意思是更新写入数据库上单个表中单个行中的单个值，并查看在读取数据库中观察新值需要多长时间。

我们应该考虑哪些因素来实现低于 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.

我们现在正在考虑对我们的缓存机制进行更改，当数据项被认为是“ volatile ”时，强制从写入数据库读取。

Answer 1

不。即使使用快速硬件，您也极不可能通过 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.