我正在开发一个将生成大量数据并将其存储到磁盘的系统。该公司以前开发的系统使用普通文件来存储其数据，但由于多种原因，它变得非常难以管理。
我相信 NoSQL 数据库对我们来说是很好的解决方案。我们要存储的通常是带有一些元数据注释的文档（通常大约 100K，但有时可能更大或更小）。查询性能不是重中之重。优先级是以 I/O 变得尽可能少的方式编写。数据生成的速率约为 1Gbps，但我们可能会在未来达到 10Gbps（甚至更高）。
我的另一个要求是（最好是有据可查的）C API 的可用性。我目前正在测试 MongoDB。这是一个不错的选择吗？如果没有，我可以使用其他什么数据库系统？
数据生成的速率大约是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 是关键要求，也许你想看看东京/京都内阁？
编辑：更多细节
MongoDB不支持全文搜索。您将不得不寻找其他工具（Sphinx/Solr）来解决这些问题。
大索引违背了使用索引的目的。
根据您的数字，您正在编写 10M 文档/20 分钟或大约 30M/小时。每个文档需要大约 16+ 字节的索引条目。12 字节用于 ObjectID + 4 字节用于指向 2GB 文件的指针 + 1 字节用于指向文件的指针 + 一些填充量。
假设每个索引条目需要大约 20 个字节，那么您的索引以 600MB/小时或 14.4GB/天的速度增长。这只是默认_id索引。
4 天后，您的主索引将不再适合 RAM，并且您的性能将开始急剧下降。（这在 MongoDB 中有详细记录）
因此，弄清楚要运行哪些查询将非常重要。
看看卡桑德拉。它执行写入比读取快得多。可能，这就是你要找的。