选择/配置数据库以实现高吞吐量、可靠、一致的写入吞吐量，并牺牲延迟

Question

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

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

换句话说（和tl；dr），客户机可以容忍延迟，但他们需要大量可信任的写入吞吐量——比“一次写入就是一次磁盘操作”的吞吐量还要高

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

我认为具有如此高的延迟容忍度，这并没有要求太多。我想其他人也有这个问题，比如金融公司，它们承受不起丢失数据的后果，但却承受得起延迟对任何一个客户的响应。

Postgres、CouchDB/Couchbase或MongoDB等经过战斗测试的数据库解决方案是否支持这种操作模式？

Answer 1

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

“客户端愿意在几秒钟内等待确认，等待的时间足以进行多次磁盘查找和写入”

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

如果你使用Pg来完成这样的工作，你需要调整检查点，以确保检查点不会暂停I/O。确保bgwriter正在积极地写出脏缓冲区。确保autovaccum经常运行——您没有从表中删除，但索引仍然需要维护，表统计信息也需要维护。

如果你期望大量的数据，而你的查询通常有一个时间元素，那么考虑将表划分为第一个月的（例如）1个月，将所有超过12个月的所有内容合并到一年中划分的表中。Pg只有有限的内置分区（使用继承和约束排除将其拼凑在一起），因此您必须使用触发器手动/编写脚本，但它可以完成这项工作。

见：

• 提交延迟配置选项