书名：Apache ShardingSphere权威指南
ISBN：978-7-115-63663-8
本书由人民邮电出版社发行数字版。版权所有，侵权必究。
您购买的人民邮电出版社电子书仅供您个人使用，未经授权，不得以任何方式复制和传播本书内容。
我们愿意相信读者具有这样的良知和觉悟，与我们共同保护知识产权。
如果购买者有侵权行为，我们可能对该用户实施包括但不限于关闭该帐号等维权措施，并可能追究法律责任。
著 潘 娟 张 亮 [阿尔及]亚幸·西·塔伊布（Yacine Si Tayeb）
译 张海燕
责任编辑 孙喆思
人民邮电出版社出版发行 北京市丰台区成寿寺路11号
邮编 100164 电子邮件 315@ptpress.com.cn
网址 http://www.ptpress.com.cn
读者服务热线：(010)81055410
反盗版热线：(010)81055315
Copyright © Packt Publishing 2022. First published in the English language under the title A Definitive Guide to Apache ShardingSphere(ISBN 978-1-80323-942-2). All rights reserved.
本书由英国Packt Publishing公司授权人民邮电出版社有限公司出版。未经出版者书面许可，对本书的任何部分不得以任何方式或任何手段复制和传播。
版权所有，侵权必究。
Apache ShardingSphere是一个基于可插拔特性和云原生原则的新开源生态系统，将其用于分布式数据基础设施有助于增强数据库性能。本书首先简要概述数据库管理系统在生产环境中面临的主要挑战和数据库软件的内核概念；然后介绍使用分布式数据库解决方案、弹性伸缩、用户身份认证、SQL授权、全链路监控、数据库网关和DistSQL的真实示例，全面讲解ShardingSphere的架构组件，以及如何利用它们配置和插入现有的基础架构并管理数据和应用；接着介绍生态系统的客户端ShardingSphere-JDBC和ShardingSphere-Proxy，以及它们如何同时或独立地工作以满足实际需求；最后讲解如何定制可插拔架构以定义个性化的用户策略和无缝管理多个配置，并在所有场景下对数据库进行功能测试和性能测试。
本书适用于对数据库、关系数据库、SQL语言、云计算和数据管理有基本的了解，对分布式数据库计算和存储解决方案感兴趣，或使用分布式数据库解决方案并希望探索Apache ShardingSphere功能的相关从业人员。
潘娟，SphereEx联合创始人兼首席技术官（CTO）。她是Apache基金会会员和孵化器导师、Apache ShardingSphere项目管理委员会（project management committee，PMC）成员、AWS大侠、腾讯云TVP。她曾负责京东数科数据库智能平台的设计与研发，现专注于分布式数据库和中间件生态及开源领域。她被评为中国开源先锋人物、OSCAR尖峰开源人物、CSDN IT领军人物、掘金引力榜年度新锐人物。
张亮，SphereEx公司创始人兼首席执行官（CEO）。他是数据库领域知名实践者、Apache基金会会员、微软MVP、阿里云MVP、腾讯云TVP、华为云MVP、Apache ShardingSphere创始人和PMC主席。他拥有超过10年的数据库领域探索、实践经验，热爱开源，擅长分布式架构，推崇优雅代码。他曾在多个大型互联网公司任职架构、数据库团队负责人。他在ICDE发表过论文“Apache ShardingSphere—A Holistic and Pluggable Platform for Data Sharding”，是《未来架构：从服务化到云原生》的作者。
亚幸·西·塔伊布（Yacine Si Tayeb）博士是Apache基金会的贡献者，也是Apache ShardingSphere社区的关键贡献者和建设者。他出生于阿尔及利亚，幼年移居意大利，大学期间来到北京，目前已获得企业管理博士学位。出于对技术和创新的热情，他在中国的初创公司和科技领域深耕多年。他的职业生涯和研究领域受到科技和商业交汇的影响。作为一位发表了社会科学引文索引（Social Sciences Citation Index，SSCI）论文的学者，他对技术的浓厚兴趣引导他开展了关于公司治理和财务绩效对公司创新结果的影响的研究。在此期间，他的研究方向逐渐演变成关于Apache ShardingSphere大数据生态系统和开源社区的建设。
Apache ShardingSphere（文中简称ShardingSphere）是一个新兴的分布式数据库开源生态，是基于可插拔和云原生原则设计的。
本书首先将概述数据库管理系统（database management system，DBMS）在当今的生产环境中面临的主要挑战，并简要地介绍ShardingSphere的核心概念。然后，本书将通过真实的案例介绍分布式数据库解决方案、弹性伸缩、DistSQL、全链路监控、SQL授权、用户身份认证和数据库网关，让你对ShardingSphere的架构组件、如何在既有基础设施中添加并配置这些组件以管理数据和应用等方面有全面认识。
接下来，本书将介绍ShardingSphere客户端ShardingSphere-JDBC和ShardingSphere-Proxy，以及如何根据需要结合或单独使用它们。接着，你将学习如何定制可插拔架构以定义个性化的用户策略，还有如何无缝地管理多个配置。最后，你将熟悉如何在各种场景中进行功能和性能测试。
阅读完本书，你将能够构建并部署自定义的ShardingSphere，消除数据管理基础设施中出现的重要痛点。
本书是为负责开发分布式数据库解决方案，并想探索ShardingSphere功能的数据库开发人员编写的；寻求更强大、更灵活、成本效益更高的分布式数据库解决方案的数据库管理员（database administrator，DBA）也将受惠于本书。要阅读本书，必须对数据库、关系数据库、结构化查询语言（structured query language，SQL）、云计算和数据管理有基本了解。
第1章介绍DBMS在当今的生产环境中面临的主要挑战、数据库开发人员角色的演变情况以及DBMS的机会和未来发展方向。本章还简要地介绍ShardingSphere生态、这个项目的演变过程以及软件解决方案需要满足的需求，为后续章节打下坚实的基础。
第2章从专业角度介绍ShardingSphere的架构，还有基于Database Plus的架构和插件平台。
第3章概述ShardingSphere在各行各业的企业环境中的应用，还有对分布式数据库来说必不可少的ShardingSphere特性。
第4章拓展有关ShardingSphere在企业环境中的应用方面的知识，专注于让你能够监视并改善性能以及提高安全性的ShardingSphere特性。
第5章介绍主要的ShardingSphere客户端以及它们之间的差别，还有如何根据需要结合或单独使用它们。
第6章介绍ShardingSphere-Proxy、如何直接将其用作MySQL和PostgreSQL服务器以及如何通过各种终端访问它。
第7章介绍客户端ShardingSphere-JDBC，包括它如何连接到数据库、它的第三方数据库连接池以及如何安装它。
第8章演示如何根据具体情况定制可插拔架构以充分发挥系统的作用，并简要地介绍云原生原则。
第9章介绍内置的基准和性能测试系统及其用法——从测试准备到报告分析。
第10章介绍测试常见的应用场景，包括分布式数据库、数据库安全、全链路监控和数据库网关。
第11章展示各种场景的最佳使用案例，还有一系列实例，如分布式数据库解决方案，数据库安全、全链路监控和数据库网关解决方案。
第12章拓展第11章介绍的知识，阐释如何将理论应用于实践。
附录A包含ShardingSphere文档使用指南、GitHub仓库中的示例项目、有关ShardingSphere源代码和许可的更详细的信息，以及加入ShardingSphere开源社区的方法。
在本书中，为充分发挥系统和ShardingSphere的作用，需要一些简单的工具。
这里列出了可能需要用到的软件（如下表所示），具体需要哪些取决于你对哪些特性或ShardingSphere客户端感兴趣。
在操作系统方面，可使用任何主流操作系统——Windows、macOS或Linux。本书所有的代码示例都在这 3 种操作系统中进行了测试，它们应该也适用于未来的 ShardingSphere版本。
| 本书涉及的软件 |
操作系统需求 |
|---|---|
| ShardingSphere-JDBC 5.0.0 |
Windows、macOS或Linux |
| ShardingSphere-Proxy 5.0.0 |
|
| Visual Studio Code（文本编辑器） |
|
| MySQL 5.7及以上版本 |
|
| MySQL Workbench（MySQL GUI客户端） |
|
| PostgreSQL 12及以上版本 |
|
| pgAdmin4（PostgreSQL GUI客户端） |
|
| ZooKeeper 3.6及以上版本 |
|
| PrettyZoo（ZooKeeper GUI） |
|
| JRE/JDK 8及以上版本 |
|
| Docker |
|
| Sysbench 1.0.20 |
如果在安装过程中遇到麻烦，且因环境独特而无法在本书找到解决办法，可通过ShardingSphere的GitHub仓库的Issues or Discussions部分向社区求助。
如果使用的是本书的数字版本，建议自己动手输入代码或配套的GitHub仓库下载代码，这有助于避免复制并粘贴代码可能导致的错误。
ShardingSphere采用的许可方式为Apache软件基金会的Apache License 2.0，有关这种许可方式的详情，请参阅Apache官网的Apache License 2.0文档。
本书示例代码的GitHub仓库地址为https://github.com/PacktPublishing/A-Definitive-Guide-to- ShardingSphere。如果我们更新了这些代码，将相应地更新这个GitHub仓库。
要了解更多的活动或用例，可与ShardingSphere社区联系；如果有意尝试，也可成为开源开发者。
通过阅读这部分，你将对ShardingSphere及其架构、概念和客户端有大致认识，知道数据库面临的最新挑战和未来发展方向，明白ShardingSphere在数据库领域所处的位置。这部分包括如下内容：
● 第1章，DBMS和DBA的演变及ShardingSphere扮演的角色；
● 第2章，ShardingSphere架构概述。
当前，数据被视为最宝贵的财产，但最近这种宝贵财产的主要表现形式为数据仓库，因此数据库并不总能获得众人的关注。互联网行业及其他相关或不相关行业（受互联网发展的正外部性影响的传统行业，如运输和零售行业）的飞速增长、云原生理念的面世以及数据库行业和分布式技术的发展，给企业及其基础设施提出了新要求，带来了新压力。
另外，整个社会及人们生活方式的变化，给所有现代企业都提出了新的问题、关切和要求。鉴于此，企业必须重新审视其产品、服务和架构，并考虑升级和革新从前端到后端的整个链条。最终，企业必将把数据库和数据视为这个演化过程中非常重要的部分。
简而言之，业务由数据驱动。从首席高管（如首席信息官）到DBA等相关人员都明白，数据在业务转型、让用户满意以及维持或增添竞争优势方面扮演着重要角色。
这样的认识让人专注于3个都与数据相关的方面——数据收集、数据存储和数据安全，它们都将在本书中得到详细讨论。尽管前述3个方面都未涉及数据库，但这绝不意味着大家没有认识到数据库在组织中扮演的不可或缺的角色，而是因为这一点显而易见，所以才不必赘述。
忽视数据库可能导致低效，而这种低效可能像滚雪球一样快速累积，形成严重的问题，例如糟糕的数据库体验、成本超支以及低劣的工作负载优化。同时，企业还需聘请能干的专家，以便能够利用其数据库，并高效地管理和使用数据。因此，数据、数据库和DBA构成了一个完整的系统，让企业能够高效地存储、保护和使用其资产。
本章介绍如下主题：
● DBMS的演变；
● DBA的角色演变；
● DBMS的机会及发展方向；
● 理解ShardingSphere。
阅读完本章，读者将对DBMS当前面临的挑战有全面认识。如果你熟悉数据库行业当前的发展变化情况，可将本章视为了解这些严峻挑战的复习资料或参考手册。
探讨这些挑战后，本章将简要地介绍ShardingSphere生态圈及其背后的理念。阅读完本章，你将知道ShardingSphere如何应对DBMS面临的严峻挑战，熟谙数据库行业的发展方向。
1.1 DBMS的演变在过去的10年中，促进革新的云、软件即服务（software as a service，SaaS）交付模式和开源仓库被广泛采用，数据量呈爆炸式增长。
这些大型数据集迫使组织必须部署有效而可靠的DBMS，以最大程度地改善客户体验。然而，组织对DBMS的专注给新技术和新从业者带来了机会，也带来了众多的挑战。既然你正阅读本书，说明你很可能想提高自己的技能，并强化或拓展有关如何卓有成效地管理DBMS的知识。
数据库是为存储和检索信息而生的，因此对组织来说，熟悉存储和检索海量数据的最新方法、技术和最佳实践至关重要。另外，云存储导致数据集群被广泛使用，并催生了与数据存储策略相关的数据科学。通常，应用在一天中使用的数据量在不断变化。
为了收集和处理数据，数据库必须是可靠且可伸缩的，从而能够将大型数据集拆分成多个较小的数据集。这样的需求催生了数据库分片和分区等概念，它们都用于将大型数据集分割成较小的数据集，同时确保性能和正常运行时间不受影响。这些概念将在3.2节以及第10章进行讨论。
我们根据开源倡议（Open Source Initiative）的开源定义（The Open Source Definition）的说法，总结一下开源意味着什么。所谓开源，指的是以如下许可方式发布的软件：版权持有人赋予用户以合适的方式使用、修改和分发软件（包括其源代码）。
在数据库方面，开源不仅至关重要，还可能给很多人带来惊喜。在2021年6月，全球超过50%的DBMS都是以开源方式许可的。在开源数据库软件的最近发展动向中，有大量社区是致力于探讨云原生数据库软件的。
随着云计算时代的到来，云原生数据库变得日益重要，其优点包括高弹性以及能够满足应用的苛刻要求。这种发展趋势催生了对云迁移能力和技能的需求，以便企业能够将工作负载迁移到不同的云平台。
当前，混合云和多云环境已司空见惯，将近75%的组织都说自己使用的是多云环境。在依然存储在本地设备中的数据中，大都是敏感数据（组织对是否要将其迁移到云端持谨慎态度），或是与遗留应用或环境相关（将其迁移到云端过于困难）的数据。
这一现状改变了我们对数据库的看法，并给数据库赋予了新含义：它们包含位于本地设备和云端的数据，而工作负载运行在多种不同的环境中。在数据库和基础设施领域，出现的另一项重要技术是分布式云。所谓分布式云，指的是这样一种架构：从公有云同时使用多个云，并集中管理它们。这给组织带来了基于云的服务，同时让云系统和本地系统之间的界线变得模糊。
下面将介绍被称为行业痛点的挑战，你可能熟悉这些行业痛点，但即便不熟悉，也没有关系。介绍完这些痛点，将接着介绍其他同样重要的需求，这些需求当前还未得到满足，给行业带来了新机会。
由于数据库类型的数量在不断增多，开发人员不得不花更多的时间来学习软件开发工具包（software development kit，SDK）和SQL方言，给开发留下的时间也就更少了。对企业来说，由于技术栈更复杂了，并且选择的技术必须与企业使用的应用框架匹配，因此对技术做出选择变得困难，而这可能导致架构过于庞大。
接下来介绍一些著名的行业痛点，再说说给DBMS带来了新机会的行业新需求。
DBA需要将大量时间用于研究和使用新数据库，以便知道其协作和监控方法有何不同，并搞明白如何优化性能。
外部服务和使用体验因数据库而异，这增加了在生产环境中使用和维护数据库的开销。企业部署的数据库类型越多，需要的投资也越多。出现新场景时，如果企业根据其需求不看具体情况就采用新数据库，投资迟早会呈几何级数增长。
为满足看起来类似的需求，需要编写不同的代码，而这些代码唯一的差别在于支持的数据库类型不同。在本书编写期间，ShardingSphere社区期望的代码迭代频率已急剧提高，但开发人员的响应速度降低了，因为响应速度与使用的数据类型的数量成反比。相同的需求和数据类型的数量都呈几何级数增长，这极大地降低了迭代速度。数据库数量越多，迭代的步伐越慢，同时迭代的性能水平也越低。
如果目标是同时对所有敏感数据加密，但无法在一对多数据库中这样做，那么唯一的解决方案是在业务应用端修改代码。大型企业通常运营着数十乃至数百个系统，要对所有系统的数据加密，开发人员将面临严峻的挑战。
数据加密只是开发人员可能面临的众多类似挑战之一，在异构数据库中，其他常见的通用需求还包括权限控制、审计等。
众所周知，当前的现状是异构数据库共存，这种情况还将持续很长时间。然而，没有统一的标准，就无法以协调一致的方式使用这些数据库。这里统一的标准，指的是普遍接受（至少是大都接受）的技术参考，如针对外部硬件设备的USB 2.0和USB-C；在软件方面，一个技术参考的例子是，为帮助创建iOS或Android应用而发布的SDK。
在数据库方面，ShardingSphere社区提出了Database Plus。简单地说，Database Plus指的是让用户能够管理和改善任何类型的数据库，甚至能够在同一个系统中集成不同的数据库类型。
在数据计算方面，对跨异构数据库的协作查询引擎和事务管理计划的需求在日益增长，但就目前而言，开发人员只能在业务应用端编写相关的代码，难以涉足基础设施。
企业的运营环境在不断变化，这必然会影响它们的业务决策和运营流程。变化的根源在于前面提及的数据量增加和互联网普及。本节介绍各行各业的企业对DBMS有何期望，然后说说DBA角色的演变情况。
海量数据可能导致单机数据库崩溃。为存储当前的海量数据（未来还将增加），需要更多的存储空间和服务器。为容纳这样的海量数据，单个数据库根本无法胜任。
DBMS必须存储海量的数据，同时为满足客户和用户对使用体验和响应时间的期望，DBMS不能为逐步组织数据而停机。因此，一个重大的问题是，如何从数据湖检索数据。
数据类型多种多样，关系数据结构只是其中之一。文档、JSON、图和键值对等都引人注目，这合乎情理，因为它们都来自各种业务场景。这些新的变化和需求都必将给数据库本身及其运维带来挑战。
你可能知道这些需求，甚至在自己的职业生涯中遇到过。如果你刚开始工作，不管从事的是哪个行业，都必然会遇到这些需求。这是因为DBA的角色变了，更准确地说是发生了演变。1.2节将介绍DBA角色具体是如何演变的。
1.2 DBA角色的演变行业需求的变化重塑了DBA的角色。对任何组织（无论它是否为技术型的组织）来说，DBA都很重要，同时DBA的重要性在不断提高，而提高速度与组织采用数字化技术的速度相关。DBA在不断寻找DBMS优化途径，还是主要的策略设计师，致力于应对数据高峰及确保数据安全和数据可用性。
长期以来，DBA都被视为重要战略数据资产的守护者。这种职责的范围其实很宽泛，因为包括众多其他的责任：DBA必须确保组织能够满足其数据需求，确保数据库以极佳的性能正常运行，并在出现问题时负责恢复数据。
在过去的10年中，新的数据生成设备（如智能手机和物联网设备）导致数据不断增多，进而导致需要管理的数据库实例以及使用的DBMS不断增多，这重塑了DBA的职责。最近的发展趋势是，DBA还日益深入地介入应用开发，在整个数据管理基础设施中，他们成了新兴的重要影响者。
下面介绍DBMS当前面临的常见且严峻的挑战，DBA必须为应对这些挑战做好准备。
在iPhone面世前，手机就已在人们的生活中扮演着日益重要的角色，让我们能够在四处奔波时拨打和接听电话。当前，通过这种能够装入口袋的小型设备，我们能够购物、订餐、订购旅行服务、办理银行业务、寻找工作、从事娱乐活动以及联系家人和朋友。这种互联性催生了众多新兴行业和业务模型（例如共享经济和网约车），它们有一个共同之处，那就是都与数据相关。我们使用和生产的数据呈爆炸式增长，达到了15年前不可想象的水平。
移动互联网面世后，网站和企业服务要获得成功，必须支持相关的移动应用，使其能够在每周内处理高达数以十亿计的访问量。在诸如美国的“网络星期一”和中国的“双十一”等促销日期间，已完成数字化转型的传统零售企业就是这样的典范，它们必须满足新的需求，才能成功地实现商业目标。在促销日期间，零售企业竭力将流量引向其网页或在线商店。然而，如果它们成功地吸引了流量，其数据库集群将面临不可思议的压力，这将带来什么问题呢？这是一个技术方面的问题，DBA和研发团队会问，企业的数据库集群能够处理蜂拥而至的访问者带来的流量吗？
为应对海量访问者，单体架构惨遭淘汰，正式成为历史，而微服务架构成了“新宠”。微服务架构用于将一系列关联松散的服务集成为应用，换而言之，这导致应用由一系列独立的组件组成，这些组件以服务的方式运行进程，并执行整个系统的部分任务。这些组件通过轻量级应用程序接口（application program interface，API）进行通信，由于每个服务都是独立运行的，因此可根据业务需求分别对其进行部署、更新和扩缩容。
云的面世带来了深远变化，改变了托管、交付和启动软件的方式。云带来的重大变化之一是硬件和软件之间的壁垒被打破。现在，大家的多媒体、电子邮件和银行账户分散在数以千计的服务器中，这些服务器由大量的企业控制着。在不到20年前，互联网还处于初始阶段，只有知道如何搜索目录和操作文件传送协议（file transfer protocol，FTP）文件的早期采用者和专业学者在使用。如果考虑到这一点，前述情况就更令人震惊了。
从某种意义上说，云的面世是万事俱备后的必然结果。如果回过头去看，就会发现云的成功基于如下因素：宽带互联网的广泛采用和手机的普及让用户能够始终在线，其他众多的革新让数据中心搭建和维护起来更容易。在这个领域，针对企业的革新和针对消费者的更新几乎是同步的，这样的情况难得一见。对消费者来说，互联网很快让物理存储非必不可少；对企业来说，有很多产品都让它们能够在第三方服务器上执行计算任务（有些还是免费的）。
出于对灵活性的永恒追求，很多企业都在逐步将其技术移到云端，因为云提供了可伸缩性，同时其费用是可以承受的。灵活性意味着强大的适应能力，而强大的适应能力正是企业高管追求的目标，这让企业能够对行业变化或更广阔的市场变化做出响应。另外，这给初创企业打开了直接在云端销售产品和服务的大门，同时让它们能够随时随地地构建、管理和部署应用。
鉴于云提供的巨大潜在机会，有些组织已采取云端优先的策略。所谓云端优先策略，简单地说就是放弃以自有数据中心为核心的策略，转而采用基于云的解决方案。信息技术（information technology，IT）领域的这种新趋势将导致数据库被迁移到云端，变为数据库即服务（database as a service，DBaaS）。
为跟上相关行业的发展步伐，企业需要进行数字化转型，而期间将面临众多重大的变化和需求。鉴于此，企业必须改变其存储、查询和管理数据库数据的方式，这一点很容易理解。图1.1展示了数据库面临的挑战。
图1.1 数据库面临的挑战
可以看到，右边的数据库是带问号的。这有两层意思，一是有哪些可能性，二是发展方向是什么。作为数据库从业者，你需要为此做好准备。
接下来将介绍数据库的机会和发展方向。明白这些后，你不仅能够获得竞争优势，还可在必要时做出职业发展规划。
1.3 DBMS的机会和发展方向下面来说说 DBMS 面临的机会及其发展方向，这包括数据库安全和行业新生事物（如DBaaS）等主题。
对DBMS来说，数据库安全已成为重要的关注领域之一。数据库厂商正努力对既有解决方案进行迭代，旨在解决数据库存在的问题。云厂商致力于对其云基础设施中的数据和应用进行保护。在传输过程中，数据需要经过网络、软件、负载均衡器以及其他各种组件，而它们都在逐步升级安全措施。
考虑到这个不断改进的过程，一个自然而然的问题是，如何才能无缝地集成使用不同语言和数据库开发的项目？为应对这个问题以及随之而来的挑战，无论是行业领先的企业，还是前途光明的初创企业，都投入了大量的资源。云会带来什么样的新约束呢？超过2/3的首席信息官都关心这个问题。鉴于此，开源数据库正逐渐成为不二的解决方案。
数据安全不仅对企业来说至关重要，还可能成为企业存亡的分水岭：是得以幸存下来，还是成为另一个就此关门大吉、被人永远遗忘的企业。只要想想勒索软件及其日益广泛传播的情况，就能够明白开源技术是如何让组织远离这种风险的。开源给组织提供了必要的权限和灵活性，让它们能够访问源代码，并以合适的方式配置和扩展软件，从而全面地满足其安全需求。这无疑反驳了多年前开源安全性被诟病的观点。开源数据库被企业快速采用，给开源争端画上了句号。数据库开源趋势浩浩荡荡，任何企业都无法置身事外。
说到SQL时，大家马上想到的是“古老”的关系数据库，它们在过去20年中始终支持高级服务。然而，关系数据库已开始尽显疲态，很多人都认为它们难以满足企业当前面临的需求。鉴于此，灵活的数据库行业巨头已采取积极措施，力图重塑其既有产品或提供新的解决方案。
NoSQL就是一个这样的例子。它是非关系数据库的始作俑者，提供了存储和检索非关系数据（如键值对、图、文档、宽列）的机制。然而，很多NoSQL产品都为支持可用性和分区容错性而牺牲了一致性：考虑到新时代的重要关切，NoSQL实现了高可用性和弹性伸缩，但不支持事务，也不具备SQL的标准优点。Couchbase、HBase、MongoDB及其他NoSQL数据库的成功，充分表明了人们对这种做法的支持。NoSQL数据库有时也强调如下两点：它们不仅是SQL（Not Only SQL），也认识到了传统SQL数据库的价值。出于这种认识，NoSQL数据库逐步吸纳了主流SQL产品的一些优点。
NewSQL可被定义为这样一种关系数据库管理系统（relational database management system，RDBMS）：致力于让NoSQL系统是可伸缩的，可用于执行联机事务处理（online transaction processing，OLTP）任务，同时具备传统数据库系统的原子性、一致性、隔离性和持久性（atomicity, consistency, isolation, and durability，ACID）特性。
对于NewSQL，学术界和数据库行业还在讨论中，因此前述的说法并非最终的定义。有关这方面的一项出色资料是论文“What's Really New with NewSQL”，它致力于根据架构和功能对数据库进行分类。所有宣称自己为NewSQL产品的数据库都致力于在一致性、可用性和分区容错性（capability, availability, and partition tolerance，CAP）定理之间取得良好的平衡。然而，什么样的数据库产品可归类为NewSQL呢？
DBMS面临众多的机会，有些将在中短期内给行业带来翻天覆地的变化，而新的数据库架构无疑是其中之一。通过使用新架构，可卸下遗留系统在架构方面的包袱，使用全新的代码库来设计数据库，就像一张白纸提供了无限的可能性一样：新数据库是完全根据新时代的需求来设计并构建的。
透明的分片中间件将数据库分成多个分片（shard），这些分片存储在由单节点DBMS实例组成的集群中。ShardingSphere就是这样做的。
诸如ShardingSphere等分片中间件让用户（或组织）能够将数据库分成多个分片，并将它们存储在多个单节点DBMS实例中。本节将帮助你搞明白什么是数据分片。DBA始终在寻找对DBMS进行优化的途径；出现数据输入高峰时，必须有适当的处理策略。对于这种问题，最佳的处理方法之一是，将数据分成独立的行和列，这样的方法包括数据分片和数据分区。下面来介绍这两个概念以及它们之间的不同之处。
将大型数据库表分成多个小表时，便创建了分片。新创建的表被称为分片或分区。这些分片存储在多个节点中，这提高了可伸缩性和性能。这种可伸缩性被称为水平伸缩性。分片能够让DBA以尽可能高效的方式使用计算资源，这被称为数据库优化。
优化计算资源只是分片的重要优点之一，重要的是它可减少需要扫描的行数，让用户查询的响应速度比使用单个巨型数据库时快得多。
说到分区，你可能感到困惑，这是完全正常的，因为数据分区常常让人误解。所谓分区，指的是将数据库分成多个子集，但这些子集依然存储在单个数据库（单个数据库有时也被称为数据库实例）中。那么分片和分区有何不同呢？分片和分区都将大型数据集分成多个小型数据集，但一个重要的不同是，分片意味着划分后的数据分散在多台计算机中，无论是水平分片还是垂直分片都如此。
数据库即服务（DBaaS）不仅提供改造后的云数据库，还为维护数据库的物理配置提供服务。用户无须关心数据库位于什么地方，因为云让云数据库提供商能够负责物理数据库的运维工作。
NoSQL和NewSQL代表着DBMS的未来发展方向，大部分乃至所有数据库厂商都在向这个领域进军。很多初创企业也在进军这个领域，旨在填补其中的市场空白，它们提供的服务可与著名行业巨头提供的服务相互补充。
近10年的技术进步让机器学习和人工智能（artificial intelligence，AI）等新兴领域有了长足发展。生活的方方面面最终都将受到这些技术的影响，企业及其数据库也不例外。AI数据库运维将成为推动DBMS增长的主要动力。看起来AI和数据库管理之间似乎没有关系：当前AI已成为媒体热词，而数据库管理还与以前一样，需要投入大量的人力。等到AI技术被集成到数据库运维中，通往新天地的大门将被打开。通过学习人们以前执行数据库管理任务方面的经验，有AI助力的数据库将能够提供建议，并指出该采取的措施，从而指导你对数据库集群进行管理、运维和保护。
另外，AI数据库管理平台还将能够与监控和报警系统取得联系，甚至采取某些紧急措施，以避免严重的生产事故。对企业来说，提高效率和减少人员编制始终是关注的焦点。
说到数据库迁移，有一些好消息，还有一些坏消息。秉持对未来充满乐观的精神，我们先来说说好消息：有新的数据库可供选择，例如最近面市的所有NewSQL和NoSQL产品。至于坏消息，那就是必须能够以最低的开销完成数据迁移。
在这个从旧到新的过程中，数据迁移和数据库选择至关重要。为避免给生产带来负面影响，同时避免新数据库可能导致的不稳定性，很多企业选择继续采用陈旧的数据库架构。另外，遗留的IT系统过于复杂，企业不敢冒险，这是对数据迁移没有信心的一个重要原因。面对这样的情况，很多数据库厂商（数据库服务企业）将开发新产品并将其推向市场，力图从数据库行业这个数十亿美元的市场中分一杯羹。
总之，DBMS面临的一些重大机会包括数据库安全、新的数据库架构、数据分片和DBaaS以及数据库迁移。
结束本节前，还有最后一点要说，那就是将旧数据库迁移到新数据库时，有些需要考虑的问题，包括：
● 选择本地还是云端；
● 迁移到新数据库的最低开销；
● 使用多个数据库导致的程序重构开销。
图1.2展示了从旧数据库切换到新数据库时可能带来的开销。
这些问题解决起来都绝非易事。可使用的工具和方式有很多，但大多数解决方案都要求投入大量的时间和资金，因为需要全面更换数据库类型（或厂商），重新配置整个系统，乃至为数据库开发定制补丁。别忘了，所有这些做法都面临风险，如丢失所有的数据。
图1.2 数据库迁移开销
鉴于此，我们打造了ShardingSphere，它被设计成尽可能灵活而非侵入性的，旨在让工作完成起来更加轻松。你可在不给系统带来任何负面影响的情况下快速安装它，进而解决前述所有问题，同时为本章前面提及的后续开发做好准备。下面来概述ShardingSphere及其涉及的主要概念。
1.4 理解ShardingSphere针对对等数据服务模型存在的瓶颈问题，最佳的解决方案是使用统一的数据服务平台。ShardingSphere是一个独立的数据库中间件平台，它基于Database Plus，致力于在多模型数据库之上打造标准和生态圈。因为基于Database Plus，所以ShardingSphere的3个核心特性是连接、增强和可插拔。接下来将详细讨论这些概念。
ShardingSphere的基本目标是，让你能够易如反掌地连接数据和应用。它力求与既有数据库兼容（让你感觉像直接与数据库交互一样），而不是通过开发新的API来打造全新的数据库标准。
统一的数据库入口（数据库网关）让ShardingSphere能够模拟目标数据库，并透明地访问数据库及其外围生态圈，例如应用SDK、命令行（command line）工具、图形用户界面（graphical user interface，GUI）、监控系统等。ShardingSphere当前支持众多的数据库协议，包括MySQL协议和PostgreSQL协议。
目标中的连接指的是ShardingSphere强大的数据库兼容性，即在数据和应用之间建立独立于数据库的连接，这极大地改善了增强特性。
如果只连接到数据库，而不提供额外功能，那就只能算作实现计划，其效果自然与直接连接到数据库没什么两样。然而，这样的实现计划不仅会增加网络开销，还会降低性能，因此给你带来的价值很低。
ShardingSphere的主要特点是能够捕获数据库入口，并透明地提供额外的功能，例如重定向（分片、读写分离和影子库）、转换（数据加密和数据脱敏）、身份认证（安全性、审计和授权）及治理［熔断、访问限制与分析、服务质量（quality of service，QoS）和可观察性］。
鉴于数据库的碎片化趋势，集中管理所有数据库功能就是一项不可能完成的任务。ShardingSphere提供的额外功能既不是针对单个数据库的，也不是要弥补数据库功能的缺陷，相反，它们旨在消除数据库的束缚，以统一方式解决DBMS关注的问题。
在ShardingSphere的整个发展过程中，通过逐步添加新功能的方式对其进行了扩展。为了避免陡峭的学习曲线吓退新的用户和开发人员，导致他们不敢在数据库环境中集成ShardingSphere，ShardingSphere采用了可插拔架构。
ShardingSphere的核心价值不在于它能访问多少数据库、提供多少功能，而在于它的可插拔架构，这种架构的可扩展性极强，对开发人员非常友好。开发人员可在不修改源代码的情况下，给ShardingSphere添加定制的功能。
ShardingSphere的可插拔架构由微内核和3层可插拔模块组成。ShardingSphere架构之上是顶层API，因此内核根本不知道各种功能的存在。对于不需要的功能，只需将相关的依赖删除即可，而这不会给系统带来任何影响。图1.3展示了ShardingSphere的内部结构。
可以看到，3层之间是彼此完全独立的。面向插件的设计意味着内核和功能模块提供了全面的可扩展性支持，让你在构建ShardingSphere实例时，即便将某些功能模块删除（即选择不安装它们），也不会影响总体的使用体验。
数据库中间件需要提供两方面的支持：访问数据库的驱动程序和独立的代理。考虑到任何架构适配器都存在缺陷，ShardingSphere选择开发多个适配器。
ShardingSphere-JDBC和ShardingSphere-Proxy是两款独立的产品，但你可选择采用混合模式（混合部署），即同时部署它们。这两款产品都提供了数十个增强功能，它们将数据库视为存储节点，适用于Java同构、异构语言、云原生等场景。
图1.3 ShardingSphere的内部结构
ShardingSphere-JDBC是ShardingSphere的前身，它是ShardingSphere生态圈的第一款产品，是一个轻量级Java框架，在Java数据库互连（Java database connectivity，JDBC）层提供额外的服务。ShardingSphere-JDBC提供了极大的灵活性。[1]
● 它适用于所有基于JDBC的对象关系映射（object relational mapping，ORM）框架，如JPA、Hibernate、MyBatis和Spring JDBC Template，我们还可直接将它与JDBC结合起来使用。
● 它支持所有的第三方数据库连接池，如DBCP、C3P0、BoneCP和HikariCP。
● 它支持所有遵循JDBC标准的数据库，当前ShardingSphere-JDBC支持MySQL、PostgreSQL、Oracle、SQL Server和其他所有支持JDBC接入的数据库。
[1]TTL为存活时间（time to live）的缩写。
上述的数据库和ORM框架中可能很多都是你耳熟能详的，那么ShardingSphere-Proxy又提供了哪些支持呢？下面来简要介绍一下。
ShardingSphere-Proxy是ShardingSphere生态圈的第二款产品。作为透明的数据库代理，它提供了一个数据库服务器，其中封装了数据库二进制协议，因此它支持异构语言。这个数据库代理具有如下特征：
● 对应用来说是透明的，因此可直接用作MySQL/PostgreSQL；
● 支持所有与MySQL/PostgreSQL协议兼容的客户端。
图1.4是ShardingSphere-Proxy的典型系统的拓扑结构，展示了ShardingSphere-Proxy所处的位置。
图1.4 ShardingSphere-Proxy的典型系统的拓扑结构
可以看到，ShardingSphere-Proxy是非侵入性的，很容易将其添加到系统中，这提供了极大的灵活性。[2]
你可能会问，这两个适配器有什么不同？下面简单比较它们。有关这两款产品的更深入的对比，请参阅第5章。
[2]CLI为命令行界面（command line interface）的缩写。
在简单的数据库中间件项目中，不同的接入端意味着不同的部署结构，但ShardingSphere是个例外，它支持大量的功能。因此，随着大数据计算和资源需求的日益增长，不同的部署结构有不同的资源分配方案。
ShardingSphere-Proxy有一个可独立部署的分布式计算模块，适用于执行多维数据计算的应用（这些应用对延迟不那么敏感，但需要使用较多的计算资源）。有关ShardingSphere-JDBC和ShardingSphere-Proxy的更深入的对比，请参阅第5章或ShardingSphere官网文档。
ShardingSphere-JDBC采用非集中式架构，适用于基于Java的轻量级、高性能OLTP应用，而ShardingSphere-Proxy提供了静态入口和异构语言支持，适用于联机分析处理（online analytical processing，OLAP）应用，还适用于管理和操作分片数据库。
因此，ShardingSphere生态圈提供了多个端点。我们通过混合部署ShardingSphere-JDBC和ShardingSphere-Proxy，并采用相同的分片策略，可以打造出适合多个应用场景的系统。图1.5简要展示了ShardingSphere混合部署（同时部署ShardingSphere-JDBC和ShardingSphere-Proxy）的拓扑结构。
通过像图1.5那样同时部署ShardingSphere-JDBC和ShardingSphere-Proxy，可获得混合计算功能，这让你能够调整系统架构，使其更贴合需求。
图1.5 ShardingSphere混合部署的拓扑结构
1.5 小结本章介绍了DBMS的演变、数据库行业痛点以及行业新需求。这意味着DBA必须与时俱进，紧跟潮流的步伐。既然你在阅读本书，就说明你的前进方向是正确的：你知道数据库领域正在发生重大变化，并力图走在时代的前列。
我们始终致力于引领潮流，积极应对数据库领域当前面临的挑战，为此我们开发了ShardingSphere。1.4节简要地介绍了ShardingSphere适配器及其构造，但这只是“开胃菜”，接下来还有“11道大菜”（11章），你把它们都吃完后，就将熟练掌握ShardingSphere：有一款新工具在手并拓展技能，同时紧跟数据库发展变化的潮流。
ShardingSphere是数据库行业一款独具特色的产品，它致力于通过打造Database Plus来开发一片蓝海，而非沉溺于分布式数据库这片红海。为应对数据库技术栈的碎片化，统一的数据库服务平台是唯一的解决方案，而ShardingSphere就是因此而生的，它致力于在多模型数据库之上打造标准和生态圈。
下一章你将开启ShardingSphere深度旅行，我们将对其架构做简要的介绍。
