专栏名称: DBAplus社群
围绕数据库、大数据、PaaS云,顶级大咖、技术干货,运营几个月受众过十万!成为运维圈最专注围绕“数据”的学习交流和专业社群!欢迎投稿,加入探讨。
目录
相关文章推荐
数据中心运维管理  ·  弱电智能化中究竟有多少个子系统? ·  昨天  
数据中心运维管理  ·  超大规模数据中心如何重新思考冷却效率 ·  2 天前  
数据中心运维管理  ·  锂电池火灾处理难度 ·  昨天  
AustinDatabases  ·  P-MySQL ... ·  昨天  
阿里云大数据AI平台  ·  【5月重点功能发布】阿里云大数据+ AI ... ·  2 天前  
阿里云大数据AI平台  ·  【5月重点功能发布】阿里云大数据+ AI ... ·  2 天前  
51好读  ›  专栏  ›  DBAplus社群

3年部署3000套PG实例的架构设计与踩坑经验

DBAplus社群  · 公众号  · 数据库  · 2020-11-22 21:32

正文

请到「今天看啥」查看全文


  • PostgreSQL + Citus


    • OLAP

    • PostgreSQL + Citus

    • GreenPlum

    三、PosgreSQL的落地


    业务场景



    我们上线的第一个PostgreSQL业务系统是一个实时大数据处理系统。这个系统的主要业务流程是从各个其它业务系统里面抽取相关数据放到它的数据库明细表里,然后再定时通过存储过程汇总明细表生成报表提供给分析平台进行展示。


    这个系统一个很大的特点就是对数据库的性能要求特别苛刻,当时使用的是单库的商业数据库,平时数据库的CPU利用率都在45%以上,大促期间更是超过80%,可以说不堪重负。而且为了支撑今后的业务发展,这个系统必须在2017年双11前扩容十倍的容量,很显然单机的数据库已经没有任何性能扩容的空间,无法满足这一需求。


    这个系统对数据库的使用主要包含下面3个不同的场景,其中每一个场景都对数据库有很高的性能要求。


    1)明细表更新


    实时更新包含400多个字段的宽表。数据加载速度要求达到5w/s以上,其中90%是UPDATE。


    2)报表计算


    支持200+/min的实时报表计算


    3)报表和明细查询


    支持高并发的报表和明细查询


    技术选型


    考虑到这个系统当前对数据库的业务需求和未来的发展规划,我们希望扩容方案是基于SQL的开源分布式数据库。我们比较了几个候选方案,考虑到和业务场景的匹配度和今后的运维的便利性,最终选择了Citus,一个能把多个单机的PostgreSQL变成分布式数据库集群的插件。



    部署架构


    下面是这个系统使用Citus的部署架构,为了优化性能,我们做了一些架构上的优化。明细表更新不经过Coordinator节点,而是先到Coordinator节点批量查询待更新记录的位置信息,再直接到对应位置的Worker上以批量INSERT ON CONFLICT的方式更新明细数据。



    上线效果


    根据POC压测的结果,把原单库的商业数据库替换成1CN + 8个Worker的Citus集群后,性能提升了10多倍,圆满达成扩容目标。



    新的系统从2017年上线后至今已平稳运行多年,生产集群规模也从最初上线的4个Worker逐步扩容到16个Worker,而且CN和Worker平时的CPU利用率都保持在10%左右,很好的支撑了业务的发展。


    四、PostgreSQL和Citus的推广


    从2017上线第一套PostgreSQL以来,截止2019双11,我们已经部署了3000+PostgreSQL实例,其中80%以Citus集群的形式部署,其余是普通的PostgreSQL。


    使用PostgreSQL的应用,既有OLTP类的业务也有OLAP类的业务。 下面介绍其中的3个业务案例。


    案例一:计费结算


    我们在很多计费结算类业务中使用了PostgreSQL + Citus的数据库架构,其中规模最大的系统是物流的计费平台。它有几百个数据库节点,多个大表的数据量超过百亿。这个系统原来使用的数据库是商业数据库,应用在业务层做分库分表。在业务层维护大量数据库节点的方式,大大增加了日常开发和管理上的成本。


    举一个简单的例子,如果要在某个表上添加一个字段,需要先在几十个库的几百张分表里依次把字段加上,然后再修改上百个应用的配置,中间不能有任何错误和遗漏。而一次发布不会只改一个表,所有实际上每次发布光编辑发布脚本就是一项很大的工作。


    后来我们把这个系统的数据库从一堆单机商业数据库迁移到了分布式的Citus。迁移后不仅省掉了商业数据库的许可和维保成本,而且应用层去掉复杂的分库分表逻辑,使用体验得到了极大的提升。


    迁移到Citus后,以前一些不容易做甚至没法做的事情变得可以做而且简单了,比如执行一些跨库的查询,包括跨库事务。这个系统中大量的业务请求是涉及跨库事务的。Citus实现了基于2PC的分布式事务,支持分布式死锁检测和故障时的自动事务恢复,透明地支撑了业务的跨库访问。Citus上的日常DDL发布也很简单,只要在Citus的Coordinator节点对逻辑表执行DDL就可以了,使用体验上和在普通单库上的DDL发布没什么区别。



    案例二:精准营销


    对电商来说,实时把握客户留存实施精准营销是一项非常重要的功课。但是对于有数亿会员和大量商品的大型电商平台,常规的处理方式是很低效的。通过探索和演进,现在我们使用citus + pg_roaringbitmap插件的技术方案。


    roaringbitmap是一种高效的bitmap压缩存储格式,在标签类的应用中,已被业界广泛使用。pg_roaringbitmap插件则把roaringbitmap作为一种新的数据类型引入到了PostgreSQL里。这体现了PostgreSQL非常容易扩展的特点,不仅数据类型,索引类型,FDW甚至存储过程语言等等都可以扩展。再结合Citus的水平扩展能力,我们实现了百亿级标签的实时存储和查询。



    案例三:基于地理位置的搜索和推荐


    苏宁有大量线下门店,为支撑线下业务的运营,需要基于地理位置为用户提供个性化的搜索和推荐服务。并且在大促期间,需要支撑非常高的访问量。我们使用PostgreSQL + PostGiS插件支持位置数据的存储和高效查询,通过一主多从和基于JDBC多主机URL的读写分离水平扩展数据库处理能力。大促期间会临时增加从节点提升数据库的吞吐能力,最多时扩容到11个节点。








    请到「今天看啥」查看全文