保存成功
订阅成功
保存失败,请重试
提交成功

饿了么 PostgreSQL 优化之旅

在 QCon、ArchSummit、TOP100、SACC、SDCC、GITC 等各大技术大会上常会看到这么一群“技术网红”,现在他们也将会出现在饿了么的技术文化社区,包括现任饿厂北京研发中心负责人的“IT民工”史海峰、写前端的 Sofish、走到哪红到哪的老毕、还有写过代码做过架构,折腾过性能优化,擅长故障定位的饿厂框架总监兰建刚(及众多大神),当然还有一群热爱技术交流分享,视 coding 为乐的技术强人,在等大家交流哦~
查看本场Chat

1. 架构演变

在O2O外卖领域,基于位置服务的需求越来越多,这就要求DB能够存储地理位置信息,而在开源数据库中,对空间地理数据支持比较好的要数PG的插件Postgis。

enter image description here

饿了么在使用PG的过程中,由于性能及容量的原因,DB结构也在不断发生变化。 在刚开始使用PG时,公司使用的是最简单的结构一主两从,读写分离,Master负责写,Slave负责读,一切都是那么快乐的运行着。 但过了一段时间,随着公司业务量的扩大,单台数据库的写遇到了瓶颈,所以需要对DB进行拆分,在水平拆分与垂直拆分中,垂直拆分是相对简单的,由于饿了么业务与地理位置相关性很大,自然想到了根据地域进行切分,结构如下:

enter image description here

经过拆分把单一Master, 拆分成多个Master, 此时数据库的写已不是瓶颈。 世间万物总是在不断变化,饿了么每天几百万的订单量,相关的地理位置信息数据达到几百GB的真是轻轻松松, 有时DBA不得不进行一些系统维护,比如导出数据,做历史归档,DDL变更等等,但如果一个表数据有100G+的时候,那些操作想想都是头疼,此时不得不对表进行水平拆分,把大表变成小表,结合业务,饿了么对数据时效性要求比较强,故我们采用每天一个轮询表的方式进行水平拆分,结构如下:

互动评论
评论
康东扬2 年前
新手请教一下,写入经过gateway的意思是一份数据存入多个机房?如果是这样,读的时候我看架构图为什么不经过gateway
评论
康东扬2 年前
为什么读取的时候不经过gateway
评论
mia4 年前
非常不错
评论
Icarus4 年前
最近总mysql也可以搞按地理搜索,加列geohush ,就可以实现,pg的搜索地理位置性能真的比mysql高么?
评论
Jekin4 年前
非常详细,感谢分享!
评论
William ^O^ 怀远4 年前
感谢分享。当回收的页分布在存储数据的中间,而不是在文件尾部时,该如何有效的进行vacuum释放空间?如保证回收的页都在文件尾部?
评论
Ray4 年前
PG的事务处理机制和Oracle/SQL有什么区别? 对于表扩展的机制,设计大表还是小表对于性能更好?谢谢
评论
P H J4 年前
good 感谢分享
评论
查看更多