洛阳发布数据库架构分区技术应用注意事项

　　1、分区与复制

　　分区一般和复制搭配使用，即每个分区的多个节点都有副本。这意味着，某条记录属于特定的分区，而同样内容会存储在不同的节点上，以提高系统容错性。

　　一个节点可能存储多个分区。主从复制模型和分区组合时数据的分布情况。每个分区都有自己的主副本，如被分配给某节点，而从库副本被分配给其他节点。一个节点可能是某些分区的主副本，同时也是其他分区的从副本。

　　2、KV数据的分区

　　分区的主要目标：将数据和查询负载均匀分布在各节点。若每个节点平均分担数据和负载，则理论上10个节点能处理10倍的数据量和10倍于单节点的读写吞吐量(暂忽略复制)。

　　但若分区不均，则会导致某些分区节点比其他分区有更多数据量或查询负载，即倾斜，这会导致分区效率下降很多。极端情况下，所有负载可能压在一个分区节点，其余9个节点空闲，系统瓶颈落在这忙的节点。这时的高负载分区即是系统热点。

　　3、避免热点

　　简单的，将记录随机分配给所有节点。这能在所有节点比较均匀分布数据，但缺点是：试图读取特定数据时，不知道保存在哪个节点，必须并行查询所有节点。

　　可以优化该方案。假设数据是简单的KV数据模型，即总能通过K访问记录。如在一本百科全书，可通过标题查找一个条目;而所有条目按字母序排序，因此能找到目标条目。

　　4、根据K的范围分区(KeyRange分区策略)

　　一种分区方案，为每个分区指定一块连续的K范围。若知道K区间的边界，就能轻松确定哪个分区包含这些K。若你还知道分区所在的节点，则可直接请求相应节点。

　　每个分区中，可按K排序保存。范围扫描就很简单，将K作为联合索引来处理，从而在一次查询中获取多个相关记录。假设有个程序存储网络传感器的数据，K是测量的时间戳(年月日-时分秒)。范围扫描此时很有用，可获取某月内的所有数据。

　　缺点

　　某些访问模式会导致热点。若K是时间戳，则分区对应于一个时间范围，如每天一个分区。测量数据从传感器写入DB时，所有写入操作都集中在同一分区(即当天的分区)，导致该分区在写入时处于高负载，而其他分区始终空闲。

　　为避免该问题，需要使用时间戳之外的内容作为K的一项。可考虑每个时间戳前添加传感器名称，这样先按传感器名称，再按时间进行分区。假设多个传感器同时运行，则写入负载终会均匀分布在多个节点。当想要获取一个时间范围内、多个传感器的数据，可根据传感器名称，各自执行单独的范围查询。

　　5、根据键的Hash分区

　　由于数据倾斜和热点问题，许多分布式系统采用基于K散列函数来分区。

　　好的散列函数可处理倾斜数据并使其均匀分布。

　　数据分区目的的hash函数无需健壮的加密能力，如Cassandra和MongoDB使用MD5。许多编程语言也有内置的简单哈希函数(主要用于哈希表)，但可能不适合分区：如Java的Object.hashCode()，同一K可能在不同进程中有不同哈希值。

　　6、一致性哈希

　　一种平均分配自己负载的方法，初用于内容分发网络(CDN)等互联网缓存系统。采用随机选择的分区边界来规避中央控制或分布式共识。此处的一致性与副本一致性或D一致性无任何关联，它只描述了数据动态平衡的一种方法。

　　正如“分区再平衡”中所见，这种特殊分区方法对于DB实际上效果并非很好，所以目前很少使用(虽然某些DB的文档仍会使用一致性哈希说法。

　　但通过hash分区，失去的执行范围查询的能力：即使相邻的K，经过hash后也会分散在不同分区。MongoDB中，若使用hash分区，则范围查询都必须发送到所有分区。而Couchbase或Voldemort干脆直接不支持K的范围查询。

　　7、负载偏斜与热点消除

　　hash分区可减少热点，但无法完全避免：极端情况下，所有读/写操作都是针对同一K，则所有请求都会被路由到同一分区。

　　大多数据系统仍无法自动消除这种高度偏斜的负载，只能通过应用层来减少倾斜。如某K被确认为热点，简单方法是在K的开始或结尾添加一个随机数。只要一个两位数的十进制随机数就能将主键分散为100种不同的K，从而存储在不同分区。