零售系统软件架构---数据架构之数据分片

一、概述

                对于一个由多个子系统组成的一个完整的系统而言。系统之间的交互，也在很大程度上反映了数据分布的情况。每个业务系统都具有自己本系统独特的业务数据。所以，目前每个业务系统一个业务库的形式。

                这种就是类似大家常说的垂直分库。然而随着业务单据的剧增，单一业务库的压力自然上升，特别是对企业应用而言，业务操作的重要性摆在第一位的。垂直分库的基础上，需要引入读写分离与水平分库分表策略。一般而言，读压力大时，我们采用读写分离就可以了，然而刚才说到，企业业务操作的比例，技术上讲就是写的压力远大于读的压力。特别是销售系统以及库存系统（不考虑报表，实际上，报表也要根据时效性，做不同处理。也分业务类，管理类）。

               一是量大，一个写要求性能较高。

二、选型

               目前我们业务库使用的是mysql数据库。网上也有一些拆分标准，比如：

  1、表的体积大于2G或行数大于1000w,以单表主键等简单形式访问数据，这个时候需要分表。
  2、表的体积大于2G或行数大于500W,以两表jion，小范围查询（结果集小100行）等形式访问数据，这个时候需要分表。
  3、表的体积大于2G或行数大于200w,以多表join，范围查询，order by，group by，高频率等复杂形式访问数据，尤其DML，这个时候需要分表。

在Mysql中，如果将拆分机制，结果集处理等应用特性写在我们的逻辑代码中，将是很恐怖的一件事情。急需一款Mysql中间件产品。

               基础开发组预研中，选定Mycat作为我们的数据库中间层。

 MyCAT的官网提到的 关键特性：（详情见官网 http://mycat.org.cn/）

• 支持 SQL 92标准
• 支持Mysql集群，可以作为Proxy使用
• 支持JDBC连接ORACLE、DB2、SQL Server，将其模拟为MySQL  Server使用
• 支持galera for mysql集群，percona-cluster或者mariadb cluster，提供高可用性数据分片集群
• 自动故障切换，高可用性
• 支持读写分离，支持Mysql双主多从，以及一主多从的模式
• 支持全局表，数据自动分片到多个节点，用于高效表关联查询
• 支持独有的基于E-R 关系的分片策略，实现了高效的表关联查询
• 多平台支持，部署和实施简单

              实际开发中，需要确定哪些表需要拆分，以及需要什么样的拆分策略。标准就是上述拆分标准。单使用什么样的拆分策略需要根据各子系统特征来确定。

三、拆分策略

              数据拆分需要了解下数据分布的方式，一种是哈希分布，比如一致性哈希；另一种方式是顺序分布，按照主键整体有序。所以不管是何种中间件也好，分布式数据库也好，数据分布大致是这两种分布形式。其他一些优化的分布方式大都在这两个基础分布之上衍生出来的。

             所以，我们讲拆分策略也基本上按照数据分布的方式来定义。具体到分片字段的选择。分片策略会受数据访问特点的影响，所以在进行数据分片前，最好先理清楚数据的访问特点，并想明白是否确实需要分片。分片字段对性能的影响非常大，所以选择一个好的分片字段是非常重要的。

             那数据访问一般都有哪些特点呢：

             大的方面分OLAP，OLTP，我们目前的系统都是业务作业层面的，mysql数据库。OLTP，如果再细分的话，我们可以粗略划分，是读密集型，还是写密集型，以及读写密集型，还有更新频度如何？不管何种形式，我们要确保的是访问的压力能均衡到各个存储系统实例上去。听上去是一个理想的做法，实际在也要做各种取舍。

             1、写操作可扩展

                   使用分片的一个主要原因之一是分散写操作。为了实现这个目标，尽可能的将写操作分散到多个分片就尤为重要了。

             2、读查询隔离
                   另外一个需要考虑的是任何一个查询操作将会由多少个分片来来提供服务。最理想的情况是，一个查询操作直接从Mycat进程路由到一个Mysql分片上去，并且这个Mysql拥有该次查询的全部数据。

             3、排序

四、拆分字段的提取

                拆分表为依据，查找所以该表相关的SQL语句，关联查询或是子查询。然后根据Where或是Join字段确定分片字段，再根据关联表关系，确定相关表拆分策略。