乐趣区

关于数据库:某邮储银行数据归集系统在HTAP场景下的选型与实践

导语:面对 HTAP 能力的需要与云原生时代的趋势,以及国产化的浪潮,某邮储银行携手 OceanBase 打造了云原生时代下的国产分布式数据库场景实际体验。以下内容整顿自某邮储银行运维方 DBA 的自述。

 

业务痛点

 

咱们有一套针对业务外部的经营数据归集零碎,各地的服务网点都将各类生产数据、经营数据及经营数据进行上报,还有前端用户埋点数据、各子系统生产数据表单会集,数据源的格局多样,数据聚合水平不一,计算形式简单多样。目前,咱们采纳两种形式进行数据采集。

  • 人工上报:通过员工自行制表、填表将数据上报至零碎中的固定页面,进行运算。
  • 机器抓取:一些老零碎或无奈提供接口,就须要通过 RPA 自动化机器人抓取数据,这是整个根底数据的起源。抓取数据后汇总,并用 Java 在程序中进行计算,将数据积淀至报表,以供前台实时读取。

面对每天的数据增长,而且外部经营零碎的数据不能间接实现实时剖析,须要将其汇总成特定格局进行转换计算,做成策略面板,提供顶层决策分析能力。咱们应用的数据库系统是 MySQL,在公众印象中,MySQL 侧重于 OLTP(联机事务处理),在 OLAP(在线剖析解决)方面的性能如高可用、备份等方面体现较弱,这些痛点在咱们应用 MySQL 的过程中也的确感触到了。而随着咱们业务并发量的进步和数据量的增长,既要求较强的 OLTP 能力,又须要 OLAP 能力的撑持,且软硬件及服务老本一直升高。面对传统关系型数据库的许多技术难题,比方海量数据下 sacle in or out(弹性扩大)的算力有余、不能原生解决单点故障和全链路高可用、OLTP+OLAP 场景无奈实现一体化,咱们决定摸索 HTAP(混合事务剖析解决)数据库,实现降本增效的指标。

 

产品调研

 

在决定摸索 HTAP 数据库后,咱们最先理解到的是 OceanBase。因为公司有一个我的项目正在应用阿里云的 PolarDB,但 PolarDB 必须在云端部署,而咱们的业务需要是本地部署,所以,OceanBase 成为咱们的首个钻研指标。OceanBase 兼容 MySQL 的个性很吸引咱们,而最终抉择 OceanBase 是出于以下几个因素。

  • 因素 1:稳固牢靠。 OceanBase 十二年稳固牢靠的产品力和在支付宝全外围场景替换 MySQL 的实际,以及利用于泛滥行业多个大型客户外围场景,为咱们在业务场景中应用它建设了信念。
  • 因素 2:AP 性能优良。 在相似的 OLAP 场景中,咱们已经应用过 GBase、PostgreSQL、Greenplum,在简单的 SQL 查问方面速度较慢,并且当用户量大的时候再连贯这些数据库,都会呈现各种各样的问题,也有可能是咱们本身资源有余的导致的。咱们在测试 OceanBase 的性能时,采纳现有环境即 2 核 40C80 线程、256GB 内存的环境,测试了 TPS 和 QPS,以下是在 3000 并发量下 Sysbench 的读写混合测试后果。这个测试后果齐全满足了业务要求。

 

SQL statistics:
    queries performed:
        read:                            2405494
        write:                           687284
        other:                           343642
        total:                           3436420
    transactions:                        171821 (2859.31 per sec.)
    queries:                             3436420 (57186.17 per sec.)
    ignored errors:                      0      (0.00 per sec.)
    reconnects:                          0      (0.00 per sec.)

General statistics:
    total time:                          60.0903s
    total number of events:              171821

Latency (ms):
         min:                                   29.15
         avg:                                  104.83
         max:                                  414.93
         95th percentile:                      155.80
         sum:                             18012703.78

Threads fairness:
    events (avg/stddev):           572.7367/30.91
    execution time (avg/stddev):   60.0423/0.02

 

因素 3:运维简略。 目前的业务需要须要在 AP 与 TP 之间找到一个平衡点,如果 AP 场景和 TP 场景应用不同的数据库,势必会减少技术栈的深度,增大运维难度,而业务对于两种应用场景并不是强依赖的关系。应用混合型的 HTAP 产品,无疑是最好的抉择,也是一种良好的摸索与尝试。OceanBase 运维简略,只需一套 OCP 工具就能搞定。且零碎告警提供了丰盛的扩大性能,能够与现有监控对接。运维人员每天只是关注重要数值,察看有没有报警,运维治理比拟轻松。

因素 4:国产化趋势。 咱们无奈意料 MySQL 在将来是否会被限度,也无奈确定是否所有零碎都会逐步成 Linux,但能够必定的是要防患于未然。因而,钻研齐全国产自研且开源的数据库是一条前途,将来如果真要替换全副零碎,至多到那时咱们曾经有肯定的技术积攒和积淀,可能应答引进软件限度的问题。

因素 5:实用业务且容错。 OceanBase 主打 HTAP,具备高可用和容灾能力,十分实用于咱们的业务。同时,咱们要利用数据库的零碎不齐全是生产零碎,而是一个后盾的报表,它处于外围零碎与边缘系统之间,有肯定的容错性,因而,决定先在这个报表环境中尝试应用 OceanBase。

因素 6:及时响应。 OceanBase 开源后社区活动与响应都很踊跃,尽管有些生态还在欠缺,然而能感觉到 OceanBase 开源的产品力在显著进步。

 

场景实际

 

决定应用 OceanBase 后,咱们开始了环境部署,表 1 列出部署参数。

 

图 1 OceanBase 三节点部署架构

 

上文提到,随着业务数据量的增大,咱们本来应用的 MySQL 不合乎业务要求,部署 OceanBase 后,咱们开始重构零碎和底层数据底座,经验了以下四个阶段。

 

第一,POC 阶段。“如果有什么问题或者和 MySQL 不统一,你们就间接报错,咱们看如何解决”,这是我过后对 OceanBase 的研发反对人员说的话,但我惊喜地发现,OceanBase 可能与咱们应用的 MySQL 5.7.18 版本良好兼容,能够轻松实现零老本迁徙。在此过程中,咱们遇到了两个问题,一是 SQLSTATE[0A000]: Feature not supported: 1235 while parameter _ob_enable_prepared_statement is disabled, prepared statement not supported,通过参数调整,轻松搞定;二是利用数据的迁徙人员在应用 Navicat 进行迁徙的时候,呈现了一些结构化语句不兼容的问题,咱们惊喜地发现 Navicat16.1 版本开始,有了 OceanBase 的专用驱动连贯,应用后兼容性问题完满解决。

 

第二,数据迁徙阶段。 咱们应用了 OceanBase 迁徙服务(OceanBase Migration Service,OMS)实现了 MySQL 数据的在线无缝迁徙。

 

第三,数据库侧革新阶段。 咱们的利用测试根本不必革新,就将 MySQL 的分区数据、表构造等迁徙到了 OceanBase,并且所有运行失常,查问性能和查问效率都超出预期。同时,对于开发人员来说,他们无需投入学习老本,在 OB 上操作与此前在 mysql 上无异。

 

第四,实际上线阶段。 在该阶段,咱们暂停了业务写入,期待零碎迁徙实现,并在新业务流量写入 OceanBase 集群后,察看业务稳定。割接后近一个月的试用,零碎运行稳固,剖析数据处理工夫缩短到了原来的 1 /3,达到了咱们的应用预期。

 

业务播种

 

以上就是咱们利用 OceanBase 的实际过程。从业务角度看,在此次的数据库实际中,咱们有五点播种。

 

  • 原生的高可用体系: OceanBase 基于 PAXOS 协定高可用,防止单点故障,RPO=0。
  • 无感知的 DDL: OceanBase DDL 无感知,能够放慢业务迭代效率。
  • 欠缺的治理平台: OCP 平台集成了部署、监控、诊断等性能,大大降低了运维与开发成本。
  • 线上扩大能力: 前期业务数据体系能够通过横向减少机器资源实现 scale in or out。
  • 赋能 HTAP 能力: 数据读写与实时统计分析场景用一个数据产品解决。

 

当然,对于 OceanBase,咱们也有三个冀望与倡议。

  • 心愿 OCP 实现集成性能测试。
  • 应用 SATA 硬盘理论测试出的 TPS 是官网的 1 /2,倡议应用 SSD 作为硬盘存储。
  • 冀望 OceanBase 能在更多场景替换 MySQ,并不断完善其三地五核心等高级能力。

不得不说,随着国产化浪潮和云原生趋势的推动,企业对数据产品的要求日趋增高。面对老牌数据产品的能力,或者敢于尝试一些优良的新型产品能力找到良好的解决方案。此次对 OceanBase 的摸索,让咱们解决了以往在高可用、线性扩大、存储老本等方面遇到的难题,并且,在领有了 HTAP 能力的同时还能继续升高业务老本。

退出移动版