值的大小是否会影响MongoDB中索引的大小？

Question

我有一组ID，它们的长度在8到11位之间，并且只有300K (所以不是精确的顺序等)。这些文件存储在collection A中。

我有一个包含数百万个条目的collection B，其中每个条目都有一个由这些ID组成的数组，每个数组可以有数千个这样的ID。我也需要索引这个字段(例如，数亿，可能高达一个billion+条目)。当我对它进行索引时，发现索引非常大，远远超出了集群的RAM大小。

是否值得尝试将每个ID的值从8-11个数字压缩为一些小的字母数字编码字符串？或者简单地从1 - 300,000中按顺序重新编号(并维护其映射)？这是否会对索引大小产生重大影响，或者这是否不值得付出努力？

Answer 1

索引字段的大小会影响索引的大小。您可以运行collStats命令来检查索引的大小，并将索引字段的大小与MongoDb创建索引所需的总大小进行比较。

Mongo已经对索引执行了一些压缩，所以尝试将字段编码为字母数字编码字符串可能不会有什么好处，也不会有什么好处。

使用较小的数字类型将在索引中节省少量的大小，但如果您需要维护映射，这可能不值得付出努力，而且可能会使事情过于复杂。

对于只有11位ID索引的300K元素的集合，索引的大小应该很小，大约在几Mb左右。所以很有可能你的索引大小不存在存储或内存问题。

关于您的第二个集合，如果您减少了每个ID中的一些字节，您可以减少一些索引的大小。

例如，将每个ID的大小从8字节减少到4字节，并拥有大约10亿个元素，您正在减少一些GB的索引大小。

将索引和集合B的大小减少一些GB可能是一个有趣的节省，因此根据您的需要，将it修改为使用尽可能小的类型可能是值得的。然而，如果集合不断增长，由于索引不适合内存而导致的内存问题，您仍然可以拥有或在不久的将来拥有它。因此，对集合进行分片可能是一个很好的选择。

Answer 2

您可以创建散列索引，如果您对节省索引大小更感兴趣，它将提供或多或少相同的性能。

您可以使用一些数据检查您为索引和性能影响而保存的数据的百分比大小，并做出决策