MongoDB中shard key的选择(2)
来源：未知 责任编辑：责任编辑 发表时间:2014-02-18 03:27 点击:次
可靠性
选择分片Key的一个非常重要因素是万一某一个分片彻底不可访问了，受到影响的Chunk有多大（即使是用貌似可以信赖的Replica Set）。
假定，有一个类似于Twiter的系统，Comment记录类似如下形式：
www.2cto.com
{
_id: ObjectId("4d084f78a4c8707815a601d7"),
user_id : 42 ,
time : "2011-01-02T21:21:56.249Z" ,
comment : "I am happily using MongoDB",
}
由于这个系统对写操作非常敏感，所以需要将写操作扁平化的分布到所有的Server上去，这个时候就需要用id或者user_id来作为分片Key了。使用Id作为分片Key有最大粒度的扁平化，但是在一个分片宕机的情况下，会影响几乎所有的用户（一些数据丢失了）。如果使用User_id作为分片Key，只有极少比率的用户会收到影响（在存在5个分片的时候，20%的用户受影响），但是这些用户会再也不会看到他们的数据了。
索引优化
正如在别的章节中提到索引的一样，如果只有一部分的索引被读或者更新的话，通常会有更好的性能，因为“活跃”的部分在大多数时间内能驻留在内存中。本文上述的所描述的选择分片Key的方法都是为了最终数据能够均匀的分布，与此同时，每一个Mongod的索引信息也被均匀分布了。相反，使用时间戳作为分片key的起始字段会有利于将常用索引限定在较小的一部分。
假定有一个图片存储系统，图片记录类似于如下形式:
{
_id: ObjectId("4d084f78a4c8707815a601d7"),
www.2cto.com
user_id : 42 ,
title: "sunset at the beach",
upload_time : "2011-01-02T21:21:56.249Z" ,
data: ...,
}
你也能构造一个客户id,让它包括图片上传时间对应的月度信息和一个唯一标志符（ObjectID,数据的MD5等）。记录看起来就像下面这个样子的：
{
_id: "2011-01-02_4d084f78a4c8707815a601d7",
user_id : 42 ,
title: "sunset at the beach",
upload_time : "2011-01-02T21:21:56.249Z" ,
data: ...,
}
客户id作为分片key,并且这个id也被用于去访问这个Document。即能将数据均衡的分布在各个节点上，也减少了大多数查询所使用的索引比例。
www.2cto.com
更进一步来讲：
在每一个月份的开始，在开最初的一段时间内只有一个Server来存取数据，随着数据量的增长，负载均衡器（balancer）就开始进行分裂和迁移数据块了。为了避免潜在的低效率和迁移数据，预先创建分片范围区间是明智之举。（如果有5个Sever则分5个区间）
可以继续改进，可以把User_ID包含到图片的id中来。这样的话会让一个用户的所有Document都在一个分片上。比如用“2011-01-02_42_4d084f78a4c8707815a601d7”作为图片的id。
GridFS
相关新闻>>
最新推荐更多>>>
- 发表评论
-
- 最新评论 更多>>
