数据库sharding

标签: 数据库 sharding | 发表时间:2016-12-22 09:21 | 作者:gavin2lee
出处:http://www.iteye.com

sharding

 

 

 

  • 在DAO层实现

当团队决定自行实现sharding的时候,DAO层可能是嵌入sharding逻辑的首选位置,因为在这个层面上,每一个DAO的方法都明确地知道需要访问的数据表以及查询参数,借助这些信息可以直接定位到目标shard上,而不必像框架那样需要对SQL进行解析然后再依据配置的规则进行路由。另一个优势是不会受ORM框架的制约。由于现在的大多数应用在数据访问层上会依赖某种ORM框架,而多数的shrading框架往往无法支持或只能支持一种orm框架,这使得在选择和应用框架时受到了很大的制约,而自行实现sharding完全没有这方面的问题,甚至不同的shard使用不同的orm框架都可以在一起协调工作。比如现在的 Java应用大多使用 hibernate,但是当下还没有非常令人满意的基于hibernate的sharding框架,(关于hibernate hards会在下文介绍),因此很多团队会选择自行实现sharding。

 

简单总结一下,在DAO层自行实现sharding的优势在于:不受ORM框架的制约、实现起来较为简单、易于根据系统特点进行灵活的定制、无需SQL解析和路由规则匹配,性能上表现会稍好一些;劣势在于:有一定的技术门槛,工作量比依靠框架实现要大(反过来看,框架会有学习成本)、不通用,只能在特定系统里工作。当然,在DAO层同样可以通过XML配置或是注解将sharding逻辑抽离到“外部”,形成一套通用的框架. 不过目前还没有出现此类的框架。

  • 在ORM框架层实现

在ORM框架层实现sharding有两个方向,一个是在实现O-R Mapping的前提下同时提供sharding支持,从而定位为一种分布式的数据访问框架,这一类类型的框架代表就是 guzz另一个方向是通过对既有ORM框架进行修改增强来加入sharding机制。此类型的代表产品是 hibernate shard. 应该说以hibernate这样主流的地位,行业对于一款面向hibernate的sharding框架的需求是非常迫切的,但是就目前的hibernate shards来看,表现还算不上令人满意,主要是它对使用hibernate的限制过多,比如它对HQL的支持就非常有限。在mybatis方面,目前还没有成熟的相关框架产生。有人提出利用mybatis的插件机制实现sharding,但是遗憾的是,mybatis的插件机制控制不到多数据源的连接层面,另一方面,离开插件层又失去了对sql进行集中解析和路由的机会,因此在mybatis框架上,目前还没有可供借鉴的框架,团队可能要在DAO层或Spring模板类上下功夫了。

  • 在JDBC API层实现

JDBC API层是很多人都会想到的一个实现sharding的绝佳场所,如果我们能提供一个实现了sharding逻辑的JDBC API实现,那么sharding对于整个应用程序来说就是完全透明的,而这样的实现可以直接作为通用的sharding产品了。但是这种方案的技术门槛和工作量显然不是一般团队能做得来的,因此基本上没有团队会在这一层面上实现sharding,甚至也没有此类的开源产品。笔者知道的只有一款商业产品 dbShards采用的是这一方案。

  • 在介于DAO与JDBC之间的Spring数据访问封装层实现

在springd大行其道的今天,几乎没有哪个java平台上构建的应用不使用spring,在DAO与JDBC之间,spring提供了各种template来管理资源的创建与释放以及与事务的同步,大多数基于spring的应用都会使用template类做为数据访问的入口,这给了我们另一个嵌入sharding逻辑的机会,就是通过提供一个嵌入了sharding逻辑的template类来完成sharding工作.这一方案在效果上与基于JDBC API实现的方案基本一致,同样是对上层代码透明,在进行sharding改造时可以平滑地过度,但它的实现却比基于JDBC API的方式简单,因此成为了不少框架的选择,阿里集团研究院开源的 Cobar Client就是这类方案的一种实现。

  • 在应用服务器与数据库之间通过代理实现

在应用服务器与数据库之间加入一个代理,应用程序向数据发出的数据请求会先通过代理,代理会根据配置的路由规则,对SQL进行解析后路由到目标shard,因为这种方案对应用程序完全透明,通用性好,所以成为了很多sharding产品的选择。在这方面较为知名的产品是mysql官方的代理工具: Mysql Proxy和一款国人开发的产品: amoeba。mysql proxy本身并没有实现任何sharding逻辑,它只是作为一种面向mysql数据库的代理,给开发人员提供了一个嵌入sharding逻辑的场所,它使用lua作为编程语言,这对很多团队来说是需要考虑的一个问题。amoeba则是专门实现读写分离与sharding的代理产品,它使用非常简单,不使用任何编程语言,只需要通过xml进行配置。不过amoeba不支持事务(从应用程序发出的包含事务信息的请求到达amoeba时,事务信息会被抹去,因此,即使是单点数据访问也不会有事务存在)一直是个硬伤。当然,这要看产品的定位和设计理念,我们只能说对于那些对事务要求非常高的系统,amoeba是不适合的。

二、使用框架还是自主开发?

前面的讨论中已经罗列了很多开源框架与产品,这里再整理一下:基于代理方式的有MySQL Proxy和Amoeba,基于Hibernate框架的是Hibernate Shards,通过重写spring的ibatis template类是Cobar Client,这些框架各有各的优势与短板,架构师可以在深入调研之后结合项目的实际情况进行选择,但是总的来说,我个人对于框架的选择是持谨慎态度的。一方面多数框架缺乏成功案例的验证,其成熟性与稳定性值得怀疑。另一方面,一些从成功商业产品开源出框架(如阿里和淘宝的一些开源项目)是否适合你的项目是需要架构师深入调研分析的。当然,最终的选择一定是基于项目特点、团队状况、技术门槛和学习成本等综合因素考量确定的。



已有 0 人发表留言,猛击->> 这里<<-参与讨论


ITeye推荐



相关 [数据库 sharding] 推荐:

数据库sharding

- - 数据库 - ITeye博客
当团队决定自行实现sharding的时候,DAO层可能是嵌入sharding逻辑的首选位置,因为在这个层面上,每一个DAO的方法都明确地知道需要访问的数据表以及查询参数,借助这些信息可以直接定位到目标shard上,而不必像框架那样需要对SQL进行解析然后再依据配置的规则进行路由. 另一个优势是不会受ORM框架的制约.

你的数据库过度 Sharding 了吗

- VonNeumann - Sky.Jian 朝阳的天空
数据库 Sharding 目前已经是数据层架构的家常便饭了,随着越来越多的人不断的通过 Sharding 技术来提升数据层的扩展能力,Sharding 本身所带来的各种弊端也开始不断的显露出来了. 最近和朋友聊天的时候针对 Sharding 带来的问题做了一些交流,记录之:. 急于 Sharding,分区键考虑不充分,影响业务发展.

数据库分库分表(sharding)系列

- - 数据库 - ITeye博客
(一) 拆分实施策略和示例演示. (三) 关于使用框架还是自主开发以及sharding实现层面的考量. (四) 多数据源的事务处理. (五) 一种支持自由规划无须数据迁移和修改路由代码的Sharding扩容方案. (一) 拆分实施策略和示例演示. 图1.数据库分库分表(sharding)实施策略图解.

数据库Sharding的基本思想和切分策略

- - BlogJava-qileilove
 本文着重介绍sharding的基本思想和理论上的切分策略,关于更加细致的实施策略和参考事例请参考我的另一篇博文:. 数据库分库分表(sharding)系列(一) 拆分实施策略和示例演示.   Sharding的基本思想就要把一个数据库切分成多个部分放到不同的数据库(. server)上,从而缓解单一数据库的性能问题.

MongoDB的分片Sharding

- - 博客园_首页
一、         分片簇综述. 分片是mongoDB扩展的一种方式. 分片分割一个collection并将不同的部分存储在不同的机器上. 当一个数据库的collections相对于当前空间过大时,你需要增加一个新的机器. 分片会自动的将collection数据分发到新的服务器上. 分片自动的均衡数据并在机器间进行负载.

基于Redis Sentinel的Redis集群(主从&Sharding)高可用方案

- - 开源软件 - ITeye博客
本文主要介绍一种通过Jedis&Sentinel实现Redis集群高可用方案,该方案需要使用Jedis2.2.2及以上版本(强制),Redis2.8及以上版本(可选,Sentinel最早出现在Redis2.4中,Redis2.8中Sentinel更加稳定),Redis集群是以分片(Sharding)加主从的方式搭建,满足可扩展性的要求;.

基于jedis、redis-sentinel的redis主从、高可用、sharding架构

- - 开源软件 - ITeye博客
最近项目上需要对Redis(目前redis用的是2.8版本)做高可用、集群等优化,就扩展了jedis客户端(MasterSlaveJedis、MasterSlaveJedisPool、ShardedMasterSlaveJedis、ShardedMasterSlaveJedisPool),以满足以下几个需求:.

kingshard--一个支持sharding的MySQL Proxy项目

- - SegmentFault 最新的文章
kingshard是一个由Go开发高性能MySQL Proxy项目,kingshard在满足基本的读写分离的功能上,致力于简化MySQL分库分表操作;能够让DBA通过kingshard轻松平滑地实现MySQL数据库扩容. 4.平滑上线DB或下线DB,前端应用无感知. kingshard sharding介绍.

Sharding-JDBC 1.3.1 发布,当当 JDBC 增强驱动

- - 开源中国社区最新新闻
Sharding-JDBC 1.3.1 发布了,Sharding-JDBC是当当应用框架ddframe中,从关系型数据库模块dd-rdb中分离出来的数据库水平分片框架,实现透明化数据库分库分表 访问. Sharding-JDBC是继dubbox和elastic-job之后,ddframe系列开源的第3个项目.