mongodb - 没有文件系统的键值存储？

Question

我正在开发一个应用程序，我们正在编写大量键值对。在生产中，数据库大小将达到数百 TB，甚至数 PB。键为 20 个字节，值最大为 128 KB，很少小于 4 KB。现在我们正在使用 MongoDB。性能不是很好，因为显然这里有很多开销。 MongoDB 写入文件系统，文件系统写入 LVM，LVM 进一步写入 RAID 6 阵列。

由于我们的要求非常基本，我认为使用通用数据库系统会影响性能。我正在考虑实现一个简单的数据库系统，我们可以在其中将文档(或“值”)直接放入原始驱动器(实际上是 RAID 阵列)，并存储键(以及指向原始值所在位置的指针驱动器)在由 SSD 支持的快速内存数据库中。这也将加快读取速度，因为不会有任何碎片(与使用文件系统相反。)

虽然文档很少被删除，但我们仍然需要在设备上维护一个可用空间池(文件系统本应提供的)。

我的问题是，这真的会带来任何重大改进吗？另外，是否有任何文档存储系统可以执行类似的操作？或任何类似的东西，我们可以用作起始点？

Answer 1

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 确实会保存到磁盘，但如果可以的话，在优化以将集合中 HitTest 的部分保留在内存中时应该具有相对的性能。

如果数据不太短暂，是否可以缓存该数据？

我会完全警告你不要自己动手。只是一个公平的警告。这不是对你或其他任何人的打击，只是我个人不得不维护由内部开发人员编写的自定义“数据索引”，这些开发人员之前遇到了麻烦。在我的工作中，我们有一个大量 磁盘键值存储，这是我们系统中的一个主要性能瓶颈，它是由一位后来离开公司的开发人员编写的。在当今激动人心的 NoSQL 机会中遇到这样的解决方案是令人沮丧的。像我上面引用的那些项目利用开源社区的整体力量来证明和优化它们的使用。除非您投入大量时间、精力和晋升，否则您无法通过自己的解决方案实现这一目标。至少I'd encourage you to look at all your nosql options也许找到一个你可以贡献的项目，而不是自己动手。编写数据库服务器本身绝对是一项非常重要的任务，需要一个庞大的团队，尤其是在您提出的要求下(但如果您最终这样做，我祝您好运!=))