快捷搜索:  as  2018  FtCWSyGV  С˵  test  xxx  Ψһ  w3viyKQx

和记娱乐和记怡情AG:GMV达百亿美元的Shopee 是如何进行数据库选型的?



Shopee于2015岁尾上线,是东南亚地区领先的电子商务平台,覆盖东南亚和台湾等多个市场,在深圳和新加坡分手设有研发中间。本文系Shopee的散播式数据库选型思路座谈。由于是『座谈』,可能不成体系,但会着重先容一些履历以及踩过的坑,供给给大年夜家参考。

1 Shopee的数据库应用环境

Shopee在用哪些数据库?

先说一下当前Shopee线上在用的几种数据库:

在Shopee,我们只有两种关系数据库:MySQL和TiDB。今朝大年夜部分营业数据运行在MySQL上,TiDB集群的比重以前一年来快速增长中。

Redis在Shopee各个产品线应用广泛。从DBA的角度看,Redis是关系数据库的一种紧张弥补。

内部也在应用诸如HBase和Pika等多种NoSQL数据库,应用范围多限于特定营业和团队。不在本次评论争论范围内。

数据库选型策略

以前的一年里,我们显着感到到数据库选型在DBA日常事情中的占比越来越重了。跟着营业快速生长,DBA每周必要创建的新数据库较之一两年前可能增添了十倍不止。我们每年都邑统计几回线上逻辑数据库个数。上图展示了以前几年间这个数字的增长趋势(纵轴表示逻辑数据库个数,我们把详细数字隐去了)。

历史数据显示,逻辑数据库个数每年都有三到五倍的增长,以前的2019年增长倍数以致更高。每个新数据库上线前,DBA和开拓团队都必要做一些评估以快速抉择物理设计和逻辑设计。履历注解,一旦在设计阶段做出了欠妥抉择,后期必要付出较多光阴和人力成原先解救。是以,我们必要拟订一些简洁高效的数据库选型策略,确保我们大年夜多半时刻都能做出精确选择。

我们的数据库选型策略可以概括为三点:

默认应用MySQL。

积极考试测验TiDB。

在需要的时刻引入Redis用于消解部分关系数和记娱乐和记怡情AG据库高并发读写流量。

在应用MySQL的历程中我们发明,当单数据库体量达到TB级别,开拓和运维的繁杂度会被指数级推高。DBA日常事情和记娱乐和记怡情AG会把打消TB级MySQL数据库实例排在高优先级。

“积极考试测验TiDB”不是一句空论。2018年头?年月开始,我们把TiDB引入了到Shopee。以前两年间TiDB在Shopee从无到有,集群节点数和数据体积已经达到了可不雅的规模。对付一些颠最后验证的营业场景,DBA会积极推动营业团队采纳TiDB,闪开拓团队有时机得到第一手履历;今朝,内部多半营业开拓团队都在线上实际应用过一次或者多次TiDB。

关于借助Redis消解关系数据库高并发读写流量,后面会展开讲一下我们的做法。

散播式数据库选型参考指标

在拟订了数据库选型策略之后,我们在选型中还有几个常用的参考指标:

1TB:对付一个新数据库,我们会问:在未来一年到一年半光阴里,数据库的体积会不会涨到1TB?假如开拓团队很确信新数据库必然会膨胀到TB级别,应该急速斟酌MySQL分库分表规划或TiDB规划。

1000万行或10GB:单一MySQL表的记录条数不要跨越1000万行,或单表磁盘空间占用不要跨越10GB。我们发明,跨越这个阈值后,数据库机能和可掩护性上每每也轻易出问题(部分SQL难以优化,不易做表布局调剂等)。假如确信单表体积会逾越该上限,则应斟酌MySQL分表规划;也可以采纳TiDB,TiDB可实现水平弹性扩展,多半场景下可免去分表的烦恼。

每秒1000次写入:单个MySQL节点上的写入速度不要跨越每秒1000次。大年夜家可能感觉这个值太低了;许多开拓同砚也常举例辩驳说,线上MySQL每秒写入几千几万次的实际案例比比皆是。我们为什么把指标定得如斯之低呢?首先,上线前做估算每每有较大年夜不确定性,正常状况下每秒写入1000次,大年夜匆匆等特殊场景下可能会陡然飙升到每秒10000次,作为设计指标守旧一点对照安然。其次,我们容许开拓团队在数据库中应用Text等大年夜字段类型,当单行记录长度增大年夜到必然程度后主库写入和从库复制机能都可能显着劣化,这种状况下对单节点写入速度不宜有太高等候。是以,假如一个项目上线前就估计到每秒写入速度会达到上万次以致更高,则应该斟酌MySQL分库分表规划或TiDB规划;同时,不妨根据详细营业场景看一下能否引入Redis或消息行列步队作为写缓冲,实现数据库写操作异步化。

P99相应光阴要求是1毫秒,10毫秒照样100毫秒?利用法度榜样要求99% 的数据库查询都要在1毫秒内返回吗?假如是,则不建议直接读写数据库。可以斟酌引入Redis等内存缓冲规划,前端直接面向Redis确保高速读写,后端异步写入数据库实现数据持久化。我们的履历是,多半场景下,MySQL办事器、表布局设计、SQL和法度榜样代码等方面做过细致优化后,MySQL有望做到99% 以上查询都在10毫秒内返回。对付TiDB,斟酌到其存储谋略分离和多组件协作实现SQL履行历程的特征,我们平日把预期值调高一个数量级到100毫秒级别。以线上某TiDB 2.x集群为例,上线半年以来多半时刻P99都保持在20毫秒以内,有时会飙升到200毫秒,大年夜匆匆时哆嗦则更频繁一些。TiDB履行SQL查询历程中,不合组件、不合节点之间的交互会多一些,自然要多花一点光阴。

要不要分库分表?

内部的数据库设计评估清单里包孕十几个项目,此中“要不要分库分表”是一个紧张议题。在相称长光阴里,MySQL分库分表规划是我们实现数据库横向扩展的独一选项;把TiDB引入Shopee后,我们多了一个“不分库分表”的选项。

从我们的履历来看,有几种场景下采纳MySQL分库分表规划的副感化对照大年夜,日常开拓和运维都要付出额外的价值和资源。DBA和开拓团队必要在数据库选型阶段甄别出这些场景并有的放矢。

难以准确预估容量的数据库。举例来讲,线上某日志数据库以前三个月的增量数据跨越了之前三年多的存量体积。对付这类数据库,采纳分库分表规划必要一次又一次做Re-sharding,每一次都步骤繁琐,工程浩大年夜。Shopee的实践证实,TiDB是较为抱负的日志存储规划;当前,把日志类数据存入TiDB已经是内部较为普遍的做法了。

必要做多维度繁杂查询的数据库。以订单数据库为例,各子系统都必要按照买家、卖家、订单状态、支付要领等诸多维度筛选数据。若以买家维度分库分表,则卖家维度的查询会变得艰苦;反之亦然。一方面,我们为最紧张的查询维度分手建立了异构索引数据库;另一方面,我们也在TiDB上实现了订单汇总表,把散落于各个分片的订单数据汇入一张TiDB表,让一些必要扫描全量数据的繁杂查询直接运行在TiDB汇总表上。

数据倾斜严重的数据库。诸如点赞和关注等偏社交类营业数据,按照用户维度分库分表后常呈现数据散播不平均的征象,少数分片的数据量可能弘远年夜于其他分片;这些大年夜分片每每也是读写的热点,进而轻易成为机能瓶颈。一种常用的解法是Re-sharding,把数据分成更多片,只管即便稀释每一片上的数据量和读写流量。近来我们也开始考试测验把部分数据搬家到TiDB上;理论上,假如TiDB表主键设计得高度分散,热点数据就有望平均散播到全体TiKV Region上。

总体来说,MySQL分库分表规划在办理了主要的数据库横向扩展问题的同时,也导致了一些开拓和运维方面的痛点。一方面,我们努力在MySQL分库分表框架内办理懈弛解各类问题;另一方面,我们也考试测验基于TiDB构建“不分库分表”的新型办理规划,并取得了一些进展。

2 MySQL在Shopee的应用环境

Shopee的母公司SEA Group成立于2009年。我们从一开始就应用MySQL作为主力数据库,从早期的MySQL 5.1徐徐进化到现在的MySQL 5.7,我们已经用了十年MySQL。

我们应用Percona分支,当前存储引擎以InnoDB为主。

一主多从是对照常见的支配布局。我们的利用法度榜样对照依附读写分离,线上数据库可能会有多达数十个从库。一套范例的数据库支配布局会散播在同城多个机房;此中会有至少一个节点放在备用机房,主要用于准时全量备份,也会供给给数据团队做数据拉取等用途。

假如利用法度榜样必要读取Binlog,从库上会安装一个名为GDS(General DB Sync)的Agent,实时解析Binlog,并写入Kafka。

利用法度榜样透过DNS进口连接主库或从库。

我们自研的数据库中心件,支持简单的分库分表。作甚“简单的分库分表”?只支持单一分库分表规则,可以按日期、Hash或者某个字段的取值范围来分片;一条SQL终极只会被路由到单一分片上,不支持聚合或Join等操作。

若何办理TB级MySQL数据库的应用?

根据我们的统计,Shopee线上数据库中80% 都低于50GB;此外,还有2.5% 的数据库体积跨越1TB。上图列出了部分TB级别数据库的一个统计结果:匀称体积是2TB,最大年夜的以致跨越4TB。

采纳MySQL分库分表规划和迁移到TiDB是我们减少TB级MySQL数据库实例个数的两种主要道路。除此之外,还有一些法子能赞助我们抗衡MySQL数据库体积膨胀带来的负面效应。

旧数据归档。很多旧数据库盘踞了大年夜量磁盘空间,读写却不频繁。换言之,这些旧数据很可能不是『热数据』。假如营业上许可,我们平日会把旧数据归档到零丁的MySQL实例上。当然,利用法度榜样必要把读写这些数据的流量改到新实例。新实例可以按年或按月把旧数据存入不合的表以避免单表体积过大年夜,还可以开启InnoDB透明页压缩以削减磁盘空间占用。TiDB是异常抱负的数据归档选项:理论上,一个TiDB集群的容量可以无限扩展,不必担心磁盘空间不敷用;TiDB在谋和记娱乐和记怡情AG略层和存储层皆可水平弹性扩展,我们得以根据数据体积和读写流量的实际增长循规蹈矩地增添办事器,使全部集群的硬件应用效率维持在较为抱负的水平。

硬件进级(Scale-up)。假如MySQL数据体积涨到了1TB,磁盘空间开始急急,是不是可以先把磁盘空间越发,内存也加大年夜一些,为开拓团队争取多一些光阴实现数据库横向扩展规划?有些数据库体积到了TB级别,但营业上可能不太轻易分库分表。假如开拓团队能够经由过程数据归档等手段使数据体积维持在一个较为稳定(但仍旧是TB级别)的水准,那么适当做一下硬件进级也有助于改良办事质量。

3 Redis和关系型数据库在Shopee的的共同应用

前文中我们提到,应用Redis来办理关系数据库高并发读写流量的问题,下面我们就来讲讲详细的做法。

先写缓存,再写数据库

对照常用的一种做法是:先写缓存,再写数据库。利用法度榜样前端直接读写Redis,后端匀速异步地把数据持久化到MySQL或TiDB。这种做法一样平常被称之为“穿透式缓存”,着实是把关系数据库作为Redis数据的持久化存储层。假如一个系统在设计阶段即判明线上会有较高并发读写流量,把Redis放在数据库前面挡一下每每有效。

在Shopee,一些偏社交类利用在大年夜匆匆时的峰值每每会比日常平凡超过跨过数十上百倍,是范例的“机能优先型利用”(Performance-critical Applications)。假如开拓团队事先没故意识到这一点,按照老例做法让法度榜样直接读写关系数据库,大年夜匆匆时弗成避免会呈现“一匆匆就倒”的状况。着实,这类场景很得当借助Redis平缓后端数据库读写峰值。

假如Redis集群整体挂掉落,怎么办?一样平常来说,有两个办理法子:

机能降级:利用法度榜样改为直接读写数据库。机能上可能会打一个大年夜的折扣,然则能包管大年夜部分数据不丢。一些数据较为关键的营业可能会更倾向于采纳这种要领。

数据降级:切换到一个空的Redis集群上以尽快规复办事。后续可以选择从零开始逐步积累数据,或者运行另一个法度榜样从数据库加载部分旧数据到Redis。一些并发高但容许数据损掉的营业可能会采纳这种要领。

先写数据库,再写缓存

还有一种做法也很常见:先写数据库,再写缓存。利用法度榜样正常读写数据库,Shopee内部有一其中心件DEC(Data Event Center)可以持续解析Binlog,把结果从新组织后写入到Redis。这样,一部分高频只读查询就可以直接打到Redis上,大年夜幅度低落关系数据库负载。

把数据写入Redis的时刻,可以为特定的查询模式定制数据布局,一些不太得当用SQL实现的查询改为读Redis之后反而会更简洁高效。

此外,相较于“双写要领”(营业法度榜样同时把数据写入关系数据库和Redis),经由过程解析Binlog的要领在Redis上重修数据有显着好处:营业法度榜样实现上较为简单,不必分心去关注数据库和Redis之间的数据同步逻辑。Binlog要领的毛病在于写入延迟:新数据先写入MySQL主库,待其流入到Redis上,中心可能有大年夜约数十毫秒延迟。实际应用上要论证营业是否能吸收这种程度的延迟。

举例来讲,在新订单实时查询等营业场景中,我们常采纳这种“先写数据库,再写缓存”的要领来消解MySQL主库上的高频度只读查询。为规避从库延迟带来的影响,部分关键订单字段的查询须打到MySQL主库上,大年夜匆匆时主库很可能就不堪重负。历次大年夜匆匆的实践证实,以这种要领引入Redis能有效缓解主库压力。

4 TiDB在Shopee的应用环境

讲完MySQL和Redis,我们来接着讲讲TiDB。

我们从2018年头?年月开始调研TiDB,到2018年6月份上线了第一个TiDB集群(风控日志集群,版本1.0.8)。2018年10月份,我们把一个核心审计日志库迁到了TiDB上,今朝该集群数据量约7TB,日常QPS约为10K~15K。总体而言,2018年上线的集群以日志类存储为主。

2019年开始我们考试测验把一些较为核心的线上系统迁移到TiDB上。3月份为买家和卖家供给谈天办事的Chat系统部分数据从MySQL迁移到了TiDB。近来的大年夜匆匆中,峰值QPS约为30K,运行平稳。今年也有一些新功能选择直接基于TiDB做开拓,比如商号标签、直播弹幕和选品办事等。这些新模块的数据量和查询量都还对照小,有待持续察看验证。

TiDB 3.0 GA后,新的Titan(https://github.com/tikv/titan) 存储引擎吸引了我们。在Shopee,我们容许MySQL表设计中应用Text等大年夜字段类型,平日存储一些半布局化数据。然则,从MySQL迁移到TiDB的历程中,大年夜字段却可能成为绊脚石。一样平常而言,TiDB单行数据尺寸不宜跨越64KB,越小越好;换言之,字段越大年夜,机能越差。Titan存储引擎有望前进大年夜字段的读写机能。今朝,我们已经动手把一些数据迁移到TiKV上,并打开了Titan,盼望能探索出更多利用处景。

集群概况

今朝Shopee线上支配了二十多个TiDB集群,约有400多个节点。版本以TiDB 2.1为主,部分集群已经开始试水TiDB 3.0。我们最大年夜的一个集群数据量约有30TB,跨越40个节点。到今朝为止,用户、商品和订单等电商核心子系统都或多或少把一部分数据和流量放在了TiDB上。

TiDB在Shopee的应用处景

我们把TiDB在Shopee的应用处景归纳为三类:

日志存储场景

MySQL分库分表数据聚合场景

法度榜样直接读写TiDB的场景

第一种应用处景这天志存储。前面讲到过,我们打仗TiDB的第一年里上线的集群以日志类存储为主。平日的做法是:前端先把日志数据写入到Kafka,后端另一个法度榜样认真把Kafka里的数据异步写入TiDB。因为不用斟酌分库分表,运营后台类营业可以方便地读取TiDB里的日志数据。对付DBA而言,可以根据必要线性增添存储节点和谋略节点,运维起来也较MySQL分库分表简单。

第二种应用处景是MySQL分库分表数据聚合。Shopee的订单表和商品表存在MySQL上,并做了细致的数据分片。为了方便其他子系统读取订单和商品数据,我们做了一层数据聚合:借助前面提到的DEC解析MySQL Binlog,把多个MySQL分片的数据聚合到单一TiDB汇总表。这样,类似BI系统这样的旁路系统就不必关注分库分表规则,直接读取TiDB数据即可。除此之外,订单和商品子系统也可以在TiDB汇总表上运行一些繁杂的SQL查询,省去了先在每个MySQL分片上查一次着末再汇总一次的麻烦。

第三种便是法度榜样直接读写TiDB。像前面提到的Chat系统,舍弃了MySQL,改为直接读写TiDB。上风体现在两个方面:不必做分库分表,利用法度榜样的实现相对简单、直接;TiDB理论上容量无限大年夜,且方便线性扩展,运维起来更轻易。

前面和记娱乐和记怡情AG提到过,在Shopee内部应用GDS(General DB Sync)实时解析MySQL Binlog,并写入Kafka供给给有必要的客户端破费。TiDB上也可以接一个Binlog组件,把数据变更持续同步到Kafka上。必要读取Binlog的利用法度榜样只要适配了TiDB Binlog数据款式,就可以像破费MySQL Binlog一样破费TiDB Binlog了。

从MySQL迁移到TiDB:要适配,不要和记娱乐和记怡情AG平移

把数据库从MySQL搬到TiDB的历程中,DBA常常提醒开拓同砚:要适配,不要平移。关于这点,我们可以举一个案例来阐明一下。

线上某系统最初采纳MySQL分表规划,全量数据均分到1000张表;迁移到TiDB后我们去掉落了分表,1000张表合为了一张。利用法度榜样上线后,发明某个SQL的机能哆嗦对照严重,并发高的时刻以致会导致全部TiDB集群卡住。阐发后发明该SQL有两个特征:

该SQL查询频度极高,占了查询高峰时整个只读查询的90%。

该SQL是一个较为繁杂的扫表查询,不易经由过程添加索引要领优化。迁移到TiDB之前,MySQL数据库分为1000张表,该SQL履行历程中只会扫描此中一张表,并且查询被分散到了多达二十几个从库上;即便如斯,跟着数据体积增长,当热数据显着越过内存尺寸后,MySQL从库也变得不堪重负了。迁移到TiDB并把1000张表合为一张之后,该SQL被迫扫描全量数据,在TiKV和SQL节点之间会有大年夜量中心结果集传送流量,机能自然不会好。

判明缘故原由后,开拓团队为利用法度榜样引入了Redis,把Binlog解析结果写入Redis,并针对上述SQL查询定制了适当的数据布局。这些优化步伐上线后,90% 只读查询从TiDB转移到了Redis上,查询变得更快、更稳定;TiDB集群也得以减少数量可不雅的存储和谋略节点。

TiDB高度兼容MySQL语法的特征有助于低落数据库迁移的难度;然则,不要忘怀它在实现上完全不合于MySQL,很多时刻我们必要根据TiDB的特质和详细营业场景定制出适配的规划。

5总结

本文回首了Shopee在关系数据库选型方面的思路,也附带简单先容了一些我们在MySQL、TiDB和Redis应用方面的心得,盼望能为大年夜家供给一点借鉴。

简单来说,假如数据量对照小,营业处于早期探索阶段,应用MySQL仍旧是一个很好的选择。Shopee的履历是不用过早的为分库分表退让设计,由于当营业开始增长,数据量开始变大年夜的时刻,可以从MySQL平滑迁移到TiDB,得到扩展性的同时也不用就义营业开拓的机动性。另一方面,Redis可以作为关系型数据库的很好的弥补,用来加速查询,缓解数据库压力,使得数据库能够更关注吞吐以及强同等场景。

注:文/刘春辉,"民众,"号:InfoQ,本文为作者自力不雅点,不代表永乐网网态度。

您可能还会对下面的文章感兴趣: