Wu Lin, Huang Wei
Recently, Huawei self-developed cloud relational database Taurus public appearance. Huawei's self-developed the latest generation of cloud cloud native distributed database, Taurus is fully compatible with MySQL 8.0, the use of computing and storage separation of data architecture design of the log that is in support of a read write 15, a native MySQL performance reached seven times.
Over the years, the development of subversive technical in nature and does not appear on the database. As the core infrastructure, database user is a very high viscosity of the product, once the core business data settled, the company will not try to replace easily, so for a long period of time, the public accustomed to the old IT vendors monopoly status of the database market. However, the cloud database vendors involved in the field of news after another in recent years, such as AWS Aurora, Ali cloud and Huawei cloud PolarDB Taurus.
Under the Internet, mobile and networking and other new scenes, images, audio, video and other explosive growth of unstructured data began to appear, overwhelmed traditional database, enterprise customers urgently needed a new database product. Under the cloud computing technology continues to mature background, cloud database began to rise, and because-demand, pay-as other characteristics of SMEs and Internet customers get a lot of support.
Not difficult to see from the incoming cloud vendors are now doing database threshold is not so high as it was before, not only the traditional database vendors can do alone in this area entrepreneurs less. In this case, the core competitiveness can only be developed from differences, everybody is doing and will do what is difficult to form the core competitiveness. Accordingly, Huawei cloud Recently public appearance since the inquiry relational database Taurus What is the difference? What is the core competitiveness? Why seven times the performance enough to reach the native MySQL? Compared with the MySQL on the cloud, which is the inadequacy of what? Huawei cloud which patches?
Native cloud database technology trends
Traditional database architecture for more than 30 years of history, designed for local deployment, local storage and stand-alone database designed and optimized for instance, after a long period of time, the architecture is not optimized for public cloud environments. In the public cloud environments, isolated over a network computing and storage to support multi-tenant database instance and scale out extended to the two ends; single node does not require high reliability.
For example, if each database instance has a local database stored locally, in order to support high availability, and deploys an instance of the standby database log (MySQL binlog) sent to the database copies standby instance rebuild internal database replication mechanism. Currently, most cloud vendors have adopted a similar mechanism to support high availability cloud database. However, this mechanism does not use internal copy reliable cloud storage has been provided by the storage layer replication, which leads to a lot of storage and bandwidth waste. In fact, the standby database instances can share data through cloud storage and primary instance, not only can save disk space and bandwidth, can also cloud database service provides fast RTO.
Obviously, when the traditional database migration on the cloud, we need to re-design and optimization of database systems. Over the past few years, major cloud vendors, such as AWS and cloud Ali, has done part of the work. The next few years, more and cloud database vendors will follow this trend, to build some form of native cloud database technology. In addition, Gartner predicts that by 2019, 90% of the database schema to support cloud computing and storage separation.
It is noteworthy that, in addition to cloud-based database schema redesign outside this area there are two major trends:
-
Take advantage of new hardware in the cloud native database: as new hardware and RDMA. These are the active area of research, but in addition to acting as a link between the cache and the fast computers and storage outside, so far, we have not seen any other breakthrough.
-
Based on real-time and historical data collected, using ML (machine learning) and statistical techniques to help management and self-tuning cloud database, including but not limited to automatic retractable database instance and parameter settings and automatically adjust anomaly detection.
Clouds on the lack of MySQL
Currently, for RDS for MySQL, the major cloud vendors have adopted the basic high availability standby mode, use Binlog between the primary and replicate, each adding this architecture requires a full stack of resources from the library, which has led to some problems:
1, the waste of resources
Library equipment often do not bear the traffic; replication thread will consume the main library / computing resources from the library, resulting in waste of computing resources; 3 under EVS copy of redundancy, N largest number of library equipment need 3 * (N + 1) copy, resulting in storing waste of resources and a variety of data storage networks need to go brush plate, resulting in waste of network resources.
2, poor scalability
Read-only copy of the data when required to add, the binlog playback, slow speed for the case where large amounts of data, especially the use of local disk scheme. Master-slave replication latency issues make the switchover affected, it is difficult to ensure the RTO. In addition, the use of physical backup, the backup logic backup recovery speed is very slow, the amount of the above 1T data in hours, so that the database limited scalability.
Huawei cloud RDS Architecture Evolution
Huawei cloud Taurus Amazon Aurora direction and evolution of the database is the same, but have different evolutionary path, which is different from the decision implemented by the respective database cloud service. Huawei cloud RDS MySQL There are several versions of these products to meet different forms of user traffic scenarios, with different characteristics, we can complement each other.
Stand-alone version of MySQL
Stand-alone version uses MySQL database compute nodes and storage nodes isolated way, with the reliability and features multiple copies cloud disk data itself, but also the use of ECS cloud server virtualization to improve the standardization of deployment, version and operation and maintenance management efficiency to meet low-end users do not focus on the business scenario highly available services.
MySQL master and slave version
MySQL High Availability version is the version of the database for high availability enterprise users, providing 99.95% SLA guarantee. Replication between data using Active-Standby availability architecture, the master node and a backup node by MySQL Binlog. When the primary node fails, the standby node to take over the service. It also supports up to five nodes read-only, read and write data to support load balancing separate access.
Financial MySQL version
MySQL version is financial for the financial industry and other high-end users design a highly available, highly reliable cloud service offerings. Two Beisan a master node architecture, cross-AZ deployment, any server downtime without affecting service availability; Paxos based protocol, to achieve a strong consistency under distributed data, with more excellent recovery time, meet the data capacity disaster backup needs of business scenarios.
Taurus evolution
Taurus technology using computing and storage architecture decoupling, while read-only support up to 15 nodes. A read only between the master node and the node Failover Active-Active mode, the computing node resources are fully utilized, since a shared storage, further reducing the user cost.
Taurus design concept has several major innovations:
- The computing portion unloaded to the storage node
- Depth hardware and software optimization, make full use of RDMA network, NVME SSD hardware advantages
- I.e. log data, compared with the conventional RDS for MySQL, you need to brush longer Page, logging all the updates are no longer needed Double
Write, reduces network traffic.
Also in the DB Server design, fully embrace the open source ecosystem, is fully compatible with MySQL 8.0.
A common design philosophy Huawei cloud Taurus and Amazon Aurora is the first launch of a write once read many versions, according to market demand, the timely introduction of multi-write version, to meet the vast majority of OLTP application scenarios and performance requirements.
Taurus architecture design principles:
Huawei next cloud storage (DFV) as a fast, scalable, reliable, and the shared database storage. Do not copy an existing function of the storage layer, for example, data replication, cross AZ reliability, data cleaning.
- Single database cluster should only take a sufficiently reliable database replica set. All shared read-only copy stored in the cloud storage, even across
AZ, there is no logic to copy the database layer. Write Once Read Many, no separate standby instances. When the primary node failover, read-only copy may be switched to take over the primary server. - Records for the database. Sequentially written only to minimize wear SSD (avoid write amplification)
- DFV database log write memory layer only from the database via the network node computer. No page refresh and checkpoints across the network, no double written. DFV-based
database log surface reconstruction data in the storage layer, in order to avoid heavy network traffic. - The database partitioning strategy based slices across DFV storage nodes to support large database volumes. DFV single
storage node managing a plurality of slices from different clusters of database instances, unlimited expansion of storage capacity and processing power.
Taurus database key technical point analysis
Taurus Architecture
As shown, Taurus cluster architecture is a distributed, computing and storage using separate design, the elastic expansion of business to meet the user public cloud computing environment rigid requirements. Between compute nodes and databases using storage node high-speed networking, and data transmission through the RDMA protocol, so that the I / O performance is no longer the bottleneck.
And MySQL database node using a fully compatible design. Active-Active Failover uses a read-only manner between the master node and the node, providing high availability service DB. At the same time, only synchronization between DB Server Redo log related metadata information.
- SQL Nodes
- Manage client connections, parses SQL requests ,, analysis of the implementation plan and execute and manage transaction isolation level
- A main read more
- Main library and read-only loosely coupled
- Less read-only communications and the main library
- Fast Failover
- Some of the features introduced in the kernel
Query the Result Cache
Query Plan Cache
Online DDL
SQL Replication
Read-only nodes maintaining multiple versions of data pages in the local buffer pool
- Reducing the read data stored in the page from the distal end
Main library interaction
- MVCC: a list of the currently active transaction synchronization main library
- Page failures: the failure to receive a list of the main library page
RDMA protocol under the high-speed network
RoCE RDMA deployed to reduce network latency and increase bandwidth. In the single AZ, Taurus high-speed network may be utilized (RDMA) read to obtain and update the low-latency storage I / O, which is useful for low client connection scheme.
Storage abstraction layer (SAL)
Storage abstraction layer (SAL) is the logical layer, the SQL data storage and isolate the distal end, the transaction, the query execution. By a set of extended capacity and processing power needed fragments nodes, SAL SQL nodes will require all data pages managed by fragmentation and scale. With the growth in size of the database, the available resources (storage, memory) with the slice to create an increase in proportion. Localized data processing, data-intensive operations are performed by the service slice on the storage node.
Taurus Storage
Taurus cloud storage memory based Huawei DFV persistence. DFV persistence cluster includes a plurality of storage nodes. Each storage node contains multiple SSD storage devices and adapt to append service process SSD media. DFV layer provides persistent storage interface to SQL nodes.
Taurus handled using SQL journaled node data, i.e., typically the expression "i.e. log data." Append mode employed for data organization SSD redesigned significantly reduced write amplification system, to reduce the memory latency. Meanwhile, in the Append mode, the data is rolled back and retreated very fast.
Taurus core competencies
Lower cost
Compared with the traditional RDS for MySQL, only one store. When you add a read-only node, simply add compute nodes, without the need to purchase additional storage. The more read-only node, the more savings in storage costs.
Scalability, higher reliability
- Scale faster. Taurus using shared memory, simply add compute nodes, no matter how much data amount, about 5 minutes, read-only and supports 15.
- Scale up faster. Container deployment, specification change faster.
- From the main faster switching time. Eliminate replication latency, RTO is guaranteed.
- Database Crash faster recovery.
- Higher performance
Flex-based hardware: Hi1822 unloading, NVMe SSD, RDMA, while kernel optimization: remove the double write, Query Cache / Plan Cache optimization, Innodb Lock Management optimization, Audit Plugin to optimize efficiency, performance up to seven times the native MySQL.
Backup and recovery faster
Taurus engine tailored specifically for the distributed storage system, which greatly enhance data backup and restore performance
- Powerful snapshot of the data processing capabilities. AppendOnly vs. WriteInPlace, data points and more time and more natural by storing a copy, snapshot-second generation, support large snapshots.
- Quickly roll back to any point in time. Multi time characteristics of the underlying storage system without incremental log replay, the time can be directly implemented by the rollback point.
- Parallel high-speed backup and restore. Backup and restore logic to sink to the memory nodes, local access to data and interact directly with third-party storage systems, high-performance concurrent.
- Examples of fast recovery. Copying via the asynchronous data + time data on demand loading mechanism, Taurus instance may reach full functionality is available within a few minutes.
to sum up
Through the above description is not difficult to find, Taurus shared storage architecture will persist into next-generation data storage, fully guaranteed data consistency and intensity 0 loss; the use of hardware and software, take full advantage of RDMA network, NVME SSD hardware advantages, is these are the key technology integration and innovation, which makes the Taurus performance has been a qualitative leap.