本篇接着上面的四篇继续讲述在window平台下mongodb的分片集群搭建。
在分片集群中也照样能够创建索引,创建索引的方式与在单独数据库中创建索引的方式一样。因此这不再多说。本篇主要聚焦在分片键的选取问题上。
分片键通俗来说就是切割海量数据的标记符。 假设更高效的划分海量数据往往依赖于分片键的选择。 分片键选得不好。应用程序就无法利用分片集群所提供的诸多优势。
在这样的情况下。查询和插入得系能都回显著下降。
一、低效的分片键
1.1 分布差
BSON对象ID是每一个mongodb文档的默认主键。
全部的对象ID最重要的组成部分是时间戳。也就是说对象ID是升序的,遗憾的是升序对于分片键来说是非常糟糕的。因为分片是基于范围的。使用升序的分片键后。全部近期插入的文档会落在某个非常小的连续范围内。假设想让插入负载分不到多个分片上,就不能使用升序分片键。应需某些随机性更强发的的东西。
1.2 缺乏局部性
如果分片集合中每一个文档都包括一个MD5,而MD5字段就是分片键。由于MD5随着文档的不同而进行变化。
全部该分片键能确保插入的文档均匀分布在集群的分片上。
可是有个问题,对于每一个分片的MD5字段索引进行的插入过程中。索引中每一个虚拟内存分页都有可能被訪问到。
这就意外着有可能全部的索引和数据都装在内存中。从而超出了物理内存。
3. 无法拆分的块
举个样例,比如用户Id上传了100张照片。那么分片键就是用户ID。第一原因对于每张照片来说具有随机性,同一时候能够通过局部性引用来提升效率。但有个问题就是当用户ID上传的照片太大时候,以至于不得不分块。而系统又不能把一个用户的照片拆分成多个快。
二、理想的分片键
以下是于分片键有关的实例分析文档: