随着企业应用的类型不断拓展，在海量数据、高并发、多类型数据的应用场景下，底层数据平台对于混合数据类型、混合业务场景处理能力的要求不断扩大，这就催生了 HTAP（混合事务和分析处理）的需求。

 

新一代分布式数据库，对于HTAP类型的处理有着无可比拟的优势。而本文将从实战出发，带大家了解HTAP场景下分布式数据库使用的几个技术要点，帮助大家使用分布式数据库六招轻松“搞定”HTAP场景。

 

传统数据库架构面临的痛点

1. 集群分散不利于整合，数据结构同步工作量大

目前传统数据库架构各个业务之间数据分散，往往一个比较全面的关联查询需要找不同的机构去不同的库中查询数据。甚至有些数据已经使用磁盘落库的方式永久尘封，数据没有使用的价值。怎么能够把各个业务系统打通，如何把数据盘活，让数据能够给业务带来新的增长点是现在面临比较棘手的问题。

 

2. 传统方式存储，后续扩展同样面临生产当前问题

因为核心系统普遍使用小型机架构，传统关系型数据库扩容会非常麻烦，且扩容成本会很高。只能不断把生产数据剥离出来同步到历史库中，应用查询往往需要对接查询多个不同库，且每天数据切割工作给运维人员带来不小压力。

 

3. SQL查询界面和服务形式单一

传统架构只有一个数据查询窗口，伴随着机器宕机、和某些用户使用不当会拖垮整个库的性能，这样是对整个业务是有很大影响的。且业务对应的SQL查询形式比较单一，无法适应目前互联网多样化的需求。

 

4. 新系统已经不适合原来传统架构

目前随着业务量的爆发式增长，随着无纸化的推进数据库不仅仅需要保存文本数据，更多需要保存音频、影像类大对象数据。传统的数据架构已经不适合这种业务系统了，急需寻找一种新的替代方案。

 

综上所述，针对目前企业转型和互联网业务系统上线，原来旧的架构已经不能有效满足新需求。关系型数据库不适合海量数据存储，需要支持多节点、高扩展、多冗余的分布式架构成为目前选型的首选，分布式数据库架构作为后起之秀，在未来IT行业发展中注定会成为技术选型主流。

 

那么针对这些新需求，分布式数据库如何应对，特别是在HTAP这样新需求下，分布式数据库的哪些特性可以更好的解决上述的技术难点？实际项目实践中，如何更好应用和发挥这些技术特性的最大特性？

 

下面我们将介绍“六招” 帮助大家更好用分布式数据库应对HTAP和混合类型场景。

 

第一招：数据源的数据同步 

用户有时需要从多个生产交易系统中，实时获取客户余额变动和交易明细数据。该过程要求数据采集组件能够提供高性能、高可用性、高安全可靠性的实时采集、传输功能。因此我们采用了具备这些特性的 CDC 和 OGG 采集框架。

 

CDC（Change Data Capture）：基于数据库日志实现对数据源变化的实时捕获，并且实时传输到目标端。CDC 组件通过读取各个业务生产系统数据库的日志文件捕获得到更新（插入、删除、更新）的交易记录信息数据，经过行列过滤，字符编码转换后由 TCP/IP 发送给目标端，目标端接收到源端数据后，经过数值转换，字符编码转换，冲突检测后将变更数据通过 Confluent Rest API 把数据传送到 Kafka，将数据直接进行持久化之前进行消息队列的数据缓存。

 

OGG（Oracle GoldenGate）：基于日志的挖掘的技术，通过解析源数据库在线日志或归档日志获得数据的增量变化后，再将这些变化的数据传输到 Kafka 中，Kafka 将数据直接进行持久化之前进行消息队列的数据缓存。以下为数据采集架构图：

 

通过开发消费kafka的程序将数据同步到SequoiaDB数据中，保持和生产实时同步。以下为数据同步加载架构图：

 

第二招：弹性扩容

数据库容量满了？扩容呗。需要接入新系统？扩容呗。

 

当原有的数据库集群无法满足业务需求，此时就需要新增服务器和新增节点来扩容集群。一般用户使用传统的x86服务器即可作为扩容的服务器，按照操作系统要求中的最低配置信息或者推荐配置来配置服务器。在分布式系统中三副本模式是最理想的服务器配置，因此建议扩容按照三台服务器或者三的倍数台服务器来扩容集群，三台服务器中其中保留一个主节点外两台服务器作为副本备份数据。同时三台服务器有利于 Raft 算法选主，不管是经济上还是数据安全可靠性上三副本都是最合适的方案。用户扩容首先需要在一个现有的集群中，添加新的主机，并把新的节点部署到这些新的主机上。

 

扩容架构图如下：

同时，我们可以灵活应用“域”的功能进行数据扩容操作。域（Domain）是由若干个复制组（ReplicaGroup）组成的逻辑单元。每个域都可以根据定义好的策略自动管理所属数据，如数据切片和数据隔离等。如上所示原来的01、02、03机器的数据节点组成一个域对接一个业务系统，新扩容的三台机器组成新的域对接新的业务系统，两个域之间数据完全独立互不影响，能够比较好的管理整个集群的数据。

 

第三招：多模数据引擎使用

 

目前 SequoiaDB 支持三种SQL引擎，分别是：MySQL、PostgreSQL 和 SparkSQL。

 

那么这三种 SQL 解析器如何选择呢？

 

• MySQL 实例适用于比较熟悉 MySQL 的操作人员，适合精准查询、业务数据写入、柜面查询、OLTP场景。增删查改操作和 MySQL 完全一致，底层数据保存在 SequoiaDB。
• PostgreSQL 实例适用于比较熟悉 PostgreSQL 的操作人员，适合精准查询和OLAP场景。支持增删查改等功能和 PostgreSQL 使用完全一致，采用外表的方式将数据保存在 SequoiaDB 中。
• Spark 实例为分布式集群，SparkSQL 适合报表分析、大表关联查询和 OLAP 场景。跨库关联查询比较友好，支持标准 SQL、支持 JDBC 访问、支持 Python 对接查询。

 

用户可以使用 MySQL 作为 OLTP 场景、SparkSQL 作为 OLAP 场景混合使用达到 HTAP 效果。HTAP 代表一个数据库既能支持 OLTP (在线事务处理)，又能支持 OLAP (在线分析处理)，从而满足大部分企业级应用的需求。相比传统使用多款数据库进行不同的业务处理方式，HTAP 数据库能够避免传统复杂的 ETL 过程，省去数据在不同数据库之间的流转时间；同时避免维护多一套用于分析的数据库，从而节省人力和时间的成本，提高数据的价值。

 

第四招：多种 SQL 引擎关联使用方法 

4.1 MySQL 创建表

• 创建 temp.test 这张表 ，其中字段信息如下所示 ：

create  table temp.test
  (    
    numcode smallint,    
    agentcode char(12),    
    bankname varchar(120),    
    flag decimal(8,4),    
    timecode datetime
  );

•  给 temp.test 这个表插入下面的4条记录：

insert into  temp.test (numcode,agentcode,bankname,flag,timecode)values(1,'test1','beijingbank1',10.1,'2019-06-21 10:07:52’);
insert into  temp.test (numcode,agentcode,bankname,flag,timecode)values(2,'test2','beijingbank2',10.2,'2019-06-22 10:07:52’);
insert into  temp.test (numcode,agentcode,bankname,flag,timecode)values(3,'test3','beijingbank3',10.3,'2019-06-23 10:07:52’);
insert into  temp.test (numcode,agentcode,bankname,flag,timecode)values(4,'test4','beijingbank4',10.4,'2019-06-24 10:07:52');

• 更新 temp.test 中 numcode=1 的记录中 bankname 为 "guangzhoubank" 

  mysql> update  temp.test  set  bankname="guangzhoubank"  where  numcode=1;                    
  Query OK, 0 rows affected (0.00 sec)Rows matched: 0  Changed: 0  Warnings: 0

• 更新后再次查询，显示更新已经成功

 mysql> select * from   temp.test;

• 删除 temp.test 表中 numcode=1 的这条记录

  mysql> delete  from  temp.test where  numcode=1;
  Query OK, 0 rows affected (0.01 sec)
  mysql> select * from   temp.test;

• 在 PostgreSQL 客户端创建映射表，能够查询出数据

  temp=# create foreign table test
  temp-# (
  temp(# numcode int,
  temp(# agentcode text,
  temp(# bankname  text,
  temp(# flag decimal(8,4),
  temp(# timecode  text
  temp(# )
  temp-# server sdb_server
  temp-# options ( collectionspace 'temp', collection 'test', decimal 'on' );

• 连接 SparkSQL 客户端创建映射表，能够查询出数据

  create table temp.test (    
    numcode int,    
    agentcode string,    
    bankname string,    
    flag decimal(8,4),    
    timecode string
  )USING com.sequoiadb.spark OPTIONS ( host '10.139.***.***:11810', collectionspace 'temp', collection 'test') ;

以上证明 MySQL 、PostgreSQL 和Spark 三者之间数据是通的，数据可以共用。

 

4.2 使用Spark生成子表

• 连接 Spark 客户端，使用 create table as 的方式创建新表 test2

 create table temp.test2 USING com.sequoiadb.spark OPTIONS ( 
    host '10.139.***.***:11810’,
    domain 'allDomain’, 
    collectionspace 'temp’, 
    collection 'test2’, 
    ignoreduplicatekey 'true'  , 
    shardingkey '{"_id":1}’, 
    shardingType 'hash’ , 
    compressiontype 'lzw’ , 
    autosplit 'true’
  )as select * from temp.test ;

• 连接 MySQL 客户端，映射 Spark 创建的新表能够查询出同步的数据

mysql> create  table temp.test2    
     -> (    
     ->     numcode smallint,    
     ->     agentcode char(12),    
     ->     bankname varchar(120),    
     ->     flag decimal(8,4),    
     ->     timecode datetime    
     -> ); 
  mysql> select * from temp.test2;

以上证明通过 Spark 创建的表 MySQL 和 PostgreSQL 也可以正常使用。、

 

第五招：多副本机制的应用 

5.1 同城三副本高可用架构

其中有主备两个机房，其中主机房部署两个节点，备机房部署一个节点。三台机器共同组成一个数据组，其中选举逻辑遵循 Raft 协议。详细架构图如下所示：

5.2 主备一致性设置

在分布式系统中，一致性是指数据在多个副本之间数据保持一致的特性。SequoiaDB 巨杉数据库支持不同级别的主备一致性策略，以适配不同的应用场景。用户可根据业务对数据安全性和服务可用性的要求，选择不同的一致性策略。

1）强一致性

写所有节点当发生写操作时，数据库会确保所有复制组节点都同步完成才返回。写操作处理成功后，后续读到的数据一定是当前复制组内最新的。优势是能够有效的保证数据的完整性和安全性，劣势则是会降低复制组的写入性能，并且当集群内有一个节点故障或者异常时，无法写入数据，降低高可用性。

在核心交易型业务中，为了保证数据安全性，同时可以牺牲一定的写入性能时，推荐使用强一致性策略。

2）最终一致性

为了提升数据库的高可用性，以及实现数据的读写分离，SequoiaDB 默认采用“最终一致性”策略。在读写分离时，读取的数据在某一段时间内可能不是最新的，但副本间的数据最终是一致的。

写主节点在主节点执行写操作成功后，写操作即可返回。对数据查询一致性要求不高的业务，如历史数据查询平台，夜间批量导入数据以及白天提供查询业务，推荐使用写主节点的最终一致性策略。

其中强一致还是最终一致创建集合时由 ReplSize 这个参数来指定，创建集合时如设置 ReplSize 为-1表示强一致，默认为 ReplSize 值为1表示最终一致。根据使用场景来选择使用强一致还是最终一致，用户可以通过 db.setAttributes() 修改 ReplSize 属性。

 

第六招：多样化的监控工具

SequoiaPerf 工具除了能够协助用户对慢查询快速定位分析，还能够帮助用户全面监控 SequoiaDB 数据集群。在 SequoiaPerf 的首页上，用户可以对 SequoiaDB 数据库集群运行情况做一个宏观的浏览，快速查阅当前集群的运行情况。

 

在 SequoiaPerf 的服务器资源页面上，用户可以了解服务器更加详细的信息。

例如服务器磁盘的I/O使用情况，可以通过放大图表获得更加详细的数据。同时用户也可以通过页面右上角的时间栏，选择查看近期一段时间的资源使用情况。

 

小结

1. 巨杉数据库在数据管理中的突出能力

SequoiaDB 巨杉数据库是一款金融级分布式关系型数据库，产品引擎采用原生分布式架构，100%兼容 MySQL 语法和协议，支持完整的 ACID 和分布式事务。同时 SequoiaDB 还提供多模（multi-model）数据库存储引擎，原生支持多数据中心容灾机制，是新一代分布式数据库的首选。SequoiaDB 巨杉数据库可以为用户带来如下价值：

• 完全兼容传统关系型数据，数据分片对应用程序完全透明
• 高性能与无限水平弹性扩展能力
• 分布式事务与 ACID 能力
• 同时支持结构化、半结构化与非结构化数据
• 金融级安全特性，多数据中心间容灾做到 RPO = 0
• HTAP 混合负载，同时运行联机交易与批处理任务且互不干扰
• 多租户能力，云环境下支持多种级别的物理与逻辑隔离 

 

2. 实践成果

巨杉数据库完美解决目前传统数据库面临的痛点，降低了IT成本、提高运维效率，使数据能够有效给企业提供服务。其优势如下：

• 提高查询效率，使用 Spark 大表查询效率提高20倍。
• 容量多，合并同步了多个生产库、历史库的全部数据。
• 模式新，支持多种数据类型、结构化和非结构化。
• 扩容简单，支持快速扩容和缩容，基本有机器就能扩容。
• 上手简单，一键部署使用，降低dba学习成本。
• 查询引擎丰富，支持多种 SQL 查询引擎，丰富业务使用。
• 接口丰富，除了 SQL 还支持 JDBC、ODBC 和 API 多种接口，灵活使用。
• 系统完备，有新的业务系统随时可以接入。