做网站的网址是哪里来的,经营网站挣钱,网站安全检测产品优势,谷歌推广哪家好2018-07-16 23:59内容来源#xff1a;2017 年 10 月 20 日#xff0c;苏宁云商IT总部资深技术经理陈华军在“PostgreSQL 2017中国技术大会”进行《苏宁citus分布式数据库应用实践》演讲分享。IT 大咖说#xff08;微信id#xff1a;itdakashuo#xff09;作为独家视频合作…2018-07-16 23:59内容来源2017 年 10 月 20 日苏宁云商IT总部资深技术经理陈华军在“PostgreSQL 2017中国技术大会”进行《苏宁citus分布式数据库应用实践》演讲分享。IT 大咖说微信iditdakashuo作为独家视频合作方经主办方和讲者审阅授权发布。摘要本次分享主要介绍了如何通过Citus打造分布式数据库对具体的部署情况进行了讲解。嘉宾演讲视频回放及 PPT请复制链接http://t.cn/RdmlKXd粘贴至浏览器地址栏即可。业务场景上图的系统架构主要是做订单的分析它会定时的从其他的业务系统中抽取订单以及订单的更新信息。每5分钟进行一次批量的处理更新10张左右的明细表。在数据库中同样也是5分钟做一次处理首先会对明细表进行计算之后的计算结果会被放到报表中。架构外层还有一些其他系统比如 cognos、智能分析 等它们主要是用来从数据中查报表或明细表。这套系统中我们采用的数据库是 DB2平时的 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 bylimit和offset。一些SQL特性Citus同样不支持比如CTE、Window函数、集合操作、非分片列的count(distinct)。最后还有一点需要注意即本地表不能和分片表(参考表)混用。这些限制其实都可以使用某些方法绕过比如通过Hll(HyperLogLog)插件支持count(distinct)对于其他的一些操作也可以通过临时表或dblink中转。不过临时表的问题在于会将一个SQL拆成多个SQL。SQL限制—更新在更新上也存在一些限制它不支持跨分片的更新SQL和事务‘insert into ... select ... from ...’的支持存在部分限制插入源表和目的表必须是具有亲和性的分片表不允许出现Stable and volatile函数不支持LIMITOFFSET窗口函数集合操作Grouping setsDISTINCT。当然这些限制也存在对应的回避方法首先是使用copy代替insert其次是用SELECT master_modify_multiple_shards(‘…’)实现扩分片更新。SQL限制—DDL上图展示的是对DDL的支持情况这里面大部分都是支持的对于不支持的可以通过创建对等的唯一索引代替变更主键或者使用run_command_on_placements函数直接在所有分片位置上执行DDL的方式来进行回避。两种执行器Citus有两种执行器通过set citus.task_executor_typetask-tracker|real-time进行切换。默认的real-time又分为router和非router方式。router适用于只需在一个shard上执行的SQL1个master后端进程对每个worker只创建一个连接并缓存连接。非route下master后端进程会对所有worker上的所有shard同时发起连接并执行SQLSQL完成后断开连接。如果使用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。