是它们的散列取模(即节点数量)必需是一致的。(是它们的散列取模(即节点数量)必需是一致的。(
本文着重介绍sharding的基本思想和理论上的切分策略,关于更加细致的实施策略和参考事例请参考我的另
一篇博文:数据库分库分表(sharding)系列(一) 拆分实施策略和示例演示
)
1.事务问题:
解决事务问题目前有两种可行的方案:分布式事务和通过应用程序与数据库共同控制实现事务下面对两套
方案进行一个简单的对比。
方案一:使用分布式事务
优点:交由数据库管理,简单有效
缺点:性能代价高,特别是shard越来越多时
方案二:由应用程序和数据库共同控制
原理:将一个跨多个数据库的分布式事务分拆成多个仅处
于单个数据库上面的小事务,并通过应用程序来总控
各个小事务。
优点:性能上有优势
缺点:需要应用程序在事务控制上做灵活设计。如果使用
了spring的事务管理,改动起来会面临一定的困难。
2.跨节点Join的问题
只要是进行切分,跨节点Join的问题是不可避免的。但是良好的设计和切分却可以减少此类情况的发
生。解决这一问题的普遍做法是分两次查询实现。在第一次查询的结果集中找出关联数据的id,根据这些id发
起第二次请求得到关联数据。
3.跨节点的count,order by,group by以及聚合函数问题
这些是一类问题,因为它们都需要基于全部数据集合进行计算。多数的代理都不会自动处理合并工作。
解决方案:与解决跨节点join问题的类似,分别在各个节点上得到结果后在应用程序端进行合并。和join不
同的是每个结点的查询可以并行执行,因此很多时候它的速度要比单一大表快很多。但如果结果集很大,
对应用程序内存的消耗是一个问题。
关于垂直切分关于垂直切分Vertical Sharding的粒度的粒度
垂直切分的粒度指的是在做垂直切分时允许几级的关联表放在一个shard里.这个问题对应用程序和sharding实现有着很大
的影响.
关联打断地越多,则受影响的join操作越多,应用程序为此做出的妥协就越大,但单表的路由会越简单,与业务的关联性
会越小,就越容易使用统一机制处理.在此方向上的极端方案是:打断所有连接,每张表都配有路由规则,可以使用统
一机制或框架自动处理.比如amoeba这样的框架,它的路由能且仅能通过SQL的特征(比如某个表的id)进行路由.
反之,若关联打断地越少,则join操作的受到的限制就小,应用程序需要做出的妥协就越小,但是表的路由就会变复杂,
与业务的关联性就越大,就越难使用统一机制处理,需要针对每个数据请求单独实现路由.在此方向上的极端方案是:
所有表都在一个shard里,也就是没有垂直切分,这样就没有关联被打断.当然这是非常极端的,除非整个数据库数据库 很简
单,表的数量很少.
实际的粒度掌控需要结合“业务紧密程度”和“表格数据量”两个因素综合考虑,一般来说:
若划归到一起的表格关系紧密,且数据量并不大,增速也非常缓慢,则适宜放在一个shard里,不需要再进行水平切
分;
若划归到一起的表格数据量巨大且增速迅猛,则势必要在垂直切分的基础上再进行水平切分,水平切分就意味着原
单一shard会被细分成多个更小的shard,每一个shard存在一个主表(即会以该表ID进行散列的表)和多个相之相关的
关联表。
总之,垂直切分的粒度在两个相反的方向上呈现优势与劣势并存并相互博弈的局面.架构架构师需要做的是结合项目的实际
情况在两者之间取得收益最大化的平衡.
数据库分库分表数据库分库分表(sharding)系列系列(一一) 拆分实施策略和示例演示拆分实施策略和示例演示
本文原文连接: http://blog.csdn.net/bluishglc/article/details/7696085 ,转载请注明出处!本文着重介绍sharding切分策略,如果你对数据数据