2017/4/5StackEdit–Editorhttps://stackedit.io/editor#1/8饿了么PostgreSQL优化之旅1.架构演变在O2O外卖领域，基于位置服务的需求越来越多，这就要求DB能够存储地理位置信息，而在开源数据库中，对空间地理数据支持比较好的要数PG的插件Postgi。饿了么在使用PG的过程中，由于性能及容量的原因，DB结构也在不断发生变化。在刚开始使用PG时，公司使用的是最简单的结构一主两从，读写分离，Master负责写，Slave负责读，一切都是那么快乐的运行着。但过了一段时间，随着公司业务量的扩大，单台数据库的写遇到了瓶颈，所以需要对DB进行拆分，在水平拆分与垂直拆分中，垂直拆分是相对简单的，由于饿了么业务与地理位置相关性很大，自然想到了根据地域进行切分，结构如下：GitChat2017/4/5StackEdit–Editorhttps://stackedit.io/editor#2/8经过拆分把单一Master，拆分成多个Master，此时数据库的写已不是瓶颈。世间万物总是在不断变化，饿了么每天几百万的订单量，相关的地理位置信息数据达到几百GB的真是轻轻松松，有时DBA不得不进行一些系统维护，比如导出数据，做历史归档，DDL变更等等，但如果一个表数据有100G+的时候，那些操作想想都是头疼，此时不得不对表进行水平拆分，把大表变成小表，结合业务，饿了么对数据时效性要求比较强，故我们采用每天一个轮询表的方式进行水平拆分，结构如下：GitChat2017/4/5StackEdit–Editorhttps://stackedit.io/editor#3/8经过以上DB架构演变，后来我们还对历史数据做了归档处理等，至此，目前PG已能支撑饿了么对数据库的要求。2.“坑”与优化2.1Diskqueue与checkpoint我们DBA在运维PG的过程中，有一段时间内总是不定期的观察到磁盘的diskqueue有大量的等待，磁盘的IOPS也很高，后来通过日志发现记录有”checkpointsareoccurringtoofrequently”，再结合checkpoint的时间点发现当时1分钟有70+个wal日志文件，1分钟写那么多的数据，当然会有diskqueue了，可这是为什么呢?大家知道，PG中也有和Oracle一样的checkpoint，其作用如下两点：1.保证数据库的一致性，这是指将脏数据写入到硬盘，保证内存和硬盘上的数据是一样的；2.缩短实例恢复的时间，实例恢复要把实例异常关闭前没有写出到硬盘的脏数据通过日志进行恢复。如果脏块过多，实例恢复的时间也会很长，检查点的发生可以减少脏块的数量，从而提高实例恢复的时间。GitChat2017/4/5StackEdit–Editorhttps://stackedit.io/editor#4/8由以上可知checkpoint刷新...
