Thoughts on Uber's choice of MySQL

In the database circle, everyone knows that Uber did a big event this year, switching PostgreSQL to MySQL. At that time, there was an uproar in the community. It's been more than half a year, and I don't want to discuss with you again which of these two relational databases is better. I just want to make everyone think about the reasons behind the choice.

In this incident, an important reason why Uber proposed migration is: PostgreSQL has too much IO overhead (mainly from the storage structure) in a large number of updated business scenarios. For the use of SSD Or the PCI-E card device basically cannot tolerate write amplification, and at the same time the following requirements are put forward:

• Need to have write buffering capability, in case the persistence to the database fails, it can still be Try again later.

• Needs a way to notify downstream dependencies, and data changes must be notified losslessly.

• Requires secondary index.

• The system must be robust enough to support 7X24 services.

• The most important point is that SchemaLess storage support is required

• It must be able to dynamically expand capacity by adding servers. Adding servers not only increases available hard disk capacity, but also reduces system response time.

In response to these needs, Uber, like other Internet manufacturers, tried Cassandra, Riak, MongoDB, and also thought about self-development, but ultimately chose MySQL as the storage layer. Here is a question: Can MySQL meet the above needs? For example:

• SchemaLess storage supports

• Write buffering capability, faster failover

• Better scalability

Everyone has the impression that Schemaless can outperform MySQL in the first place, but from the article it seems that Uber’s technical leader: Jakob Thomsen finally used MySQL for Schemaless. Storage options. Oh my god, you read that right, that’s right, it’s a schemaless storage solution made with MySQL.

Driven by curiosity, take a look at MySQL again. You will find that two heavyweight features have been introduced from MySQL 5.7, which exactly meet Uber’s needs:

• DocumentStore

• It can be considered that MySQL has also started to become NoSQL, supports json type, and added more json support. Feel it out:

# Supports traditional SQL operations such as CRUD. In order to better support the NoSQL interface, another heavyweight protocol was launched based on this: X-protocol. As well as launching a bunch of mysqlsh and drivers for various programs. If you don’t understand it now, you may be out soon

X-Protocol

A brand new protocol that reduces interaction overhead, reduces message size, supports pipeline processing, and supports notification processing

More friendly support for NoSQL, richer data processing interfaces, taking into account data Sharding implementation Faster Query response

The above two functions are also the two functions that MySQL 8.0 will focus on. The knowledge is updated very quickly. If you don’t know the characteristics of these two, you should take the time to update your knowledge. MySQL is starting to show its power, and it has been updated very quickly recently.

It is these two features that exactly meet Uber's needs. Based on NoSQL interface storage, the underlying data is guaranteed to use MySQL's Replication replication (MySQL Group Replication will soon be GA). Data splitting and routing settings are easy to achieve at the NoSQL interface layer, and the underlying replication can better ensure data availability and security.

MySQL is no longer the relational database it was originally. Now it has more features that require you to dig deeper

The above are my thoughts on Uber’s choice of MySQL For more related content, please pay attention to the PHP Chinese website (m.sbmmt.com)!