Eer*_*nen 5 database database-design mongodb nosql
首先,我为我对NoSQL架构(以及一般数据库)的潜在浅薄理解深表歉意,所以请耐心等待.
我正在考虑使用mongoDB来存储与UUID相关的资源.资源可以是诸如大图像文件(几十兆字节)之类的东西,因此将它们存储为文件并仅在我的数据库中存储链接以及相关元数据是有意义的.还有增加灵活性来解耦资源文件的实际位置,因此如果需要,我可以使用不同的第三方来存储文件.
现在,一个描述资源的文档大约是1kB.起初我除了几十万个数据库大小相当于几百兆字节的资源文档,很容易适应服务器内存.但是将来我可能需要将其扩展到数十万个文档的数量级.这将是几十千兆字节,我不能再挤进服务器内存了.
只有索引仍然适合内存大约一千兆字节或两千兆字节.但是,如果我理解正确,每次我在UUID上查找时都必须从磁盘读取.在这种情况下,传统的关系数据库是否可以从mongoDB获得显着的速度优势？
奖金问题:有没有一种既定的方式来做我想要实现的目标？:)
当整个数据库不再适合物理内存时，MongoDB 不会突然变慢。MongoDB 目前使用基于内存映射文件的存储引擎。这意味着经常访问的数据通常位于内存中（操作系统管理，但假设采用 LRU 方案或类似的方案）。
因此，此时它可能根本不会减慢或仅稍微减慢，这实际上取决于您的数据访问模式。与索引类似的故事，如果您（右）适当地平衡索引，并且您的用例允许，您可以拥有一个巨大的索引，其中只有一小部分位于物理内存中，并且仍然具有非常不错的性能，大部分索引命中发生在物理内存。
因为您谈论的是 UUID，所以这可能有点难以实现，因为无法保证相同的有限用户组会生成绝大多数吞吐量。在这些情况下，分片确实是维持服务质量的最合适方法。