选择/配置数据库以获得高吞吐量、可靠、一致的写入吞吐量，牺牲延迟答案

【问题标题】：Choosing/configuring a database for high-throughput, reliable, consistent write throughput, sacrificing latency选择/配置数据库以获得高吞吐量、可靠、一致的写入吞吐量，牺牲延迟
【发布时间】：2012-10-11 05:30:47
【问题描述】：

我正在开发一个具有以下特征的实时应用程序：

数百个客户端将同时插入行/文档，每个客户端每隔几秒插入一行。
大部分仅追加；几乎所有的行/文档，一旦插入，就永远不会改变。
只有当数据刷新到磁盘后，客户端才会看到成功，此后读你写的一致性应该保持。
客户端愿意等待秒左右的确认时间 - 足够长的时间来进行多次磁盘查找和写入。
RAM 中无法容纳的数据过多（排除 Redis 等选项）。但是很久以前写入的行很少被访问，因此不将它们放在内存中是可以接受的。
理想情况下，这些写入不应阻塞读取。
键值对存储没问题，但至少需要一个可靠的自增索引。

换句话说（和 tl;dr），客户端可以容忍延迟，但他们需要大量可信赖的写入吞吐量 - 比“一次写入是一次磁盘操作”更高的吞吐量。

我正在设想一个数据库，它的实现方式如下：接受（理论上受文件描述符数量限制）数量的 TCP 连接，在内存中缓冲这些写入，尽可能频繁地将它们的批次记录到磁盘（以及对自动递增索引的更新），并且仅在相关的磁盘写入操作完成时才响应这些 TCP 连接。或者它可以像延迟写入的数据库一样简单，它发布已完成磁盘写入的消息（客户端等待延迟响应，然后等待写入消息报告成功）。

我认为具有如此高的延迟容忍度，这并不过分要求。而且我想其他人也遇到过这个问题，例如金融公司，它们不能承受丢失数据，但可以承受延迟对任何客户的响应。

是否有任何久经考验的数据库解决方案（如 Postgres、CouchDB/Couchbase 或 MongoDB）支持这样的操作模式？

【问题讨论】：

标签： mongodb postgresql couchdb throughput database

【解决方案1】：

PostgreSQL 应该非常适合这种工作负载；您指定的几乎所有内容都在其正常功能集中。 Pg 符合 ACID，支持组提交以减少同步开销，写入器不会阻塞读取器，并且它使用操作系统进行缓存，因此它自然倾向于仅将热数据集保留在内存中。

“客户愿意等待几秒钟的时间来确认 - 足够长的时间进行多次磁盘查找和写入”

如果考虑使用 PostgreSQL，您的应用程序非常适合非常大的 commit_delay，这将极大地提高写入吞吐量。您不能使用synchronous_commit = off，因为您需要在回复之前确认提交，但您可以将提交排队等待几秒钟以节省同步成本。

如果您将 Pg 用于此类工作，您将需要调整检查点以确保检查点不会停止 I/O。确保 bgwriter 积极地写出脏缓冲区。确保 autovaccum 经常运行 - 您不会从表中删除，但索引仍需要维护，表统计信息也需要维护。

如果您期望大量数据，并且您的查询通常具有时间元素，请考虑将 partitioning the table 第 1 年（例如）1 个月的块，合并超过 12 个月的所有数据到按年份分区的表中。 Pg 只有有限的内置分区（它使用继承和约束排除一起被破解）所以你必须使用触发器手动/脚本来完成，但它可以完成这项工作。

见：

【讨论】：

正是我正在寻找的答案类型！我对文档中的Since all pending commit data will be written at every flush regardless of this setting, it is rare that adding delay by increasing this parameter will actually improve performance 有点失望——但我假设我的用例是那些“罕见”的案例之一？无论如何，我需要对此进行大量阅读并进行测试/调整，但这看起来很有希望。
@btown 在做出任何决定之前，您当然需要进行测试和基准测试。我发现文档中的那一点有点不清楚；我怀疑它可能指的是任何非延迟提交都会导致延迟提交也刷新到磁盘。我会对你的结果感兴趣。
@btown BTW，对于这种工作负载，您可以做的最好的事情就是确保您的存储具有非常快速的同步。在回写模式下具有电池备份缓存的 RAID 控制器是最便宜的选择。你不会相信它带来的不同。一个好的 SAN 是更昂贵的选择。无论您做什么，都不要在诸如 EC2 之类的东西上运行这种工作负载。如果您使用带有 BBU 的 RAID 控制器，它们就不一样了。基准测试或询问 pgsql-general 邮件列表。如果使用 BBU，请定期测试您的 BBU，以确保电池仍然正常工作。