Question

我一直在考虑为我的数据选择最好的分片键（通过复合索引），并认为文档创建日期与客户号码的组合。（或发票号码）将是一个很好的组合。如果MongoDB将客户视为向后字符串，即：。

90043 => 34009
90044 => 44009
90045 => 54009
etc.

创建日期的索引将确保相对较新的数据保存在内存中，而后向客户no将帮助MongoDB在群集中分发数据/负载。

这是正确的假设吗？如果是这样的话......我是否需要保存我的客户而不是按照我期望的方式进行分发？

Answer 1

关于你的具体问题“我是否需要保存我的客户，不能按照我期望的方式进行分配？”，不，你不会。

即使您列出的客户编号值相对较窄，如果您在复合密钥中使用customerNumber，MongoDB也会将数据拆分为块并相应地分发这些数据。只要与customerNumber相关联的数据相对均匀分布（例如，一个用户不支配系统），您就可以获得所需的分片平衡。

我会考虑您的原始选择（减去字符串反转）或Dan的选择（使用内置的ObjectId而不是时间戳）作为复合键的良好候选。

Answer 2

从我在文档中看到的MongoId已经基于时间。因此，您可以将_id添加到复合键中，如下所示：（_ id，customerid）。如果您在应用程序中不需要日期，则可以删除该字段，这样可以节省一些存储空间。

MongoDB存储最近在内存中使用的数据集。集合的索引将始终尝试存储到RAM中。

当索引太大而无法放入RAM时，MongoDB必须读取来自磁盘的索引，这是一个比读取慢得多的操作内存。请记住，当服务器具有RAM时，索引适合RAM 可用于索引与工作集的其余部分相结合。

希望这有帮助。

干杯丹

Answer 3

我认为你认为这个问题，不管怎么说，你觉得节点1会比节点2更快。除非硬件完全不同，否则节点1和节点2的访问速度会相同，因此不会反转字符串帮助你。

我看到的主要问题与您系统中的客户数量有关。这可能导致单调分片，其中最后一个分片总是被击中并且可能导致过度分裂和迁移。如果您拥有大量客户，则没有任何问题，否则您可能希望在客户ID和日期字段之上添加另一个密钥，以便更均匀地划分您的内容。我听说有人使用随机标识符，散列_id或使用GUID来解决这个问题。