618大促,苏宁如何通过citus打造分布式数据库抗住DB高负载

内容来源:2017 年 10 月 20 日,苏宁云商IT总部资深技术经理陈华军在“PostgreSQL 2017中国技术大会”进行《苏宁citus分布式数据库应用实践》演讲分享。IT 大咖说(微信id:itdakashuo)作为独家视频合作方,经主办方和讲者审阅授权发布。

阅读字数:5089 | 13分钟阅读

摘要

本次分享主要介绍了如何通过Citus打造分布式数据库,对具体的部署情况进行了讲解。

嘉宾演讲视频回放及PPT,请复制链接:http://t.cn/RdmlKXd,粘贴至浏览器地址栏即可。

业务场景

上图的系统架构主要是做订单的分析,它会定时的从其他的业务系统中抽取订单以及订单的更新信息。每5分钟进行一次批量的处理,更新10张左右的明细表。在数据库中同样也是5分钟做一次处理,首先会对明细表进行计算,之后的计算结果会被放到报表中。架构外层还有一些其他系统,比如cognos、智能分析等,它们主要是用来从数据中查报表或明细表。

这套系统中我们采用的数据库是DB 2,平时的CPU负载都达到了50%左右,大促期间更是超过了80%,可以算是不堪重负。

DB负载在哪?

如此高的负载,到底问题是出在那些地方?其实主要是在明细更新、报表计算、报表查询/明细查询上

明细更新时是5分钟更新10张明细表,这其中最宽的表有400字段,大概每行2.5kB。每次更新最宽的表约10w记录,总体上是30w。我们还要保持最近数天的数据。这样看下来其实主要的压力是在随机更新,换算一下大概每秒要做5k条记录的更新,关键是这 5K条记录还都是宽表。

报表计算也是每5分钟计算30多张报表,要求2分钟完成,每个报表平均执行14次明细表集合查询。估算下来大概是每分钟200次明细表的聚合运算。

报表查询/明细查询中要求的并发度是大于30,但正常情况下没有这么高,大概只有10个左右。同时要求的响应时间要小于3秒。

由于我们的系统接入的业务需要扩张,预计年内负载还会增加10倍,也就是说原先的每秒5k的明细表随机更新和3000w明细表数据,将提升为每秒5k的明细表随机更新和3亿明细表数据。

这样的背景下基于单机的DB 2肯定是搞不定的,我们需要的应该是一种分布式方案。

方案选型

上图列出的就是我们当时所考察的各种方案,因为PG在分析上还是比较有优势,所以这些方案都和PG相关。第一个Greenplum由于已经比较成熟了,所以我们一开始就比较看好,但是它更新慢、并发低的缺陷,不符合明细更新的性能要求,因此被排除在外。第二个postgres_fdw由于不支持聚合下推和并行查询,所以不符合明细表查询性能要求。第三个PG_XL方案我们并没有做深入的评估,但是GMT对性能是有影响的,估计很难满足我们对随机更新的需求。最后的citus的优势在于它是一个扩展,稳定性和可维护性都比较好,同时分片表的管理也很方便,最终我们选择的就是这个方案。

Citus介绍

Citus架构与原理

这张是Citus的架构图,可以看到它由1个maste多个worker组成,数据表通过hash或者append分片的方式分散到每个worker上。这里的表被分为分片表和参考表,参考表只有一个分片,并且每个worker上都有一份。

在应用访问的时候master接收应用的查询SQL,然后对查询SQL进行解析生成分布式执行计划,再将子执行路径分发到worker上执行,最后汇总执行结果返回给应用。

Citus主要适用于两种环境,一种是实时数据分析,一种是多租户应用。

案例演示

这里演示的是Citus的使用过程。分片表的创建和普通表是一样的,只不过完成之后需要设置分片数,最后执行create_distributed_table函数,参数为需要分片的表以及分片字段,还可以指定分片方法,默认是hash方式。参考表的不同在于函数换成了create_reference_table。这两个函数主要做了两件事,首先是在每个worker上创建分片,其次是更新元数据。元数据定义了分片信息。

元数据pg_dist_partition中存放的是分片表和分片规则,可以从图中看到,h代表的hash分片,n表示的是参考表。分片表中有一个partkey,它用来指定哪个字段做分片以及分片类型。

元数据- pg_dist_shard定义了每个分片以及分片对应的hash范围,不过参考表由于只有一个分片,所以没有hash范围。

元数据-pg_dist_shard_placement定义了每个分片存放的位置,第一列是分片的ID号,后面是所在的worker节点位置和端口号。

基于元数据master可以生成分布式执行计划,比如聚合查询就会生成如上图所示的执行计划。上半部分是在每个worker上预聚合,每个分片并行执行,下面则是master对worker的结果做最终的聚合。

SQL限制—查询

Citus最大的缺陷在于有着SQL限制,并不是所有SQL都支持。最典型的就是对Join的限制,它不支持2个非亲和分片表的outer join,仅task-tracker执行器支持2个非亲和分片表的inner join,对分片表和参考表的outer join,参考表只能出现在left join的右边或right join的左边。对子查询也有着限制,子查询不能参与join,不能出现order by,limit和offset。一些SQL特性Citus同样不支持,比如CTE、Window函数、集合操作、非分片列的count(distinct)。最后还有一点需要注意,即本地表不能和分片表(参考表)混用。

这些限制其实都可以使用某些方法绕过,比如通过Hll(HyperLogLog)插件支持count(distinct),对于其他的一些操作也可以通过临时表或dblink中转。不过临时表的问题在于会将一个SQL拆成多个SQL。

SQL限制—更新

在更新上也存在一些限制,它不支持跨分片的更新SQL和事务,‘insert into ... select ... from ...’的支持存在部分限制,插入源表和目的表必须是具有亲和性的分片表,不允许出现Stable and volatile函数,不支持LIMIT,OFFSET,窗口函数,集合操作,Grouping sets,DISTINCT。

当然这些限制也存在对应的回避方法,首先是使用copy代替insert,其次是用SELECT master_modify_multiple_shards(‘…’)实现扩分片更新。

SQL限制—DDL

上图展示的是对DDL的支持情况,这里面大部分都是支持的,对于不支持的可以通过创建对等的唯一索引代替变更主键,或者使用`run_command_on_placements`函数,直接在所有分片位置上执行DDL的方式来进行回避。

两种执行器

Citus有两种执行器,通过set citus.task_executor_type='task-tracker'|'real-time'进行切换。

默认的real-time又分为router和非router方式。router适用于只需在一个shard上执行的SQL,1个master后端进程对每个worker只创建一个连接,并缓存连接。非route下master后端进程会对所有worker上的所有shard同时发起连接,并执行SQL,SQL完成后断开连接。

如果使用task-tracker执行器。Master是只和worker上的task-tracker进程交互,task-tracker进程负责worker上的任务调度,任务结束后master从worker上取回结果。worker上总的并发任务数可以通过参数控制。

这里对这两种执行器进行了比较。real-time的优势主要在于响应时间小。task-tracker则是支持数据重分布,SQL支持也比real-time略好,同时并发数,资源消耗可控。

部署方案

痛点

我们的系统中首先面临的痛点就是对随机更新速度要求高。上图左边是Citus官方展示的性能数据,看似接近所需的性能要求,实际上远远不够,因为这里记录的是普通的窄表,而我们的是宽表而且还有其他的负载。

图中右边是我这边做的性能测试。单机状态下插入速度是每秒13万条,使用Citus后下降到了5w多,这主要是由于master要对SQL进行解析和分发。在尝试对Citus进行优化后,使Citus不解析SQL,提升也不是很明显。最后一种方式是不使用master,将每个worker作为master,这次的效果达到了每秒30万条。

第二个痛点就是前面提到的SQL限制问题,虽然这些限制都有方法回避,但是对应用的改造量比较大。

解决方案

这是我们最终的解决方案。首先对于插入和更新数据慢的问题,不在走master,直接在worker上更新。在更新之前会现在worker上查询分片的元数据,然后再进行更新。

另外为了尽量减少SQL限制对应用的影响,我们采用的策略是尽量少做分片,只对明细表进行分片。应用在查询的时候会将报表和维表做join,也会将明细表和维表做join,那么这里就会出现问题,因为本地表和参考表不能出现在同一个SQL里。所以我们做了N份参考表,每个worker放一份,同时再将一份本地维表放在master上,由报表做join用,最后在更新的时候通过触发器同步本地维表和参考表。

辅助工具函数开发

为了支撑前面提到的两个策略,我们实现了两个函数。pg_get_dist_shard_placement()函数用来批量获取记录所在分片位置函数。create_sync_trigger_for_table()函数用来自动生成本地维表和参考维表同步触发器的函数。

连接池

因为业务对SQL的响应时间要求较高,所以我们使用的是real time执行器。但是由于real time存在的缺陷,因此我们在master上部署了两套pgbounce连接池。一个在PostgreSQL前面,应用在连接PostgreSQL前先连接到pgbouncer。另一个在master和worker之间。

实际的使用的时候由于pgbounce不支持prepare语句,所以有些应用还是要直连到master。

效果

上图是POC压测的结果,基本上明细更新和报表结算满足了性能要求。测试的时候我们使用的是8个worker,而在部署的时候其实是先部署4台,然后再扩容到8台。

日常维护

Citus的维护和普通的PG维护在大部分情况下区别不大,不过有些有时候DDL执行会无法分发,这时可以用它的一些公有函数来完成。

另外更新多副本分片表的途中worker发生故障,可能导致该worker上的副本没有被正确更新。此时citus会在系统表pg_dist_shard_placement 中将其标识为“失效”状态。使用master_copy_shard_placement() 函数就能够进行恢复。

Citus对DDL、copy等跨库操作采用2PC保障事务一致,2PC中途发生故障会产生未决事务。对每个2PC事务中的操作都记录到系统表pg_dist_transaction,通过该表就能够判断哪些事务该回滚或提交。

踩过的坑

在实际的应用中我们并没有碰到什么大坑,主要是一些小问题。

第一个是由于master(real-time)到worker用的短连接,pgbouncer默认记录连接和断连接事件,导致日志文件增长太快。后来我们将其关闭了。

第二个是master(real-time)会瞬间创建大量到worker 的并发连接,而默认的unix套接字的 backlog连接数偏低, master节点的 PostgreSQL日志中经常发现大量连接出错的告警。对此的解决办法是修改修改pgbouncer的listen_backlog,然后硬重启pgbouncer。

以上为今天的全部分享内容,谢谢大家!

注:本文内容基于较早的citus 6.x版,当前版本citus中“master”节点的名称已改为“Coordinator”。

详细参考:https://pan.baidu.com/s/1_tkfp9xLSQuwA2LEInQWTw。 推荐文章

  • Sharding-JDBC:分布式微服务数据库访问框架的设计与实现
  • 你是否知道怎样借助ES在不同场景下构建数据仓库
  • 分布式强一致性数据库的灵魂 - Raft 算法

原文发布于微信公众号 - IT大咖说(itdakashuo)

原文发表时间:2018-07-11

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏微信终端开发团队的专栏

微信移动端数据库组件 WCDB 系列:数据库修复三板斧(二)

之前一篇文章《微信 SQLite 数据库修复实践》介绍了微信对SQLite数据库修复以及降低损坏率的实践, 这次再深入介绍一下微信数据库修复的具体方案和发展历程...

5390
来自专栏杨建荣的学习笔记

生产环境数据迁移问题汇总(r2第16天)

在测试环境中做了3轮数据迁移的演练,最终到了生产环境中,还是出现了不少问题,经过大半夜的奋战,终于是数据都迁移成功了。 1)共享存储的配置问题 共享存储使用NF...

3227
来自专栏数据和云

青铜到王者,看看你的MySQL数据库是什么段位,如何提升?

作者 | 张甦, 数据库领域的专家和知名人士、图书《MySQL王者晋级之路》作者,51CTO 专家博主。近10年互联网线上处理及培训经验,专注于 MySQL 数...

1974
来自专栏即时通讯技术

微信自用高性能通用key-value组件MMKV已开源!

腾讯微信团队于2018年9月底宣布开源 MMKV ,这是基于 mmap 内存映射的 key-value 组件,底层序列化/反序列化使用 protobuf 实现,...

1482
来自专栏即时通讯技术

微信自用高性能通用key-value组件MMKV已开源!

腾讯微信团队于2018年9月底宣布开源 MMKV ,这是基于 mmap 内存映射的 key-value 组件,底层序列化/反序列化使用 protobuf 实现,...

1422
来自专栏Web 开发

小项目里面的大内涵

额~因为我从没系统的看过,所以实施的时候总是出这样那样的语法问题,尤其是对 ‘ “ . ` 这些个符号的使用,非常混乱~

983
来自专栏美团技术团队

美团点评数据平台Kerberos优化实战

29610
来自专栏ThoughtWorks

phantomJs之殇,chrome-headless之生 | 洞见

技术雷达快讯:自2017年中以来,Chrome用户可以选择以headless模式运行浏览器。此功能非常适合运行前端浏览器测试,而无需在屏幕上显示操作过程。在此之...

3956
来自专栏IT大咖说

开源NewSQL – CockroachDB在百度内部的应用与实践

4002
来自专栏文渊之博

史上最大的CPU Bug(幽灵和熔断的OS&SQLServer补丁)

背景 原文地址(http://www.cnblogs.com/wenBlog/p/8435229.html) 最近针对我们的处理器出现了一系列的严重的bug。这...

3635

扫码关注云+社区

领取腾讯云代金券