Distributed database middleware comparison summary (1)
At present, there are many database middleware. Basically, these middleware are understood and used below, and the advantages and disadvantages of various middleware and usage scenarios are also somewhat conscientious. So summarize a series on middleware comparison, I hope it can be helpful to everyone.
1. What is middleware
The traditional architecture mode is that the application connects to the database to directly access the data, which is characterized by simplicity and convenience.
However, as the current amount of data continues to increase, we have encountered problems:
- The amount of data in a single table is too large
- The amount of data in a single database is too large
- A single data server is under great pressure
- Read and write speed encounters a bottleneck
When faced with the above problems, the first solution we will think of is to scale up (scale up) , which is simply to continuously increase the hardware performance. This method can only solve the problem temporarily, and it will not solve the problem when the business volume continues to grow. Especially when Taobao, facebook, and youtube are linear or even exponentially rising
At this point we have to rely on the second way: horizontal scaling . Directly increase the machine, put the database on a different server, and add a proxy between the application and the database for routing, so that the above problems can be solved.
2. Middleware and read-write separation
Many people think of middleware as read-write separation. In fact, read-write separation is only a function that middleware can provide. The main function is that it can separate databases and tables . The following is a schematic diagram of read-write separation:
As can be seen from the above figure, the red line represents write requests, and the green line represents read requests. This is a simple read-write separation. Let's take a look at the sub-database sub-table middleware.
The above picture shows the role of middleware, such as the following SQL:
- <span class="operator" style=""><span class="keyword" style="">select</span> * <span class="keyword" style="">from</span> table_name <span class="keyword" style="">where</span> id = <span class="number" style="">1</span>;</span>
按照中间件分库分表算法，此SQL将发送到DB1节点，由DB1这个MySQL负责解析和获取id=1的数据，并通过中间件返回给客户端。而在读写分离结构中并没有这些分库分表规则， 他只能在众多读节点中load balance随机进行分发，它要求各个节点都要存放一份完整的数据。
3.各类中间件比较
目前市面上中间件种类很多种 先看下各种中间件背景:
Cobar:
阿里巴巴B2B开发的关系型分布式系统，管理将近3000个mysql实例。 在阿里经受住了考验，后面由于作者的走开的原因cobar没有人维护 了，阿里也开发了tddl替代cobar。
MyCAT:
社区爱好者在阿里cobar基础上进行二次开发，解决了cobar当时存 在的一些问题，并且加入了许多新的功能在其中。目前MyCAT社区活 跃度很高，目前已经有一些公司在使用MyCAT。总体来说支持度比 较高，也会一直维护下去，
OneProxy:
数据库界大牛，前支付宝数据库团队领导楼总开发，基于mysql官方 的proxy思想利用c进行开发的，OneProxy是一款商业收费的中间件， 楼总舍去了一些功能点，专注在性能和稳定性上。有朋友测试过说在 高并发下很稳定。
Vitess:
这个中间件是Youtube生产在使用的，但是架构很复杂。 与以往中间件不同，使用Vitess应用改动比较大要 使用他提供语言的API接口，我们可以借鉴他其中的一些设计思想。
Kingshard:
Kingshard是前360Atlas中间件开发团队的陈菲利用业务时间 用Go语言开发的，目前参与开发的人员有3个左右， 目前来看还不是成熟可以使用的产品，需要在不断完善。
Atlas:
The 360 team rewritten lua in C based on mysql proxy. The original version supports sub-tables, and the sub-database sub-table version has been released. I saw some friends on the Internet often say that it will often hang up under high concurrency. If you want to use it, you need to test it in advance.
MaxScale与MySQL Route:
These two middleware are both official. MaxScale is developed by mariadb (a version maintained by the original author of MySQL). The current version does not support sub-database and sub-table.
MySQL Route is a middleware released by the official MySQL company Oracle .
These two middleware will be followed up and tested later to see how the effect is.
4. Conclusion
Here is a brief introduction to the origin and characteristics of various middleware. Later articles will introduce more detailed features, advantages and disadvantages, and performance test results of each middleware.