《解读NoSQL》——2.6　通过数据库分片获得水平扩展能力

数据库的成长性和自动分区数据的容错性对于NoSQL系统来说很重要。对于大数据系统和容错系统，分片操作已经成为高度自动化的过程。接下来让我们来看看分片如何工作以及它面临的挑战。

本节书摘来自异步社区出版社《解读NoSQL》一书中的第2章，第2.6节，作者： 【美】Dan McCreary（丹•麦克雷） , Ann Kelly（安•凯利），更多章节内容可以访问云栖社区“异步社区”公众号查看。

2.6 通过数据库分片获得水平扩展能力

随着一个组织存储的数据量增加，可能在某个时候，业务运行所需的数据量超过了当前环境所能运行的最大值，这时候，一些将数据分成合理的数据块的机制是必要的。组织和系统可以将数据库自动分片（将一个数据库划分为一些块，这些块称作数据库分片，它们遍布在一些分布式服务器上）作为持续存储数据并且最小化宕机时间的手段。在稍早的系统上手动配置数据库并将数据从旧系统复制到新系统时，这个操作可能会耗费系统数小时，然而NoSQL系统会自动进行这个操作。数据库的成长性和自动分区数据的容错性对于NoSQL系统来说很重要。对于大数据系统和容错系统，分片操作已经成为高度自动化的过程。接下来让我们来看看分片如何工作以及它面临的挑战。

假设你创建了一个网站，它允许用户登录和创建自己的私人空间并与朋友们分享。他们会上传文件、发送信息并发表一些他们对喜欢的（或不喜欢的）事物的看法。你搭建起网站，将这些信息保存到运行在单个CPU之上的MySQL数据库中。人们如果喜欢它，就会登录网站，创建主页，邀请朋友，不知不觉间你的磁盘空间已经所剩无几。接下来该怎么办？如果你使用的是典型的RDBMS，那么答案是购买新的系统并将一半用户迁移到新系统中。哎，你以前的系统可能需要宕机一段时间，这样你才能重写应用让它知道从哪个数据库中得到所需的信息。图2-9显示了一个数据分片的典型示例。

图2-9 当单个处理器不能很好地胜任系统的吞吐量需求时，就需要执行分片操作。当发生分片时，你会希望数据被移动到两个系统中，而每个系统负责原来一半的工作。许多NoSQL系统内建了自动分片功能，你只需将一台服务器添加至工作节点资源池里，数据库管理系统会自动将数据移动至新节点。大多数RDBMS不支持自动分片

有多种方式可以完成从单个数据库迁移至多个数据库的过程。

（1）可以将用户名以A～N开头的用户保留在原有的系统中，而将用户名以O～Z开头的用户迁移至新系统。

（2）可以将美国用户保留在原有系统中，而将欧洲用户迁移至新系统。

（3）可以随机将一半用户迁移至新系统中。

每一种方式都有其优势和劣势。例如，第一种方案，如果某个用户修改了用户名，那么是否应该将它自动迁移到新系统？第二种方案，如果某个用户搬家到一个新的国家，那么他的数据是否也该被迁移？如果用户都喜欢与周围的人分享链接，那么将这些用户放在同一系统中是否有性能上优势？如果美国的用户都习惯在晚上同一时间活跃又会怎么样？其中一个数据库会承受巨大压力而另一个空闲吗？如果你的网站规模再次翻倍又会如何？你会每次硬着头皮不断地重写代码来应付吗？你会让你的系统宕机一周等你升级软件吗？

随着服务器数量的增长，你会发现每一台服务器宕机的概率是均等的，所以每当你增加一台服务器，那么某一部分不工作的概率会增加。你或许会认为你将数据库切分到两个系统的过程也可以用来复制数据到备份系统或者镜像系统以防系统故障，但是这会带来新的问题。如果主节点被修改了，那么必须保证备份数据同步更新，这就需要有一个数据复制方案。同步这些数据库耗费时间的同时也会降低系统性能。现在你需要维护更多服务器了！

欢迎来到数据库分片、复制和分布式计算的世界。可以看到当数据库不断成长，你需要考虑和权衡许多问题。NoSQL系统已经有很多方法允许用户在扩大数据库规模的同时不用关闭服务器。当存储节点或网络出现故障时仍维持数据库运行叫作被称为分区容错性——一个在NoSQL社区出现的而传统数据库管理者努力追求的新概念。

理解事务完整性和自动分片对于考虑搭建分布式系统时面临的权衡问题是很重要的。尽管数据库性能、事务完整性以及如何利用内存和自动分片特性很重要，但有些时候，你必须确认并专注于系统最重要的方面，而使其他方面变得灵活。在下一节中，我们将通过一个标准的流程来了解在选择过程中需要做出的权衡，这样有助你专注于对组织最重要的事物。

数据库治理利器：动态读写分离 本文详细描述了 MSE 即将推出的数据库治理能力矩阵中关于动态读写分离能力的介绍。通过 MSE 提供的 SQL 洞察能力，结合我们对业务的理解，我们可以快速定位划分接口请求为弱请求。将对主库性能以及稳定性影响大的读操作，分流至 RDS 只读库，可以有效降低主库的读写压力，进一步提升微服务应用的稳定性。
谈谈 PolarDB-X 的水平扩展 水平扩展（Scale Out）对于数据库系统是一个重要的能力。采用支持 Scale Out 架构的存储系统在扩展之后，从用户的视角看起来它仍然是一个单一的系统，对应用完全透明，因此，它可以使数据库系统能有效地应对不同的负载场景，对用户非常用价值。 但是，数据库本身是一个有状态的系统，所以，它的水平扩展是一件比较困难的事情。数据库通常需要管理着庞大的数据，系统在扩展期间，如何保证数据一致性、高可用以及系统整体的负载均衡，更是整个水平扩展的难点。 水平扩展按不同资源类型分类，可以细分为计算节点的水平扩展与数据节点的水平扩展，后文若无特别说明，水平扩展特指数据节点的水平扩展。而数据节点的水平扩展
数据库主流容灾方案对比分析 数据库可以通过软件或硬件方式容灾，等级分为数据级容灾和应用级容灾。不同数据库容灾方案都有自己的优势，企业如何选择最优的容灾方案？投资最多的方案就是最安全、最满足实际需求的吗？答案显然是否定，可以说方案没有最好，只有最适合。在设计和选择方案时需要考虑各个因素：如投入成本、复杂度、可行性、异构性、可管理性、可扩展性等，最终方案会采用一种或多种方式组合，以满足企业不同业务系统对RPO、RTO指标的要求。
分布式系统 in 2010s ：存储之数据库篇 回看这几年，分布式系统领域出现了很多新东西，特别是云和 AI 的崛起，让这个过去其实不太 sexy 的领域一下到了风口浪尖，在这期间诞生了很多新技术、新思想，让这个古老的领域重新焕发生机。站在 2010s 的尾巴上，我想跟大家一起聊聊分布式系统令人振奋的进化路程，以及谈一些对 2020s 的大胆猜想。 无论哪个时代，存储都是一个重要的话题，今天先聊聊数据库。在过去的几年，数据库技术上出现了几个很明显的趋势。 存储和计算进一步分离 我印象中最早的存储-计算分离的尝试是 Snowflake，Snowflake 团队在 2016 年发表的论文《The Snowflake Elastic Data
分布式系统技术：存储之数据库 经常思考一个问题，为什么我们需要分布式？很大程度或许是不得已而为之。如果摩尔定律不会失效，如果通过低成本的硬件就能解决互联网日益增长的计算存储需求，是不是我们也就不需要分布式了。 过去的二三十年，是一场软件工程师们自我拯救的，浩浩荡荡的革命。
多key业务，数据库水平切分架构一次搞定 数据库水平切分是一个很有意思的话题，不同业务类型，数据库水平切分的方法不同。本篇将以“订单中心”为例，介绍“多key”类业务，随着数据量的逐步增大，数据库性能显著降低，数据库水平切分相关的架构实践。
1对多业务，数据库水平切分架构一次搞定 | 架构师之路 本文将以“帖子中心”为例，介绍“1对多”类业务，随着数据量的逐步增大，数据库性能显著降低，数据库水平切分相关的架构实践：
异步社区 异步社区(www.epubit.com)是人民邮电出版社旗下IT专业图书旗舰社区，也是国内领先的IT专业图书社区，致力于优质学习内容的出版和分享，实现了纸书电子书的同步上架，于2015年8月上线运营。公众号【异步图书】，每日赠送异步新书。