带着问题学习分布式系统之数据分片

前面也提到，假如行使非sharding key去会见数据，那么元数据处事器(可能元数据缓存处事器，后头会讲授这一部门)是没法知道对应的数据在哪一个shard上，那么该会见就得发送到全部的shard，获得全部shard的功效之后再做聚合，在mongoDB中，由mongos(缓存有元数据信息)做数据聚合。对付数据读取(R： read or retrieve)，通过统一个字段获取到多个数据，是没有题目的，只是服从较量低罢了。对付数据更新，假如只能更新一个数据，那么在哪一个shard上更新呢，好像都差池，这个时辰，MongoDB是拒绝的。对应到MongoDB(MongoDD3.0)的呼吁包罗但不限于：

findandmodify：这个呼吁只能更新一个document，因此查询部门必需包括sharding key

• When using findAndModify in a sharded environment, the query must contain the shard key for all operations against the shard cluster for the sharded collections.

update：这个呼吁有一个参数multi，默认是false，即只能更新一个document，此时查询部门必需包括sharding key

• All update() operations for a sharded collection that specify the multi: false option must include theshard key or the _id field in the query specification.

remove：有一个参数JustOne，假如为True，只能删除一个document，也必需行使sharidng key

其它，认识sql的同窗都知道，在数据中索引中有unique index(独一索引)，即担保这个字段的值在table中是独一的。mongoDB中，也可以成立unique index，可是在sharded cluster情形下，只能对sharding key建设unique index，原理也很简朴，假如unique index不是sharidng key，那么插入的时辰就得去全部shard上查察，并且还得加锁。

接下来，接头分片到shard上的数据不均的题目，假如一段时刻内shardkey过于齐集(好比定时刻增添)，那么数据只往一个shard写入，导致无法均衡集群压力。

MongoDB中提供了"range partition"和"hash partition"，这个跟上面提到的分片方法 hash方法， ranged based不是一回事儿，而是指对sharding key处理赏罚。MongoDB必然是ranged base分片方法,docuemnt中如是说：

• MongoDB partitions data in the collection using ranges of shard key values. Each range defines a non-overlapping range of shard key values and is associated with a chunk.

那么什么是"range partition"和"hash partition"，官网的一张图很好声名白二者的区别：

上图左是range partition，右是hash partition。range partition就是行使字段自己作为分片的界线，好比上图的x;而hash partition会将字段从头hash到一个更大、更离散的值域区间。

hash partition的最大甜头在于担保数据在各个节点上匀称漫衍(这里的匀称指的是在写入的时辰就匀称，而不是通过MongoDB的balancing成果)。好比MongoDB中默认的_id是objectid，objectid是一个12个字节的BSON范例，前4个字节是呆板的时刻戳，那么假如在统一时刻大量建设以ObjectId为_id的数据 会分派到统一个shard上，此时若将_id配置为hash index 和 hash sharding key，就不会有这个题目。

虽然，hash partition对比range partition也有一个很大的弱点，就是范畴查询的时辰服从低!因此到底选用hash partition照旧range partition还得按照应用场景来详细接头。

最后得知道，sharding key一但选定，就无法修改(Immutable)。假如应用必必要修改sharidng key，那么只能将数据导出，新建数据库并建设新的sharding key，最后导入数据。

元数据处事器

在上面接头的三种数据分片分式中，或多或少城市记录一些元数据：数据与节点的映射相关、节点状态等等。我们称记录元数据的处事器为元数据处事器(metaserver)，差异的体系叫法纷歧样，好比master、configserver、namenode等。

元数据处事器就像人类的大脑，一只手不能用了还没忍受，大脑不事变整小我私人就瘫痪了。因此，元数据处事器的高机能、高可用，要到达这两个方针，元数据处事器就得高可扩展 -- 以此应对元数据的增添。

元数据的高可用要求元数据处事器不能成为妨碍单点(single point of failure)，因此必要元数据处事器有多个备份，而且可以或许在妨碍的时辰敏捷切换。

有多个备份，那么题目就来了，怎么担保多个备份的数据同等性?

多个副本的同等性、可用性是CAP理论接头的领域，这里简朴先容两种方案。第一种是主从同步，起首选出主处事器，只有主处事器提供对外处事，主处事器将元数据的厘革信息以日记的方法耐久化到共享存储(譬喻nfs)，然后从处事器从共享存储读取日记并应用，到达与主处事器同等的状态，假如主处事器被检测到妨碍(好比通过心跳)，那么会从头选出新的主处事器。第二种方法，通过漫衍式同等性协议来到达多个副本件的同等，好比台甫鼎鼎的Paxos协议，以及工程中行使较多的Paxos的特化版本 -- Raft协议，协议可以实现全部备份均可以提供对外处事，而且担保强同等性。

HDFS元数据

HDFS中，元数据处事器被称之为namenode，在hdfs1.0之前，namenode照旧单点，一旦namenode挂掉，整个体系就无法事变。在hdfs2.0，办理了namenode的单点题目。

（编辑：湖南网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!