淘宝商品库MySQL优化实践的学习

jopen 10年前

淘宝商品库是淘宝网最核心的数据库之一，采用MySQL主备集群的架构，特点是数据量大且增长速度快，读多写少，对安全性要求高，并发请求高。由于 MySQL最初的设计不是用来存储大规模数据的，但淘宝的数据量非常惊人，所以在I/O方面，尤其是CPU I/O层面会有很大瓶颈，因此淘宝的主要目标也是解决IO方面的瓶颈问题。

以下内容整理自淘宝的演讲，演讲内容包括淘宝商品库硬件的选型决策，安全性和性能的平衡，特别是创新引入PCI-E Flash卡和Flashcache作为Cache提高IO性能，在保证安全性的前提下就包括MySQL、InnoDB引擎、文件系统、系统Page Cache、 IO调度算法、DM层（Flashcache）、Raid卡、设备驱动在内的整条IO路径的Cache进行优化，进一步挖掘了系统IO的潜能，重点介绍优化过程中的一些经验教训、测量手段和工具。

一、商品库项目背景介绍以及约束

淘宝的产品线很多，以淘宝的商品库为例，商品库是卖家卖的所有的商品信息数据库。我们都知道淘宝商品是非常多的，有可能是十亿级别的，而且淘宝每年的数据都会翻番，在淘宝上，由于卖家是非常活跃的，所以每天的交易数也是非常多的，而且每天的访问量也是相当大的。更比如在一些高峰期，比如节假日，像光棍节促销，当时一天的访问量可就是平常的好几倍，几十倍的样子。

商品库(单机，测试)情况

  • 无复杂查询，离散度高
  • 记录数：1亿条键值对
  • 记录大小：100字节 
  • 数据文件：170G
  • 访问热点情况：20%的键占用55％的访问量
  • 键读写比例： 10：1

硬件选择

  • 主机： Dell; PowerEdge C2100;
  • 处理器： physical = 2, cores = 12, virtual = 24 
  • 内存： 96 G 
  • RAID卡：LSI MegaSAS 9260/512MB Memory
  • PCI-E Flash卡: Fusion-io ioDrive 320GB/MLC 
  • 硬盘: SEAGATE ST3300657SS  300G x 12 

软件选择

  • 发行版： Red Hat Enterprise Linux Server release 5.4
  • 内核： Kernel | 2.6.18-164.el5 
  • 文件系统：Ext3 
  • Flashcache: FB内部版本 
  • MySQL 版本：  5.1.48-log Source 

二、技术要求和方案

1、商品库技术要求：

  1. 高可用，安全第一。因为淘宝卖家的商品都存在上面，一大堆数据，商品没了，淘宝会非常的难受；
  2. 高性能，性能平稳，性价比高。因为数据量大，而且未来增长的速度会非常快，以前系统是跑在Oracle的小机上面，它的成本是非常高的。现在改用高性能的PC服务器，性价比较高，而且Oracle数据库的能力不足以维持淘宝的更新速度；
  3. 控制运维风险。Oracle是有一套完整的工具，利用它们我们可随时查看相关的状态和预测它的一些变化。MySQL作为开源产品，这部分的功能稍显欠缺，因此就需要根据运维团队和DBA的需求去开发一些工具。

2、调优指导思想

  • 杜绝拍脑袋，理论（源码）指导+精确测量+效果验证
  • 内存为王
  • 数据访问规律导向，随机数据和顺序数据尽量分离
  • 尽量提高IO的利用率，减少无谓的IO能力浪费
  • 在安全性的前提下，尽可能的利用好系统各个层次cache

3、技术方案

  • MySQL数据库集群，数据水平切割，主从备份 
  • 采用高性价比PC服务器，大内存，强劲CPU，可靠性高
  • 采用高性能PCI-E Flash卡作为cache,  提高系统的IO性能 
  • 充分利用系统各部件的cache, 大胆采用新技术 
  • 充分考虑容灾，在各个层面考虑数据的安全性

4、调优工具

  • 源码+emacs+大脑
  • 必备工具：systemtap、oprofile、latencytop 、blktrace/btt/seekwatcher、aspersa、tcprstat、sar、gdb 
  • 自制工具：bash脚本、gnuplot脚本

三、系统资源规划

内存分配：

  • MySQL
  • InnoDB buffer pool
  • OS pagecache
  • 驱动程序

IO能力分配：

  • 读能力，零散读，提高IOPS
  • 写能力，集中写，提高吞吐量

Cache分配：

  • MySQL内部cache
  • 匿名页面/文件页面
  • Flashcache 混合存储
  • Raid卡内部cache

1、MySQL数据库

考虑因素：

  • 主从备份带来的性能影响
  • 复杂数据查询操作是否需要预留内存以及上限
  • 数据备份dump对系统的影响，避免系统swap
  • 开启binlog带来的性能开销 
  • 限制最大链接数

#############################

  • max_binlog_cache_size=2G
  • max_binlog_size = 500M
  • max_connections = 1020
  • max_user_connections=1000
  • query_cache_size = 30M

2、InnoDB引擎

考虑因素：

  • 尽可能大的BP(buffer pool)
  • 日志和数据分设备存储
  • 离散数据走direct-IO，顺序日志走buffered-IO
  • 减少脏页的同步，提高命中率
  • 减少锁对多核CPU性能的影响 
  • 提高底层存储默认的IO能力

############################# 

  • innodb_buffer_pool_size = 72G
  • innodb_flush_method = O_DIRECT
  • innodb_sync_spin_loops=0
  • innodb_log_group_home_dir = /u02/
  • innodb_io_capacity=2000
  • innodb_thread_concurrency = 64

3、高速页缓存

考虑因素：

  • page资源倾斜给数据库, 尽量不浪费，兼顾临时内存申请
  • 避免NUMA架构带来的zone内存分配不均而导致的swap现象
  • cache大部分由InnoDB日志产生，适时清除，限制page数量

#############################

  • # numactl –interleave=all mysqld
  • # sysctl vm.drop_caches = 1
  • vm.swappiness = 0
  • vm.dirty_ratio = ？
  • vm.dirty_background_ratio =？
  • vm.pagecache = ?

4、文件系统

考虑因素(选择)：

  • Ext3/4
  • Xfs

考虑因素(配置)：

  • 减少元数据变化产生的IO
  • 对混合存储系统友好
  • 关闭barrier

############################# 

  •  /dev/mapper/cachedev  (rw,noatime,nodiratime,barrier=0) /u01
  • /dev/sda12                     (rw,barrier=0)                               /u02

5、IO调度

考虑因素：

  • 调度算法对减少磁头移动的效果
  • 关闭预读
  • 设备队列长度

#############################

  • sda | [deadline]  128
  • sdb | [deadline]  128

6、混合存储（Flashcache）

考虑因素

  • 结合磁盘的大容量，PCI-E Flash卡的高随机读写性能优点
  • 数据尽可能多停留在PCI-E Flash卡上,提高读写命中率
  • 减少同步次数，保留磁盘的IO能力
  • 适时同步数据，减少安全风险

#############################

  • dev.flashcache.dirty_thresh_pct = 90
  • dev.flashcache.cache_all = 0
  • dev.flashcache.fast_remove = 1
  • dev.flashcache.reclaim_policy = 1

7、Raid卡

考虑因素：

  • 逻辑分卷
  • Cache使用写优先，读少分配（数据无相关性效果不好）
  • 数据安全和raid level
  • 少预读

#############################

  • Controller |  LSI Logic / Symbios Logic LSI MegaSAS 9260 (rev 03)  
  • Model | LSI MegaRAID SAS 9260-8i, PCIE interface, 8 ports
  • Cache | 512MB Memory, BBU Present
  • BBU | 95% Charged, Temperature 28C, isSOHGood=
  • VirtualDev Size      RAID Level Disks SpnDpth Stripe Status  Cache
  • 0(no name) 278.875 GB 1 (1-0-0)      2     1-1     64 Optimal WB, RA
  • 1(no name) 1.361 TB  1 (1-0-0)      2     5-5     64 Optimal WB, RA

8、存储设备驱动

考虑因素：

  • 减少IO的抖动，提高IOPS
  • 提高寿命
  • 关闭或减少预读

#############################

PCI-E Flash卡驱动：

$cat /etc/modprobe.d/iomemory-vsl.conf

  • options iomemory-vsl use_workqueue=0
  • options iomemory-vsl disable-msi=0
  • options iomemory-vsl use_large_pcie_rx_buffer=1

四、具体优化内容

1、安全保证

  • Raid卡带Flash，掉电保护，raid level10防止磁盘损害
  • PCI-E卡自身有日志系统，恢复时间最差10分钟
  • Ext3文件系统带日志保护
  • Flashcache上的cache数据最多24小时都会同步到SAS盘
  • 数据库Innodb引擎本身有redo日志，数据安全校验，高级别日志同步
  • MySQL主从备份
  • 商品库应用方有事务日志

2、性能保证

解决IO瓶颈:

  • 高速PCI-E Flash卡做Cache，读写速度可达800/500M
  • 10 x SAS 300G 存放离散度高数据文件
  • 2 x SAS 300G 存放顺序binlog和trx日志
  • 控制数据库脏页面的刷新频率和强度
  • 优化操作系统的pagecache，资源倾斜, 杜绝swap发生
  • 优化文件系统减少meta数据的产生，以及写入延迟
  • 优化IO调度器和预读
  • 开启raid卡的读写cache
  • 优化设备驱动，适应高强度的读写请求，减少jitter

解决CPU瓶颈:

  • 业务上优化掉复杂查询
  • 优化自旋锁

3、运维保证

数据预热：

  • 支持热点数据每秒150M从磁盘直接加载到混合存储
  • 数据库重新启动，无需重新预热

数据库DDL 操作：

  • 控制数据表的大小，让DDL时间可接受
  • 减少DDL对性能的冲击

混合存储cache：

  • 通过设置白名单，减少诸如备份操作对cache的干扰
  • 混合存储cache可管理

五、优化成果

经过优化从机器的运算能力上来看的话，比原来要高很多，从设备的总体的价格来看的话，相比原来小机的价格，现在的价格相当于原来的几分之一。具体细节为：

  • 充足的容量规划，可对抗突增业务，满足未来几年业务增长
  • 系统总体运行平稳，系统负载CPU util <50%，磁盘 util <10%，PCI-E Flash卡 util < 20% 
  • QPS/36000，其中读/32800，写/3200 
  • 请求平均延时时间：260微秒(包括网络时间)
  • 掉电和操作系统失效的情况下，数据无丢失
  • 第一次预热时间半个小时以内，之后只需几分钟

六、一些重要讨论问题的分享

1、优化MySQL的过程中有没有涉及到水平分片，或者垂直分片，大概的策略是什么？

 这块因为之前的MySQL从业务的角度上我们已经优化过了。涉及到业务上的复杂SQL查询，基本上都把它当成Key- Value来处理。所以说在水平切割上就变得非常简单，只需要根据用户的这些ID把它平均地分割到集群的各个机器上去即可，所以说这块会做得非常简单，也不会有那些非常复杂的SQL。

 2、淘宝在去Oracle化过程中，最终选择了MySQL。是怎样的原因使你没有去选择NoSQL或是其它技术来作为提高性能优化方面的考虑呢？

主要考虑到以下这几个方面，第一是因为MySQL已经是非常成熟的产品，而且也是经过大规模系统考验的，所以它的稳定性，开发的便捷性还是比较有优势的。从另外一个角度上来讲，也能最大限度的保障历史系统的迁移，这是第一个方面。此外，之所以没有采用NoSQL主要基于以下几个方面的考虑，第一由于市面上流行的NoSQL方案相对来说都比较年轻。然而对于淘宝商品库来讲，它是作为淘宝非常重要的库，是不允许我们有丝毫闪失的，不能出现任何问题。第二点，现在流行的NoSQL方案，从程序的架构上来讲，就是对传统数据库的过程进行了精简。但是它的存储、内存等问题其实还是存在的。只是解决问题的思路变得轻量。但是这些问题依旧在的。现在我们在数据库层面，因为平常都是从引擎层面去开发，在原码级别去做优化，甚至包括操作系统级的优化。所以我们可以很清楚的知道问题在哪里，应该解决什么问题，最终能达到什么样的效果。那这样做的好处就是我们既能解决问题，又能充分利用传统数据库的方便性以及稳定性。

3、优化过程中具体还做了哪些工作？

优化听起来好像没什么内容，但实际上我们做了很多的工作。首先要有明确的目标，我们的目标是什么，是为了提高性能还是提高安全性，还是提高其他的什么指标，这个目标要清晰和完整。第二点是测量，你不能说，我拍脑袋看到某某某，他怎么优化的，然后我也上去这样照着优化，这不是我们做事的风格。我们要测量现在的瓶颈在哪里？我们的系统遇到了什么问题，这点我们会借助一些工具来实现。比如说测量CPU的使用，我们会非常精确的去测量I/O的使用，比如说在设备层面，I/O是怎么使用的，在软件系统层面I/O是怎么使用的，在数据库引擎层面I/O是怎么使用的。通过非常精细的测量，我们就能找出，对I/O使用不恰当的地方，然后就是要去解决这种问题，为什么会比设想的要多呢，或者为什么要比设想的要慢呢，我们会针对此类问题做理论上的分析，甚至会去翻翻源码它到底是怎么实现的，这样我们就可以比较有针对性将问题解决。

4、优化过程中有哪些创新和亮点？

这次有一个创新，用高速的SSD盘去做2级Cache，因为传统的MySQL数据库都是引擎里面发挥pool的功能，然后直接在软件系统存储。就是引擎里边吐出来东西到那边去，命不中东西从磁盘读进去，由于是传统的磁盘，所以它的寻道时间是非常长的。那它的I/O其实是不高的，但是吞吐量大。为了解决问题，我们采用一种叫PCI-E的Flash卡。这个卡的特点是，它是电子盘，所以它没有寻道时间，随机特性非常好，同时它的读写吞吐量非常高，读能大概到1G，写能达到几百兆。采用其作为二级cache，数据从InnoDB引擎这边出来，不到磁盘去，而是先写到高速卡中。由于高速卡很快，它完成的I/O PS是微秒级的，几十微秒就写完了，然后传统磁盘却是十个毫秒级的。所以从数据库引擎的角度来看，只需写入几十微妙就解决了。写入数据开始是随机的，随机累计起来以后它就不是随机的，我们通过把它排序，就可以使其变为顺序的。然后我们再把这顺序的数据利用磁盘的高吞吐量特点，由于数据库半夜时候它可能会比较轻松。那这时候，把它导到磁盘中去，这样就大大的提高整个系统的IO能力。这是比较大的一个创新点。

来自：http://www.biaodianfu.com/taobao-item-database-optimization.html