3

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

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

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

这是一个正确的假设吗？如果是这样......我是否需要保存我的客户没有反转它以我期望的方式分发？

4

3 回答 3

1

关于您的具体问题：“我是否需要保存我的客户，以使其按我期望的方式分发？”，不-您不会。

即使您列出的客户编号值的分布相对较窄，如果您customerNumber在复合键中使用，MongoDB 也会将数据分解成块并相应地分配它们。只要与之相关的数据customerNumber分布相对均匀（例如，一个用户不控制系统），您就会获得所需的分片平衡。

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

于 2012-12-20T16:58:41.083 回答
0

我认为你认为的问题是，不知何故，你觉得节点 1 会比节点 2 快。除非硬件有很大不同，否则节点 1 和节点 2 的访问速度将同样快，因此反转字符串不会帮助你.

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

于 2012-12-20T20:41:59.653 回答
0

从我在文档中读到的内容来看，MongoId 已经是基于时间的。因此，您可以像这样将 _id 添加到复合键中：(_id, customerid)。如果您不需要应用程序中的日期，您只需删除该字段即可节省一些存储空间。

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

当索引太大而无法放入 RAM 时，MongoDB 必须从磁盘读取索引，这比从 RAM 读取要慢得多。请记住，当您的服务器具有可用于索引的 RAM 以及工作集的其余部分时，索引适合 RAM。

希望这可以帮助。

干杯丹

于 2012-12-20T16:18:26.957 回答