本文作者PeterZaitsev是知名数据库专家，2006年联合创立Percona，负责维护网站“MySQLPerformance”。同时，他也是《高性能MySQL》一书的合著者。以下是他对MySQL分片的建议：在与客户讨论分片决策时，我通常会先告诉他们以下真实故事。几年前，一位客户来找我寻求有关如何对他们的系统进行切片的指导。他告诉我，因为他知道许多使用MySQL的巨头（例如Facebook和Twitter）都在使用分片技术，所以他也想这样做。他们（巨人）都是聪明人，所以他自然认为他也需要这样做。我停了一下，问他的数据库有多大。他说：“还有10GB”。我点头表示理解，然后继续问他是在处理很多问题，还是有很多非常复杂的问题。他回答：“没有。每秒只有几百个查询，这些查询对系统的性能消耗只是很小的百分比。我问他是否预计在不久的将来数据量会呈指数级增长，例如，数据量每周都会翻一番什么的。”没有。去年我们的负载和数据规模增长了大约7%，我们预计今年和可预见的未来也会有类似的增长率。“我给他的建议是不要在分片上浪费时间和精力，因为他公司的情况不需要这个。你是否真的需要分片，在决定怎么分片之前，你必须从一开始就想清楚，你真的需要分片吗？”诚然，在非常大规模的数据库需求的情况下，分片是必由之路。不仅对于MySQL，对于大多数类似的技术也是如此。但是，由于很多新兴技术的出现，越来越多的应用支持不分片运行数据库。现在，我们可以轻松地在每个MySQL实例上运行TB级的数据，并在许多OLT??P环境中支持数万个查询。可见，我们可以在不分片的情况下构建非常庞大的应用程序。我们应该记住sharding是所有环境的不得已，即使你使用开箱即用的支持sharding的数据库，也会引入更多的组件和复杂的麻烦程度。构建一个好的distrib查询执行计划是一项非常复杂的任务，需要考虑网络拓扑和负载情况，以及数据分布和各个独立节点的负载。在判断是否需要分片之前，您应该首先考虑是否有其他方法可以扩展您的应用程序。在MySQL世界中，通常有一些选项需要考虑。ShardingFunctionPartitioning的替代方案：在许多环境中，单个MySQL实例成为各种数据库的垃圾场。您最终可能会让您的主应用程序与Drupal共享一个数据库实例，使用WordPress为您的站点提供支持，使用vBulletin为您的博客提供支持，甚至是论坛。将所有这些应用程序分片分离到不同的数据库实例是您首先应该考虑的事情，而不是直接考虑分片。自定义系统往往有不同数据集的应用，所以这种划分很容易实现。复制：许多应用程序都承受着“读取”压力，扩展读取性能比扩展写入性能更容易。如果是这种情况，复制是一个很好的选择。MySQL有一个非常健壮的内置复制功能，尽管它的异步特性增加了应用程序的复杂性。在这种情况下，开发人员必须确定从哪个复制服务器读取信息，以及在何处无法获取信息。因为你必须绝对保证你读到的是最新的实际数据。这就是MySQL的替代异步复制技术（例如PerconaXtraDB）流行的原因。这些工具提供了集群环境的大部分功能，以便能够对单个数据库进行操作。缓存和排队：缓存是一种减少数据库读取量的出色技术。许多应用程序可以使用此技术将数据库读取负载减少多达80-95%。对面是队列，用来优化写操作。通过合并多个写操作，提高了数据库操作的效率。大多数大型应用程序都应该关注这两种技术。Memcached和Redis是MySQL领域非常流行的两种缓存技术。对于队列，最好的技术是ActiveMQ和RabbitMQ。外部支持技术：MySQL在很多方面都很棒，但不是全部。如果你需要高性能的全文搜索，你应该考虑ElasticSearch、Sphinx或Lucene。如果你想做大规模的数据分析，可以考虑基于Hadoop的基础架构或者Vertica也是不错的选择。您应该让MySQL处理它擅长的事情，而将其他事情留给外部支持工具去做。应该在分片之前完成的优化缩放不仅适用于架构。您还需要确保您的系统得到适当优化。许多人认为分片并不是真正必要的，即使它是为他们获得性能的更简单、更有效的方法。我想说的是，如果最终必须选择分片，那么之前所做的所有优化仍然是有价值的。硬件。考虑你使用的硬件是否合适？我看到很多人都在寻找分片解决方案，但实际上，只购买硬件的十分之一就可以解决他们的问题，并保证它在未来很多年都能正常工作。如果您使用的是大型数据库，请确保您有足够的内存和高性能闪存。在许多情况下，它几乎可以神奇地显着提升您的系统。MySQL版本和配置。建议使用最新的MySQL版本。我指的是最新的GA版本（发布本文时最新版本是MySQL5.6）。PerconaServer是免费的，它通常可以为需要它的工作负载提供额外的性能提升。还建议使用最新版本的操作系统，尤其是在使用最新硬件的情况下。***，确保MySQL配置正确。MySQL配置的好坏都会导致其性能的巨大差异，性能差距可能达到十倍甚至更多。模式和查询。相同的应用程序逻辑可以由多个模式和查询来表达。我见过许多类似的应用程序以不同的方式实现，优化的方法和性能不佳的方法（确实在生产环境中使用）之间的性能差异可能是一百倍或更多。许多修改可能会调整现有的结构模式，例如对索引结构的微小调整。但是，如果您的结构不能很好地满足您的应用程序需求，那么您可能需要重新设计。因此，有必要尽早开始思考问题。何时考虑分片那么我们什么时候可以开始考虑分片呢？一般来说，如果上面列出的方法都不能给你满意的性能，那么就该考虑分片了。分片确实具有使用低成本硬件或更便宜的云实例的潜在性能优势。今天的大多数开发人员都在使用敏捷开发方法。有一个常用的术语叫做“架构跑道”，它表示应用程序基于当前的架构可以发展到什么程度。如果您在复制方面取得了成功，那么使用分片可能是一个糟糕的选择，因为它迫使开发人员处理分片和异步复制的复杂性。然而，即使您已经在使用分片，复制通常仍用于提高可用性，但在这种情况下，它不仅仅用于未来的扩展读取。如果你确信分片是必要的，你可以自己检查以下问题，都是关于如何实施分片策略的。分片级别：我们应该在哪个级别进行分片？不必在数据库级别进行分片。许多应用程序（尤其是SaaS）往往在更高层次上是碎片化的，可以部署完整应用程序堆的多个副本，以实现完全独立的可用性、性能、安全性等。在许多大规模应用程序中，你会看到许多完整的副本，每个有自己的分片MySQL环境。分片的关键：我们如何分片？在许多情况下，选择取决于您是对用户帐户还是对您的组织进行身份验证，但也有一些情况并不那么明显。选择分片方案时，需要考虑两点：1）尽可能多的数据接入点安排在一起，因为跨分片接入成本高（前提是支持）；2）确保要做的分片方案不会产生新的分片，也就是说新的分片不能太大，无法处理相关的数据规模或访问量。例如，按国家分片不是一个好主意，因为处理来自比利时的流量肯定不同于处理来自美国或中国的流量，后者需要更多资源。架构或实例共享：分片的粒度是多少？一般选择MySQL实例或者数据库（schema）。我喜欢您对数据库进行分片的方式，因为它不会限制每个物理节点只能使用一个MySQL实例。这样您就不必运行太多MySQL实例，但如果应用程序在这种情况下运行得更好，您可以运行更多实例。分片单元：如果将每个单独的MySQL服务器分片，您将很快遇到高可用性问题。如果你有一百台MySQL服务器，那么失败的可能性大约是只有一台的一百倍。因此，确保高可用性的解决方案是关键。对于MySQL服务器节点的分片处理，我们通常可以按照复制集群节点来分片（比如一个作为MySQL主节点，一个或多个作为复制服务器或者PXC，即PerconaXtraDB集群）).分片技术：你打算用什么技术来帮助实现分片？在MySQL世界中，没有适用于所有人的通用分片技术。大多数大型网站都针对自己的分片需求实施了一些定制，其中一些已经将其解决方案作为开源项目发布。一个例子是谷歌公司贡献的Vitess。另一个例子是Tumblr贡献的JetPants。推出我们自己的分片框架对于一些开发者来说可能看起来很容易，但是它通常会遇到一些棘手的实际问题，比如平衡分片，更大规模的重新分片等等。有许多有助于分片的特殊用途技术，它们可能与您的团队今天管理分片的方式不同。分片技术以下是一些您可以参考的技术。MySQLFabric：这是甲骨文MySQL团队开发的分片技术。MySQLFabric是GA版本，但是目前功能比较有限，尤其是在支持多分片查询方面。然而，随着时间的推移，它有可能成为MySQL的标准分片技术。Tesora：Tesora为MySQL分片技术提供了基于代理的解决方案，前段时间已经开源。如果您正在考虑部署OpenStack，我特别推荐Tesora，因为他们在集成方面投入了大量资金。ScaleArc：ScaleArc是一种商业数据库代理解决方案，支持缓存、过滤、路由和分发。这是一个相当成熟的解决方案，可以处理多种数据库，而不仅仅是MySQL。ScaleBase：ScaleBase是专门为MySQL和云计算设计的分配方案。与MySQL类似，它在代理级别运行。MySQL世界中还有许多技术可以在不分配的情况下扩展您的应用程序。但是，如果你打算成为下一个“Facebook”，那么你就不得不考虑分片了。还有许多技术可以帮助您尽可能轻松地实现分片。基于大型数据库的大型应用总是带来复杂性，开发和管理此类应用也更加复杂。只有付出，你才会成功。
