582      新东方

数据拆分策略__最佳实践_分布式关系型数据库 DRDS-阿里云

切分维度的选择是决定我们的分布式数据最重要的一个权衡性因素，需要审慎选择，一般而言，您可以按照以下五个维度进行思考和权衡，包括数据均衡度考虑、事务边界因素、常用查询效率考虑、异构索引考虑、简单性策略。 每一个应用业务类型可能都不太一样，也不太可能匹配所有因素的最优策略，具体采用何种方式，还需要通过综合考量，每个因素都不能太走极端，否则会导致开发运维成本急剧增长。

容量和访问均衡

一般来说数据容量和访问均衡是我们考量的第一点，不均衡的数据分布和访问可能不能充分发挥数据拆分的能力，让访问体验变差，同时带来成本上的损耗，相当于1+1<2的效果。所以一般来说拆分字段区分度比较大，数据分布和访问相对会比较均衡，但是这点也需要考虑到某一个拆分值是否有热点的问题。

那么按照这个原则，能否按主键拆分(区分度最大)呢？我们没有禁止按主键拆分，但是不推荐，因为按主键拆分，如果要保持最佳性能，你每个sql都需要带上这个主键字段(当然不带扫描所有数据分片也可以，只是性能会降低)。

事务边界

事务边界越大(或者单个sql所执行的数据分片数)，那么系统的锁冲突概率越高，系统越难以扩展，性能越低。因此，若想将您的系统做到很好的扩展性，那么一个最重要的原则就是想办法划小事务边界，并尽可能让事务的边界限制在单台机器内。缩小事务边界的方式，主要有以下三类：

第一种方式：事务边界本来就很小

比如，您发现按照某个切分条件，数据分布均匀，并且事务边界只在单机内，不需要跨机事务，那么恭喜，这个切分条件是非常合适的切分维度。

第二种方式：使用基于消息的最终一致模型，将强一致事务变为最终一致事务

针对事务的拆解，是个比较复杂的概念，我们会专门进行阐述，在这里只针对一个最常见的最终一致性事务拆解模型做出简单说明。例如，当我们要通过分布式事务完成在两台数据库内的数据转账操作的时候，我们会发现有些操作不得不通过网络而进行传递，这明显的增加了单次事务的延迟，极大的降低了性能。

第三种方式：谨慎的使用分布式事务

使用最终一致性事务，一般只能解决90%的业务场景，剩下的一些场景，可能还是需要使用分布式事务方式完成。但分布式事务必然带来非常多的性能问题，因此，我们只建议在不得不使用分布式事务的时候，才使用。

常用查询

对于常用查询优化的核心要义，就是尽可能让您的一次前端请求，物理上直接发送到一台存储的机器上，尽可能避免那些需要将请求下发到多台机器的查询。下发到多台机器的查询，虽然每次查询的延迟不会出现问题，但这类查询会导致一次请求物理上必须被发送到很大一批存储的机器上，会额外占用过多下层数据节点的各类的资源，因此应该尽可能的与以避免。

异构索引

在上面的例子中出现的都是只按照一个维度进行查询时的处理方式，那么如果这个系统会有多个主要的查询维度时，我们又能有什么处理方式呢？

第一种方式

就是接受全表扫描，虽然这会带来更多地读取量，但我们可以通过水平加备库的方式，近乎无限的扩展我们的读取能力。因此是一个可行的方案，只是成本略高。

第二种方式

如果想进一步降低成本，我们可以考虑使用异构索引表，其本质就是利用异步触发器，将原表内的每一次更新，都换一个写入的维度，写入到新的表中。如果您对数据库比较熟悉，那么简单映射一下，异构索引表的作用就基本等同于传统数据库中的索引概念，其不同之处，主要是索引构建过程从同步改成了异步，索引表和主表之间可能存在100ms左右的延迟

保持简单

处理各方面冲突，在真实的世界中，切分键的选择往往都是充满着各种诱惑，选择A方案，有这些好处。而选择B方案，也会有那些好处。

如果查询优化与均衡读写访问两个选项发生了冲突，那么请选择均衡读写访问作为优先考虑原则，因为查询的问题相对的更好解决，无论是加机器做全表扫描或做异构索引复制都是可以解决的。而写入或单机容量如果出现不均衡，那么处理起来难度就比较大。

尽管复杂的切分规则或取巧的程序代码能够带来短期系统性能或成本上的好处，但其后面所带来的系统运维复杂度上升将会吃掉之前您在系统中获得的大部分好处。因此，从系统架构上来说，以82法则，简单直接处理的方式往往是最有效的方式。

最后更新：2016-11-23 16:04:05

  上一篇： DRDS操作__快速开始_分布式关系型数据库 DRDS-阿里云

  下一篇： 应用连接池选择__最佳实践_分布式关系型数据库 DRDS-阿里云