Heim  >  Artikel  >  Datenbank  >  Gedanken zu Ubers Wahl von MySQL

Gedanken zu Ubers Wahl von MySQL

黄舟
黄舟Original
2017-02-07 11:51:361318Durchsuche

Im Datenbankkreis weiß jeder, dass Uber dieses Jahr ein großes Ereignis durchgeführt hat und PostgreSQL auf MySQL umgestellt hat. Damals gab es einen Aufruhr in der Community. Es ist mehr als ein halbes Jahr her und ich möchte nicht noch einmal mit Ihnen diskutieren, welche dieser beiden relationalen Datenbanken besser ist. Ich möchte nur jeden dazu bringen, über die Gründe für die Wahl nachzudenken.

In diesem Fall ist ein wichtiger Grund, warum Uber die Migration vorgeschlagen hat: PostgreSQL hat in vielen aktualisierten Geschäftsszenarien zu viel E/A-Overhead (hauptsächlich durch die Speicherstruktur) Für die Verwendung von SSD oder PCI-E Kartengeräte können eine Schreibverstärkung grundsätzlich nicht tolerieren, und gleichzeitig werden die folgenden Anforderungen gestellt:

  • Es müssen Schreibpufferfunktionen vorhanden sein, falls die Persistenz in der Datenbank fehlschlägt, ist dies möglich Versuchen Sie es später noch einmal.

  • Benötigt eine Möglichkeit, nachgelagerte Abhängigkeiten zu benachrichtigen, und Datenänderungen müssen verlustfrei gemeldet werden.

  • erfordert einen sekundären Index.

  • Das System muss robust genug sein, um 7X24-Dienste zu unterstützen.

  • Das Wichtigste ist, dass SchemaLess-Speicherunterstützung erforderlich ist

  • Die Möglichkeit, die Kapazität durch das Hinzufügen von Servern dynamisch zu erweitern. Durch das Hinzufügen von Servern wird nicht nur die verfügbare Festplattenkapazität erhöht, sondern auch die Reaktionszeit des Systems verkürzt.

Als Reaktion auf diese Bedürfnisse versuchte Uber wie andere Internethersteller Cassandra, Riak und MongoDB und dachte auch über eine Selbstentwicklung nach, entschied sich aber letztendlich für MySQL als Speicherschicht. Hier ist eine Frage: Kann MySQL die oben genannten Anforderungen erfüllen? Zum Beispiel:

  • SchemaLess-Speicherunterstützung

  • Schreibpufferfähigkeit, schnelleres Failover

  • Bessere Skalierbarkeit

Jeder hat den Eindruck, dass Schemaless MySQL überhaupt übertreffen kann, aber aus dem Artikel geht hervor, dass der technische Leiter von Uber: Jakob Thomsen schließlich MySQL für Schemaless-Speicheroptionen verwendet hat. Oh mein Gott, Sie haben richtig gelesen, das ist richtig, es ist eine schemalose Speicherlösung, die mit MySQL erstellt wurde.

Schauen Sie sich aus Neugier noch einmal MySQL an. Sie werden feststellen, dass mit MySQL 5.7 zwei wichtige Funktionen eingeführt wurden, die genau den Anforderungen von Uber entsprechen:

  • DocumentStore

  • Man kann davon ausgehen, dass MySQL auch zu NoSQL geworden ist, den JSON-Typ unterstützt und mehr JSON-Unterstützung hinzugefügt hat. Probieren Sie es aus:

Unterstützt traditionelle SQL-Operationen wie CRUD. Um die NoSQL-Schnittstelle besser zu unterstützen, wurde auf dieser Basis ein weiteres Schwergewichtsprotokoll eingeführt: das X-Protokoll. Außerdem wird eine Reihe von MySQL- und Treiber-Programmen für verschiedene Programme gestartet. Wenn Sie es jetzt nicht verstehen, sind Sie möglicherweise bald draußen

X-Protokoll

Ein brandneues Protokoll, das den Interaktionsaufwand reduziert, die Nachrichtengröße reduziert, die Pipeline-Verarbeitung unterstützt und die Benachrichtigungsverarbeitung unterstützt

Benutzerfreundlichere Unterstützung für NoSQL, umfangreichere Datenverarbeitungsschnittstellen, unter Berücksichtigung von Daten-Sharding, um Gedanken zu Ubers Wahl von MySQL eine schnellere Antwort auf Abfragen zu erreichen

Die beiden oben genannten Funktionen sind auch die beiden Funktionen, auf die sich MySQL 8.0 konzentrieren wird. Das Wissen wird sehr schnell aktualisiert. Wenn Sie die Eigenschaften dieser beiden nicht kennen, sollten Sie sich die Zeit nehmen, Ihr Wissen zu aktualisieren. MySQL beginnt seine Leistungsfähigkeit unter Beweis zu stellen und wurde in letzter Zeit sehr schnell aktualisiert.

Es sind diese beiden Funktionen, die genau den Anforderungen von Uber entsprechen. Basierend auf der NoSQL-Schnittstellenspeicherung verwenden die zugrunde liegenden Daten garantiert die Replikationsreplikation von MySQL (die MySQL-Gruppenreplikation wird bald GA sein). Datenaufteilungs- und Routing-Einstellungen sind auf der NoSQL-Schnittstellenebene einfach zu erreichen, und die zugrunde liegende Replikation kann die Datenverfügbarkeit und -sicherheit besser gewährleisten.

MySQL ist nicht mehr die relationale Datenbank, die es früher war.


Die oben genannten sind meine Gedanken zu Ubers Wahl von MySQL Weitere verwandte Inhalte finden Sie auf der chinesischen PHP-Website (www.php.cn)!

Stellungnahme:
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn