Database table split three solutions

Click above " the Java back-end technology stack", Select" Top Public No. "

Technical articles first time delivery!

Database sub-library sub-table of three solutions

There are two ways to split the database, the text has been talked foregoing, i.e. that the vertical resolution and horizontal resolution, sub-library sub-table is a solution to the split database. According to different levels of sub-library sub-table for an embodiment of logic slices, we can divide the database library sub-table of the implementation is divided into three categories

  1. Client fragmentation

  2. Acting fragmentation

  3. Support for distributed database transactions

Client fragmentation

Sub-library is to use an application layer partition table database directly operating logic slice, slice rules need to be synchronized between multiple nodes in the same application, each application layer are embedded logic implementing an operation of slice (slice rules), this is generally achieved by relying on the jar package.

There are specific implementation can be divided into three types:

  • Directly in the application layer

  • Achieved through custom JDBC protocol

  • Achieved through custom ORM framework

Directly in the application layer

This is a very versatile and simple solution, read directly at the application layer fragmentation rules, then resolve fragmentation rules, then routing logic implemented according to specific segmentation fragmentation rules. From the application layer for each operation directly determines which database instance, database tables, etc., and which database should be used.

The following is a general internal logic will these packages, labeled jar package, other items for the company use.

Be achieved through custom JDBC protocol

In the small partners to achieve more or less directly to the application layer logic chips embedded into the code of business, and the development of children's competencies is still quite high, the development of both need to implement business logic, but also to achieve the framework requirements. In order for the development of small partners to focus more on business logic implementation, we can achieve through custom JDBC protocol, which is consistent with the business logic for providing JDBC protocol interface that allows developers to small partners do not have to be concerned about sub-libraries points implement a table, so that sub-library sub-table implementation class in internal JDBC, and transparent to the business. This solution is transparent to the business, not embedded in the code to go into business, so that the development of small partners and sub-library sub-table of staffing a certain extent, can be divided into left, allowing the development of small partners to a greater extent into to implement business logic to go, but the development of small partners still have to understand JDBC protocol to achieve sub-library sub-table logic.

For example: the current popular client sub-library sub-table frame Sharding-JDBC, is the use of such programs.

Achieved through custom ORM framework

由于关系型数据库与面向对象语言之间的差异,ORM框架得到了广泛的发展和应用,因此就有了通过定制ORM框架实现的分库分表方案,也就是把分片规则实现到了ORM框架中或者通过ORM框架支持的扩展机制来完成分库分表的逻辑。

在很多公司里是通过在Mybatis配置文件的SQL中增加表索引的参数来实现分片的。

demo代码如下:

<select id="getUser" parameter="java.util.Map" resultType="User">
    SELECT user_id,user_name FROM USER_#{index} WHERE user_id=#{userId}
<>

代理分片

就是在应用层和数据库层之间加一层代理层,把分片的路由规则配置在代理层,代理层对外提供与JDBC相兼容的接口给应用层,应用层的开发小伙伴们就不用关心分片规则了,只需要关心业务代码的实现,等业务代码实现完了以后,在代理层配置一个路由规则就搞定了。

优缺点:

优点:让应用层的开发小伙伴们更多去关注业务代码的实现,把分库分表的配置留给代理层做。

缺点:增加了代理层,增大了成本。

尽管代理层是轻量级的转发协议,但是毕竟要实现JDBC协议的解析,并且还有通过分片的路由规则来路由请求,对每个数据库操作都增加一个网络传输,这对新性能是很有影响的,需要维护增加的代理层,也有硬件成本,最主要的是需要有大牛在,大牛专门解决代理层出现的bug,哈哈,所以嘛,成本相对高不少。

比如:当前流行的分库分表使用代理分片实现的框架有Cobar、Mycat等。

支持事务的分布式数据库

现在有很多产品,比如:OceanBase、TiDB等对外提供可伸缩的体系架构,并提供一定的分布式事务支持,将可伸缩的特点和分布式事务的实现包装到分布式数据库内部实现,对其使用者透明,使用者不需要直接控制这些特性,例如:TiDB对外提供JDBC的接口,让应用层想使用Mysql等传统数据库依赖来使用TiDB,而不需要关注其内部是如何实现伸缩、分片以及处理分布式事务的。

大家都知道在金融行业,最重要的就是钱,什么金额,余额等。所以金融行业在技术方便还是比较保守的,毕竟是在于钱打交道,每天的交易流水上亿都是很正常的。在各种交易系统中,我么通常采用对事务支持良好的关系型数据库,很少有使用其他类型的数据库,而这些分布式数据库更适合实现非交易系统,比如说:大数据日志系统、统计系统、查询系统、报表系统、社交系统等等。

扫描关注,获取更多知识

发布了321 篇原创文章 · 获赞 96 · 访问量 63万+

Guess you like

Origin blog.csdn.net/o9109003234/article/details/104421476