BaikalDB 正式开启 1.1.X 版本

版本发布

https://github.com/baidu/BaikalDB/releases/tag/v1.1.2

https://gitee.com/mirrors/BaikalDB/tree/v1.1.2

主要特性介绍

分布式事务实现优化

在第一版事务设计中，如果事务COMMIT过程中有部分Region失败，通过持续重试直到Region全部成功才结束，但在生产环境下可能永远不会结束重试，这会带来额外的运维工作。

因此在新版本事务实现中，我们结合Rocksdb悲观事务与Percolator事务模型，引入Primary Region作为事务同步点。只有Primary Region COMMIT成功或者ROLLBACK成功后，才会继续给其他Region发送COMMIT/ROLLBACK指令。

基于Primary Region，接入层模块（baikaldb）的相关逻辑得以简化，其他Region超时未收到COMMIT/ROLLBACK指令会通过反查Primary Region来判断事务状态。Primary Region也通过raft同步状态，稳定性大幅提升。

还有一个重要的改进点是与Raft结合的部分，在第一版设计中，DML语句是在Leader上全部执行成功，Leader收到PREPARE指令后，才一次性打包复制给Follower，导致大事务情况下，Follower比Leader落后过多，造成不一致和不稳定的情况。本次我们改造了单条DML语句在Leader执行成功无冲突后，就直接通过Raft复制给Follower，使得Follower不会落后Leader过多，有效降低了不一致风险。

二级索引

在1.0.x版本中，BaikalDB 只支持局部二级索引，新版本中开始支持全局二级索引，并实现了局部二级索引的 Online Index Change。

局部二级索引，类似分片MySQL的各个分表的索引，主表与索引数据存储在统一分片中。好处是在分片内的处理是可以走单机事务，查询的也时候不需要网络交互。但是最大的问题是，局部索引查询时，如果没有分片信息（BaikalDB中是主键前缀），查询语句需要广播到所有分片，然后合并处理结果，在分片数上千的表中性能非常差。

全局二级索引，主表和索引数据独立存储，索引有独立的分片规则。好处是索引独立路由，查询性能比较稳定，不会有大量分片广播的问题。缺点是每次查询需要额外网络开销，索引写入时需要分布式事务保证一致。

BaikalDB同时支持全局二级索引与局部二级索引。在查询语句都会带上分片信息时，优先建议使用局部二级索引，对于无分片信息的表建议选全局二级索引。参考索引选择。

业务最常见的Schema Change需求是加列与加索引。BaikalDB底层数据存储采用了ProtoBuf，因此加列无需特殊处理。对于加索引场景，目前支持了局部二级索引的Online Index Change。

Online Index Change主要参考了Google F1 的Online Schema Change方案，过程不阻塞业务读写，通过多状态保证一致。实现过程中，引入了NONE、DELETE_ONLY、WRITE_ONLY、REORG、PUBLIC几个状态保证数据一致。DELETE_ONLY只能删除索引，WRITE_ONLY可以写入和删除索引，REORG阶段把全部历史数据读出后写入到二级索引中。随着全局二级索引使用越来越多，全局索引的Online Index Change也将实现。

基于代价模型的索引选择

在1.0.x版本中，我们的索引选择是依靠规则的，这在业务规模比较小的时候工作得很好。随着业务不断扩大，固定规则难以覆盖业务场景，业务使用显式Hint也较为繁琐。

因此在新版本中，我们引入了直方图和CMSketch收集表的统计信息。索引选择过程中，使用统计信息预估代价来选择索引。这部分依赖的统计信息目前还比较基础，后面也会引入更多统计维度。

支持SST备份恢复

在新版本中，我们引入了一个新的SST备份接口，通过Brpc的Stream接口，可以把全表的Region都写成SST文件并流式发送出去。这个接口比之前的select *的方式有着数量级的提升，可以用于数据的定期备份。同时，考虑到一个大集群中大量的Region是更新频率很低的，因此这个接口也支持版本号的传入，数据不更新就不需要备份，沿用之前的即可。配套的备份调度管理工具也在整理中，后续将逐步开源出来。