从MySQL到HBase：数据存储方案转型演进
|
根据主键查询，可以快速定位到数据所在磁盘块，只需要极少的磁盘IO即可拿到数据：通过缓存高层节点，主健查询只需要一次磁盘IO就可拿到数据;MySQL单表行数一般建议不会超过2千万，千万行以下的大表，B+树只需2~3层即可; 辅助索引，提供快速定位能力：辅助索引B+树，可以快速定位到最终所需的主键ID，根据主键ID可以快速拿到所需信息。 HBase只有局部信息，没有辅助索引 查询会优先查找memstore，如果没有会查找Hfile(存储结构类似B+树)。如果第一个Hfile中没有所需的信息，则需要去第二、第三个Hfile中查询;如果查询的数据恰好在memstore，第一个Hfile，HBase会优于MySQL;平均下来，HBase读性能一般。减少Hfile数据以提速，小的HFile合并成大的HFile文件。这种存储结构叫LSM树(Log-structured merge-tree); 如果需要检索特定的列，可能需要遍历所有Hfile，成本巨高。 MySQL成也B+，败也B+;HBase成也LSM，败也LSM。 4、附录 B+ 树 查询“值为25”的节点，只需要2次定位即可。 LSM树 查询“值为25”的节点，只需要4次定位即可。 三、优化思路 1、HBase优化点 (主要是读) 异步化 后台线程将memstore写入Hfile; 后台线程完成Hfile合并; wal异步写入(数据有丢失的风险)。 数据就近 blockcache，缓存常用数据块：读请求先到memstore中查数据，查不到就到blockcache中查，再查不到就会到磁盘上读，把最近读的信息放入blockcache，基于LRU淘汰，可以减少磁盘读写，提高性能; 本地化，如果Region Server恰好是HDFS的data node，Hfile会将其中一个副本放在本地; 就近原则，如果数据没在本地，Region Server会取最近的data node中数据。 快速检索 基于bloomfilter过滤： 正常检索，RegionServer会遍历所有Hfile查询所需数据。其中，需要遍历Hfile的索引块才能判断Hfile中是否有所需数据; BloomFiler存储HFile的摘要，可以通过极少磁盘IO，快速判断当前HFile是否有所需数据： 行缓存：快速判断Hflie是否有所需要的行，粒度较粗，存储占用少，磁盘IO少，数据较快; 列缓存：快速判断Hfile是否有所需的列，粒度较细，但存储占用较多。 基于timestamp过滤： HFile基于日志追加、合并，维护了版本信息; 当查询1小时内提交的信息时，可以跳过只包含1小时前数据的文件。 HFile存储结构： HFile存储格式 参考链接： https://link.zhihu.com/?target=https%3A//blog.csdn.net/yangbutao/article/details/8394149 Trailer存储整个Hfile的定位信息; （编辑：惠州站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
