使用文件时MongoDB缩放

Question

我已经阅读了MongoDB手册中有关切分和复制集的内容。

然而，我想知道，如果有足够的性能(读/写)，是否可以实现以下目标：

• 通过GridFS在MongoDB实例上保存10,000,000个文件
• 没有索引和日志的大约2TB的总文件大小
• 10,000次写作/日
• 10 000次阅读/日
• 查询文档不需要立即响应，2秒仍然可以接受。

设置在脑海中：

• 1个3个节点的复制集
• 每个节点具有32 2TB，2TB SSD
• 1个Mongos实例
• 1 Config服务器

如果所建议的设置不足以实现每天存储10,000,000个文档和每天读写10,000,000个具有相当好的性能的目标，下一步将采取什么步骤？

• 向每个节点添加更多的RAM
• 向每个节点添加更多磁盘容量
• 添加具有相同配置的另一个副本集
• 切分

我想尽量避免切分，因为我认为最好的做法是尽可能避免切分。我觉得这只会不必要地使拓扑复杂化，在这种情况下，这很可能是过分的。

有些建议是很受欢迎的。

干杯

Answer 1

我的答案是:视情况而定。如果您正在通过_id字段访问文件，该字段已经建立了索引，那么您不需要很快添加更多内存。

_id字段为ObjectID类型，大小为12字节。这意味着它最多可以容纳2^(12*8)文件。3字节表示机器ID，它是一个哈希值，机器上有一个固定的值，可以减去它，给你大约2^72个文件。作为参考，2^20是1,048,576。

就内存而言，_id字段上的索引需要10,000,000 x12字节= 114 MiBytes。老实说，我现在不知道一个拥有1000万美元价值的索引的开销有多大，但我认为它不需要超过1G。

现在，如果您的_id字段不是ObjectID的类型，那么就进行计算。

在gridfs中，文件集合的文件名值也会被索引。如果没有使用文件名访问文件，则可以将其保留为空白并删除文件名的索引。

另一方面，如果要向所添加的文件中添加一些元数据，并希望根据这些元数据查询文件，则应该为这些元数据建立索引，并再次进行计算。

我有一个生产环境，有超过3,000,000 pdf文件(占用180 G空间的磁盘)。我的服务器是一个虚拟服务器，它有4 vCPU和4 Gig，仍然没有问题。您提供的规格太高，无法满足您的需要。你可以用这些服务器保存数十亿个文件。尤其是如果你有SSD。因为即使您的索引不适合内存，交换将非常快，您甚至不会注意到减速。

Answer 2

我们得到了16.200.000个文件，在mongo/gridfs中的总大小约为4.8 in。

每天增加25.000到30.000个文件.

grid_fs数据库(参考gridfs规范)根据一天中的时间，每秒大约有50-300次查询。

我们在副本集中有一对服务器，它们都是单四核cpu、32吉内存和一堆慢速2tb raid6数据磁盘。

一切都进展顺利。