数据库专家谈MySQL分片.docxVIP

数据库专家：MySQL分片水很深

本文作者PeterZaitsev是知名数据库专家，2006年联合创立了Percona。负责维护网站“MySQL性能”。同时，他也是《高性能MySQL》一书的联合作者。以下是他对MySQL分片的建议：在与客户讨论分片决策的时候，我经常会先给他们讲下面这个真实的故事。

几年前，有客户来找我，希望获得关于如何对系统分片的一些指导建议。他告诉我说，自从他知道很多应用MySQL的巨头(比如Facebook和Twitter)都在使用分片技术以后他就也想这么做。他们(这些巨头)都是聪明人，所以很自然他也相信自己需要这么做。

我停了一会然后问他的数据库有多大规模。他说：“有10GB”。

我点头表示理解，并继续问他是否要处理许多查询或者有很多非常复杂的查询。

他回答说：“没有。每秒钟只有几百个查询，这些查询给系统带来的性能消耗只占很少的百分比。

我有问他是否预期在不远的未来数据量有指数级增长，比如每周数据量就会翻倍之类的情况。“不会的。我们的负载和数据规模去年增长了大约7%，我们预计今年乃至可预见的未来增长率也差不多。”

我给他的建议是不要在分片上浪费时间和精力了，因为他公司的情况需要的不是这个。是否真的需要分片

在你决定如何分片之前，你最好从一开始弄明白你是否真的需要分片。诚然，在超大规模数据库需求的情况下，分片是唯一的途径。不只是对于MySQL，对大部分同类技术都是一样。然而，由于出现了很多新兴技术，越来越多的应用都支持无需分片运行数据库。现在，我们可以很轻松地在每个MySQL实例上运行TB级数据，并在许多OLTP环境下支持数以万计的查询。可见我们可以构建非常庞大的应用而无需分片。

我们应该铭记：分片对所有环境都是不得已而为的做法。即便你使用的数据库支持开箱即用的分片功能，那也会由于引入更多组件和复杂度而带来麻烦。构建良好的分布式查询执行计划是非常复杂的任务，需要考虑网络拓扑结构和负载情况，另外还要考虑数据分布和每个独立节点的负载。

在判断是否需要分片之前，你应该首先考虑是否有替代方法可以扩展你的应用。在MySQL

的世界里，通常有以下一些方案可以考虑。分片的替代方案

功能分区：在许多环境中，单独的MySQL实例变成了各种数据库的倾销之所。你可能最终让你的主应用与Drupal共享一个数据库实例，用WordPress增强你的站点，用vBulletin增强你的博客，甚至论坛。把所有这些应用碎片分入不同的数据库实例是你首先应该考虑的，而不是直接考虑分片。客户定制系统经常有不同数据集的应用，所以这个分法很容易实现。复制：许多应用都是“读操作”的压力大，而扩展读操作性能要比扩展写性能更容易一些。如果是这种情况，那么复制就是非常好的选择。MySQL有自带的复制功能非常健壮，虽然其异步特性增加了应用的复杂性。这种情况下，开发人员必须判断从哪台复制服务器上读取信息，不可以从哪里获取。因为你必须绝对保证你读取到的是必威体育精装版的实际数据。这也正是针对MySQL出现的可替代的异步复制技术广受欢迎的原因(例如PerconaXtraDB)。这些工具把大部分集群环境下的功能提供给向单个数据库操作的能力。

缓存和队列：缓存是降低数据库读取量的出色技术。有许多应用使用这种技术可以降低数据库读负载高达80-95%。与之相对的是队列，它是用来优化写操作的。通过合并多次写操作，提高了对数据库操作的效率。大部分大型应用都应该重点考虑这两种技术。Memcached和

Redis是MySQL领域非常流行的两种缓存技术。对于队列，最流行的技术是ActiveMQ和

RabbitMQ。

外部支持技术：MySQL在很多方面都很出色，但也不是所有方面都强。如果你需要高性能全文检索，应该考虑ElasticSearch、Sphinx或者Lucene。如果你想做大规模数据分析，可以考虑基于Hadoop的基础架构或者Vertica也是不错的选择。你应该让MySQL处理它擅长的事，把其它事留给外部支持工具来做。

分片之前应该做的优化

扩展不只是针对架构而言。你还需要确保你的系统经过了合理的优化。许多人决定采用分片其实不是真正必要的，虽然对于他们来说这是获得性能提升更容易而且更有效的方式。我想说的是，如果分片最终也必须选择的话，之前做的所有这一切优化也仍然是有价值的。硬件。考虑一下你使用的硬件合适吗?我见过好多人在寻求分片方案，但事实上只要购买其

十分之一的硬件就能解决他们的问题，并保证在未来多年有效。如果你使用的数据库比较大，请确保你有大量内存和高性能闪存。在许多情况下，它几乎像变魔术一样可以极大地提升你的系统。

MySQL版本和配置。建议