Quelle: https://zhuanlan.zhihu.com/p/45652076
Autor: Wen positive Lake (arbeitete am NetEase Hangzhou Research Institute in der Datenbankkernentwicklung)
MyRocks ist eine MySQL-Datenbank, die für Speicherplatz und Schreibleistung optimiert ist und eine zuverlässige Wahl für die Auswahl Ihrer Geschäftsdatenbank bietet. In diesem Artikel wird hauptsächlich vorgestellt, was MyRocks ist, einschließlich seiner Funktionen, wobei der Schwerpunkt auf den Vorteilen von MyRocks im Vergleich zu InnoDB liegt und eine detaillierte Analyse verschiedener Szenarien, auf die MyRocks anwendbar ist.
RocksDB wird von FaceBook basierend auf Googles Open Source LevelDB implementiert und verwendet den LSM-Baum (Log-Structure Merge) zum Speichern von Daten. Facebook-Entwicklungsingenieure haben viel an RocksDB entwickelt, um die Anforderungen des Plug-in-Speicher-Engine-Frameworks von MySQL zu erfüllen. Es ist auf MySQL portiert und heißt MyRocks. MyRocks unterstützt die meisten MySQL-Funktionen wie SQL-basiertes Lesen und Schreiben von Daten, Sperrmechanismus, MVCC, Transaktionen und Master-Slave-Replikation. In Bezug auf die Nutzungsgewohnheiten gibt es keinen großen Unterschied zwischen der Verwendung von MyRocks oder MySQL / InnoDB.
Nach mehr als 4 Jahren Entwicklungszeit ist MyRocks ausgereift. Die Open-Source-MySQL-Zweigversionen Percona und MariaDB haben MyRocks in ihre eigenen MySQL-Zweige migriert. InnoSQL ist der MySQL-Zweig von NetEase und unterstützt derzeit MyRocks. Die spezifische Version ist InnoSQL 5.7.20 -v4, basierend auf dem Open-Source-MyRocks-Code, haben wir Funktionsoptimierungsverbesserungen, Bugfixes und Unterstützung für lokale und Remote-Online-physische Sicherungen vorgenommen. Lassen Sie uns kurz die Funktionen von MyRocks vorstellen, damit jeder ein grundlegendes Verständnis davon hat. Da MyRocks nur InnoDB durch RocksDB ersetzt, hat sich an der Logik der MySQL Server-Schicht nicht viel geändert, einschließlich des SQL-Parsing- und Ausführungsplans und des Binlog-basierten Multithread-Replikationsmechanismus. Der Fokus unserer Diskussion liegt hauptsächlich auf der Speicher-Engine-Schicht, die sich auf RocksDB befindet.
Dieser Artikel besteht hauptsächlich aus drei Teilen: Zunächst werden das allgemeine Framework, das Speicher-Backend und die funktionalen Eigenschaften durch den Lese- und Schreibprozess von RocksDB vorgestellt. Anschließend werden die Unterschiede zu InnoDB in mehreren Dimensionen und die Vorteile dieser Unterschiede analysiert. Schließlich werden die Unterschiede analysiert In welchen Geschäftsszenarien können diese Vorteile von RocksDB genutzt werden? Der Artikel ist länger, sodass Sie das Teil auswählen können, an dem Sie interessiert sind.
RocksDB Lese- und Schreibprozess
Schreibprozess
Die obige Abbildung zeigt ein schematisches Diagramm der Schreibanforderung von RocksDB. Die Änderung einer Transaktion wird vor der Übermittlung in den WriteBatch des Transaktionsthreads selbst geschrieben (im obigen Beispiel führt die Transaktion nur eine Put-Operation aus, sodass der WriteBatch nur diesen Put hat). Wenn es gesendet wird, wird es in die MemTable von RocksDB im Speicher geschrieben. MemTable ist im Wesentlichen eine SkipList, und die zwischengespeicherten Datensätze sind in Ordnung. Wie bei InnoDB werden auch die durch die Transaktion (WriteBatch) geänderten Daten vor der Übermittlung in das Write Ahead Log (WAL) geschrieben. Nach der Übermittlung der Transaktion müssen Sie nur sicherstellen, dass die WAL beibehalten wurde und die Daten in MemTable nicht auf die Daten auf der Festplatte geschrieben werden müssen. Datei. Wenn die Größe von MemTable den Schwellenwert erreicht (z. B. 32 MB), generiert RocksDB eine neue MemTable, und die ursprüngliche MemTable wird schreibgeschützt (unveränderlich) und erhält keine neuen Schreibvorgänge mehr. Unveränderliche MemTable werden vom Hintergrund-Flush-Thread in eine sst-Datei kopiert. Auf der Festplatte speichert RocksDB Daten über SST-Dateien, und jede Protokolldatei speichert WAL-Protokolle. Auf der Festplatte ist die sst-Datei überlagert, und jede Ebene verfügt über eine oder mehrere sst-Dateien. Die Dateigröße ist grundsätzlich festgelegt. Je größer die Ebene, desto mehr Dateien befinden sich in der Ebene. Dies bedeutet, dass die für die Ebene zulässige Gesamtgröße wie folgt größer ist Wie in der Abbildung gezeigt.
Im Allgemeinen werden die aus dem Speicher abgelegten Dateien in Level0 abgelegt, und die aufgezeichneten Intervalle jeder sst-Datei in der Level0-Ebene können sich überschneiden. Beispielsweise speichert sst1 1.4.6.9 und sst2 5.6.10.20. Da die LSM-Baumtechnologie zum Speichern von Daten verwendet wird, hat ein Datensatz mehrere Versionen. Beispielsweise haben sowohl sst1 als auch sst2 Datensatz 6, aber die Version in sst2 wird aktualisiert. In ähnlicher Weise existieren verschiedene Versionen desselben Datensatzes zwischen verschiedenen Ebenen. Im Gegensatz zu Level0 haben sst-Dateien von Level1 und höheren Ebenen nicht dieselben Datensätze unter den sst-Dateien derselben Ebene.
Verdichtungsmechanismus
Da es mehrere verschiedene Datensatzversionen gibt, muss es einen Mechanismus zum Zusammenführen von Versionen geben, und dieser Mechanismus ist Komprimierung.
Das obige Bild ist eine Level0-Komprimierung, bei der eine oder mehrere Level0-Dateien mit Level1-Dateien komprimiert werden. Unabhängig davon, ob die MemTable des Speichers in die sst-Datei oder die Komprimierung zwischen den sst-Dateien ausgegeben wird, wird sie aus E / A-Sicht sequentiell gelesen und geschrieben. Dies ist sowohl für SSD als auch für HDD von Vorteil. Die sequentielle Leistung von HDD ist viel höher als zufällig. Leistungsmerkmale für SSD können den durch zufälliges Schreiben verursachten Schreibverstärkungseffekt für Flash-Medien vermeiden.
Lesevorgang
Nachdem wir über den RocksDB-Schreibprozess gesprochen haben, schauen wir uns die Komponenten an, die mit dem Lesen zusammenhängen. Wie folgt:
Das Lesen in der Datenbank kann in aktuelles Lesen und Snapshot-Lesen unterteilt werden. Das sogenannte aktuelle Lesen dient zum Lesen der neuesten Versionsdaten des Datensatzes und das Snapshot-Lesen zum Lesen der Daten der angegebenen Version. Hier werden nur aktuelle Lesevorgänge behandelt, und Snapshot-Lesevorgänge können auf ähnliche Weise analysiert werden. Aufgrund der LSM-Baumspeicherstruktur unterscheidet sich die Leseoperation von RocksDB erheblich von InnoDB. Dies liegt daran, dass möglicherweise mehrere Versionen von LSM aufgezeichnet sind (und im Gegensatz zu InnoDB, dessen Zeiger mit der vorherigen und den nachfolgenden Versionen verbunden sind) und nicht übergeben werden können (strikte Bedeutung). Oben) binäre Suche. Daher wird Bloom Rock in RocksDB eingeführt, um den Lesepfad zu optimieren. In RocksDB kann Bloom Filter drei verschiedene Methoden auswählen: datenblockbasiert, partitionbasiert und sst-dateibasiert, Bloom Mit dem Filter kann festgelegt werden, dass sich der zu durchsuchende Schlüssel nicht in einem Block / einer Partition / einem sst befinden darf. RocksDB basiert standardmäßig auf einem Datenblock mit der geringsten Granularität.
Als nächstes werden wir den RocksDB-Lesevorgang anhand der beiden obigen Abbildungen kurz analysieren. Eine Get (key = bbb) -Anforderung wird zuerst in der aktuellen MemTable über Bloom Filter durchsucht. Wenn sie nicht getroffen wird, wird sie in die schreibgeschützte MemTable verschoben. Wenn sie nicht getroffen wird, bedeutet dies, dass sich die Schlüssel-Vaule entweder in der sst-Datei der Festplatte befindet oder nicht vorhanden ist. Daher ist es erforderlich, die Metadateninformationen jeder sst-Datei zu durchsuchen, um alle sst-Dateien zu finden, deren Schlüsselintervall den angeforderten Schlüsselwert enthält. Und je nach Untersuchungsniveau von klein nach groß. Durchsuchen Sie für jede sst-Datei den Bloom-Filter weiter, lesen Sie den Datenblock in der sst-Datei in BlockCache, durchlaufen Sie die Suche innerhalb des Blocks durch Dichotomie und geben Sie schließlich den entsprechenden Schlüssel oder NotFound zurück, wie in der folgenden Abbildung gezeigt.
RocksDB-Spaltenfamilie
In RocksDB ist die Spaltenfamilie ein logisch unabhängiger LSM-Baum. Jede Spaltenfamilie verfügt über eine eigene unabhängige MemTable, und alle Spaltenfamilien verwenden ein WAL-Protokoll. Die Komprimierung der sst-Datei erfolgt mit der Granularität der Spaltenfamilie.
Standardmäßig enthält eine MyRocks-Instanz zwei Spaltenfamilien, nämlich _system_ zum Speichern von Systemmetadaten und standardmäßig zum Speichern von Tabellendaten, die von allen Benutzern erstellt wurden. Wenn der Benutzer die Tabelle definiert, kann er natürlich den Namen der vom Index verwendeten Spaltenfamilie deklarieren, indem er nach dem Index einen Kommentar hinzufügt. Im folgenden Beispiel werden der Primärschlüssel und der eindeutige Index der rdbtable für die unabhängigen Spaltenfamilien cf_pk und cf_uid angegeben .
CREATE TABLE "rdbtable" (
"id" bigint(11) NOT NULL COMMENT '主键',
"userId" bigint(20) NOT NULL DEFAULT '0' COMMENT '用户ID',
PRIMARY KEY ("id") COMMENT 'cf_pk',
UNIQUE KEY "uid" ("userId") COMMENT 'cf_uid',
) ENGINE=ROCKSDB DEFAULT CHARSET=utf8
Hauptfunktionen von MyRocks
Parallelitätskontrolle
MyRocks implementiert die Transaktions-Parallelitätssteuerung basierend auf der Zeilensperrung, und die Sperrinformationen werden im Speicher gespeichert. MyRocks unterstützt gemeinsam genutzte und exklusive Zeilensperren. MyRocks verwendet die RocksDB-Bibliothek für die Sperrverwaltung, wenn Aktualisierungen in einer Transaktion durchgeführt werden. Sie können unique_check = 0 setzen, um Zeilensperren und eindeutige Schlüsselprüfungen abzuschirmen. Dies verbessert die Leistung beim Importieren von Daten in Stapeln. Sie sollten jedoch darauf achten, ob die Datenschlüssel bei ihrer Verwendung dupliziert werden. Daher ist die Eindeutigkeitsprüfung der allgemeinen Hochverfügbarkeitsinstanz von der Bibliothek auf deaktiviert Beschleunigen Sie die Wiedergabegeschwindigkeit von Binlog. Derzeit hat MyRocks keine Lückensperren implementiert, und es liegt ein Phantom-Leseproblem vor. Dies entspricht der Standard-RR-Isolationsstufe, ist jedoch schwächer als die RR von InnoDB.
Transaktionsisolationsstufe
MyRocks unterstützt derzeit zwei Transaktionsisolationsstufen: Read Commited (RC) und Repeatable Reads (RR). MyRocks verwendet Snapshots, um diese beiden Isolationsstufen zu erreichen. Bei wiederholbaren Lesevorgängen werden Snapshots in der gesamten Transaktion gespeichert, und Anweisungen in der Transaktion sehen konsistente Daten. In der isolierten Leseisolationsstufe wird der Snapshot von jeder Anweisung gespeichert, sodass die SQL-Anweisung die Änderung der Datenbank sehen kann, bevor die Anweisung ausgeführt wird. Wie bei den meisten Datenbankimplementierungen wird der Snapshot erhalten, wenn die Transaktion das erste SQL unter der RR-Isolationsstufe ausführt, anstatt wenn die Transaktion beginnt (Start / Start).
Wie InnoDB unterstützt MyRocks das MVCC-basierte Lesen von Snapshots, und das Lesen von Snapshots erfordert kein Sperren. MVCC wird über RocksDB-Snapshots implementiert, ähnlich der Leseansicht von InnoDB.
Sichern und Wiederherstellen
Wie InnoDB unterstützt MyRocks physische Online-Sicherung und logische Sicherung. Die logische Sicherung erfolgt über vorhandene MySQL-Sicherungstools wie mysqldump oder mydumper. Die physische Sicherung wird remote über das von MyRocks implementierte Tool myrocks_hotbackup durchgeführt, oder das von mariadb bereitgestellte Mariabackup-Tool wird für die lokale Sicherung verwendet.
Vergleichende Vorteile mit InnoDB
Diejenigen, die mit MySQL vertraut sind, wissen, dass InnoDB derzeit die dominierende Speicher-Engine unter MySQL ist. Es verfügt über die meisten Funktionen, die eine relationale Datenbankspeicher-Engine haben sollte, z. B. einen leistungsstarken und vollständigen Transaktionsmechanismus. Der MySQL-Mitarbeiter hat InnoDB zu einem integralen Bestandteil von MySQL gemacht. Die neu hinzugefügten MySQL-Systemtabellen verwenden InnoDB anstelle von MyISAM. . Warum nutzte Facebook InnoDB nicht und begann, MyRocks basierend auf RocksDB zu entwickeln. Offensichtlich muss RocksDB seine eigenen Vorteile haben. Im Folgenden werden mehrere Dimensionen verglichen und analysiert.
Kleinerer Stauraum
Werfen wir einen Blick auf die Probleme bei der Speicherplatznutzung von InnoDB. Wir wissen, dass InnoDB auf dem B + -Baum basiert, der den SMO-Betrieb von Baumknoten nicht vermeiden kann. Das Folgende ist ein schematisches Diagramm der Blattknotenteilung.
Nach dem Einfügen von user_id = 31 löst der Blattknoten Block1 die Knotenaufteilungsbedingung aus und wird von der Mitte aus in zwei Blöcke aufgeteilt. Jeder Block nimmt etwa die Hälfte des ursprünglichen Block1-Raums ein. Offensichtlich beträgt die Füllrate jedes Blocks weniger als 50%, was bedeutet Zu diesem Zeitpunkt gibt es die Hälfte der internen Fragmente.
Bei nacheinander eingefügten Szenen ist die Füllrate der Blöcke höher. Bei zufälligen Szenen sinkt die Raumnutzungsrate jedes Blocks jedoch stark. Insgesamt ist der von einer Tabelle belegte Speicherplatz viel größer als der für die tatsächlichen Daten erforderliche Speicherplatz.
RocksDB, das auf dem LSM-Baum basiert, hat dieses Problem jedoch nicht. Jedes Mal, wenn Daten eingefügt, aktualisiert und gelöscht werden, werden sie an eine neue sst-Datei angehängt. Sie muss nur innerhalb der Datei in Ordnung sein und muss nicht durch Suchen gefunden werden. Fügen Sie eine bestimmte Migrationsposition der globalen Reihenfolge des B + -Baums ein oder aktualisieren Sie sie, wodurch das Problem der Füllrate des B + -Baumknotens gelöst und die Speicherplatznutzungsrate verbessert wird.
Darüber hinaus ist die sst-Datei von RocksDB hierarchisch und das Gesamtgrößenverhältnis der oberen und unteren Ebene beträgt bis zu 10. Bei großem Datenvolumen beträgt das schlechteste nur etwa 10% der Speicherplatzvergrößerung, was im Vergleich zu InnoDB eine große Verbesserung darstellt.
Darüber hinaus verwendet RocksDB, wie in der obigen Abbildung gezeigt, beim Speichern die Präfixcodierung für Datensatzspalten. Ein ähnlicher Ansatz wird für jede Zeile von Metadaten gewählt. Dies reduziert den erforderlichen Speicherplatz weiter.
Effizientere Komprimierungsmethode
Im vorherigen Artikel haben wir den auf Datensätzen basierenden Komprimierungsmechanismus von InnoDB vorgestellt. Die ungefähre Implementierung besteht darin, einige Felder jedes Datensatzes auf einer 16-KB-Seite (Seite) zu komprimieren und dann alle komprimierten Datensätze gemäß der angegebenen Seitengröße zu speichern. . Wenn beispielsweise key_block_size auf 8 festgelegt ist, dh nach der Komprimierung als 8 KB gespeichert wird. Wenn die Seitengröße nach der Komprimierung 5 KB beträgt, werden 3 KB Speicherplatz verschwendet. InnoDB hat in MySQL 5.7 eine transparente Seitenkomprimierung eingeführt, die oben genannten Probleme bestehen jedoch weiterhin.
RocksDB ist während der Datensatzkomprimierung nicht seitenbasiert und muss nicht gemäß key_block_size ausgerichtet werden. Es muss nur nach der Blockgröße des Dateisystems (normalerweise 4 KB) ausgerichtet werden, nachdem jede sst-Datei komprimiert wurde, und der Ausrichtungsaufwand jeder sst-Datei von mehreren MB überschreitet nicht 4 KB, weit weniger als der Ausrichtungsaufwand der InnoDB-Komprimierung.
Umfassender Vergleich: MyRocks kann im Vergleich zu InnoDB mehr als die Hälfte des Speicherplatzes einsparen.
Recyclingoptimierung für alte Versionen
In Szenarien, in denen Datensätze häufig aktualisiert werden, führt InnoDB bei einem langfristig konsistenten Snapshot-Lesen dazu, dass der Rückgängig-Speicherplatz stark zunimmt, da die alte Version des Datensatzes nicht gelöscht werden kann. Aber RocksDB kann das Problem effektiv lindern. Das Folgende ist ein Beispiel zur Veranschaulichung.
Angenommen, eine konsistente logische Sicherung wird unter MySQL durchgeführt und die Transaktion wird gestartet, aber der Datensatz, dessen Primärschlüssel 1 und der Wert 0 ist, wird 1 Million Inkrementoperationen ausgeführt, bevor die Auswahloperation für die Tabelle t ausgeführt wird. Nach dem Prinzip muss diese Sicherung den Originaldatensatz mit dem Wert 0 lesen.
Für InnoDB werden die 1 Million alten Versionsdatensätze (dh Rückgängig) nicht gelöscht, da die Sicherungs-Transaktions-ID kleiner als die um 1 Million Mal inkrementierte Transaktions-ID ist. Dies bedeutet, dass beim Sichern des Datensatzes 100 Das Backtracking der Version 10.000 wird jedes Mal, wenn die Rückgängig-Seite zufällig gelesen wird, basierend auf dem Rückgängig-Zeiger im Datensatz, was sehr ineffizient ist.
RocksDB ist für die alte Version des InnoDB-Problems zum Löschen von Datensätzen optimiert. Unter der Annahme, dass die Sequenznummer des ursprünglichen Datensatzes 2 ist, ist diese Version die sichtbare Version der Sicherungstransaktion. Speichern Sie MemTable für die größere Version als sst-Datei in RocksDB oder Beim Komprimieren der sst-Datei wird die Zwischenversion gelöscht und nur die sichtbare Version der aktuell aktiven Transaktion und die neueste Version des Datensatzes bleiben erhalten. Dies erfüllt nicht nur die MVCC-Anforderungen, sondern verbessert auch die Effizienz des Snapshot-Lesens und reduziert gleichzeitig den erforderlichen Speicherplatz.
Kleinere Schreibvergrößerung
In InnoDB muss ein Datensatzaktualisierungsvorgang die aktuelle Datensatzversion in das Rückgängig-Protokoll für Transaktions-Rollback und MVCC schreiben (Sie müssen auch das Rückgängig-Wiederherstellen schreiben, bevor Sie die Rückgängig-Seite schreiben) und anschließend ein nach dem Update aufgezeichnetes Wiederherstellen schreiben Es wird für die Wiederherstellung nach einem Absturz verwendet. Anschließend kann der Aktualisierungsvorgang auf die entsprechende Datenseite geschrieben werden (kann die Aufteilung des B + -Baumknotens auslösen). Um den durch den Absturz beim Flashen verursachten Schaden auf der Datenseite zu vermeiden, muss eine weitere Kopie in Doublewrite geschrieben werden Festplatten-Cache.
Es ist ersichtlich, dass viele Dinge in einem Update geschrieben werden müssen, insbesondere wenn es sich um ein zufälliges Update-Szenario handelt. Beim Schreiben von Datenseiten und Doublewrite ist das Verhältnis der Schreibverstärkung die Seitengröße / Datensatzgröße, was sehr erstaunlich ist.
Die RocksDB-Schreibverstärkung bezieht sich auf den Gesamtpegel der sst-Datei. Die schlechteste Schreibverstärkung liegt bei (n-2) * 10, wobei n die Gesamtzahl der Schichten ist. Offensichtlich wird es viel besser sein als InnoDB.
Die Reduzierung der Schreibverstärkung bedeutet, dass die eingeschränkten Speicher- und Schreibfunktionen effizienter genutzt werden können. Man kann sagen, dass RocksDB mehr Datensätze schreiben kann, wenn der Leistungsengpass bei Speicher-E / A erreicht ist.
Andererseits werden RocksDB-Daten jedes Mal, wenn sie eingefügt, aktualisiert und gelöscht werden, zusätzlich geschrieben und nicht an Ort und Stelle aktualisiert. Auf diese Weise wird das Speicher-Backend alle nacheinander und nicht zufällig geschrieben. Bei einer auf NAND-Flash basierenden SSD kann dieselbe SSD unter RocksDB länger verwendet werden als unter InnoDB, ohne die Optimierung der Schreibverstärkung innerhalb der SSD zu berücksichtigen.
Schnellere Schreibleistung
Wie bereits erwähnt, aktualisiert InnoDB Datensätze an Ort und Stelle, was bedeutet, dass in zufälligen DML-Szenarien jede Datensatzoperation zufällig geschrieben wird (selbst wenn der Sekundärindex gelöscht und dann in den neuen Datensatz geschrieben wird, ist er auch zufällig ),Wie nachfolgend dargestellt.
Im Gegensatz zu RocksDB wird das zufällige Schreiben in sequentielles Schreiben konvertiert, und die Multithread-Komprimierung, die die Zusammenführung der alten und neuen Version im Hintergrund aufzeichnet, ist auch ein Stapel-sequentielles Schreiben. In Batch-Einfügeszenarien kann RocksDB auch die Überprüfung der Eindeutigkeit von Datensätzen deaktivieren, um die Datenimportgeschwindigkeit weiter zu beschleunigen.
Auf einer Festplatte kann eine solche Optimierung die sequentielle Lese- und Schreibleistung mechanischer Festplatten nutzen, die dem zufälligen Lesen und Schreiben weit überlegen sind. Selbst auf SSDs ist eine solche Optimierung für die Datenbankleistung hilfreich.
Kleinere Master-Slave-Verzögerung
Im Vergleich zu InnoDB bietet RocksDB auch mehr DML-Optimierungsoptionen aus der Bibliothek.
Da die Transaktionen, die parallel in der Slave-Datenbank wiedergegeben werden können, definitiv konfliktfrei sind, dh keine Sperre-Wartebeziehung zwischen Transaktionen besteht, hat RocksDB einen Optimierungsparameter rpl_skip_tx_api eingeführt, um die Sperre für den Datensatz anzupassen und die Transaktionsisolation sicherzustellen Der Vorgang beschleunigt die Transaktionswiedergabegeschwindigkeit.
In ähnlicher Weise können Sie für die Transaktionsmerkmale aus der Datenbank die Überprüfung der eindeutigen Schlüsselbeschränkung des Datensatzeinfügevorgangs überspringen, und für die Aktualisierungs- und Löschvorgänge können Sie den Datensatzsuchvorgang überspringen, da der Operationsdatensatz erfüllt sein muss, solange kein Implementierungsfehler vorliegt Transaktion gebunden.
Andere Funktionen, die InnoDB nicht hat
MyRocks hat in MySQL 5.6 / 5.7 einen Index in umgekehrter Reihenfolge implementiert, der auf der Implementierung der Spaltenfamilie in umgekehrter Reihenfolge basiert. Offensichtlich können Indizes in umgekehrter Reihenfolge nicht die Standard-Standardspaltenfamilie verwenden. Basierend auf der LSM-Funktion implementiert MyRocks auch den TTL-Index zu sehr geringen Kosten, ähnlich wie HBase. Verglichen mit der TTL-Implementierung von MongoDB-Durchlaufdatensätzen zum Löschen von Stapeln erfordert die TTL-Funktion unter LSM-Speicher keinen zusätzlichen Verlust an Wartungsleistung, außer dass der Zeitstempel gespeichert werden muss, und kann direkt während der Komprimierung zusammengeführt und verarbeitet werden.
MyRocks anwendbare Szenarien
Basierend auf der obigen Beschreibung können die für MyRocks geltenden Geschäftsszenarien zusammengefasst werden, einschließlich:
Big Data-Geschäft
Im Vergleich zu InnoDB belegt RocksDB weniger Speicherplatz und weist eine höhere Komprimierungseffizienz auf, was für Unternehmen mit großem Datenvolumen sehr gut geeignet ist. Das Bild unten zeigt den von Facebook veröffentlichten Raumbelegungsvergleich von RocksDB und InnoDB.
Das Bild unten zeigt die komprimierten Daten von RocksDB, InnoDB und TokuDB im Internet
In Kombination mit der obigen Abbildung kann festgestellt werden, dass der von RocksDB benötigte Speicherplatz viel kleiner als InnoDB und sogar besser als TokuDB ist, das für sein hohes Komprimierungsverhältnis bekannt ist.
In den internen Geschäftstests von NetEase wurde auch bestätigt, dass die DDB-Instanz eines beliebten Unternehmens aufgrund des schnellen Wachstums des Datenvolumens häufige Tabellenerweiterungsvorgänge ausführen musste. Die Verwendung von MyRocks als Ersatz für InnoDB ergab, dass die 165 GB InnoDB-Einzeltabelle mit aktivierter Komprimierung (key_block_size = 8) unter MyRocks-Komprimierung nur 51 GB groß ist . Diese DDB-Instanz verfügt über insgesamt 8 hochverfügbare MySQL-Instanzen, und jede DBN enthält 10 InnoDB-Tabellen. Statistik Nach dem Ersetzen von MyRocks sank der für die Instanz erforderliche Speicherplatz von 26 TB auf weniger als 9 TB. Dies spart zwei Drittel (ca. 17 TB) Speicheraufwand und verlängert auch den Zeitraum, in dem DBA nach Tabellen erweitert werden muss. Angenommen, DBA muss vierteljährlich erweitert werden, muss es jetzt nur noch alle drei Quartale erweitert werden Das ist es.
Schreibintensives Geschäft
MyRocks verwendet eine zusätzliche Methode zum Aufzeichnen von DML-Vorgängen, bei der zufällige Schreibvorgänge in sequentielle Schreibvorgänge umgewandelt werden. Dies ist sehr gut für Geschäftsszenarien geeignet, in denen Stapeleinfügungen und häufige Aktualisierungen vorhanden sind. Die folgende Abbildung zeigt die Leistungsvergleichstabelle im von Alibaba Cloud veröffentlichten Batch-Insert-Szenario. Im Vergleich zu InnSDB-basiertem AliSQL hat MyRocks fast die doppelte Leistungsverbesserung erzielt.
In einem bestimmten aktualisierungsintensiven Geschäftsszenario innerhalb von NetEase wurde auch eine bessere Leistung erzielt. Zusätzlich zu der Schreibleistung, die nicht schwächer als das KV-Speichersystem ist, bietet es auch einen gewissen Vorteil bei der Leseleistung. Der Vergleich ist wie folgt:
Das obige Bild ist das Ergebnis eines 10-minütigen Tests unter den gemischten Lese- und Schreibbedingungen 1: 1 und 2: 1 mit Lesezugriff. Es zeigt sich, dass MyRocks sowohl hinsichtlich Leistung als auch Latenz eine gute Leistung aufweist.
Die obige Abbildung zeigt die Schreibleistung und Latenz in einem gemischten 1: 1-Lese- / Schreib- und Nur-Schreib-Szenario. Es zeigt sich, dass MyRocks auch bei 20 Schreibvorgängen eine gute Leistung erbringt.
Cache-Persistenzschema
Da MyRocks im Vergleich zu InnoDB eine effiziente Speicherplatznutzung aufweist, kann dieselbe Speichergröße mehr Daten zwischenspeichern. Im Vergleich zu Redis-Alternativen wie Pika verfügt MyRocks über einen ausgereiften Fehlerbehebungsmechanismus und eine Master-Slave-Replikationsarchitektur Die Replikationsverzögerung erleichtert die Erweiterung der Lesekapazität. Daher ist MyRocks auch eine geeignetere Redis-Cache-Alternative.
TokuDB ersetzen
Im Vergleich zu TokuDB weist RocksDB / LevelDB keine schlechtere Schreibleistung und Komprimierungsrate sowie eine bessere Leseleistung auf. Als Speicher-Engine wird es von gängigen Datenbanksystemen wie MySQL, MongoDB, Kudu und TiDB verwendet und verfügt über eine bessere Open Source-Community. Unterstützung, schnellere Problemlokalisierung und BugFix-Möglichkeit, besser lesbarer Quellcode. Wenn TokuDB immer weniger vielversprechend wird, kann MyRocks verwendet werden, um die aktuelle Online-TokuDB-Instanz zu ersetzen.
Niedrige Kosten und Slave-Bibliothek mit geringer Latenz
Die bessere Schreibleistung von MyRocks in Verbindung mit der Optimierung bestimmter Parameter aus der Bibliothek kann eine geringere Replikationslatenz als InnoDB erzielen. In Verbindung mit dem Vorteil eines kleineren Speicherplatzes eignet es sich zum Erstellen spezieller Slave-Bibliotheken, z. B. verzögerter Slave-Bibliotheken, um ein versehentliches Löschen von Online-Daten zu verhindern, und Slave-Bibliotheken für Big-Data-Statistiken und -Analysen.
um zusammenzufassen
Im Vergleich zu InnoDB belegt MyRocks im Allgemeinen weniger Speicherplatz, wodurch die Speicherkosten gesenkt und die Effizienz des Hotspot-Cachings verbessert werden können. Das Schreibverstärkungsverhältnis ist geringer, wodurch die Speicher-E / A-Bandbreite effizienter genutzt werden kann. Zufällige Schreibvorgänge werden in sequentielle Schreibvorgänge umgewandelt , Verbessern Sie die Schreibleistung und verlängern Sie die Lebensdauer der SSD. Optimieren Sie die Parameter, um die Verzögerung der Master-Slave-Replikation zu verringern. Daher eignet es sich sehr gut für Geschäftsszenarien wie großes Datenvolumen und schreibintensiv. Darüber hinaus verfügt MyRocks als dieselbe MySQL-Schreib- und Speicheroptimierungslösung über eine bessere Community-Ökologie und eignet sich zum Ersetzen von TokuDB-Instanzen. Die effiziente Cache-Nutzung, die ausgereifte Fehlerbehebung und der Master-Slave-Replikationsmechanismus von MyRocks machen es auch als Redis-Persistenzlösung verfügbar.
Referenzmaterialien:
1. Analyse der RocksDB-Implementierung http://ks.netease.com/blog?id=10818
2 、 RocksDB-Wiki https://github.com/facebook/rocksdb/wiki
3. RocksDB-bezogene Dokumente und PPT, veröffentlicht von Facebook, Percona und Alibaba
Der vollständige Text ist vorbei.
Viel Spaß mit Linux & MySQL :)
Der Kurs "MySQL Core Optimization" wurde auf MySQL 8.0 aktualisiert. Scannen Sie den Code, um die Reise des MySQL-Trainings zu beginnen