BaikalDB 1.1.2 版本发布

栏目: 软件资讯 · 发布时间: 4年前

内容简介: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 版本发布》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!

查看所有标签

猜你喜欢:

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

改变未来的九大算法

改变未来的九大算法

[美] 约翰.麦考密克 / 管策 / 中信出版社 / 2013-6 / 39.00元

Google得出的搜索结果是如何产生的? 百度为何会陷入“搜索门”,又是什么机制使然? 身处在大数据时代的我们,究竟该如何应对变化莫测的世界? …… 没有满篇的专业术语,第一次让我们通过简单明了的语言、生动的例证了解支撑计算机王国的灵魂支柱——9大算法,包括人工智能、数据压缩,以及Google著名的PageRank等。 本书精彩地介绍了搜索引擎、PageRank、公开......一起来看看 《改变未来的九大算法》 这本书的介绍吧!

HTML 压缩/解压工具
HTML 压缩/解压工具

在线压缩/解压 HTML 代码

RGB CMYK 转换工具
RGB CMYK 转换工具

RGB CMYK 互转工具

HSV CMYK 转换工具
HSV CMYK 转换工具

HSV CMYK互换工具