HBase根本知识分享(二)
HBase的Split机制Region的分裂计谋
HBase中的Region存储的是一张表的数据。当Region中的数据条数过多时，会直接影响查询效率，过大的Region会被拆分为两个Region，HMaster会将这些分裂的Region分配到不同的RegionServer上，最终到达负载均衡的目的，这是HBase的一个优点。
常见的Region分裂计谋：
[*]ConstantSizeRegionSplitPolicy
[*]0.94版本前是HBase默认的Region切分计谋。
[*]当Region中最大的Store大小超过某个阈值（hbase.hregion.max.filesize=10G）时，触发Region的切分。
[*]然而，这种计谋对大表和小表没有显着区分：
[*]大表：阈值设置较大时对大表友好，但小表大概不会触发分裂。
[*]小表：阈值设置较小时对小表友好，但会在集群中产生大量的Region，增长资源管理和failover的负担。
[*]IncreasingToUpperBoundRegionSplitPolicy
[*]0.94版本到2.0版本是HBase的默认切分计谋。
[*]切分阈值基于Region的数目动态调解，随着Region数目的增长，切分阈值逐渐增大，避免大量小Region的产生。
[*]该计谋更加自适应大表、小表，但对小表不太友好，大概导致大量小Region分布在不同RegionServer上。
[*]SteppingSplitPolicy
[*]2.0版本后默认的切分计谋。
[*]简朴高效。根据Region数目调解切分阈值：
[*]当Region数目为1时，利用较小的阈值（128M*2）。
[*]否则，利用最大Region文件大小（MaxRegionFileSize）。
[*]对大集群的适应性好，不会导致大量的小Region，而且较适用于小表。
[*]KeyPrefixRegionSplitPolicy
[*]根据RowKey的前缀举行数据分区，例如RowKey是16位，指定前5位作为前缀举行切分。
[*]DelimitedKeyPrefixRegionSplitPolicy
[*]与KeyPrefixRegionSplitPolicy类似，但切分时利用指定的分隔符，例如RowKey格式为userid_eventtype_eventid，指定_为分隔符举行切分。
[*]BusyRegionSplitPolicy
[*]依据Region是否“繁忙”来判断是否必要拆分。如果系统常常会出现热点Region，而且对性能有较高要求，可以考虑利用此计谋。
[*]DisabledRegionSplitPolicy
[*]不启用自动拆分，必要手动拆分Region。
RowKey计划的原则
1. RowKey唯一原则
[*]RowKey必须包管唯一性，HBase是按照字典顺序存储数据的，因此计划RowKey时应充分利用这种特性，将常访问的数据存储在同一区域。
2. RowKey长度原则
[*]RowKey的长度一般发起不超过100字节。过长的RowKey会占用更多的内存和存储空间，影响HFile的存储效率，同时减少MemStore和BlockCache的缓存效率，降低检索效率。
3. RowKey散列原则
[*]如果RowKey按照时间戳等递增模式计划，大概导致热点问题。为了避免这种问题，可以将RowKey的高位计划为散列字段，低位放置时间戳等字段，这样可以将数据均衡分布到不同RegionServer上，避免热点。
HBase热点问题
1. 什么是热点问题？
[*]在HBase中，数据按照RowKey排序并存储。如果某些RowKey频繁被访问，数据会会合存储在同一个Region，大概导致：
[*]某个Region的负载过高。
[*]某个RegionServer被过度请求，成为瓶颈。
[*]集群负载不均，造成资源浪费和性能瓶颈。
2. 导致热点问题的原因
[*]顺序写入：如利用递增的ID或时间戳，导致写入操作会合在同一个Region。
[*]过度会合在某些RowKey范围：某些特定的RowKey频繁被访问，导致特定Region频繁被请求。
[*]RowKey缺乏随机性：如果RowKey计划缺乏随机性，访问会会合在某个Region，导致负载不均。
3. 如何避免和解决热点问题
[*]随机化RowKey：例如在RowKey前加上随机数，或者利用逆序时间戳来避免顺序写入带来的热点问题。
[*]利用时间区间分区（预分裂）：在表创建时举行预分裂，将RowKey按时间或其他特征举行分区，避免数据会合在某个Region。
[*]更复杂的RowKey计划：例如利用复合型RowKey，结合多种字段（如用户ID、时间戳等）举行计划，从而实现数据的均匀分布。
[*]动态扩展与负载均衡：通过Region Split或Region Merge操作，及时调解Region的分布，解决热点问题。
[*]监控与调优：及时监控RegionServer的负载情况，通过调解计谋解决热点问题。
HBase的Flush机制
触发条件
[*]Region中的MemStore占用内存超过阈值：如果MemStore的占用内存超过hbase.hregion.memstore.flush.size（默认为128MB），会触发Flush操作。
[*]RegionServer的MemStore占用内存超过阈值：当RegionServer中所有Region的MemStore占用内存超过阈值时，Flush操作会被触发。
[*]WAL数目超过阈值：如果RegionServer的WAL数目或大小超过某个阈值，MemStore会被触发Flush。
[*]定期自动刷写：通过定期检查MemStore，触发定时的Flush操作。
触发操作
常见的操作，如put、delete、append、incr等，会触发Flush操作。此外，Region的分裂、Merge操作、bulkLoad HFiles、快照等操作也会触发Flush。
Flush计谋
[*]FlushAllStoresPolicy：每次刷写都会触及Region中的所有MemStore。
[*]FlushAllLargeStoresPolicy：首先判断MemStore是否超过某个阈值，如果超过则触发刷写。
[*]FlushNonSloppyStoresFirstPolicy：优先刷写内存占用大的、非Sloppy范例的MemStore。
HBase的Compaction机制
Minor Compaction
Minor Compaction指的是将相邻的小StoreFile合并为更大的StoreFile，不会处理已删除或过期的数据。效果是StoreFile变少，文件更大。
Major Compaction
Major Compaction会将所有StoreFile合并为一个StoreFile，并清理无效数据（如已删除的数据、过期数据）。这一过程消耗大量资源，通常会在低峰时手动触发。
二级索引
[*]基于一级索引之上构建的索引。
[*]为什么构建二级索引：HBase默认的RowKey是唯一且只能做前缀匹配查询，查询条件如果不是RowKey的前缀，查询效率较低。通过二级索引可以进步查询性能，尤其是当查询条件不包罗RowKey时。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]