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:
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 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.