Shulou(Shulou.com)05/31 Report--

This article mainly explains "what are the advantages of distributed relational database RadonDB". The content of the explanation is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn "what are the advantages of distributed relational database RadonDB?"

Generally speaking, the current technical architecture in the direction of MySQL is a relatively stable system. Generally speaking, the traditional master-slave replication, semi-synchronization, one master and multiple slaves, to sub-database and sub-table, plus middleware, high availability, seems to be about all the tricks to play with, so based on these, we can only say that the use of MySQL is based on distributed architecture, from the perspective of CAP, consistency (C), availability (A). It is difficult to account for all aspects of partition tolerance (P).

To tell you the truth, it feels strange to hear the name RadonDB at first. Opening the technical architecture diagram and taking a quick look at it doesn't seem to be anything new, so the initial environment deployment and simple experience are actually viewed with a critical eye, asking some small questions about experience and compatibility.

However, with the in-depth communication with designer Yanfei and RadonDB team in the afternoon, I found that this architecture is really interesting, can play new tricks under the existing architecture patterns, and does solve the basic requirements of distributed solutions, which is very rare.

Let me briefly add the highlights of the product.

1. First of all, the whole set of solutions are intended to be open source, which can already be experienced in Qingyun's product line. From deployment to use, the whole process is based on the cloud platform, and the cost of basic operation and maintenance is very low.

two。 From the perspective of architecture design, the design orientation of RadonDB makes full use of the open source dividend of MySQL. The storage node directly uses the version of MySQL5.7, which can sink the storage computing tasks to the MySQL level, so it is a set of distributed solutions customized entirely based on MySQL, and the architecture looks lightweight.

3. For relational databases, the impact of capacity expansion is very large. For the implementation of RandonDB here, the upper layer is based on hash, and the storage mode is based on Range, that is, a large table can also scale out according to the range of chip key values. For example, if a large table is divided into 30 fragments, then the granularity of none of them is 1G. At this cost, online DDL or data migration are relatively controllable granularity. What I appreciate most is its implementation in elastic expansion. Based on this split idea, we can learn from similar ideas in Redis Cluster and expand the capacity according to fine-grained slot-level data.

4. In the high availability above is worth mentioning is an independent tool MySQL Plus, this tool can be based on version 5.7 of GTID to meet the original MHA to do, and then based on semi-synchronous to ensure the integrity of the data, the current whole set of solutions are based on Raft.

Of course, there are some other details that have been improved quite well:

For example, the function of audit log actually has audit requirements for many companies.

The customization of mydumper is based on go and can make full use of some advantages of go.

The stress testing tool is also customized based on go, and the experience will be better from the high availability tests in the field.

Of course, in the process of experience, we also found some areas for improvement, some are the supplement and improvement of display information, some are suggestions on the technical implementation scheme, and so on. I would like to make two simple points:

First of all, the role of RandonDB is actually a middleware, such as ProxySQL,MyCAT, which can achieve basic SQL forwarding. Taking into account the technical improvements to the future distributed transaction design, the current SQL Node is written by one node and read-only by other nodes.

For the business support of OLAP, in fact, from the SQL forwarding of RadonDB, for complexity, the need for aggregation can be directly sunk to the computing node. For the computing node, the current preliminary design is implemented by using plug-ins. The preliminary idea of the design team is to introduce a scheme similar to MariaDB columnstore. I have a suggestion that we can also use a way similar to MPP. After all, MPP is also a distributed solution. In this architecture mode, we will make full use of the advantage of storing multiple replicas, such as multiple replicas, and we can use one or two of them to meet the needs of AP, so that the write intrusiveness to the main database is minimum, and it can give full play to the characteristics of the current architecture, similar to the role of segment nodes in Greenplum.

In the communication with the RadonDB team, I found that their team is actually not large, but it is really admirable to support such a product and be able to iterate quickly.

RadonDB will be released by open source in May, in fact, open source is not only products, but also an open attitude. I hope RadonDB can bring some new ideas and improvements to our operation and maintenance work.

Thank you for reading, the above is the content of "what are the advantages of distributed relational database RadonDB". After the study of this article, I believe you have a deeper understanding of the advantages of distributed relational database RadonDB, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.