我正在开发一个可以生成大量数据并将其存储到磁盘的系统。该公司以前开发的系统使用普通文件来存储其数据，但由于多种原因，它变得非常难以管理。
我相信 NoSQL 数据库对我们来说是很好的解决方案。我们要存储的通常是带有一些元数据注释的文档（通常约为 100K，但有时可能更大或更小）。查询性能不是重中之重。优先级是以 I/O 变得尽可能少的方式编写。数据生成速率约为 1Gbps，但未来我们可能会向 10Gbps（甚至更高）发展。
我的另一个要求是（最好是有据可查的）C API 的可用性。我目前正在测试 MongoDB。这是一个不错的选择吗？如果没有，我可以使用其他什么数据库系统？
【问题讨论】：
redisredis.io
标签： c mongodb cassandra high-volume nosql
数据生成的速率大约是1Gbps，...我目前正在测试MongoDB。这是一个不错的选择吗？
好的，澄清一下，您的数据速率约为每 10 秒 1 gigaBYTE。所以你每 20 分钟左右填充一个 1TB 的硬盘？
MongoDB 具有相当稳定的写入速率，但它非常适合用于 RAM 与数据比率相当低的情况。您希望在内存中保留至少主索引以及一些数据。
根据我的经验，每 5-10GB 的数据需要大约 1GB 的 RAM。超过这个数字，读取性能会急剧下降。一旦为 100GB 的数据使用 1GB 的 RAM，即使添加新数据也会很慢，因为索引不再适合 RAM。
这里的关键是：
您计划运行哪些查询，MongoDB 如何让这些查询的运行更轻松？
您的数据很快就会占用足够的空间，基本上每个查询都会进入磁盘。除非您有非常具体的索引和分片策略，否则您最终只会进行磁盘扫描。
另外，MongoDB 不支持压缩。因此，您将使用大量磁盘空间。
如果没有，我可以使用其他什么数据库系统？
您是否考虑过压缩平面文件？或者可能是像 Hadoop 这样的大数据 Map/Reduce 系统（我知道 Hadoop 是用 Java 编写的）
如果C是关键要求，也许你想看看Tokyo/Kyoto Cabinet？
编辑：更多细节
MongoDB 不支持全文搜索。您将不得不寻找其他工具（Sphinx/Solr）来解决这些问题。
大索引无法达到使用索引的目的。
根据您的数字，您正在编写 10M 文档/20 分钟或大约 30M/小时。每个文档需要大约 16+ 字节的索引条目。 12 字节用于 ObjectID + 4 字节用于指向 2GB 文件的指针 + 1 字节用于指向文件的指针 + 一些填充量。
假设每个索引条目需要大约 20 个字节，那么您的索引以 600MB/小时或 14.4GB/天的速度增长。这只是默认的_id 索引。
4 天后，您的主索引将不再适合 RAM，您的性能将开始急剧下降。 （这在 MongoDB 中有详细记录）
因此，确定要运行哪些查询非常重要。
【讨论】：
看看Cassandra。它执行写入比读取快得多。可能，这就是你要找的。p>
【讨论】：