我正在开发一个应用程序，我们正在编写大量的关键值对。在生产时，数据库大小将达到数百TB甚至数PB。密钥是20个字节，值最大为128 KB，很少小于4 KB。现在我们正在使用MongoDB。性能不是很好，因为很明显这里有很多开销。 MongoDB写入文件系统，写入LVM，进一步写入RAID 6阵列。
由于我们的要求非常基础，我认为使用通用数据库系统会达到性能。我正在考虑实现一个简单的数据库系统，我们可以将文档（或“值”）直接放到原始驱动器（实际上是RAID阵列），并存储密钥（以及指向值在原始位置的指针）驱动器）在由SSD支持的快速内存数据库中。这也会加快读取速度，因为所有这些都不会出现碎片（与使用文件系统相反）。
虽然很少删除文档，但我们仍然需要维护设备上可用的可用空间池（文件系统提供的内容）。
我的问题是，这真的会提供任何重大改进吗？此外，有没有任何文件存储系统做这样的事情？或类似的东西，我们可以用作起始点？
答案 0 :(得分：5)
Apache Cassandra跳了起来。这是当前的选举NoSQL解决方案，其中涉及大规模扩展。它看到several large companies with massive scaling requirements.的生产使用情况。稍微研究过一下，我可以说需要一点时间来重新思考你的数据模型以适应它如何安排它的存储引擎。着名的文章"WTF is a supercolumn"给出了一个很好的介绍。警告：当你计划存储庞大的数据集和分布时，Cassandra真的才有意义，没有单点故障是关键任务要求。通过您解释数据的方式，这听起来很合适。
另外，你有没有看过redis，至少是为了保存关键参考？您的内存需求远远超过单个实例能够处理的内容，但Redis也可以配置为分片。它不是主要用例，而是sees production use at both Craigslist and Groupon
另外，您是否已尽一切可能优化mongo，尤其是调查如何改进索引？ Mongo确实可以保存到磁盘，但在优化时应该相对高效，以便在内存中保留最热的部分（如果能够的话）。
如果数据不太短暂，是否可以缓存这些数据？
我会完全提醒你不要反对这种做法。只是一个公平的警告。这不是对你或其他任何人的打击，只是因为我个人不得不维护内部开发人员编写的自定义“数据索引”，这些开发人员之前已经超越了他们的头脑。在我的工作中，我们在磁盘键值存储上有一个大量，这是我们系统中的一个主要性能瓶颈，由开发人员编写，后者已经与公司分离。在今天激动人心的NoSQL机会中遇到这样的解决方案令人沮丧。像我上面引用的那些项目利用了开源社区的全部优势来证明和优化它们的使用。除非您投入大量时间，精力和促销，否则您无法实现自己的解决方案。至少I'd encourage you to look at all your nosql options并且可能找到一个项目，你可以贡献而不是自己动手。编写数据库服务器本身绝对是一项非常重要的任务，需要一个庞大的团队，特别是你已经给出的要求（但是你最终应该这样做，我祝你好运！=）
答案 1 :(得分：0)
迟到的答案，但为了将来的参考，我认为蜘蛛会这样做