对几种分布式关系型数据路由工具的考察.docx

对开源的分布式关系型数据路由工具的考察问题的由来一个生产系统总会经历一个业务量由小变大的过程，可扩展性成为了考量系统高可用性的一个重要衡量指标。在大数据时代，数据规模的支持成为衡量系统能力的重要指标。现代，大数据处理已经普及到各个行业，各种规模的企业和项目都有可能会接触到传统意义上的“大数据”，集中式的数据库已经不能满足系统扩容和灾备等各种需要。在云计算和大数据的时代中，我们经常碰到需要提供数据分片的关系型数据结构。一方面，需要基于SQL的关系型数据存储结构和OLTP事务的支持能力，另一方面需要能支持海量数据。一般谈大数据，都侧重数据存储和数据分析技术。这当然是大数据技术当中必不可少的方向，我们这里谈一下OLTP类应用如何拥抱大数据的问题。谈这个问题，就不可避免的需要谈到DRDS。DRDS的全称是分布式关系型数据库服务(Distribute Relational Database Service)。DRDS的概念其实并不是这些年才有，事实上，远在互联网和“大数据”概念时代之前，银行和电信业早已在处理数十亿数百亿级的数据，并且采用了传统的分区、分表、分库等手段，因此数据分片并不是什么新鲜概念。Oracle 9以前就提供分区表的功能，并且提供管理了TB以上单表的生产案例。在后来若干年中，支持数据分区已经成为各种商业数据库的标配特性。DRDS（分布式数据服务）为了解决OLTP类应用下的大数据问题。在过去，我们需要在OLTP业务中处理大数据时，不得不购买昂贵的商业数据库解决方案，如Oracle RAC、甚至是天价的Exadata。但是随着互联网企业将大数据的门槛进一步降低，目前业界的一个重要研究方向是，用多个小型的（开源）数据库实例，来替换传统的大型数据库，比如用MySQL集群替代Oracle数据库。DRDS和数据库自身分区方案的比较数据库软件提供的数据分片方案，一般都是分区方案，根据分区条件，可以让数据存储在不同的表空间中。在DBA配置完分区规则后，整个分区的动作对应用程序是透明的。开发人员可以用普通的SQL语句来操作分区表，无须考虑分区的规则和数据位置。商业数据库提供的原生数据分区方案，有不可替代的优越性——使用简单，性能较好，而且数据还会提供进一步的优化特性（如分区索引等）。最大的特点是，数据库原生的分区方案基本都能做到对开发者透明。尽管数据库的供应商们已经为我们设计了众多的数据分片sharding方式；尽管在大数据时代各种分布式数据存储系统都提供了海量的存储规模。然而在大量的系统中，基于分库分表的RDBMS仍然占用重要的地位。在对实时性和一致性有高度要求的系统中，分库分表依然是处理海量结构化数据最重要的手段，并且为此也开发出了众多的中间框架。为什么系统的开发者们不使用数据库软件本身提供分区功能，而要自行开发分库分表的DRDS实现？一般有以下的理由——使用数据库分区功能对数据库DBA的人力和技能要求。分区表后期的维护复杂性。分成不同的表，有利于数据的归档、清除、备份等维护性行为。例如对交易记录和日志等，按历史表归档既简单又符合业务需求。需要用多台数据库服务器的场合。RDBMS一般只提供分区功能，无法将分片到不同的实例上。成本因素。不愿意花费购买商业数据库的分区特性或相关服务。还是成本因素。使用了一些不支持分区功能的低成本数据库。希望保留跨数据库的移植性。用户希望系统将来能移植到其他数据库软件上，无论这些软件是否支持分区功能。习惯和守旧。沿用过去的做法，不愿意学习和接受数据库软件的新功能。对于上面的几种因素，除了最后一种以外，我们都有在应用中自行实现数据分片的必要。分库分表依然是数据库分片中，成本最低，适应性最广，对开发者要求最低的方案。因此这种做法到今天为止也有着广泛的市场。但无论任何用户自行开发的或是框架提供的分表方案，都对操作有着诸多的限制，（例如不支持Join等），因此不能完全做到对开发者透明。三、DRDS需要支持水平拆分和垂直拆分水平拆分水平拆分就是将原本一张表的数据，按每条记录的特性分别存储到不同的数据表或数据库中。例如——将用户表拆成男用户表和女用户表将日志表拆成每个月一张表将某数据备份表拆成周一到周日，七张表并循环使用按手机尾号的数字将用户拆分到10张表上。水平拆分示意如下——水平分表后，拆开的表可以分布在同一个数据库上，也可以分布到不同的数据库上。水平分区在大型网站，大型企业应用中经常采用。目的是出于海量数据分散存储，分散操作，分散查询以便提高数据处理量和整体数据处理性能。垂直拆分垂直拆分，就是将不同的数据表存在到不同的数据库中。起到均衡负载的作用。解决多个表之间的IO竞争问题。但是垂直拆分不解决单表数据库过大引起的查询和修改效率等问题。在实际操作中，一个DRDS中难度最大的是水平拆分，而水平拆分最大的难度在于路