建立网站免费,在建设银行网站能换美元吗,外贸网站建设公司流程,保险公司早会新闻资讯携程#xff0c;一家中国领先的在线票务服务公司#xff0c;从 1999 年创立至今#xff0c;数据库系统历经三次替换。在移动互联网时代#xff0c;面对云计算卷积而来的海量数据#xff0c;携程通过新的数据库方案实现存储成本降低 85% 左右#xff0c;性能提升数倍。本文…携程一家中国领先的在线票务服务公司从 1999 年创立至今数据库系统历经三次替换。在移动互联网时代面对云计算卷积而来的海量数据携程通过新的数据库方案实现存储成本降低 85% 左右性能提升数倍。本文讲述携程在历史库场景下如何解决水平扩容、存储成本、导入性能等痛点以及对于解决方案的制定和思考过程。 自创立之初携程前期业务以使用 SQL Server 数据库为主。在 MySQL 传入国内并大行其道时携程也在 2016-2018 年将数据库逐步从 SQL Server 转到 MySQL 数据库。但是随着技术多元化及业务的不断发展MySQL 逐渐显露瓶颈如扩容工艺复杂、数据存储成本高、表相关维护操作耗时等如今已无法满足携程需求。 因此携程在生产环境数据量过大时尝试将生产环境中业务访问极少的冷数据归档到历史库以减少生产环境中的数据量降低生产环境中的查询时延、表结构变更时延等关键性能指标。 最初携程使用 MyRocks RocksDB for MySQL 作为历史库只因其兼容 MySQL 主从架构且自带压缩对成本节约友好。如下图所示今年上半年国内、国外机票预定量倍增订单量相应增加但随着业务数据量的激增 MyRocks 扩容难的问题暴露了出来。由于 MyRocks 无法适应如此快速的数据增长携程需要再次考虑历史库选型引入新的架构进行优化。 在历史库选型过程中携程重点关注以下四个方面 水平扩缩容。所选数据库是否能够水平扩缩容、扩缩容后是否方便进行负载均衡 迁移便捷度。是否方便数据迁移 降本。是否有足够低的存储成本 增效。数据写入历史库的性能是否能达到要求。 基于上一次的历史库选型经验和产品调研此次携程决定对完全自研且开源的分布式数据库 OceanBase 进行初步考察。除了高度兼容 MySQL 外OceanBase 还具备透明水平扩展、高可靠、数据压缩能力强等特点。于是携程根据业务场景对 OceanBase 数据库做了进一步的调研和测试。 如下图所示携程对 MySQL 业务迁移至 OceanBase 的容量进行了测试对比依据压缩算法的原理表对比压缩率与数据类型、重复度等密切相关所以携程采用了整库迁移对比希望更接近实际场景。结果显示MySQL 容量 2.1TB迁移到 OceanBase 后为 264GB数据压缩比 8:1。 空间对比MySQL蓝 vs OceanBase橙 此外在测试过程中携程也考察了 OceanBase 在水平扩缩容、迁移便捷度以及性能方面的表现最终决定应用 OceanBase上线后效果符合预期。 一、水平扩缩容 携程最初使用 MySQL 作为归档历史库当集群空间也达到上限时采用了分库分表的解决方案。分库分表的方案在一定程度上带来了水平扩展的能力降低了业务的系统性风险。 与此同时分库分表方案使携程历史库面临诸多问题。 问题 1在通过增加节点进行水平扩容时需要 DBA 介入数据的迁移过程利用人工完成数据的 rebalance。 问题 2 额外的数据管理负担和数据运算压力在某些场景下需要遍历每个 ShardDB并执行相同语句获取结果。此时请求量会翻倍一旦出现慢 SQL容易导致进程堆积。 问题 3分库分表方案多种多样如果开发人员设计不合理或使用不当会出现数据分布不均的问题。 综合以上问题我们在对历史库进行选型时希望能够找到一款可以同时支持对业务无感的在线扩缩容、自动负载均衡及分布式事务的原生分布式数据库。 OceanBase 是原生分布式数据库基于 Multi-Paxos 实现了分布式一致性协议支持分布式事务同时支持透明水平扩展满足业务快速扩容缩容的需求扩容后分区表的数据会自动均衡到新节点上对上层业务透明节省迁移成本。 在携程业务高速发展时历史库的扩容操作对业务透明这些特性完美地解决了携程历史库业务场景在最初使用分库分表策略时的各种痛点。 携程历史库在使用 MySQL 分库分表方案时将数据按照月、日进行分表需要开发人员在发布系统上主动配置应用代码需要进行改造。一旦容量告警需要 DBA 人工介入进行数据拆分。而在 OceanBase 中只需要创建以时间作为分区键的 range 分区表OceanBase 会自动将分区表的多个分区均匀地分散在每个 Zone 的各台节点上。每台节点均可以独立执行 SQL如果应用需要访问的数据在不同机器上节点自动将请求路由至数据所在的机器对业务完全透明。 扩容时只需要在集群维度为其增加资源节点通过修改租户资源规格的方式可以将资源分配给指定租户然后集群的 RootService 会调度分区副本在各 Zone 内部进行迁移直到各节点的负载差值小于用户配置的阈值。各个分区主副本也会在每个节点上进行自动均衡避免主副本的分配倾斜导致部分节点的请求负载过大。 二、数据迁移 在传统异构数据迁移方案中通常有两种方式一种是静态数据迁移确保数据静态后使用导出工具的方式进行迁移另一种是需要开发人员在业务代码中进行双写。针对 MySQL 历史库的迁移携程最终选择 OMS进行数据迁移。 OMSOceanBase Migration Service OceanBase 迁移服务是一种支持同构或异构数据源与 OceanBase 之间进行数据交互的服务具备在线迁移存量数据和实时同步增量数据的能力。OMS 支持了携程历史库的在线不停服迁移整个迁移过程中业务应用无感知。 OMS 提供了可视化的集中管控平台支持为数据迁移过程进行全生命周期的管理服务在管控界面上即可完成对数据迁移和数据同步任务的创建、配置、监控和管理交互简单方便。同时还提供了多种数据一致性校验方式更加全面、省时、高效地保证数据质量。 携程通过 OMSOceanBase Migration Service提供的不停服数据迁移功能将现有的 MySQL 历史库通过 OMS 平滑迁移至 OceanBase在迁移过程中没有进行业务上的改造。迁移过程中原 MySQL 历史库持续对外提供服务将数据迁移对业务的影响最小化。 三、存储成本 数据压缩是降低海量数据存储空间占用的关键手段。OceanBase 高压缩比的分布式存储引擎 摒弃了传统数据库的定长数据块存储 采用基于 LSM-Tree 的存储架构和自适应压缩技术创造性地解决了传统数据库无法平衡“性能”和“压缩比”的难题。 OceanBase 支持 zlib、snappy、lz4 和 zstd 四种压缩算法。在通用压缩的基础上OceanBase 自研了一套对数据库进行行列混存编码的压缩方法encoding使用行列的字典、差值、前缀等编码算法在通用压缩算法之前对数据做了编码压缩带来更大的压缩率进一步降低存储成本。 存储层会根据数据特征自适应地选择最优的编码规则合并时会计算数据的压缩比如果发现压缩比不高会尽快回退选择其他的编码方式从而确保数据编码的过程不会影响正常的数据写入性能。 OceanBase 在数据压缩方面的表现十分优秀携程 MySQL 历史库中大小为 475G 的表迁移到 OceanBase 后仅占 55G平均存储资源仅为原来的 1/8存储成本降低 85% 左右。 四、导入性能 携程历史库除了看重水平扩展性、存储成本等因素外还对历史库的大量归档数据导入性能提出了较高要求。OceanBase 的并行执行框架能够将 DML 语句通过并发的方式进行执行 Parallel DML 对于多节点的数据库实现了多机并发写入并且保证大事务的一致性。结合异步转储机制还能在很大程度上优化 LSM-Tree 存储引擎在内存紧张的情况下对大事务的支持。 我们可以通过这样一个例子来体验 PDML以 TPC-H 的 lineitem 表为基础创建一张相同表结构的空表 lineitem2。然后以 INSERT INTO...SELECT 的方式将 lineitem 的全部 600 万行数据插入新表 lineitem2 中。然后我们分别用关闭和开启 PDML 的方式执行观察其效果和区别。 首先复制 lineitem 的表结构创建 lineitem2。需要注意的是在 OceanBase 数据库中我们使用分区表进行数据扩展此处的例子中我们使用 16 个分区那么对应的 lineitem2 也应完全相同 obclient [test] SHOW CREATE TABLE lineitem;
CREATE TABLE lineitem ( l_orderkey bigint(20) NOT NULL, l_partkey bigint(20) NOT NULL, l_suppkey bigint(20) NOT NULL, l_linenumber bigint(20) NOT NULL, l_quantity bigint(20) NOT NULL, l_extendedprice bigint(20) NOT NULL, l_discount bigint(20) NOT NULL, l_tax bigint(20) NOT NULL, l_returnflag char(1) DEFAULT NULL, l_linestatus char(1) DEFAULT NULL, l_shipdate date NOT NULL, l_commitdate date DEFAULT NULL, l_receiptdate date DEFAULT NULL, l_shipinstruct char(25) DEFAULT NULL, l_shipmode char(10) DEFAULT NULL, l_comment varchar(44) DEFAULT NULL, PRIMARY KEY (l_orderkey, l_linenumber), KEY I_L_ORDERKEY (l_orderkey) BLOCK_SIZE 16384 LOCAL, KEY I_L_SHIPDATE (l_shipdate) BLOCK_SIZE 16384 LOCAL) partition by key(l_orderkey) (partition p0, partition p1, partition p2, partition p3, partition p4, partition p5, partition p6, partition p7, partition p8, partition p9, partition p10, partition p11, partition p12, partition p13, partition p14, partition p15); 在不开启 PDML 的情况下创建好 lineitem2 后我们先以默认配置不开启并行的方式插入, 因为这是一个 600 万行的大事务我们需要将 OceanBase 数据库默认的事务超时时间调整到更大的值单位为 μs
obclient [test] INSERT INTO lineitem2 SELECT * FROM lineitem;Query OK, 6001215 rows affected (1 min 47.312 sec)Records: 6001215 Duplicates: 0 Warnings: 0 可以看到不开启并行的情况下单个事务插入 600 万行数据OceanBase 的耗时为 107 秒。 下面我们通过添加一个 Hint开启 PDML 的执行选项。再次插入前我们先将上次插入的数据清空。来看这次的执行耗时
obclient [test] TRUNCATE TABLE lineitem2;Query OK, 0 rows affected (0.108 sec)
obclient [test] INSERT /* parallel(16) enable_parallel_dml */ INTO lineitem2 SELECT * FROM lineitem;Query OK, 6001215 rows affected (22.117 sec)Records: 6001215 Duplicates: 0 Warnings: 0 可以看到开启 PDML 后相同的表插入 600 万行数据OceanBase 数据库的耗时缩短为 22 秒左右。PDML 特性带来的性能提升大约为 5 倍数据写入性能远超 MySQL并发 DML 这一特性支撑了携程批量归档数据快速导入历史库的需求。 总的来说到目前为止携程已经把众多核心业务迁移到 OceanBase 数据库。携程历史库场景经过 OceanBase 替换 MySQL 的实践后取得了以下四点主要收益。 第一无缝 scale-in or out使用普通的 PC 服务器即可构建超高吞吐的 OceanBase 集群无需分库分表快速按需扩展并为携程历史库在水平扩展过程中提供了平滑的成本增长曲线。 第二数据迁移对业务透明OMS 支持全量数据迁移、增量数据同步支持主流数据库的一站式数据迁移高效地完成了携程历史库数据到 OceanBase 的迁移。 第三降低存储成本 85% 左右基于 OceanBase 的高级压缩技术在保证性能的同时数据存储空间节约近 85%。同等硬件投入的前提下OceanBase 支持携程历史库存储更多数据。 第四数据写入性能优秀OceanBase 的无共享架构、分区级主副本打散以及并行执行框架提供的 Parallel DML 能力真正实现了高效的多节点写入。利用该特性数据写入性能提升了数倍能够从容应对携程历史库的超高并发数据写入需求。 目前携程使用的是 OceanBase 3.x 版本未来将逐步升级至 4.x 版本以获得更好的性能和写入效率。此外OceanBase 4.x 高度兼容 MySQL 8.0并支持租户级别的物理备份这将有利于携程做数据的离线备份以及能够更快地恢复备份。
