CNDBA社区
1 Sharding概述
Sharding是Oracle数据层面架构，可以将数据水平切分并存储到不同的独立数据库中。其本质上就是通过分区表将数据分别存储到不同的数据库中，而在此之前分区表只能存储在不同的表空间中。
Sharding中的每个数据库都是独立存在的，运行在不同的服务器上，数据库之间相互不影响。这种单独的数据库叫做分片。所有分片组成一个逻辑的数据库，叫SDB(sharded database)。Sharding可以在单实例或RAC环境中运行，它不共享任何硬件资源，每个数据库独立运行，所以不存在单点故障。
从数据库管理员的角度来看，SDB由多个数据库组成，这些数据库可以集中或单独管理。但是，从应用程序的角度来看，SDB就是一个整体，SDB中的分片数量和数据分布对数据库应用是完全透明的。
Sharding为OLTP 应用提供了高可扩展性和完全的故障隔离，其主要有以下优点：
1) 可扩展性：Sharding消除了性能瓶颈，可以通过添加分片来提升性能、增加容量。
2) 无单点故障：分片之间不共享任何硬件资源，所以各个分片之间不会相互影响，不存在单点故障。
3) 数据物理上分开存储：可以将数据分开存储到不同的服务器上。
4) 滚动升级：可以每次只升级一个分片，而不会影响其他分片。
5) 简化云端部署：Sharding可以在云上部署。分片的大小可根据需要调整，以适应云基础架构的高可用。 Oracle Sharding支持本地，云和混合部署。
SDB的主要使用场景是通过单个分片键来访问数据的OLTP事务，所以应用必须具有定义明确的数据模型和数据分布存储策略（一致的散列，范围，列表或组合），比如面向客户的Web应用程序（如电子商务，移动和社交媒体）就非常适合使用SDB。这种应用程序具有定义良好的数据模型和数据分配策略（散列，范围，列表或组合分区方式），并主要使用分片键访问数据。
Oracle Shading的主要组件如下：
1) SDB(Sharded database)：一个逻辑Oracle数据库，包含多个独立的分片数据库。
2) Shards : 独立的物理数据库，简称分片， SDB的组成节点，SDB中最多支持1000个分片。
3) Global Service：提供访问SDB中数据的全局服务。
4) Shard catalog：一个单独的数据库，是SDB 的核心组件，用于集中存储管理 SDB 配置信息，推荐使用Data Guard高可以用架构来实现。其支持自动Shard部署，集中管理shard和跨shard查询。SDB 的配置操作，比如添加/删除 shard，Global Service 等都会记录在 Shard catalog。如果 Shard catalog 无法访问，那么只会影响一些维护操作和跨shard查询，而不会影响单独的 shard 操作。
5) Shard directors：通过GSM实现，GSM 类似于监听器，提供基于分片键的高性能连接路由，将客户端对 SDB 的请求路由到对应的 shard ，SDB中最多可以配置5个Shard directors, Shard directors和Shard catalog属于SDB的管理层。
6) Connection pools：在运行时，通过跨池连接路由数据库请求来实现Shard directors功能。
7) 管理接口 ：可以使用GDSCTL工具和OEM来管理sharding。
1.1 SDB和分片
分片是独立运行的Oracle数据库，SDB是分片的逻辑集合。分片可以放在一个机房中，也可以放在不同的机房中。对于SDB中的分片，建议使用Oracle复制技术来实现高可用性(HA)和灾难恢复(DR)，比如Data Guard。对于HA，备分片和主分片可以放在同一个机房。对于DR，主备分片需要放在不同的机房。
1.2 Global Service
全局服务是对传统数据库服务概念的一种扩展。对于全局服务，支持传统数据库服务的所有特性。对于SDB，全局服务还支持一些其他特性，例如，数据库角色、可允许的复制延迟、客户端和分片之间的区域关联等等。对于读写操作的事务，创建一个全局服务来访问SDB中主Shard的数据。对于使用ADG的高可用Shard，还可以创建只读的全局服务。
1.3 Shard Catalog
Shard catalog是一个特殊的Oracle数据库，用来存储SDB的配置数据，在SDB的集中管理中起着关键作用。所有配置更改，例如添加或删除分片、全局服务，都是在Shard catalog上进行的。SDB中的所有DDL操作都是通过连接到Shard catalog来执行的，然后再由Shard catalog传到其他分片上执行。
Shard catalog还包含SDB中所有Duplicated Table的主副本。Shard catalog使用物化视图自动将更改复制到所有分片中的表中。Shard catalog数据库还充当查询协调器，用于处理多分片查询和不指定分片键的查询。
建议对Shard catalog数据库使用Data Guard架构，用来保证高可用性。Shard catalog的可用性对SDB没有影响。Shard catalog的宕机只会影响切换到备用Shard catalog过程中需要执行维护操作或跨分片查询的能力。OLTP事务继续由SDB路由和执行，不受Shard catalog中断的影响。
1.4 Shard directors
Oracle 12c中引入了全局服务管理器(GSM:global service manager)，用来路由基于数据库角色，负载，复制延迟的连接。为了支持Oracle Sharding，GSM支持了基于数据位置的连接路由，通过GSM实现了Shard directors。
Shard directors作用就是充当客户端和SDB之间的监听，维护SDB环境中的拓扑图(记录了所有分片和它们之间的关系)，然后根据客户端请求传递过来的分片键，将连接路由到相应的分片上进行查询。
由于Shard directors本身不存储数据，只是充当一个指挥者的角色，所以对于部署Shard directors机器的性能要求非常低。但是为了保证高可用，建议将其部署到DG环境中。在Oracle 12c R2中，同一个环境中最多支持5个Shard directors。 GSM 本质上就是一个监听程序。
以下是Shard directors的主要作用：
1) 运行期间维护SDB的配置数据和分片数据的可用；
2) 计算自己和其他区域的网络延迟；
3) 作为客户端连接到SDB的监听；
4) 管理全局服务；
5) 连接负载均衡 。
1.5 连接池
Oracle支持数据访问驱动程序（如OCI，JDBC和ODP.NET）中的连接池。在Oracle 12c R2中，这些驱动程序可以识别连接请求中的分配键。类似地，JDBC客户端的Oracle Universal Connection Pool (UCP)也可以识别连接URL中指定的分片键。Oracle UCP还允许Apache Tomcat和WebSphere等非Oracle应用程序客户端使用Oracle Sharding。
根据应用程序请求指定的分片键，Oracle客户端通过使用UCP缓存的路由信息来直接将数据库请求路由到指定的分片上，这样就减少了网络之间的访问磁盘。对于大并发下的应用访问，可降低事务延迟。
在第一次连接到分片时，由Shard directors来决定将连接请求路由到哪个分片上。之后Oracle就将路由信息缓存了起来，如果下一次连接请求的分片键在缓存中，那么将直接被路由到指定分片上，不会经过Shard directors。而当某个分片不可用或SDB环境结构有变化，那么之前的缓存信息将不可用，缓存信息将被自动刷新。对于高性能，数据相关的路由，Oracle建议在访问SDB中的数据时使用连接池。
版权声明：本文为博主原创文章，未经博主允许不得转载。
