Réflexions sur le choix de MySQL par Uber

Dans le cercle des bases de données, tout le monde sait qu'Uber a organisé un grand événement cette année en passant de PostgreSQL à MySQL. À cette époque, il y avait un tollé dans la communauté. Cela fait plus de six mois et je ne veux plus discuter avec vous de laquelle de ces deux bases de données relationnelles est la meilleure. Je veux juste faire réfléchir tout le monde aux raisons de ce choix.

Dans cet incident, une raison importante pour laquelle Uber a proposé la migration est la suivante : PostgreSQL a trop de surcharge d'E/S (principalement à cause de la structure de stockage) dans un grand nombre de scénarios commerciaux mis à jour pour l'utilisation de SSD ou de PCI-E. les appareils à cartes ne peuvent fondamentalement pas tolérer l'amplification en écriture, et en même temps les exigences suivantes sont mises en avant :

• Besoin d'avoir des capacités de mise en mémoire tampon d'écriture, en cas d'échec de la persistance dans la base de données, elle peut toujours be Réessayez plus tard.

• Nécessite un moyen de notifier les dépendances en aval, et les modifications de données doivent être notifiées sans perte.

• nécessite un index secondaire.

• Le système doit être suffisamment robuste pour prendre en charge les services 7X24.

• La chose la plus importante est que la prise en charge du stockage SchemaLess est requise.

• La possibilité d'étendre dynamiquement la capacité en ajoutant des serveurs. L'ajout de serveurs augmente non seulement la capacité du disque dur disponible, mais réduit également le temps de réponse du système.

En réponse à ces besoins, comme d'autres fabricants Internet, Uber a essayé Cassandra, Riak, MongoDB, et a également réfléchi à l'auto-développement, mais a finalement choisi MySQL comme couche de stockage. Voici une question : MySQL peut-il répondre aux besoins ci-dessus ? Par exemple :

• Prise en charge du stockage sans schéma

• Capacité de mise en mémoire tampon d'écriture, basculement plus rapide

• Meilleure évolutivité

Tout le monde a l'impression que Schemaless peut surpasser MySQL en premier lieu, mais d'après l'article, il semble que le responsable technique d'Uber : Jakob Thomsen a finalement utilisé MySQL pour les options de stockage Schemaless. Oh mon Dieu, vous avez bien lu, c'est vrai, c'est une solution de stockage sans schéma réalisée avec MySQL.

Poussé par la curiosité, jetez à nouveau un œil à MySQL. Vous constaterez que deux fonctionnalités lourdes ont été introduites à partir de MySQL 5.7, qui répondent exactement aux besoins d'Uber :

• DocumentStore.

• On peut considérer que MySQL a également commencé à devenir NoSQL, prend en charge le type json et a ajouté davantage de support json. Ressentez-le :

Prend en charge les opérations SQL traditionnelles telles que CRUD. Afin de mieux prendre en charge l'interface NoSQL, un autre protocole lourd a été lancé sur cette base : X-protocol. En plus de lancer un tas de mysqlsh et de pilotes pour divers programmes. Si vous ne le comprenez pas maintenant, vous serez peut-être bientôt disponible

X-Protocol

Un tout nouveau protocole qui réduit la surcharge d'interaction, réduit la taille des messages, prend en charge le traitement du pipeline et prend en charge le traitement des notifications

Prise en charge plus conviviale de NoSQL, interfaces de traitement de données plus riches, prenant en compte le partage des données pour obtenir réponse plus rapide aux requêtes

Les deux fonctions ci-dessus sont également les deux fonctions sur lesquelles MySQL 8.0 se concentrera. Les connaissances sont mises à jour très rapidement. Si vous ne connaissez pas les caractéristiques de ces deux-là, vous devriez prendre le temps de mettre à jour vos connaissances. MySQL commence à montrer sa puissance et a été mis à jour très rapidement récemment.

Ce sont ces deux fonctionnalités qui répondent exactement aux besoins d'Uber. Basées sur le stockage de l'interface NoSQL, les données sous-jacentes sont garanties d'utiliser la réplication de MySQL (la réplication de groupe MySQL sera bientôt GA). Les paramètres de fractionnement et de routage des données sont faciles à réaliser au niveau de la couche d'interface NoSQL, et la réplication sous-jacente peut mieux garantir la disponibilité et la sécurité des données.

MySQL n'est plus la base de données relationnelle qu'il était à l'origine. Il possède désormais plus de fonctionnalités que vous devez approfondir

Voici mes réflexions ci-dessus. Le choix d'Uber pour MySQL Pour plus de contenu connexe, veuillez faire attention au site Web PHP chinois (www.php.cn) !