关于tidb:LiveMe-x-TiDB丨单表数据量-39-亿条简化架构新体验

近些年，因为互联网的疾速倒退以及线上需要的暴发，直播在国内曾经成为一个十分成熟的商业模式。在娱乐、教育、办公等场景中涌现出许多优良的视频直播产品。随着国内市场竞争日益白热化，加之企业出海渐成趋势，越来越多的直播公司抉择走进来，寻找新的海内直播市场，借鉴国内成熟的产品、经营以及商业模式，让寰球的用户都用上中国人发明的产品，LiveMe 便是胜利的出海直播产品之一。

LiveMe 是一个寰球直播和社交平台，于 2016 年 4 月推出。LiveMe 的产品性能包含 H2H、多人聊天、虚构形象直播、蹦迪房等，它使用户可能随时随地直播、并观看其余精彩的直播以及与世界各地的敌人进行视频聊天。目前 LiveMe 已在寰球积攒了超过 1 亿用户和超过 300 万的主播。它已成为美国最受欢迎的社交应用程序之一，并已在 200 多个国家和地区推出。

业务痛点

与其余行业出海一样，直播产品的出海也面临着许多全球化挑战。如各地的合规监管、本地化经营、继续翻新、政治文化差异等，都为直播产品出海带来微小挑战。而在出海的过程中，底层的技术能力帮忙 LiveMe 在老本节约、用户增长、金融风控、晋升研发效率等方面一直实现精细化经营与业务翻新。

通过了多年的积淀，LiveMe 在业务上曾经造成了线上微服务主导，线下计算中心主导的技术架构。线上业务是通过 Go 语言开发的一套微服务架构，每个服务依据不同业务个性具备本人独立的存储。线下业务是由数据研发团队来保护，通过 sqoop 和 MySQL Binlog 同步等形式从数据库层面抓取数据到数据仓库，实现一系列业务相干的反对。

这套业务架构中线上业务次要面临着以下痛点：

第一，尽管实现了微服务分库的设计，每个服务都有本人独立的数据库，然而每个业务中又存在很多业务上的大表，都存在 MySQL 分表的景象。在典型的分表场景中，数据库表会依照用户的 UID 尾号通过 MD5 后分到 256 张表，然而与日俱增后又须要再依据工夫日期做一个垂直的分表，导致数据库表无奈实现聚合查问，再加上跨时间段的分表需要，很多场景无奈满足线上需要。

第二，对于剖析型业务数据而言，须要保证数据的实时性，并保留数据细节。实时的数据分析，能够在业务上更快做出决策，例如在一些流动经营场景中，业务团队须要疾速从各个数据维度来分组统计察看流动成果；在金融相干风控业务中，须要依据各个维度疾速聚合来判断各项数据是否达到风控模型的阈值。如果应用离线计算的形式，数据的实时性根本无法失去保障；此外，通过离线计算或者实时计算过的数据，如果用户反馈数据有问题，须要查看数据的细节也很难实现。

第三，各种精细化经营需要，例如举荐、个性化经营等场景一直减少，对于数据的实时要求越来越高。因而，LiveMe 急需一种更简略，同时让线上线下业务做好均衡的计划。

此时，如果 LiveMe 持续抉择大数据技术栈解决痛点就会面临以下挑战：1）大数据技术栈的架构非常复杂，中间件过多；2）须要额定的技术栈学习老本，比方如果应用数据同步，就须要 sqoop、scala、kafka 等中间件，会大幅减少整个业务的复杂性；3）心愿线上业务以及架构非常简单，可能简化到一般开发人员只有可能 CRUD（减少 (Create)、读取(Read)、更新(Update) 和删除(Delete)）数据库就能够上手开发。

为什么抉择 TiDB？

基于以上业务挑战，LiveMe 通过一系列技术选型后最终抉择了 TiDB 数据库。TiDB 的以下个性能够帮忙 LiveMe 很好的应答挑战：

1. TiDB 的性能大于等于 MySQL；
2. TiDB 的 HTAP 个性可能解决线上大表的问题，在后盾或者一些实时剖析场景中，其 OLAP 剖析能力可能保障实时数据报表；
3. TiDB 引入的 MPP 架构剖析能力，使得 OLAP 查问速度十分快，这也是 OLAP 数据库架构上的技术方向；
4. TiDB 团队有着欠缺和业余的技术支持，在过程中能够帮忙 LiveMe 解决很多问题，在线上大规模应用后也没有后顾之忧。

如何利用 TiDB 实现实时聚合查问

鉴于 LiveMe 的微服务架构，如果将数据源全副替换，工程量大且不能欲速不达，因而就须要一种兼容性的计划，在保障线上业务不受影响的同时也能应用 TiDB 的个性来解决 LiveMe 的业务痛点。因而，对于须要聚合查问的业务，LiveMe 通过音讯队列播送的形式，在业务层订阅相干事件再补充业务侧须要的宽表信息写入 TiDB，基于 TiFlash 就能够做到实时的经营报表。业务开发人员只须要编写对应的 SQL 查问，就能够轻松实现需要。没有了简单的 ETL 过程，大大简化了开发流程。

对于业务数据，LiveMe 应用 AWS SQS 音讯队列，相比 Kafka 的劣势在于每条数据都是原子性的，每条数据都能够用来做幂等重试，来保证数据的最终一致性。目前，这套技术计划曾经撑持了 LiveMe 的流动经营和金融风控等多个业务场景，满足了 LiveMe 对于线上大量数据实时聚合查问的要求。

如何应用 TiDB 简化技术架构

LiveMe 有一个相似朋友圈性能的场景，这个业务中存在两个技术难点：第一是对于数据的无限量增长存储如何实现扩容；第二是数据的冷热拆散，这又波及到数据老本的问题。

以用户发 Twitter 的场景举例：如果用户发了一条 Twitter，它会写入到本人所有的关注列表，比方有 100 个粉丝，就写入 100 条，如果有 10 万粉丝就须要写入 10 万条数据，这是一个典型的写扩散场景。这个场景带来的成果是数据爆炸半径十分大，如果某流量网红发一条 Twitter，数据写入量会十分大，因而须要一个可能靠近于有限扩容的存储机制才能够实现这个场景。

<center>Twitter 的技术实现 </center>

Twitter 是通过保护一个 redis-cluster 来解决 feed 散发的存储。LiveMe 的技术团队也想到应用这种技术架构，技术团队通过选型思考应用 codis 集群来做存储，但通过对老本的考量，认为这个计划是不可行的，大量的 feed 冷数据存储在 codis 这样的内存密集型数据库中，老本十分高。因而，技术团队面临的挑战是如何用低成本的形式去实现一个写扩散的场景。

<center>Twitter 的解决方案 </center>

基于 TiDB 解决方案，LiveMe 技术团队在上述写扩散场景中，把扩散写入的局部替换成了 TiDB，应用一张数据库表来存储所有 feed 的写入关系，比方用户有 100 万粉丝，就在数据库里插入 100 万条数据。基于 TiDB 的分布式数据库个性，帮忙 LiveMe 简略高效地解决了数据增长扩容问题。

基于此技术架构，技术团队简化了一个典型的 redis 缓存设计问题，热数据放在 redis 中，用 mget 来获取。冷数据放在 TiDB 中，用 select in 查问，这样做数据冷热辨别就非常容易，甚至能够实现一个简略的布隆过滤器来理解哪些数据在热数据，哪些数据在冷数据里。以此缩小有效数据的回源，更高效获取数据。

LiveMe 的朋友圈性能基于 TiDB 的分布式存储个性进行技术改造后，feed 表从 2021 年中旬上线至今曾经达到数十亿数据写入，当初的数据量单表 39 亿条。因为这些数据是永恒保留不会删除的，所以该数据也会始终增长。

将来布局

将来，LiveMe 将会持续尝试 TiDB 在更多业务中，一方面会做数据库治理开发；另一方面将对于强事务依赖交易型的业务尝试应用 TiDB，为直播电商场景做技术储备。