面向金融级应用的 GreatSQL 正式开源

来源: OSCHINA
2021-08-26

GreatSQL 社区宣布,在经过几个月的紧张筹备后,GreatSQL 现已正式开源。

根据介绍,GreatSQL 是源于 Percona Server的分支版本,除了Percona Server已有的稳定可靠、高效、管理更方便等优势外,特别是进一步提升了MGR(MySQL Group Replication)的性能及可靠性,以及众多bug修复。此外,GreatSQL还合并了由华为鲲鹏计算团队贡献的两个Patch,分别针对OLTP和OLAP两种业务场景,尤其是InnoDB并行查询特性,TPC-H测试中平均提升聚合分析型SQL性能15倍,最高提升40多倍,特别适用于周期性数据汇总报表之类的SAP、财务统计等业务。

GreatSQL 可以作为MySQL或Percona Server的可选替代方案,用于线上生产环境;完全免费并兼容MySQL或Percona Server。GreatSQL 由万里数据库发起、主导、维护,官方欢迎广大MySQL使用者、爱好者下载使用,或者提交代码、issue等。

1. 使用 MySQL 社区版存在什么风险

万里数据库核心研发团队深入研究MGR架构,并在不断的BUG修复实践中总结出了一套完善、流畅的BUG修复流程,将MGR的缺陷分为BUG和性能两类,整理出共16大类共数几十个BUG及性能缺陷问题。

搜索MySQL官方bug站,可以看到MGR分类下未修复的bug数量还是比较多的:

当服务器配置高,网络环境好,业务量小的时候,这些MGR相关的bug可能不容易碰到。如果是网络环境稍微复杂一些,例如同城多数据中心环境,甚至跨交换机,都可能会遇到网络分区条件下的一些bug。或者当业务量较大,负载较高时,可能会产生丢数据、OOM,或事务频繁回滚、死锁等问题。

由于MGR自身的复杂性,以及复现BUG场景也更困难,所以MySQL社区版针对MGR的BUG修复工作通常比较缓慢,堆积较多。这也就造成了不少用户不太敢放心使用MySQL社区版的MGR,担心遇到各种不可控的BUG,甚至较严重的线程、事务hang住等问题,感觉还是不那么可靠。

而GreatSQL已经有效解决了绝大多数较严重的问题,可以更放心地在金融级应用场景使用MGR架构。

2. GreatSQL的优势及展望

在金融级应用场景中,对数据的可靠性和架构的容错性要求都更高,对多数据中心甚至多活都有较高需求。为此,GreatSQL未来会在以下几方面着重发力。

2.1 增加更多金融级场景需求特性

  • 增加地理标签功能。当在多机房部署MGR时,可以保证每个机房中至少有一个节点都参与事务认证,确保该节点总有最新事务,这可用于解决多机房数据同步的问题。

  • 采用全新的流控机制,流控阈值计算更合理、细致,不会出现频繁性能抖动问题。

官方称,更多企业级新特性正在持续完善中,后续的版本会陆续放出。

2.2 提升同城双机房和跨城架构部署的可靠性

  • 支持AFTER模式下多数派写机制。发生网络分区时,只要多数派节点已经回放完毕,集群就可以继续处理新的事务,依然可以保障集群的高可用性。

  • 解决磁盘空间爆满时导致MGR集群阻塞的问题。当发现某节点磁盘空间满了,就会让这个节点主动退出集群,避免像MySQL社区版那样整个集群被阻塞的问题。

  • 解决多主模式下或切主时可能导致丢数据的问题。调整了事务认证处理流程,改成放到 applier queue 里按照paxos顺序处理,这就解决了在多主模式下或切主时可能导致丢数据的问题。

  • 解决节点异常退出集群时导致性能抖动的问题。优化paxos通信机制,发生异常时只会产生约1~3秒的性能小抖动,最差时TPS可能只损失约20% ~ 30%。而MySQL社区版本可能会造成约20~30秒的性能抖动,最差时TPS可能有好几秒都降为0。下面两个图非常明显体现了GreatSQL针对这种情况所做的优化。

MySQL社区版:5秒发现问题,22秒后将其踢出。

GreatSQL版本:耗时约3秒即完全恢复,时效提升约90%

  • 节点异常状态判断更完善,比MySQL社区版本能更快发现、判断节点异常状态,有效减少切主和异常节点的等待耗时。下面两个图体现了GreatSQL针对节点状态异常做出更快速准确的判断。

MySQL社区版:5秒发现问题,22秒后将其踢出。

GreatSQL版本:2秒发现问题,9秒后将其踢出,时效提升约60%

2.3 MGR 性能提升

  • 优化事务认证队列清理算法。MySQL社区版本中,认证数据库采用类似全表扫描的方式,效率极低。优化后,采用基于类似索引机制,有效解决清理效率低、性能抖动大的问题。

  • 提高MGR吞吐量。经过优化,有效提升MGR的吞吐量,并减少网络延迟对访问性能的影响。

  • 提升一致性读性能,并降低从库只读延迟。

2.4 InnoDB 事务锁以及并行查询优化

合并了由华为鲲鹏计算团队贡献的两个Patch,分别针对OLTP和OLAP两种业务场景。

  • 优化InnoDB事务锁机制,将原来的红黑树改为无锁哈希结构,在高并发场景中有效提升事务并发性能至少10%以上。

  • 实现对InnoDB底层B+树多个子树的并行扫描机制,极大提升聚合查询效率,TPC-H测试中,最高可提升30倍,平均提升15倍。

    特别适用于周期性数据汇总报表之类的SAP、财务统计等业务。

其他更多企业级特性展望

官方表示,在未来,他们还计划将一部分企业级特性也开放出来,包括且不仅限于国产化硬件适配、等保合规、安全加密、Oracle兼容等众多特性。

3. GreatSQL VS MySQL社区版

特性 GreatSQL MySQL社区版
地理标签
全新流控算法
InnoDB并行查询优化
InnoDB事务锁优化
网络分区异常应对 ⭐️⭐️⭐️⭐️⭐️ ⭐️
大事务处理 ⭐️⭐️⭐️⭐️⭐️ ⭐️
节点异常退出处理 ⭐️⭐️⭐️⭐️⭐️ ⭐️
一致性读性能 ⭐️⭐️⭐️⭐️⭐️ ⭐️
提升MGR吞吐量 ⭐️⭐️⭐️⭐️⭐️ ⭐️
多写模式下可能丢数据 ⭐️⭐️⭐️⭐️⭐️ /
单主模式下切主丢数据 ⭐️⭐️⭐️⭐️⭐️ /
MGR集群启动效率 ⭐️⭐️⭐️⭐️⭐️ /
集群节点磁盘满处理 ⭐️⭐️⭐️⭐️⭐️ /
TCP self-connect问 题 ⭐️⭐️⭐️⭐️⭐️ /
 

GreatSQL 代码现已上传到 Gitee,项目地址:https://gitee.com/GreatSQL/GreatSQL

展开阅读全文
26 收藏
分享
加载中
精彩评论
国内对这些基础设施的衍生分支,搞着搞着就不维护了,谁敢用?
先稳定维护 3-5 年再说。
2021-08-26 10:05
17
举报
金融行业数据库方面最不愿意用的就是开源的东西,因为没有售后运维团队,出了问题都不知道找谁来解决
2021-08-26 16:57
7
举报
great!请问GreatSQL是与Mysql哪个版本做得比对呢?求开导……
2021-08-26 08:48
6
举报
mysql用于金融?mygod!
也许是我观念需要更新,
不过以前的纽币奇葩问题的确让人印象太深刻了。
2021-08-26 09:40
4
举报
同问,不写具体版本号的,总感觉像是忽悠
2021-08-26 09:01
4
举报
最新评论 (33)
为什么产品名要用 Great 呢?如果被用户发现了一个 bug , 哪还 great 不?到时候再改产品名?
2021-09-01 10:11
1
回复
举报
GreatSQL北京万里开源软件有限公司
bug和产品名并不冲突,毕竟我们的名字没叫"零bug数据库"哈,感谢支持,也欢迎提bug
2021-09-01 14:14
0
回复
举报
I_I
这种有技术含量的开源项目还是应该支持一下
如果都不支持,就没法形成正反馈,也没法继续进步
2021-09-01 09:38
2
回复
举报
GreatSQL北京万里开源软件有限公司
的确是需要形成正反馈才能让项目持续做的更好,感谢支持哈
2021-09-01 14:11
0
回复
举报
怎么不和pg对比一下
2021-09-01 09:11
0
回复
举报
GreatSQL北京万里开源软件有限公司
MySQL路线和PG不是一回事,个人感觉对比意义不大哈
2021-09-01 14:13
0
回复
举报
大家可以考虑下LightDB,www.hs.net/lightdb
2021-08-26 22:57
0
回复
举报
GreatSQL北京万里开源软件有限公司
看了下官网文档,没找到lightdb相关的详细技术架构介绍,不太清楚具体情况。
不过我想和GreatSQL也并不冲突,有各自适用的业务场景,不妨试试新事物 :)
2021-08-27 17:08
0
回复
举报
很好, 然后继续用我的 TiDB
2021-08-26 18:07
2
回复
举报
GreatSQL北京万里开源软件有限公司
GreatSQL和tidb并不冲突,各有其适用的业务场景
2021-08-27 17:01
0
回复
举报
金融行业数据库方面最不愿意用的就是开源的东西,因为没有售后运维团队,出了问题都不知道找谁来解决
2021-08-26 16:57
7
回复
举报
P2P也属于金融行业,出问题了不更好么,反正钱也找不回来了
2021-08-26 17:19
0
回复
举报
GreatSQL北京万里开源软件有限公司
这里要澄清个观念,开源并不等于没有服务。包括MySQL和Percona都是提供商业服务的,但并不影响开源。只不过人们白嫖惯了,实际上只要肯付费,开源一样有商业售后服务保障的哈
2021-08-27 14:53
0
回复
举报
Mysql开源这么久也没说人白嫖,Linus 这几十年也没怪人白嫖linux,最烦国内很多开源项目动不动就说人白嫖,这种项目基本上都是准备利用开源引流,推广开来后就割匪菜。
2021-08-31 07:08
0
回复
举报
GreatSQL北京万里开源软件有限公司
我们欢迎白嫖,既然开源了,就预想到这点了。但别一边白嫖,一边抱怨服务不到位哈
2021-09-01 14:19
0
回复
举报
吹牛不打草稿了?
金融公司不用Linux了?不用开源框架了?Linux、MySQL都维护几十年了,金融公司这么牛,你找几个能替代的出来?Oracle这种笨重的东西,迟早进入垃圾堆,不过是金融公司需要背锅侠、金融公司的IT部门巩固地位、要预算的理由而已,你指望国内的金融公司那种IT买办能成事、能担风险,是不可能的。
2021-08-31 10:22
1
回复
举报
有钱的话,为什么要自己担风险?
2021-09-01 08:50
0
回复
举报
无风险的活谁不会干。所以传统金融公司的IT部门是成本中心,所以没地位。
2021-09-02 10:58
0
回复
举报
金融公司的IT部门要建设成利润部门吗?减低风险,本身就是金融业务线的要求,只是落在了IT部门去实现而已。而且就算时成本也是要综合考量的,用Oracle的时候雇两个DBA可以解决全公司的90%的数据库问题,换用了MySQL,两个人够吗?阿里从Oracle切数据库,DBA团队扩张了多少倍,互联网公司养得起人,金融企业也养这么多IT人员,不也是成本吗?
2021-09-03 08:57
0
回复
举报
你一年license 1000万往上,够养好大个团队了。互联网公司遇到公司特殊的业务场景还能深度定制开发,这就是格局的差异。
2021-09-05 21:51
0
回复
举报
回复 @漠孤烟 : 你说的对
2021-09-07 12:59
0
回复
举报
金融还是用大厂的东西,就算是衍生版,也最好用大厂做的。
2021-08-26 16:09
0
回复
举报
GreatSQL北京万里开源软件有限公司
金融行业里,也会有些可用性等级要求没那么高的场景,不妨试试新事物 :)
2021-08-27 17:04
0
回复
举报
好像文档太少了啊
2021-08-26 13:18
0
回复
举报
GreatSQL北京万里开源软件有限公司
GreatSQL文档在这里 https://gitee.com/GreatSQL/GreatSQL-Doc ,其他文档我们也在陆续补全哈
2021-08-27 14:50
0
回复
举报
国内对这些基础设施的衍生分支,搞着搞着就不维护了,谁敢用?
先稳定维护 3-5 年再说。
2021-08-26 10:05
17
回复
举报
GreatSQL北京万里开源软件有限公司
不用担心,GreatSQL是基于Percona的,版本也是同频的。万一哪天真不幸言中不维护了,直接无缝切换回Percona就可以了。Percona本身也是和MySQL官方社区版同频的,所以说,直接无缝切换回MySQL也是OK的
2021-08-27 17:03
0
回复
举报
mysql用于金融?mygod!
也许是我观念需要更新,
不过以前的纽币奇葩问题的确让人印象太深刻了。
2021-08-26 09:40
4
回复
举报
更多评论
33 评论
26 收藏
分享
返回顶部
顶部