选择MongoDB分片字段（Shard Key）的几点思考

　　MongoDB数据库是否能高效运转取决于你指定了文档的哪个字段作为分片字段。由于分片字段都是预先选择且选定后无法更改的，选择时就需要深思熟虑了。查询为主的应用程序，字段应限定在一个或几个分片上；对于需要大量集群间缩放的应用程序，创建一个高效写入的字段就十分必要。

　　MongoDB的前景很美好，它是目前最流行的非关系型的数据库管理系统（NoSQL DBMS）。市场研究公司Research and Markets在2014年三月发布的《Global NoSQL Market 2014-2018》的报告中指出，2013年到2018年，整个NoSQL市场将以53％复合年增长率增加，而大部分增长是由于各种规模的组织机构使用大数据增加导致的。

　　对比关系型数据库，MongoDB最显著的优势在于其效率高、扩展性好，以及“深入的查询能力”，Tutorialspoint的MongoDB Tutorial曾这样形容。然而通常来说，这里还有个棘手的问题：MongoDB的高效数据存储、缩放和查询依赖于分片，而分片依赖于精心选择的分片字段。

　　MongoDB手册中这样写到，集合（collection）中的每个文档都有一个索引字段或复合索引字段，这个字段用于确定集合中的文档在群集分片中如何分配。分片允许数据库跨服务器水平缩放，它的成本比通过增加处理器、内存和存储等垂直缩放要低很多。

　　一个微分片字段选择的词汇

　　当MongoDB的集合增长超过了其群集，它会根据分片字段值的范围将文档分块（chunkifie）。切记，一旦选择了分片字段，你就被它限制住了：分片字段日后无法更改。

　　基数是使数据块易于划分的特征。MongoDB手册建议分片字段应具有高度的随机性，以确保群集的写入操作是均匀分布的，这被称为写入缩放。反过来，当一个字段具有高度随机性，对特定分片的锁定难度便会大大增加。而使用绑定到单个分片的分片字段，查询效率会大大提高；这就是所谓的查询隔离。

　　当一个集合不具有可作为分片字段的字段时，可使用复合分片字段，或向服务器添加一个字段作为分片字段。

　　分片字段的选择取决于集合的性质

　　怎样知道哪个字段适合作为分片字段呢？Goran Zugic在2014年5月发表的一个帖子里介绍三种MongoDB支持的分片：

• 基于距离的分片（range-basedsharding）用于拆分基于分片字段值的集合。
• 基于散列的分片（hash-basedsharding）用于确定基于分片字段值的散列值。
• 标签感知分片（tag-awaresharding）用于将分片字段值绑定到特定分片上，通常用在基于位置的应用上。

　　指定分片字段时，集合将如何使用是首先需要考虑的。Zugic将其作为查询隔离和写入缩放之间的平衡：当查询接入到一个或少数分片时，前者是首选；当服务器间群集有效缩放至关重要时，则优先考虑后者。

　　2014年3月，Conrad Irwin曾在BugSnag发帖说，MongoDB确保了所有副本集具有相同数量的组块。Irwin列出了确定分片字段的三个因素：

• 读写分布：均匀读取所有副本集，以便在几个分片中线性缩放工作集大小，并避免向群集中单个机器写入。
• 组块大小：确保使用同一分片字段的文档不会多到导致组块太大而无法在分片间移动。
• 查询点击：如果查询需要访问太多服务器，延迟增加，可精选分片字段以便查询运行尽可能高效。

　　Irwin提供了两个例子。最简单的方法是使用文档_id的散列：

　　除了高效分配读写，该技术还保证了每个文档都有自己的分片字段，将组块能力最大化。

　　另一个例子通过项目分组索引中的相关文档，同时使用散列来区分分片字段：

分片字段选择的微型决策树可能是这样的：

• 如果应用程序中没有合适的一组密钥备选，散列_id。
• 如果应用程序有合适的分组密钥，将其选为分片字段并使用_id防止组块过大。
• 一定要用选定的分片字段均分读写，以避免将所有查询发送至同一机器。.

　　以上以及其他优化MongoDB数据库的方法都可以通过Morpheus数据库即服务（DBaaS）的单个的仪表板来处理。Morpheus让你可以提供，部署和主持异构的MySQL、MongoDB、Redis和Elasticsearch数据库。这是第一个也是唯一一个支持SQL、NoSQL和内存数据库的DBaaS。

原文链接：The Three Most Important Considerations in Selecting a MongoDB Shard Key（译者：李贻丽）