MongoDB 分片片键选择与设计

心已赠人 2022-08-07 05:58 173阅读 0赞

MongoDB的分片机制能够帮助你将你的数据库划分到多个服务器，通常在生产环境中可以将数据集划分到多个副本集中。但分片最好在数据库建立早期划分，因为一旦你的数据大于512GB那么分片划分就不是那么容易了。这受到MongoDB纵向扩展能力的限制。为了实现分片，你必须向MongoDB指定使用哪个索引作为片键，然后MongoDB会根据你的设置将你的数据划分到有着相同片键的数据块(Chunk)中。而后这些数据块将根据片键的大致顺序分散到副本集中。   
MongoDB不允许插入没有片键的文档。但是允许不同文档的片键类型不一样，MongoDB内部对不同类型有一个排序：   
**null< 数字< 字符串 < 对象 < 数组 < 二进制数据 < objectId < 布尔值 < 日期 < 正则表达式 **

分片之后数据的存放位置依赖于片键，所以合理的选择片键十分重要。所以对于分片Key的选定直接决定了集群中数据分布是否均衡、集群性能是否合理。

**一、选择片键的要素   
1.读和写的分布**   
其中最重要的一点是读和写的分布。如果你总是朝一台机器写，那么这台机器将会成为写瓶颈，则你的集群的写性能将会降低。这无关乎你的集群有多少个节点，因为所有的写操作都只在一个地方进行。因此，你不应该使用单调递增的\`\_id\`或时间戳作为片键，这样将会导致你一直往最后一个副本集中添加数据。   
相类似的是如果你的读操作一直都在同一个副本集上，那么你最好祈求你的任务能在机器内存所能承受的范围之内。通过副本集将读请求划分开能够使你的工作数据集大小随着分片数线性扩展。这样的话你能够将负载压力均分到各台机器的内存和磁盘之上。   
**2.数据块的大小 **  
其次是数据块的大小。MongoDB能够将大的数据块划分成更小的，但这种情况仅仅在片键不同的情况下发生。如果你有巨量的数据文档都使用了同样的片键，那么你相应的会得到巨大的数据块。出现巨大块是非常不好的，不仅仅因为它会导致数据的不平均分布，还因为一旦这个数据块的大小超过某个值，那么你就不能够在分片之间移动它了。   
**3.每个查询命中的分片数目 **  
最后一点，如果能够保证大部分的查询请求都能够命中尽可能少的分片那就最好了。对于一个查询请求来说，其延迟直接取决于最慢的那个命中服务器的延迟；所以你命中的分片越少，那么理论上来说查询将会越快。这一点并不是硬性的规定，不过如果能够做到充分考虑那么应该是很有利的。因为数据块在分片上的分布仅仅是近似的遵循片键的顺序，而并不是严格的强制指定。   
**二、片键的设计   
1.Hashed id **  
作为第一个方案，你可以使用数据文档\_id的哈希作为片键。   
db.events.createIndex(\{\_id: 'hashed'\})   
这个方案能够是的读和写都能够平均分布，并且它能够保证每个文档都有不同的片键所以数据块能够很精细。   
似乎还是不够完美，因为这样的话对多个文档的查询必将命中所有的分片。虽说如此，这也是一种比较好的方案了。   
**2.多租户混合索引(Multi-tenant compound index) **  
db.events.createIndex(\{projectId: 1, \_id: 1\})   
如上不能简单地使用projectID作为片键，因为那会导致巨大块的产生，所以我们引入了\_id来将大project打散到多个块中。这些打散的块仍旧是索引连续的，所以仍然会分布在用一个分片上。   
找一个好的片键是很难的，不过这真的只有两种方案。如果在应用中找不出一个好的聚合键，那么对\_id做哈希吧。如果你能够找到，那么将它与\`\_id\`聚合以避免巨大块的产生。请记住无论你使用何种聚合键，它都需要能够将读和写平均分布以充分利用集群中的每个节点。   
**三、GridFS片键的设计 **  
根据需求的不同，GridFS有几种不同的分片方法。基于预先存在的索引是惯用的分片办法：   
1）“files”集合（Collection）不会分片,所有的文件记录都会位于一个分片上,高度推荐使该分片保持高度灵活（至少使用由3个节点构成的replica set）。   
2）“chunks”集合（Collection）应该被分片，并且用索引”files\_id:1”。已经存在的由MongoDB的驱动来创建的“files\_id,n”索引不能用作分片Key（这个是一个分片约束，后续会被修复），所以不得不创建一个独立的”files\_id”索引。使用“files\_id”作为分片Key的原因是一个特定的文件的所有Chunks都是在相同的分片上，非常安全并且允许运行“filemd5”命令（要求特定的驱动）。   
运行如下命令：   
> db.fs.chunks.ensureIndex(\{files\_id: 1\});   
> db.runCommand(\{ shardcollection : "test.fs.chunks", key : \{ files\_id : 1 \}\})   
\{ "collectionsharded" : "test.fs.chunks", "ok" : 1 \}   
由于默认的files\_id是一个ObjectId，files\_id将会升序增长，因此，GridFS的全部Chunks都会被从一个单点分片上存取。如果写的负载比较高，就需要使用其他的分片Key了，或者使用其它的值（\_id）来作为分片Key了。   
转至：   
[http://blog.jobbole.com/68854/][http_blog.jobbole.com_68854]  
[http://blog.csdn.net/fly542/article/details/7717778 ][http_blog.csdn.net_fly542_article_details_7717778]

[http_blog.jobbole.com_68854]: http://blog.jobbole.com/68854/
[http_blog.csdn.net_fly542_article_details_7717778]: http://blog.csdn.net/fly542/article/details/7717778