巨杉Tech-分布式数据库六招玩转HTAP场景

随着企业应用的类型一直拓展，在海量数据、高并发、多类型数据的利用场景下，底层数据平台对于混合数据类型、混合业务场景解决能力的要求不断扩大，这就催生了 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;                    

• 更新后再次查问，显示更新曾经胜利

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 多种接口，灵便应用。
• 零碎齐备，有新的业务零碎随时能够接入。