mro*_*man 1 performance transaction acid
假设每秒有大约 1k 个请求需要插入。
现在，互联网上对此有很多答案……但在这种特定情况下，它们在技术上是错误的。是的，几乎任何 RDBMS 都可以在标准硬件上每秒处理 1k 次插入，但如果且仅当您放弃 ACID 保证时。令人惊讶的是，互联网上有多少可怕的答案。例如“您可以随时扩展 CPU 和 RAM”，这应该可以每秒提供更多插入次数，但这不是它的工作原理。限制因素是磁盘速度或更精确：您实际上可以将多少事务刷新/同步到磁盘。这是棘手的一点。
在体面的“商品硬件”上（除非您投资于高性能 SSD），这就是您可以期待的：
这是您可以在保持 ACID 保证的同时插入的速率。这实质上意味着，如果您有一个每秒 100 个帖子的论坛……您无法通过这样的设置来处理它。
读取请求不是问题。您每秒可以有数千个读取请求，但写入请求通常小于每秒 100 个。
因此，这个问题专门针对如何在保持 ACID 保证的同时处理每秒 1k 次插入 - 假设单个节点每秒可以处理大约 80 个事务。
我可以看到这种工作的一种方法是，如果您在应用程序逻辑中的某处缓冲插入并将它们作为更大的事务提交到数据库（同时让客户端等待事务结束），如果您只需要单个插入，这应该可以正常工作，尽管它很复杂应用逻辑相当多。
我的简单 RAID 10 阵列在具有 300GB SAS 磁盘的旧硬件上运行，每秒可以处理 200-300 次插入而没有任何问题；这是在虚拟机上运行的 SQL Server，同时运行许多其他虚拟机。
仅使用消费级 SSD，您就可以达到每秒 3,000 到 5,000 或更多的 4K I/O。
你的问题究竟是什么？
这
这本质上意味着，如果您的论坛每秒发帖数为 100 个，您将无法通过这样的设置来处理它。
根本就是不正确的。您缺少的是多个用户可以在每次日志刷新中将更改排入队列。因此，虽然每次日志刷新需要 10 毫秒，但它可以强化数十或数百个单独的并发事务。
打个比方：一列每小时来回一次的火车每小时运载的人数远多于 1 人。
在 SQL Server 中，并发会话将全部写入日志缓冲区，然后在提交时等待确认其 LSN 已包含在后续日志刷新中。
假设您的日志磁盘具有 10 毫秒的写入延迟和 100mB/s 的最大写入吞吐量（单个旋转磁盘的保守数字）。如果每个事务需要 100kB 的日志空间（大），那么您可以每秒在磁盘上刷新 1000 个事务，只要您随时至少有 10 个用户等待提交事务。