共计 2696 个字符，预计需要花费 7 分钟才能阅读完成。
为进一步理解各家厂商的利用场景与深层次需要，晋升企业研发团队在应用 Apache ShardingSphere 的效率，Apache ShardingSphere 社区开启了【走进企业】系列流动。
2 月 28 日，Apache ShardingSphere 核心技术团队应邀来到中信云网，Apache ShardingSphere PMC Chair、SphereEx CEO 张亮与中信云网的技术同学在开源生态建设、ShardingSphere 场景解决方案等方面开展了深度交换和探讨。
作为一家由中信集团全资成立的产业互联网赋能平台服务型公司，联合本身物联网、云计算以及大数据平台，曾经造成智能建造、智慧园区、智慧水务、智能制作、衰弱养老、智慧农业等多个深度聚焦行业场景的产品及解决方案，中信云网开始思考如何在现有数据库体系上进行技术革新，以反对多个产业的翻新倒退。与此同时，作为中间件畛域最驰名的开源我的项目之一，随同着 Apache ShardingSphere 生态的扩充，Apache ShardingSphere 的能力与中信云网的技术场景逐步产生了交加。
迁徙后如何确保数据统一
业务倒退到肯定阶段，激增的业务压力以及数据量的暴发会给企业带来新的挑战，Scale-Out 的形式可无效解决以上问题。
Apache ShardingSphere 通过 Scaling 工具实现在线的弹性扩容，同时也提供了多种内置的数据一致性校验算法，用以比拟源端数据和指标端数据是否统一，默认应用 CRC32 以便在速度与一致性上获得均衡，且校验算法反对 SPI 自定义。数据迁徙工夫和数据量级成正比，为保障两端数据统一，个别须要停机窗口来让日志追平，最初通过 Scaling、业务层以及数据库层实现数据校验。
Apache ShardingSphere 能够将数据迁徙工作分为多个局部并行执行，合并同一记录的批改操作，在配置上之后再执行一条命令进行主库的写入，使主库只具备只读的权限，同时在只读期间暂停 SQL 执行并在停写的霎时确保数据是全局统一的，进而再操作切库，缩小对于零碎可用性的影响。
JDBC 与 Proxy，面向不同外围用户
Apache ShardingSphere 反对 JDBC 接入、Proxy 接入这两种模式，云上 Mesh 接入的形式正在研发中，用户能够按具体需要来做选型，在原有集群之上来做分片、读写拆散、数据迁徙等相干操作。
ShardingSphere-JDBC 面向应用 Java 的研发人员，定义为一款轻量级的 Java 框架，可将其了解为一款加强的 JDBC 驱动程序，其性能更高，对于性能损耗在 2%-7% 之间，如果专一于调优，可能损耗 0.1% 都不到，更可能满足研发人员的需要。研发人员可能通过 JDBC 客户端间接拜访数据库，以 jar 的模式提供服务，不须要额定的部署和依赖。
ShardingSphere-Proxy 则是面向于运维人员的数据库管控代理端，用户须要先通过 Proxy 后能力拜访数据库，两头经验了网络的一跳，导致 Proxy 产生 30%-70% 的性能损耗。因而 ShardingSphere-JDBC 模式的性能要显著优于 ShardingSphere-Proxy。但 ShardingSphere 可插拔架构提供了数十个基于 SPI 的扩大点，基于扩大点，ShardingSphere 默认实现了数据分片、读写拆散、数据加密、影子库压测、高可用等性能，开发者能够非常不便的对性能进行定制化扩大。
ShardingSphere-JDBC 采纳去中心化架构，实用于 Java 开发的高性能轻量级 OLTP 利用。ShardingSphere-Proxy 提供动态入口和全语言反对，实用于 OLAP 利用和分片数据库的治理和运行状况。一端面向研发侧，一端面向运维侧，JDBC 为研发晋升了效率，Proxy 为运维带来了质的变动，应用 DistSQL 即可像操作数据库一样操作 Apache ShardingSphere，赋予运维侧人员更多的研发能力，进而为企业提供更加全面的数据管控能力。
通过 ShardingSphere-JDBC 和 ShardingSphere-Proxy 的混合应用，以及同一个注册核心对立的分片策略，ShardingSphere 能够构建一个实用于各种场景的利用零碎，造成相似数据库网关的模式，用户能够通过 Proxy 治理底层所有数据库集群，并且可能通过 SQL 察看到分布式集群的状态，从而能够让运维人员、架构师将零碎架构调整为最适宜业务须要的架构，进而更自在地开展业务。
ShardingSphere 联邦查问
SQL Federation 联邦查问是针对散布在多个不同数据库上的数据提供跨库查问能力的一种查问形式，用户无需将这些数据存储到同一个数据库中即可执行查问。SQL Federation 引擎蕴含了 SQL Parser、SQL Binder、SQL Optimizer、Data Fetcher 及 Operator Calculator 等流程，用于解决跨多个数据库实例的关联查问及子查问，底层应用 Calcite 基于关系代数进行 RBO（Rule Based Optimizer）和 CBO（Cost Based Optimizer）优化，通过最优执行打算查问出后果。
随着现阶段数据仓库、数据湖等概念的风行，ShardingSphere SQL Federation 的利用须要与场景具体联合起来。
对于用户而言，如果须要联邦查问的数据库是关系型数据库的话，应用 ShardingSphere 就会很不便，因为数据湖部署起来比较复杂，ShardingSphere 通过对接数据库，能够对数据湖内和数据湖外的数据进行联邦计算，实现左外链接、右外链接、简单的聚合查问等等。此外大数据处理是须要过程和工夫的，如果数据体量十分大，数据湖必定是更优的抉择。但如果数据体量绝对较小，且对数据处理的实时性要求较高时，ShardingSphere 则绝对更高效，操作、实现起来也比较简单。
【分割咱们】
如果您在业务中有利用 Apache ShardingSphere，想要疾速理解、接入 Apache ShardingSphere 5.0 新生态，心愿借此机会在团队外部举办一场对于 Apache ShardingSphere 的技术分享，欢送在公众号后盾中留下您的 姓名、公司、职位、电话 等信息，或增加官网小助手:ss_assistant_1，备注“走进企业”，会有专人与您对接。
在沟通过后如果单方认为产品和场景均十分匹配，Apache ShardingSphere 社区的外围团队将会走进您的企业，与各条研发线的工程师们现场沟通，解答对于 Apache ShardingSphere 的任何疑难。
