简单分析下GOLDENDB

白鳝的洞穴 2022-08-24

17182

GOLDENDB是金融行业使用的比较广泛的一个数据库产品，以前也经常有朋友希望我写几篇分析GoldenDB数据库的文章。说实在的这类文章不好写，必须对某个产品有一定程度的了解，特别是真正上手用过之后，感受才会比较真实。因为之前一直没机会接触GoldenDB，因此也没法写此类文章。

应我们的一个D-SMART用户的要求，最近我们团队准备在D-SMART里增加对GOLDENDB的支持。想要在我们的运维工具里支持一个数据库产品，我们的团队就必须先认真研究一下这个数据库。于是最近这段时间我闲下来主要的事情就是翻阅GOLDENDB的一些文档。一段时间下来，算是对GOLDENDB有了一个初步的认识，今天我就和大家分享一些关于GoldenDB的知识。

上面的这个架构图来自于GOLDENDB的官网，实际上GOLDENDB这个超级大乐高不是一个简单的数据库，而是一个数据库云平台。GOLDENDB采用DBPROXY+MYSQL数据库的存算分离的架构，计算节点是一组DBPROXY，负责SQL分发与聚合计算工作，数据都存储在存储节点中，GOLDENDB的存储节点支持NO-SHARDING模式的主从数据库和SHARDING数据库集群两种类型。我听一些用户说，实际上他们比较喜欢使用NO-SHARDING的数据库，只有核心系统才从高可用方面考虑，使用SHARDING集群。

GOLDENDB是一个十分复杂的系统，里面包含多种网元，通过一个集群管理把这些网元整合起来。

计算节点（DBPROXY）是一个无状态的代理层，负责SQL解析，路由选择，执行计划优化等。GOLDENDB的计算节点可以根据需要横向扩展。

采用此类架构的国产分布式数据库产品很多，各个企业之间的研发能力，技术水平的差异，会导致这些架构类似的数据库产品的功能有较大的差异，而产生这方面的差异的组件就是计算节点。我们要了解此类数据库产品，一定要参考相关的SQL编写规范（采用此架构的数据库产品一般会提供一个类似的文档）。

在这个规范中，我们可以从建表，修改表，SELECT语句，DML语句的一些语法限定上大致了解此类架构数据库的使用限制。

GoldenDB在计算节点上做了大量的和Oracle兼容的改造，支持类似Oracle数据库中的sequence,rownum,并且在一些数据库维护的DDL方面与Oracle保持了一定的兼容性。同时GoldenDB也保留了不少MYSQL数据库的兼容性。

在创建表方面，GoldenDB还是存在一定限制的，比如说必须存在主键，这也是绝大多数分布式数据库和Mysql的特性。另外CTAS语句中的SELECT只支持单表，其他建表方面的限制对我们的应用建设影响不大。

另外在建表策略上，GoldenDB建议采用一些去范式化的设计，从而避免一些性能问题。这个是绝大多数分布式数据库都可能存在的问题。

在DML/SELECT上，大多数采用此架构的数据库都或多或少会对SELECT/UPDATE语句存在一定的限制。在选择某个数据库产品之前最好能够认真阅读下相关文档。GoldenDB在SELECT语法上做了读写分离的扩展，除了支持通过HINT来选择读取SLAVE外，还在语法上的增加了readslave的语法，让计算节点既可以把SELECT语句分发到SLAVE节点，又避免事务中強一致性要求的SELECT被误发。把选择权完全交给了应用开发人员。

因为GoldenDB“创造性地”发明了分布式数据库“一阶段提交”这种分布式事务提交的策略。因此GoldenDB在分布式事务的实现上还是与普通的分布式数据库，亦或是其他关系型数据库有所不同的。大事务回滚的性能可能会是一个比较大的问题。而且大事务与大事务回滚对于事务一致性隔离策略方面也会与其他数据库有所不同。因此可能对于某些业务系统来说可能需要针对性的优化改造来适应。

另外对于存储过程是否支持的问题，我目前还没有发现相关的文档，不过在一些GoldenDB的产品宣传类的PPT中，可以看到GoldenDB好像是支持存储过程的。这方面我们后续会继续分析一下。

这里所说的兼容“存储过程”不知道指的是为了确保和Oracle的兼容性而支持的一些内置存储过程还是支持用户定义存储过程。在开发指导文档中并没有看到存储过程编写的相关说明。因为没有文档，我们也就没办法去测试了。

每个数据节点集群由一个或者多个DBGROUP(安全组)组成，每个安全组包含一组主从复制的多副本数据集。实际上每个数据节点就是一个Mysql实例，GoldenDB中称之为RDB，我们客户的版本是Mysql 8.0.25，默认的RDB的端口号是3309。

GoldenDB的另外一个十分重要的组件是GTM，是用来管理全局分布式事务的。提供了创建、释放、查询全局分布式事务（GTID）的能力。GTM采用主从架构，主节点故障时会切换到从节点。这种架构在主从切换会对全局事务有一定的影响。

此外GoldenDB还有一种节点类型是管理节点，包含对集群，代理，元数据的管理，并提供了一个操作维护平台。还提供了一个集中式管理工具Insight。

一个内网使用的数据库管控台还要输入验证码，总觉得比较怪异。

不过从管理台的功能上来看还是挺丰富的。这种分布式数据库没有一个这样的管理台用起来还是挺费劲的。只不过Insight提供的并不是一个完整功能的分布式数据库管理台，很多数据库的管理工作是无法在这个工具中完成，比如对表、视图、序列号等的查看，修改等功能在当前版本的Insight中是没有的。不过Insight中提供了一个DDL执行工具，可以上传SQL文件或者输入DDL语句执行。

今天时间关系，我只是简单的介绍了一下GoldenDB数据库，这个数据库产品称为数据库云平台可能更为合适一些。里面集成了Mysql、Zookeeper、Redis、kafka、ES等大量的开源组件。外加自研成分较大的dbproxy,gtm，SuperProxy（跨多个GoldenDB集群之间的超级代理），因此其复杂度还是挺高的。对于一些小用户使用来说还是有一定困难的。因此GoldenDB的主要用户群体是一些规模较大的金融企业。

最后说说GoldenDB的文档吧，实际上我们在外面能够看到的GoldenDB的资料极少，不过GoldenDB的文档还是不少的。只不过这些文档并没有系统化的整理，并没有按照一个数据库产品去做文档的总体规划与开发。这也是国产数据库的一个通病，缺少好的文档方面的产品经理来规划文档，在文档开发方面也投入偏少。GoldenDB的文档还是有一些中兴通讯这种通讯产品制造商的风格的，大部分文档都是用于解决一个问题或者做某项工作的，也就是一些工程文档。这些文档在工程实施上有一定的作用，但是无法用于学习或者需要时查找某个功能或者资料。从文档上也可以看出，GoldenDB的用户数应该是不少了，因为很多文档的内容可能来自于某个用户现场出现过的问题，或者用户使用时不太会用时需要厂商提供的一些指导性的资料。

要想仔细分析一个数据库产品还是挺费劲的，今天我仅仅从表面上简单分析了一下，希望对想了解GoldenDB数据库的朋友有所帮助。当然因为接触这个数据库也不过一周不到的时间，因此难免有些地方理解的不太对，如果有朋友发现我有说错的地方，请多多指教。