PolarDB-X with X-DB, PolarDB
To answer this question, we must first understand what is X-DB.
What is X-DB?
In short, X-DB mainly refers to a distributed cross-AZ high-availability database built on the basis of MySQL and based on the XEngine engine.
One of the core capabilities of X-DB is based on Paxos cross-AZ RPO of 0. Initially, the MySQL used internally by Alibaba is a traditional active-standby architecture. Each MySQL instance consists of two nodes.
This architecture has an important flaw. If a master-slave switchover occurs, it may lead to inconsistency of replica data. In order to solve the problem of the active and standby architecture, Ali initially adopted a lot of operation and maintenance methods to solve this problem, such as:
A set of system called ADHA, which is specially used to probe the MySQL service, switch between active and standby, etc.
Do some complex data verification before the master/slave switchover to ensure that the master/slave data is consistent before switching (so if it cannot be consistent, how to switch?)
In cross-city scenarios, the self-developed data synchronization service is used to replace the synchronization mechanism within MySQL
The rollback and replenishment of business data uses a set of complex data correction procedures (related to the business, and has certain requirements for the table structure of the business) ...
Although this architecture works, it is not elegant. The complexity and cost of use are very high, and it is difficult to keep up with the development of the business.
In 2016, Ali started the research and development of X-DB internally. X-DB is the first to overcome the problem of replica data consistency. The X-DB team chose the self-developed Paxos protocol to replace MySQL's built-in master-slave synchronization logic. There are many articles on the introduction of Paxos, so I won't repeat them here. Interested students can search by themselves.
Here is a brief list of the two core advantages of MySQL after using the Paxos protocol: 1. The master switch operation can be performed at any time without any data consistency problems, RPO=0 2. Leader election, active detection, etc. Completely done within the X-DB kernel (MySQL process), no need to rely on any external system
The solution of X-DB's Paxos protocol library combined with MySQL has been developed within Alibaba for several years, and it has completely replaced the existing traditional active and standby MySQL clusters with high reliability.
PolarDB-X and X-DB
It can be seen from the above that X-DB better solves problems such as disaster recovery and fault recovery, but the general applicability of service scenarios and the ability to scale horizontally are the strengths of PolarDB-X.
The data node (DN) of PolarDB-X 2.0 integrates the cluster disaster recovery technology of X-DB, which provides the ability of horizontal expansion.
In addition, from the perspective of the industry, using a protocol similar to Paxos to construct storage nodes is a common choice for many distributed databases. For example, TiKV uses the Raft protocol, and OceanBase uses the Paxos protocol.
For example: three copies of Raft in TiKV:
In fact, the relationship between X-DB and PolarDB-X goes far beyond the Paxos protocol. A lot of development work has been done in distributed transactions, scalability, push-down of computing power, HTAP, etc. Please pay attention to our follow-up article.
PolarDB-X and PolarDB
PolarDB (referred to here as PolarDB For MySQL) is a cloud-native database based on shared storage technology. PolarDB can achieve strong flexibility in storage space, but in general usage, its computing power and write capacity still have the upper limit of a single machine.
The share-nothing architecture of PolarDB-X 2.0 enables all resources including computing, writing, reading, storage, etc. to be horizontally scalable, so there is no single-machine bottleneck upper limit.
However, the share-nothing architecture is not as good as the shared storage architecture of PolarDB in terms of the elasticity of pure data capacity.
For example, no matter what kind of share-nothing database is used, such as PolarDB-X 2.0, TiDB, if there are currently 10 machines and 10T data, and now you want to expand the storage space by adding machines, it will always be half The data needs to be relocated to a new machine, and the time required for this relocation will be positively related to the amount of data (for example, under normal circumstances, it usually takes at least several hours to relocate a dozen terabytes of data).
For PolarDB, the above scenario can be expanded in minutes.
So, is it possible to combine the advantages of share-nothing with the advantages of shared-storage/share-everything?
The answer is yes.
At present, the next-generation distributed database will introduce the core technology of PolarDB based on the RDMA hardware + shared storage architecture in DN, so that all resources can be scaled horizontally while greatly reducing the cost of capacity elasticity.
The PolarDB-X local disk version and the shared storage version will have a long-term coexistence relationship in the future, and there will be no question of who completely replaces the other. Because the local disk version does not depend on any special hardware, it is mainly more friendly to the lightweight output of the proprietary cloud. The goal is to complete the delivery of PolarDB-X based on the user's 3 machines; the shared storage version has high flexibility in capacity, but this flexibility requires Only a public cloud of a certain scale will have a good performance (only a public cloud can have a large enough machine pool for business elasticity).
PolarDB-X will be an epoch-making product, everyone is welcome to continue to pay attention!
Knowledge Base Team
Knowledge Base Team
Knowledge Base Team
Knowledge Base Team
Explore More Special Offers
50,000 email package starts as low as USD 1.99, 120 short messages start at only USD 1.00