关于mysql:TiDB-在茄子科技的应用实践及演进

1次阅读

共计 3071 个字符，预计需要花费 8 分钟才能阅读完成。

茄子科技（海内 SHAREit Group）是一家 全球化互联网科技公司 ，次要从事 挪动互联网软件研发与寰球挪动广告变现解决方案、跨境领取解决方案等互联网服务 等业务。茄子快传（SHAREit）是茄子科技旗下的代表产品，是一款 一站式数字娱乐内容与跨平台资源分享平台，累计装置用户数近 24 亿。茄子科技作为一家出海企业，曾经在东南亚、南亚、中东以及非洲等地区，打造了多款工具和内容的利用，并且在 Google Play 的下载榜上长年名落孙山。

茄子科技的产品矩阵较多，产品状态绝对比较复杂，包含了 工具、内容、游戏、广告、领取 等。针对绝对简单的业务场景，依据不同的业务状态，咱们做了不同的数据库选型。目前，茄子科技应用的六款最次要的数据库包含：

自研长久化 KV：特色平台、用户画像、行为记录等
Redis Cluster：业务缓存、session 信息等
Cassandra：内容库
MySQL：Hue、Metadata、经营平台等
ClickHouse：数据分析、实时报表
TiDB：用户增长、APM 零碎、云账单等

基于业务层面的痛点思考，咱们在多个业务场景引入了 TiDB：
第一，茄子科技作为一家出海企业引入了多家 私有云 作为基础设施，所以在数据库的层面，要思考业务在多云架构下的 业务适配、数据迁徙、数据库的兼容以及数据同步 的问题。
第二，茄子有多款高流量的 APP 产品，业务出现 高速增长 的态势，传统的 DRS 数据库，比方 MySQL，因为须要分库分表，妨碍业务疾速倒退。
第三，Cassandra、HBase 等 NoSQL 数据库，无奈满足 分布式事务，多表 join 等简单场景。

茄子科技的 APM 等零碎，有一些是 HTAP 场景，同一份业务数据既有 OLTP 又有 OLAP 的需要，咱们心愿一套数据库能够搞定。

引入 TiDB 之后，TiDB 在多个方面施展出独特劣势，帮忙茄子科技打造可继续倒退的数据库生态：

利用 TiDB 的 跨集群迁徙、数据同步 的能力打造多云架构下的业务扩大能力，满足多云架构下的业务架构设计。
TiDB 提供 主动程度弹性 扩大的能力，做到业务无感知，解决分库分表的问题。
TiDB 高度兼容 MySQL，在大容量、高并发的场景下学习成本低、迁徙成本低。
利用 TiDB HTAP 的能力，满足业务在一份数据上的 OLTP 与 OLAP 的双重需要。

TiDB 的利用实际–APM 场景利用

茄子科技的 APM（Application Performance Management）零碎提供 APP 解体、性能等问题的 监控、剖析、看板、修复 的一体化能力，用来撑持多款高增长的 APP 利用。这个零碎的第一个特点就是 信息量大 ，每天产生百亿条的数据，须要保留 30 天；第二个特点是 时效性 要求比拟高，针对一些比拟辣手的状况，比如说解体以及重大的性能问题，如果时效性不能满足的话会间接影响到用户的体验，甚至是产品的营收；第三个特点是须要买通 工单零碎，提供问题追踪、修复的一体化 能力；第四个特点是 在 OLTP 事务场景的根底上须要兼顾 OLAP 的剖析场景。

首先剖析一下晚期 APM 的数据流转，从 APP 数据上报到日志收集，最初到 ClickHouse，整个数据流转是一个相似 批处理 的流程，大略须要两个多小时，整体时效性偏弱，问题裸露不及时，会对用户体验产生影响。另外，这套零碎外面有 MySQL 和 ClickHouse 两套数据库。为什么这么设计？因为 ClickHouse 能够用来做 数据的剖析聚合 ，MySQL 次要是用来打造 流程工单 ，同时有两套数据库在撑持，在老本上比拟高。

再来看引入了 TiDB 之后的新版 APM 数据流转，能够看到从 APP 的上报，到看板展现，到报警，再到流程工单，实现 分钟级 的准实时看版展现和报警。这部分次要是借助了 TiDB 的 HTAP 能力，通过聚合剖析向看版进行展现，向报警核心进行及时的报警。同时，利用 TiDB 的 OLTP 能力进行看板的行更新。所以，咱们能够通过一套 TiDB 数据库买通看版、监控、问题的追踪和修复流程。

大家晓得 TiKV 是 TiDB 的 存储层 ，同时也是一个 Key-Value 数据库，接下来谈谈茄子科技基于 TiKV 打造分布式 KV 零碎的历程。茄子科技次要是提供工具和内容产品，产生的数据量十分大，KV 存储须要撑持两类场景：一类是 数据的实时产生 ，实时写入；另一类是针对 用户画像和特色引擎 ，将离线产生的大批量数据疾速地加载到在线的 KV 存储，为在线业务提供疾速的拜访，即 Bulk Load 能力，理论业务中须要 每小时 TB 级的吞吐量。

下图是茄子科技之前基于 Rocksdb 自研的分布式 KV，这个零碎同时满足上述的两类对 KV 的需要。图中右边展现的架构次要是 实时写入能力的实现 ，数据先从 SDK 到网络协议层，而后到拓扑层，再到数据结构的映射层，最初到 Rocksdb。左边是 Bulk Load 批量导入的流程。大家可能有一个疑难，为什么右边实时的写入流程不能满足小时级 TB 数据导入？次要起因有两点：一是因为 Rocksdb 的写放大，尤其在大 key 型场景下，Rocksdb 写放大是十分重大的。另一点是受限于单块盘的网络带宽，导致了单机负载或者单机存储是无限的。左边 整个批量导入的能力 是怎么实现的？它是通过 Spark 把 Parquet 进行数据解析、预分片以及 SST 生成，把 SST 上传到 Rocksdb 的存储节点，最初通过 ingest & compact 对立加载到 KV 层，供在线的业务进行拜访，单机吞吐每秒种能够达到百兆。

茄子科技既然曾经自研了基于 Rocksdb 的分布式 KV，为什么还要用到 TiKV？首先在技术层面，尽管自研分布式 KV 在生产曾经运行了两年多的工夫，撑持了上百 TB 的数据，然而有些技术问题，比方 主动弹性升缩、强一致性、事务和大 key 等反对上还须要进一步投入研发。第二，在 人才层面针对高质量数据库人才储备 还有肯定的欠缺。通过屡次调研以及和 TiKV 研发同学的沟通，发现咱们的需要和痛点与 TiKV 的产品布局是不约而同的，这就促使了咱们踊跃地拥抱 TiKV。咱们借助 TiKV 能够在技术上打造存储与计算拆散的 KV 产品。第三，TiKV 领有沉闷的开源社区，咱们能够借助社区的力量独特打磨产品。

下图中的架构是茄子科技基于 TiKV 打造的一款分布式 KV。左侧局部次要是解决数据实时写入的一个流程，从 SDK 到网络存储，到数据计算，最初到 TiKV 的存储引擎。咱们重点的钻研方向是右侧局部 整个 Bulk Load 能力 的研发，与自研的分布式 KV 的不同，把整个 SST 的生成流程放在 TiKV 外部去做，这样做的起因是能够 最大化地缩小 Spark 局部的代码开发和保护老本，晋升易用性。

以下两张表是基于 TiKV 的 Bulk Load 能力进行理论测试的后果。下面这张表是在 E5 CPU，40 个 vcore，磁盘应用 NVMe 的状况下，最大能够达到 256 兆 的单机吞吐。下边这张表是咱们在进行 Bulk Load 的同时对 online reading 局部进行压测，能够看到 Latency 响应工夫的抖动是十分小的，不论是 P99 还是 P99.99，都是处在一个 比较稳定 的状态。这个测试后果是一个 Demo 的验证，置信后续通过咱们的优化，不论是存储吞吐还是响应提早，都会有质的晋升。

Bulk Load 的能力是咱们和 TiKV 的研发同学一起，独特合作开发、独特演进的。咱们置信凋谢的力量，前面咱们会把整个架构，包含测试数据都会放到 GitHub 上公开，如果大家有相应的需要能够关注一下。

正文完