目录
本文是第六章Partition的读书笔记。
这部分讨论的内容是
- 怎么partition，发生 热点数据/数据偏斜 的时候怎么办
- partition后数据的二级索引怎么管理
- rebalancing 重平衡：添加删除节点时分区怎么处理
- 服务发现：怎么知道自己要的数据在哪个节点上，节点或分区发生变化了怎么告知客户端
partition的目的是为了 scalability
partition的方式
方式1：By Key Range
- 每个partition都是一个范围，例如[start, end], 在start和end之间的key都分配在这个partition，key在partition内部是有序的
- 优点在于支持
范围查询 - 缺点是可能出现数据分配不均匀的情况
方式2：By hash of Key
- 根据key的hash值决定分区
- 能更好的均匀分配数据
方式3：混合方式
- key由多个列组成，例如(user_id, update_timestamp)
- 第一列用来哈希后决定所在分区
- 剩下的列用来排序
出现热点数据/数据偏斜怎么办
- key前后加上随机字段。例如key前面加2个0-9的数字，那么这个key就可以被拆分为100个不同的key
- 写的时候随机分散
- 读的时候并发的读所有的key，例如同时读上面的100个key
二级索引
方式1: partitioned by document(local index)。 每个partition维护自己持有数据的二级索引，写容易，读困难
方式2: partitioned by term(global index)。 全局维护一个二级索引，每个partition负责一部分，读容易，写困难
rebalancing
-
一致性hash(固定数量的分区，分区数>已有节点数)
-
动态的根据数据量的大小分裂或合并partition -
最好有人参与，而不是全自动化
service discovery
三种方式：
- Allow clients to contact any node (e.g., via a round-robin load balancer). 客户端挨着问该请求谁
- Send all requests from clients to a routing tier first. 客户端通过请求路由服务获取具体该请求哪个节点
- Require that clients be aware of the partitioning and the assignment of partitions to nodes. 客户端本地存储partition的相关信息
如何察觉partition或节点的变化
- 依赖一个外部服务（zookeeper等）。用routing tier模式进行服务发现
- 使用Gossip协议，以peer-to-peer的方式通知。 用上面的第一种模式进行服务发现
参考:
Designing Data-Intensive Applications https://book.douban.com/subject/26197294/