一种分布式数据库管理方法及系统与流程

1.本发明涉及分布式数据库管理技术领域，具体地说是一种分布式数据库管理方法及系统。


背景技术：

2.随着数据量和访问量的增长，当数据库数据量变得非常巨大的时候，单机数据库在使用过程中不可避免会遇到数据库容量、连接数、事务数、读性能瓶颈，数据库读写性能将变得很低。


技术实现要素：

3.本发明的技术任务是针对以上不足之处，提供一种分布式数据库管理方法及系统，该方法能够提高应用软件的开发效率，具有更好的代码可读性和维护性，并能够降低升级硬件带来的高额成本。
4.本发明解决其技术问题所采用的技术方案是：
5.一种分布式数据库管理方法，基于shardingsphere建立分布式数据库框架，根据实际业务进行数据分片，并根据强一致性要求与吞吐量要求选择合适的分布式事务；
6.所述数据分片包括：
7.分库和分表，根据查询qps进行拆库分库，根据单标数据量规则设定进行拆表分表；
8.配置读写分离，通过主数据库和从数据库设置实现读写分离；
9.定制分片策略；
10.制定无中心化分布式主键。
11.对于背景技术中所描述的问题，突破这些瓶颈的两种通用的解决模型是单机垂直扩展scale up模型和水平扩展scale out模型。可以通过scale-up的方式，即升级数据库服务器的cpu、内存、磁盘，将sata/sas盘换ssd盘等方式解决。不过相对scale-up来说，分布式数据库这种scale-out的方式，扩展性会更强一些，一般来说也更具性价比。
12.shardingsphere是一套开源的分布式数据库中间件解决方案组成的生态圈，它由sharding-jdbc、sharding-proxy和sharding-sidecar(规划中)这3款相互独立的产品组成。他们均提供标准化的数据分片、分布式事务和数据库治理功能，可适用于如java同构、异构语言、容器、云原生等各种多样化的应用场景。shardingshpere在刚刚过去的双十一之前通过了apache基金会的投票，正式进入孵化器，成为apache的首个分布式数据库中间件。
13.sharding-jdbc是sharding-sphere的第一个产品，也是sharding-sphere的前身，是当当网开源的一个产品。定位为轻量级的java框架，在java的jdbc层提供额外服务。它使用客户端直连数据库，以jar包形式提供服务，无需额外部署和依赖，可理解为增强版的jdbc驱动，完全兼容jdbc和各种orm框架。
14.sharding-proxy是sharding-sphere的第二个产品。它定位为透明化的数据库代
理端，提供封装了数据库二进制协议的服务端版本，用于完成对异构语言的支持。sharding-proxy屏蔽了底层的分库分表，您可以像使用一个简单的数据库一样来操作分库分表的数据。
15.sharding-sidecar定位为kubernetes或mesos的云原生数据库代理，以daemonset的形式代理所有对数据库的访问。通过无中心、零侵入的方案提供与数据库交互的的啮合层，即database。
16.shardingsphere可以采用混合使用sharding-jdbc和sharding-proxy的部署方式满足在线 管理的能力，也可以独立使用sharding-jdbc或sharding-proxy。shardingsphere希望可以通过多元化的接入端架构去满足不同需求。
17.qps是指每秒查询率。qps是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。
18.acid是指数据库管理系统(dbms)在写入或更新资料的过程中，为保证事务(transaction)是正确可靠的，所必须具备的四个特性：原子性(atomicity，或称不可分割性)、一致性(consistency)、隔离性(isolation，又称独立性)、持久性)。
19.jdbc，java数据库连接，(java database connectivity，简称jdbc)是java语言中用来规范客户端程序如何来访问数据库的应用程序接口，提供了诸如查询和更新数据库中数据的方法。
20.优选的，所述根据查询qps进行拆库分库，若查询qps为3500，单库可以支撑1000个连接数，则拆分成4个库。
21.优选的，所述读写分离配置，主数据库处理事务性增、改、删操作(insert、update、delete)，从数据库处理select查询操作。
22.优选的，所述分片策略包括：
23.标准分片策略：对应standard sharding strategy，提供对sql语句中的＝,》,《,》＝,《＝,in和between and的分片操作支持；standard sharding strategy只支持单分片键，提供precise sharding algorithm和range sharding algorithm两个分片算法，precise sharding algorithm是必选的，用于处理＝和in的分片；range sharding algorithm是可选的,用于处理between and,》,《,》＝,《＝分片，如果不配置range sharding algorithm，sql中的between and将按照全库路由处理；
24.复合分片策略：对应complex sharding strategy，提供对sql语句中的＝,》,《,》＝,《＝,in和between and的分片操作支持；complex sharding strategy支持多分片键，直接将分片键值组合以及分片操作符透传至分片算法，完全由应用开发者实现；
25.行表达式分片策略：对应inline sharding strategy，使用groovy的表达式，提供对sql语句中的＝和in的分片操作支持，只支持单分片键；对于简单的分片算法，可以通过简单的配置使用，从而避免繁琐的java代码开发，如:t_user_$-》{u_id％8}表示t_user表根据u_id模8，而分成8张表，表名称为t_user_0到t_user_7；
26.hint分片策略：对应hint sharding strategy，通过hint指定分片值而非从sql中提取分片值的方式进行分片的策略；
27.不分片策略：对应none sharding strategy，不分片的策略。
28.优选的，所述无中心化分布式主键，使用snowflake算法生成分布式唯一和基本有
序的主键。
29.优选的，所述强一致性要求采用基于xa协议的分布式事务。
30.xa协议最早的分布式事务模型是由x/open国际联盟提出的x/open distributed transaction processing(dtp)模型，简称xa协议。
31.基于xa协议实现的分布式事务对业务侵入很小。它最大的优势就是对使用方透明，用户可以像使用本地事务一样使用基于xa协议的分布式事务。xa协议能够严格保障事务acid特性。
32.优选的，对吞吐量要求较高时选择柔性事务，所述柔性事务为基于base事务要素的事务，base事务即基本可用basically available、柔性状态soft state、最终一致性eventually consistent。
33.基本可用basically available保证分布式事务参与方不一定同时在线；
34.柔性状态soft state则允许系统状态更新有一定的延时，这个延时对客户来说不一定能够察觉；
35.最终一致性eventually consistent通常是通过消息传递的方式保证系统的最终一致性。
36.在acid事务中对隔离性的要求很高，在事务执行过程中，必须将所有的资源锁定。柔性事务通过业务逻辑将互斥锁操作从资源层面上移至业务层面。通过放宽对强一致性要求，来换取系统吞吐量的提升。
37.本发明还要求保护一种分布式数据库管理系统，基于shardingsphere建立分布式数据库框架，该系统实现上述的分布式数据库管理方法。
38.本发明还要求保护一种分布式数据库管理装置，包括：至少一个存储器和至少一个处理器；
39.所述至少一个存储器，用于存储机器可读程序；
40.所述至少一个处理器，用于调用所述机器可读程序，执行上述的分布式数据库管理方法。
41.本发明还要求保护计算机可读介质，所述计算机可读介质上存储有计算机指令，所述计算机指令在被处理器执行时，使所述处理器执行上述的分布式数据库管理方法。
42.本发明的一种分布式数据库管理方法及系统与现有技术相比，具有以下有益效果：
43.本方法基于shardingsphere建立分布式数据库框架，同于统筹协调分库分表下的数据读写，而让业务开发人员只关注数据层之外的工作，而不用去用业务代码判断操作哪个库，哪个表，从而提高应用软件的开发效率；能够具有更好的代码可读性和维护性；同时降低了升级硬件带来的高额成本。
附图说明
44.图1是本发明一个实施例提供的分布式数据库管理方法实现架构图。
具体实施方式
45.下面结合具体实施例对本发明作进一步说明。
algorithm是可选的,用于处理between and,》,《,》＝,《＝分片，如果不配置range sharding algorithm，sql中的between and将按照全库路由处理。
64.复合分片策略：对应complex sharding strategy。复合分片策略。提供对sql语句中的＝,》,《,》＝,《＝,in和between and的分片操作支持。complex sharding strategy支持多分片键，由于多分片键之间的关系复杂，因此并未进行过多的封装，而是直接将分片键值组合以及分片操作符透传至分片算法，完全由应用开发者实现，提供最大的灵活度。
65.行表达式分片策略：对应inline sharding strategy。使用groovy的表达式，提供对sql语句中的＝和in的分片操作支持，只支持单分片键。对于简单的分片算法，可以通过简单的配置使用，从而避免繁琐的java代码开发，如:t_user_$-》{u_id％8}表示t_user表根据u_id模8，而分成8张表，表名称为t_user_0到t_user_7。
66.hint分片策略：对应hint sharding strategy。通过hint指定分片值而非从sql中提取分片值的方式进行分片的策略。
67.不分片策略：对应none sharding strategy。不分片的策略。
68.制定无中心化分布式主键：
69.分布式主键的生成方式分为中心化和去中心化两大类。
70.中心化可以继续采用数据库生成自增主键的方式，为每个不同的分库设置不同的初始值，并将步长设置为分片的个数即可，这种方式对分片个数有依赖，一旦再次水平扩展，原有的分布式主键不易迁移。还有一种中心化生成分布式主键的方式，即采用redis在内存中生成自增序列，但此种方式新增加了一个外部组件的依赖，一旦redis不可用，则整个数据库将无法在插入，可用性会大大下降，另外redis的单点问题也需要解决，部署复杂度较高。
71.去中心化方式无需额外部署，可扩展性也很好，因此更推荐使用。uuid是去中心化生成分布式主键较为常见的一种方式，但它的主键很长，而且无序，通过主键排序时对数据库的性能影响较大，不建议使用。目前较为完美的方案是使用snowflake算法生成分布式唯一和基本有序的主键。
72.二、选择分布式事务
73.1、xa强一致事务：
74.xa协议最早的分布式事务模型是由x/open国际联盟提出的x/open distributed transaction processing(dtp)模型，简称xa协议。
75.基于xa协议实现的分布式事务对业务侵入很小。它最大的优势就是对使用方透明，用户可以像使用本地事务一样使用基于xa协议的分布式事务。xa协议能够严格保障事务acid特性。
76.严格保障事务acid特性是一把双刃剑。事务执行在过程中需要将所需资源全部锁定，它更加适用于执行时间确定的短事务。对于长事务来说，整个事务进行期间对数据的独占，将导致对热点数据依赖的业务系统并发性能衰退明显。因此，在高并发的性能至上场景中，基于xa协议的分布式事务并不是最佳选择。
77.2、柔性事务：
78.如果将实现了acid的事务要素的事务称为刚性事务的话，那么基于base事务要素的事务则称为柔性事务。base是基本可用、柔性状态和最终一致性这三个要素的缩写：
79.基本可用(basically available)保证分布式事务参与方不一定同时在线。
80.柔性状态(soft state)则允许系统状态更新有一定的延时，这个延时对客户来说不一定能够察觉。
81.而最终一致性(eventually consistent)通常是通过消息传递的方式保证系统的最终一致性。
82.在acid事务中对隔离性的要求很高，在事务执行过程中，必须将所有的资源锁定。柔性事务的理念则是通过业务逻辑将互斥锁操作从资源层面上移至业务层面。通过放宽对强一致性要求，来换取系统吞吐量的提升。
83.本发明实施例还提供了一种分布式数据库管理系统，基于shardingsphere建立分布式数据库框架，该系统实现本发明上述实施例所述的分布式数据库管理方法。
84.本发明实施例还提供了一种分布式数据库管理装置，包括：至少一个存储器和至少一个处理器；
85.所述至少一个存储器，用于存储机器可读程序；
86.所述至少一个处理器，用于调用所述机器可读程序，执行上述实施例描述的分布式数据库管理方法。
87.本发明实施例还提供了一种计算机可读介质，所述计算机可读介质上存储有计算机指令，所述计算机指令在被处理器执行时，使所述处理器执行上述实施例描述的分布式数据库管理方法。具体地，可以提供配有存储介质的系统或者装置，在该存储介质上存储着实现上述实施例中任一实施例的功能的软件程序代码，且使该系统或者装置的计算机(或cpu或mpu)读出并执行存储在存储介质中的程序代码。
88.在这种情况下，从存储介质读取的程序代码本身可实现上述实施例中任何一项实施例的功能，因此程序代码和存储程序代码的存储介质构成了本发明的一部分。
89.用于提供程序代码的存储介质实施例包括软盘、硬盘、磁光盘、光盘(如cd-rom、cd-r、cd-rw、dvd-rom、dvd-ram、dvd-rw、dvd rw)、磁带、非易失性存储卡和rom。可选择地，可以由通信网络从服务器计算机上下载程序代码。
90.此外，应该清楚的是，不仅可以通过执行计算机所读出的程序代码，而且可以通过基于程序代码的指令使计算机上操作的操作系统等来完成部分或者全部的实际操作，从而实现上述实施例中任意一项实施例的功能。
91.此外，可以理解的是，将由存储介质读出的程序代码写到插入计算机内的扩展板中所设置的存储器中或者写到与计算机相连接的扩展单元中设置的存储器中，随后基于程序代码的指令使安装在扩展板或者扩展单元上的cpu等来执行部分和全部实际操作，从而实现上述实施例中任一实施例的功能。
92.上文通过附图和优选实施例对本发明进行了详细展示和说明，然而本发明不限于这些已揭示的实施例，基与上述多个实施例本领域技术人员可以知晓，可以组合上述不同实施例中的代码审核手段得到本发明更多的实施例，这些实施例也在本发明的保护范围之内。