2.6 通过数据库分片获得水平扩展能力
随着一个组织存储的数据量增加，可能在某个时候，业务运行所需的数据量超过了当前环境所能运行的最大值，这时候，一些将数据分成合理的数据块的机制是必要的。组织和系统可以将数据库自动分片（将一个数据库划分为一些块，这些块称作数据库分片，它们遍布在一些分布式服务器上）作为持续存储数据并且最小化宕机时间的手段。在稍早的系统上手动配置数据库并将数据从旧系统复制到新系统时，这个操作可能会耗费系统数小时，然而NoSQL系统会自动进行这个操作。数据库的成长性和自动分区数据的容错性对于NoSQL系统来说很重要。对于大数据系统和容错系统，分片操作已经成为高度自动化的过程。接下来让我们来看看分片如何工作以及它面临的挑战。
假设你创建了一个网站，它允许用户登录和创建自己的私人空间并与朋友们分享。他们会上传文件、发送信息并发表一些他们对喜欢的（或不喜欢的）事物的看法。你搭建起网站，将这些信息保存到运行在单个CPU之上的MySQL数据库中。人们如果喜欢它，就会登录网站，创建主页，邀请朋友，不知不觉间你的磁盘空间已经所剩无几。接下来该怎么办？如果你使用的是典型的RDBMS，那么答案是购买新的系统并将一半用户迁移到新系统中。哎，你以前的系统可能需要宕机一段时间，这样你才能重写应用让它知道从哪个数据库中得到所需的信息。图2-9显示了一个数据分片的典型示例。
图2-9 当单个处理器不能很好地胜任系统的吞吐量需求时，就需要执行分片操作。当发生分片时，你会希望数据被移动到两个系统中，而每个系统负责原来一半的工作。许多NoSQL系统内建了自动分片功能，你只需将一台服务器添加至工作节点资源池里，数据库管理系统会自动将数据移动至新节点。大多数RDBMS不支持自动分片
有多种方式可以完成从单个数据库迁移至多个数据库的过程。
（1）可以将用户名以A～N开头的用户保留在原有的系统中，而将用户名以O～Z开头的用户迁移至新系统。
（2）可以将美国用户保留在原有系统中，而将欧洲用户迁移至新系统。
（3）可以随机将一半用户迁移至新系统中。
每一种方式都有其优势和劣势。例如，第一种方案，如果某个用户修改了用户名，那么是否应该将它自动迁移到新系统？第二种方案，如果某个用户搬家到一个新的国家，那么他的数据是否也该被迁移？如果用户都喜欢与周围的人分享链接，那么将这些用户放在同一系统中是否有性能上优势？如果美国的用户都习惯在晚上同一时间活跃又会怎么样？其中一个数据库会承受巨大压力而另一个空闲吗？如果你的网站规模再次翻倍又会如何？你会每次硬着头皮不断地重写代码来应付吗？你会让你的系统宕机一周等你升级软件吗？
随着服务器数量的增长，你会发现每一台服务器宕机的概率是均等的，所以每当你增加一台服务器，那么某一部分不工作的概率会增加。你或许会认为你将数据库切分到两个系统的过程也可以用来复制数据到备份系统或者镜像系统以防系统故障，但是这会带来新的问题。如果主节点被修改了，那么必须保证备份数据同步更新，这就需要有一个数据复制方案。同步这些数据库耗费时间的同时也会降低系统性能。现在你需要维护更多服务器了！
欢迎来到数据库分片、复制和分布式计算的世界。可以看到当数据库不断成长，你需要考虑和权衡许多问题。NoSQL系统已经有很多方法允许用户在扩大数据库规模的同时不用关闭服务器。当存储节点或网络出现故障时仍维持数据库运行叫作被称为分区容错性——一个在NoSQL社区出现的而传统数据库管理者努力追求的新概念。
理解事务完整性和自动分片对于考虑搭建分布式系统时面临的权衡问题是很重要的。尽管数据库性能、事务完整性以及如何利用内存和自动分片特性很重要，但有些时候，你必须确认并专注于系统最重要的方面，而使其他方面变得灵活。在下一节中，我们将通过一个标准的流程来了解在选择过程中需要做出的权衡，这样有助你专注于对组织最重要的事物。