6

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

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

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

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

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

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

4

1 回答 1

11

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

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

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

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

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

看：

于 2012-10-11T06:12:01.953 回答