引擎级多模｜SequoiaDB让研发和DBA和谐共处很多朋友可能是通过2011年成立

很多朋友可能是通过2011年成立的PostgreSQL中国社区认识我的，今年，我加入SequoiaDB巨杉数据库，期待在分布式数据库领域，继续与大家探讨无尽的技术话题。周日，转发了公司公众号文章《SequoiaDB SQL查询语句执行过程》后，不少同行都问我SequoiaDB是不是就是基于一个分布式的存储，并对接上层的各类数据库及存储操作协议，形成兼容架构，这是不是就是巨杉的核心特色。
在此，我先进行回答：「首先， SequoiaDB底层是一个完整的原生分布式数据库，绝不仅仅是一个分布式存储；其次，支持多种引擎只是特色之一，惊喜绝对不仅是这一点。」因此，借着自己在公司公众号发表的首篇文章，给关心这些问题的朋友进行解答。
我们先定义一下数据库的直接用户是谁，那当然是我们的研发人员及DBA 。这往往是两个互相紧密合作，同时又在某些环节互相制约的角色。研发人员希望快速敏捷地开发程序，用越简单的方式开发越好，不希望受到数据库底层各种条件限制的束缚。在近年来兴起的微服务架构中，更是鼓励独立的开发团队管理并选择自己所需要的数据库。微服务中，为了保持各个服务之间的松耦合，每个服务都有自己的数据库。针对不同的业务需求，研发人员可以选择不同的数据库类型，有的使用关系型数据库，如：MySQL、PostgreSQL ，有的使用非关系型数据库，如：MongoDB 。每个客户项目中，为了完成业务流程，往往牵涉到多个服务，因此在多个服务之间进行数据处理往往充满挑战。而DBA更将会由于陷入到多个数据库的交叉管理，导致管理难度急速增加，往往由最初双方共同解决问题，到最后是大家剑拔弩张。
以一个金融在线交易的业务为例，通常包括各种信息，例如：账户查询、业务办理、账目调整，过程中需要验证交易信息，同时需要写入交易历史。传统单体应用中，只需要使用一次事务交易就可以检查账号的信息，同时基于事务完成交易历史数据的写入。但在微服务架构下，由于各个业务存放在不同的数据库中，考虑到业务需求不，研发团队可能认为账户信息更适合使用MySQL处理，而历史数据由于其海量膨胀及结构需要灵活变化的特性可能选择MongoDB引擎。导致业务处理时，需要通过各服务提供的API进行数据交换，给程序设计复杂度及系统处理性能都带来挑战，如下图“方案1” 。另一个方案，是通过ETL或日志复制等方式，将某个库中的业务数据同步到另一数据库，然后进行使用，带来的问题是数据不一致，同时数据存在多分冗余，耗费磁盘空间，如下图“方案2” 。
文章插图
市场上云计算厂商提供了支持不同协议的云数据库服务，受到不少用户青睐，特别是使得DBA可以减少很多安装部署及维护不同数据库架构的工作。但一方面，即使是使用云数据库，每个不同的数据库引擎之间，数据依然是各个孤岛，与上图一样方案1、方案2中的数据交互问题没有解决。如果需要进一步进行“数据中台”整合，还需要单独的ETL操作汇总到单独的数据仓库。另一方面，从平台的角度，用户必须使用公共云，或在企业中花费巨资，部署绑定某个云厂商的私有云“全家桶”方案，才可获得云数据库基于资源池化的存储计算分离，及多引擎支持能力。
文章插图
巨杉数据库提供引擎级多模能力，在SequoiaDB的原生分布式数据库基础上，同时支持多种数据库，现有的v3.4版本已经支持：MySQL、PostgreSQL、Spark、PosixFS兼容协议及原生SDB JSON API ，新的v5.0版本更将支持MariaDB、MongoDB、S3兼容协议，也欢迎关注并报名参加我们10月22日的SequoiaDB v5.0发布会。
文章插图
点击图片长按二维码报名
谈到这里，让我们拆解一下巨杉数据库SequoiaDB是如何支持多个不同的数据库引擎，以及在真实的业务场景中如何协助研发及DBA取得各自的平衡。如下图，从大粒度来拆解， SequoiaDB分为「SequoiaDB Instance Layer计算实例层」、「SequoiaDB Database Layer分布式数据库层」两层。顾名思义，分布式数据库层本身就是一个完整的数据库，通过SDB JSON API可以通过shell或SDK的方式进行数据操作，具备完整的事务一致性及数据库所有应有的管理功能。而计算实例层则提供更广泛的通用联机引擎模型，及对象引擎模型， SequoiaDB的多模支持能力不限于数据类型，而进一步实现了「引擎级多模」支持。