BaikalDB 1.1.2 版本发布

内容简介：BaikalDB 正式开启 1.1.X 版本 版本发布 https://github.com/baidu/BaikalDB/releases/tag/v1.1.2 https://gitee.com/mirrors/BaikalDB/tree/v1.1.2 主要特性介绍 分布式事务实现优化 在第一版事务设计中，如果事...

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同时支持全局二级索引与局部二级索引。在查询语句都会带上分片信息时，优先建议使用局部二级索引，对于无分片信息的表建议选全局二级索引。参考[索引选择](https://github.com/baidu/BaikalDB/wiki/Index-Selection)。

业务最常见的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是更新频率很低的，因此这个接口也支持版本号的传入，数据不更新就不需要备份，沿用之前的即可。配套的备份调度管理 工具 也在整理中，后续将逐步开源出来。

性能优化

在1.0.x版本中，倒排拉链使用的是ProtoBuf的存储格式，解析和析构性能较差。在新版本中引入了Apache Arrow的新拉链格式，可以大幅降低长拉链的解析和析构开销。

通过减少中间转化和ProtoBuf反射优化，大量数据扫描性能也相比之前有较高的提升。PREPARE STMT通过复用查询计划，减少bthread开销等方式，降低CPU使用。

其他功能

• 支持TTL功能，减轻业务GC负担
• 支持HyperLogLog功能，支持业务统计，实现跟 Redis HyperLogLog 完全一致
• 支持存储通过resource_tag隔离，支持表粒度的不同集群间迁移数据
• 支持物理机房分布功能，可以选择不同机房副本分布方式
• 增加几十个常用MySQL函数

以上所述就是小编给大家介绍的《BaikalDB 1.1.2 版本发布》，希望对大家有所帮助，如果大家有任何疑问请给我留言，小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持！

查看所有标签

猜你喜欢:

• IJPay 0.8 版本发布，兼容低版本 JDK
• fastjson 1.2.55 版本发布，Bug 修复版本
• Apache Ignite 2.9.1 版本发布，小版本更新
• Swoole v4.6.1 版本发布，Bug 修复版本
• Swoole v4.6.2 版本发布，Bug 修复版本
• Swoole v4.6.4 版本发布，Bug 修复版本

本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。