mongodb如何实现每个节点42T驱动器

我们听说mongodb有一个每个节点42T的客户机，我想了解更多。我知道cassandra有一个Bloomfilters，它会跳过磁盘来找出一行可能在哪个文件中

mongodb是否有类似于bloomfilters的功能

mongodb是否使用类似于SSTables的东西

我确实读过mongodb和cassandra一样进行压缩，我认为这将是一个非常长的过程，有一个42T节点

我想在这里研究mongodb时，我不知道要搜索什么术语（在cassandra中，它们被称为SSTables）

谢谢，

---

Dean

MongoDB不支持在线压缩。事实上，数据碎片是具有许多文档更新的系统中的一个当前问题。为了防止数据碎片，MongoDB尝试计算自动填充因子，以最小化数据移动的次数

compact命令会阻塞整个数据库，直到完成。此外，MongoDB不支持字典压缩，因此字段名占用存储的每个对象的空间。我猜MongoDB使用的布局不是任何花哨的数据结构。它只是由标题（偏移量、长度…）、bson数据和填充因子组成

因为MongoDB不是键/值或列数据库，所以它不使用SSTables（用于列布局的高效数据结构）。为数据库创建的每个文件都命名为“区段”

---

好吧，MongoDB不使用bloom过滤器。

除非被访问，否则文档不会从磁盘读取到RAM中。索引用于知道需要访问哪些文档。好的索引策略将意味着只有完整的索引，并且一些小的文档子集（正在被访问）需要在RAM中，或者需要从磁盘读取。所以mongodb可以支持每个节点数十亿行。我在它的压缩算法上找不到任何东西，比如大小分层压缩与分级压缩，这些都是有充分文档记录的google方法，可以随着数据集大小的增长进行压缩。实现其中之一对于快速查找信息来说通常是至关重要的。对于大量的信息，需要索引到rowkey（及其所在行）的位置。它是如何工作的？它是通过使用索引来工作的，索引给你直接指向记录的指针。我确实读了一些关于compact命令的东西…很好…这似乎与我发现的一致，所以我认为42T似乎真的很难用我们的模型来做。