带着问题学习分布式系统之数据分片
|
上面的三种方式都提到了对数据的分片是基于关键值、特征值的。这个特征值在不同的系统中有不同的叫法，比如MongoDB中的sharding key， Oracle中的Partition Key，不管怎么样，这个特征值的选择都是非常非常重要的。 那么。怎么选择这个特征值呢?《Distributed systems for fun and profit》给出了言简意赅的标准：
大概翻译为：基于最常用的访问模式。访问时包括对数据的增删改查的。比如上面的列子，我们选择“id”作为分片的依据，那么就是默认对的数据增删改查都是通过“id”字段来进行的。 如果在应用中，大量的数据操作都是通过这个特征值进行，那么数据分片就能提供两个额外的好处：
如果大量操作并没有使用到特征值，那么就很麻烦了。比如在本文的例子中，如果用name去查询，而元数据记录的是如何根据按照id映射数据位置，那就尴尬了，需要到多有分片都去查一下，然后再做一个聚合! 另外一个问题，如果以单个字段为特征值(如id)，那么不管按照什么分布方式，在多条数据拥有相同的特征值(如id)的情况下，这些数据一定都会分布到同一个节点上。在这种情况下有两个问题，一是不能达到节点间数据的均衡，二是如果数据超过了单个节点的存储能力怎么办?关键在于，即使按照分布式系统解决问题的常规办法 -- 增加节点 --也是于事无补的。 在这个时候，单个字段做特征值就不行了，可能得再增加一个字段作为“联合特征值”，类似数据库中的联合索引。比如，数据是用户的操作日志，可以使用id和时间戳一起作为hash函数的输入，然后算出特征值;但在这种情况下，如果还想以id为查询关键字来查询，那就得遍历所有节点了。 所以说没有最优的设计，只有最符合应用需求的设计。 下面以MongoDB中的sharding key为例，解释特征值选择的重要性以及对数据操作的影响。如果有数据库操作基础，即使没有使用过MongoDB，阅读下面的内容应该也没有问题。 以MongoDB sharding key为例 关于MongoDB Sharded cluster，之前也写过一篇文章《通过一步步创建sharded cluster来认识mongodb》，做了简单介绍。在我的工作场景中，除了联合查询(join)和事务，MongoDB的使用和Mysql还是比较相似的，特别是基本的CRUD操作、数据库索引。MongoDb中，每一个分片成为一个shard，分片的特征值成为sharding key，每个数据称之为一个document。选择适合的字段作为shardingkey非常重要，why? （编辑：惠州站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
