我正在开发一个应用程序，我们正在编写大量的键值对。在生产环境中，数据库大小将达到数百 TB，甚至数 PB。密钥为 20 字节，值最大为 128 KB，很少小于 4 KB。现在我们正在使用 MongoDB。性能不是很好，因为显然这里有很多开销。MongoDB 写入文件系统，该文件系统写入 LVM，该 LVM 进一步写入 RAID 6 阵列。
由于我们的要求非常基本，我认为使用通用数据库系统会影响性能。我正在考虑实现一个简单的数据库系统，我们可以将文档（或“值”）直接放入原始驱动器（实际上是 RAID 阵列），并存储密钥（以及指向原始值所在位置的指针）驱动器）在由 SSD 支持的快速内存数据库中。这也将加快读取速度，因为不会有任何碎片（与使用文件系统相反）。
尽管文档很少被删除，但我们仍然必须在设备上维护一个可用空间池（文件系统会提供的东西）。
我的问题是，这真的会带来任何重大改进吗？此外，是否有任何文档存储系统可以执行此类操作？或任何类似的东西，我们可以用作起始点？
Apache Cassandra 突然想到。这是当前涉及大规模扩展的选择 NoSQL 解决方案。它看到了几家具有大规模扩展需求的大公司的生产使用情况。 经过一些工作，我可以说它需要一点时间来重新考虑您的数据模型以适应它如何安排其存储引擎。著名的文章“WTF is a supercolumn”对此进行了很好的介绍。警告：Cassandra 仅在您计划存储大量数据集时才有意义，并且没有单点故障的分发是关键任务要求。以您解释数据的方式，这听起来很合适。
另外，你有没有研究过 redis，至少是为了保存关键引用？您的内存需求远远超出了单个实例能够处理的能力，但 Redis 也可以配置为分片。这不是它的主要用例，但它在 Craigslist 和 Groupon 都看到了生产用途
另外，您是否已尽一切可能优化 mongo，尤其是研究如何改进索引？Mongo 确实会保存到磁盘，但在优化时应该相对性能更好，以尽可能将最热的部分保留在内存中。
如果它不是太短暂，是否可以缓存这些数据？
我会完全警告你不要自己动手。 只是一个公平的警告。这不是对您或其他任何人的打击，只是我个人不得不维护由内部开发人员编写的自定义“数据索引”，这些开发人员以前在他们的头脑中遇到了麻烦。在我的工作中，我们有一个巨大的在磁盘键值存储上，这是我们系统中的主要性能瓶颈，由一位从公司离职的开发人员编写。在当今令人兴奋的 NoSQL 机会中陷入这样的解决方案是令人沮丧的。我上面提到的项目利用了开源社区的全部力量来证明和优化它们的使用。除非您投入大量时间、精力和促销，否则您无法通过自己的解决方案实现这一目标。至少我会鼓励你看看你所有的 nosql 选项也许找到一个你可以贡献的项目，而不是自己动手。编写数据库服务器本身绝对是一项不平凡的任务，需要一个庞大的团队，尤其是根据您给出的要求（但如果您最终这样做，我祝您好运！=））
迟到的答案，但为了将来参考，我认为蜘蛛会这样做