从MySQL到HBase：数据存储方案转型演进

　　DataIndex存储Data块的索引信息：Data存储为一组磁盘块，存储数据信息;DataIndex功能类似于B+树的非叶子节点;Data每个磁盘块中的数据按key有序，加载到内存后可以用二分查找定位;Key按行 + 列族 + 列 + 时间戳生成，按字典序排序(最佳查询方式：最左匹配);

　　MetaIndex存储Meta的索引信息，Meta存储一系列元信息;MetaIndex功能类似于B+树的非叶子节点;Meta存储bloomfiler等辅助信息。

　　2、MySQL优化点(主要是写)

　　查询缓存

　　将SQL执行结果放入缓存。

　　缓存B+高层节点

　　一千万行的大表，一般只需要一棵3层的B+树，其中索引节点 (非叶子节点) 的大小约20MB。完全可以考虑将大部叶子节点缓存，基于主键查询只需要一次IO。

　　减少随机写——缓冲：延迟写/批量写

　　上节提到，B+树通过自增主键大量减少随机插入。由于辅助索引的存在，插入、修改、删除操作，辅助索引可能引起大量的随机IO。

　　插入缓冲：只是将被插入数据写入insert buffer;定期将其merge到B+树;

　　修改缓冲：类似于insert buffer的思路。

　　减少随机读——MRR

　　SELECT * FROM t WHERE key_part1 >= 1000 AND key_part1 < 2000 AND key_part2 = 10000; # 普通操作分解： key_part1= 1000， key_part2=1000， id = 1 select * from t where id=1 key_part1= 1001， key_part2=1000， id = 10 select * from t where id=10 ... # MRR 操作分解: SELECT * FROM t WHERE key_part1 >= 1000 AND key_part1 < 2000 AND key_part2 = 10000; key_part1= 1000， key_part2=1000， id = 1 buffer.append(1) key_part1= 1000， key_part2=1000， id = 10 buffer.append(10) ... sort(buffer) select * from t where id in (buffer)

　　索引下推

　　MySQL的server处理完索引后，会将索引其它部分传给引擎层;

　　引擎层根据过滤条件过滤掉无用的行，减少数据量，进而优化server的性能。

　　3、集群化数据库的辅助索引

　　InnoDB的辅助索引

　　B+树全局有序，叶子节点存储的是主键。基于辅助索引定位主键，再用主键定位数据。MySQL水平切分后，没办法跨库维持建立全局有序索引：

　　单实例维护索引，丧失了全局有序性;

　　再做一个基于新索引分库方案，丧失了辅助索引维护的事务性。

　　HBase相同问题

　　仿照InnoDB实现辅助索引，辅助索引可以做成单独的key，其value是被索引行的key;

　　可以做到全局信息的维护，但没法保证事务性。

　　4、HBase异步合并带来的好处

　　TTL：基于后台合并，TTL很容易做;

　　数据多版本支持：基于“追加”，HBase天然的可以支持多版本;

　　版本数量：基于后台合并，可以将太旧版本干掉。

　　四、总结

（编辑：西安站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!