In dieser dreiteiligen Reihe werden wir technische Errungenschaften offenbaren, die die Datenverarbeitung von Anwendungen, die über das Internet Computer Protocol (ICP) laufen, erheblich verbessern können.
Dieses Upgrade ist ein Meilenstein im Stellarator-Fahrplan des ICP und wird derzeit im gesamten Netzwerk ausgerollt. Stellarator ist ein Durchbruch im Bereich der On-Chain-Datenspeicherung, der es jedem Subnetz ermöglicht, mehr als 1 TB an Speicher zu tragen und damit Chancen für datendichte Anwendungen zu schaffen, die zuvor durch Speicherbeschränkungen limitiert waren.
Dieser Fortschritt ermöglicht es Entwicklern, komplexe Anwendungen zu erstellen, die große Datenverarbeitung erfordern, und bringt ein neues praktisches Niveau in die Blockchain-Technologie.
Lassen Sie uns ohne weitere Verzögerung mit dieser Reihe beginnen und sehen, wie ICP jetzt mit den Stellarator-Updates Daten speichert.
Datenpersistenz auf dem Internet Computer
In diesem Blogbeitrag wird beschrieben, wie die Replikmaschinen des Internet Computers funktionieren, wobei der Schwerpunkt auf den kürzlich eingeführten Änderungen der auf log-strukturierten Merge-Bäumen (LSMT) basierenden Speicherung liegt, die eine bessere Handhabung von replizierter Speicherung im Internet Computer-Subnetz ermöglichen und sie besser in der Lage machen, anspruchsvolle Arbeitslasten zu bewältigen.
Der Internet Computer besteht aus Subnetzen und virtuellen Maschinen, die auf 13-40 Replikmaschinen die gleiche Replikation durchführen. Jede Replik ist dafür verantwortlich, alle Nachrichten, die an die Container in diesem Subnetz gesendet werden, auszuführen und alle Containerdaten zu speichern, sodass alle Replikate den vollständigen und identischen Zustand des Subnetzes haben.
Entwickler können Container auf dem Internet Computer bereitstellen. Container sind ähnlich wie Smart Contracts auf anderen Blockchains, können jedoch allgemeinere Berechnungen durchführen und speichern Daten in Größenordnungen mehr als die Smart Contracts auf anderen Ketten.
Die in Containern gespeicherten Daten müssen schließlich auf bestimmter physischer Hardware gespeichert werden. Dank der kürzlich eingeführten LSMT-basierten Speicherebene und vieler anderer Optimierungen und Verbesserungen kann der Subnetz des Internet Computers bis zu 1 TB an Containerdaten speichern.
Die meisten Daten eines Containers werden entweder in seinem Heap-Speicher (bis zu 4 GB beim Schreiben) oder in seinem stabilen Speicher (bis zu 500 GB beim Schreiben) gespeichert. Es gibt auch andere Formen von Daten, die mit Containern verbunden sind, wie Containercodes, Nachrichten in der Luft und verschiedene Informationen, wie Controller-Listen und Cycles-Salden.
Die Speicherebene von ICP überbrückt die Kluft zwischen der Container-Speicherung (z. B. Heap- und stabiler Speicher) und der zugrunde liegenden Speicherhardware der Replikmaschinen (z. B. Festplatte und RAM).
Im Rahmen des Stellarator-Meilensteins wurde die Speicherebene umfassend neu gestaltet und neu implementiert, um dem ICP zu ermöglichen, zukünftige Skalierbarkeitsherausforderungen zu bewältigen und die wichtigsten Skalierbarkeitsengpässe der alten Speicherebene zu beheben. Alle relevanten Änderungen wurden kürzlich abgeschlossen, und der Internet Computer läuft nun seit mehreren Monaten mit der neuen Implementierung der Speicherebene.
Der Rest dieses Blogbeitrags beschreibt den Prozess der Neugestaltung der Speicherebene als logische Struktur von Merge-Bäumen, die darauf abzielt, speicherbezogene Engpässe zu beseitigen und Benutzern und Entwicklern von speicherintensiven Containern ein besseres Erlebnis zu bieten.
Für ICP-Nutzer ist insbesondere bemerkenswert, dass diese Arbeit dazu geführt hat, dass der replizierte Zustand innerhalb eines einzelnen Subnetzes kürzlich auf 1 TB erhöht wurde. Darüber hinaus ermöglicht das Redesign dem Internet Computer, besser mit Containern umzugehen, die große Datenmengen schreiben.
Checkpoint
Im Allgemeinen kombiniert die Speicherebene des Internet Computers die Verwendung von persistentem Speicher auf der Festplatte und temporärem Speicher im RAM. Ein Schlüsselkonzept, wie der Internet Computer seinen Zustand speichert, ist der sogenannte Checkpoint, der einen logischen Zeitpunkt darstellt, zu dem der gesamte Zustand des Subnetzes auf der Festplatte gespeichert wird.
Checkpoints werden deterministisch alle 500 Blöcke oder alle paar Minuten erstellt, was bedeutet, dass alle Replikate auf der gleichen Höhe denselben Checkpoint schreiben. Checkpoints werden als Dateiverzeichnis auf der Festplatte jedes Replikknotens gespeichert, die Verzeichnisstruktur sieht wie folgt aus (stark vereinfacht):
In dieser Struktur wird jeder Container in einem eigenen Unterverzeichnis gespeichert, und jedes Containerverzeichnis enthält separate Dateien für Heap-Speicher, stabilen Speicher und andere Informationen (wie Nachrichten in der Luft). Es gibt verschiedene Gründe, warum Daten in Form von Checkpoints auf die Festplatte gespeichert werden.
1. Datenpersistenz: Replikmaschinen können jederzeit neu gestartet werden, im Replikcode können Softwarefehler auftreten oder Hardware kann ausfallen oder es kann ein Problem mit der Stromversorgung im Datenzentrum auftreten. In solchen Fällen kann der neueste Checkpoint neu geladen werden.
Bitte beachten Sie, dass selbst wenn Checkpoints nur alle 500 Runden erstellt werden, Repliken auch für Nicht-Checkpoint-Höhen den Zustand neu erstellen können. Repliken benötigen nur den neuesten Checkpoint sowie alle endgültigen Blöcke zwischen dem Checkpoint und dem neuesten Zustand. Da alle Ausführungen deterministisch sind, können diese Blöcke wiederholt werden, und es wird garantiert, dass der neu erstellte Zustand identisch ist. Die erforderlichen Blöcke können vom Checkpoint getrennt auf der Festplatte gespeichert oder von anderen Repliken abgerufen werden.
2. Synchronisierung: Alle (replizierten) Nachrichten werden von allen Repliken ausgeführt, sodass alle Repliken für jeden bestimmten Höhe h denselben Zustand haben sollten. Das Protokoll verhindert Abweichungen, indem es zunächst den Zustand hash und dann die erzeugte Hash durch Schwellenwertsignatur überprüft (d.h. wenn einige ehrliche Repliken schließlich in einem anderen Zustand als dem Konsenszustand sind). Ein solcher Schwellenwertsignatur kann nur erstellt werden, wenn mindestens ⅔ (genauer gesagt 2f + 1) Repliken dem gleichen Hash zustimmen, damit das Subnetz weiterarbeiten kann.
Die Subnetze des Internet Computers können jedoch über einen großen Zustand verfügen, der zum Zeitpunkt des Schreibens auf 1 TB begrenzt ist, während sie gleichzeitig bis zu 2,5 Blöcke pro Sekunde aufrechterhalten (was das schnellste Subnetz des Internet Computers derzeit erreicht), ist es nicht praktikabel, so viele Daten nach jedem Block zu hashen. Daher hashed der Internet Computer nur einen ausgewählten Teil des Zustands für Nicht-Checkpoint-Höhen, z. B. einige grundlegende Informationen zu jedem Container, die letzten Antworten auf Eingangsnachrichten und XNet-Nachrichten, die an andere Subnetze gesendet wurden.
Für Checkpoints hash das Protokoll den gesamten Zustand, um eine als Liste bezeichnete Datenstruktur zu erhalten. Diese Liste wird berechnet, indem die Hashes aller Dateien im Checkpoint-Verzeichnis gehasht werden und alle einzelnen Dateien in 1 MB großen Blöcken aufgeteilt werden. Am Ende der Berechnung wird der Root-Hash der Liste berechnet, der alle einzelnen Hashes in der Liste abdeckt, und dann wird die Liste von dem Subnetz mit einer Schwellenwertsignatur versehen. Die Berechnung kann einige zehn Sekunden in Anspruch nehmen, aber diese Arbeit wird nur alle 500 Blöcke einmal durchgeführt und läuft im Hintergrund parallel zur Ausführung des Containers.
3. Zustandssynchronisierung: Der Internet Computer ermöglicht es, die Subnetz-Topologie durch NNS-Vorschläge zu ändern. Wenn Replikknoten einem Subnetz beitreten, können sie den neuesten Checkpoint von anderen Replikknoten abrufen. Denken Sie daran, dass ein Checkpoint eine Sammlung von Dateien ist. Daher kann das Zustandssynchronisierungsprotokoll Block für Block Dateien abrufen, nachdem die Root-Hash und die Schwellenwertsignaturvalidierungsliste des Subnetzes verwendet wurden. Wenn alle Prüfungen erfolgreich sind, kann die Replik schließen, dass der abgerufene Zustand dem vereinbarten Zustand der jeweiligen Subnetze zum Zeitpunkt des Checkpoints entspricht. Wenn die Replik aus anderen Gründen hinterherhinkt und die Lücke zum gesunden Zustand zu groß ist, um die reine Blockwiederholung aufzuholen, wird auch die Zustandssynchronisierung ausgelöst.
4. Maximale Zustandgröße: Momentan beträgt die maximale Zustandgröße 1 TB, während der RAM der Replikknotenmaschinen 512 GB beträgt. Daher ist es nicht möglich, den gesamten Zustand in den RAM zu laden. Der Internet Computer verwendet RAM hauptsächlich, um die neuesten Daten, die noch nicht persistiert wurden, zu speichern und Daten zwischenzuspeichern, um die Leistung zu steigern.
PageMap und Nicht-Checkpoint-Höhen
Da Checkpoints nur alle 500 Blöcke erstellt werden, benötigt der ICP für Nicht-Checkpoint-Höhen unterschiedliche Speicherplatz für Container. Die grundlegende Idee, der die Speicherebene folgt, besteht darin, dass diese Daten in Form einer Kombination des letzten Checkpoints auf der Festplatte gespeichert werden, während alle nachfolgenden Änderungen im RAM gespeichert werden.
Die PageMap ist die Implementierung für den größten Teil des Zustands des Subnetzes. Der Großteil des Zustands des Subnetzes besteht aus Containerzuständen, insbesondere aus den Heap- und stabilen Speichern von Containern.
Momentan kann ein Container bis zu 4 GB Heap-Speicher, 500 GB stabilen Speicher und eine Gesamtzustandsgrenze von 1 TB im Subnetz haben, aber all diese Grenzen können sich in Zukunft ändern. Beide Speichertypen können durch Kopier- (Aktualisierungen) und Nicht-Kopier- (Abfragen) Containeraufrufe gelesen und durch Kopieraufrufe modifiziert werden.
Die PageMap-Datenstruktur ist darauf ausgelegt, eine effiziente Lese- und Schreibzugriff auf den Speicher zu ermöglichen und das effiziente Schreiben von Checkpoints zu unterstützen. Ein bestimmtes Ziel besteht darin, die Leistung unabhängig von der Gesamtgröße des Speichers zu gestalten. Beachten Sie, dass der Name PageMap daher rührt, dass alle Lese- und Schreibvorgänge in 4 KB großen Seiten erfolgen, die der vom zugrunde liegenden Betriebssystem verwendeten Seitengröße entsprechen.
PageMap speichert den Zustand in zwei Ebenen. Die erste Ebene wird als Speicher bezeichnet und besteht aus Dateien des vorherigen Checkpoints, die den Zustand der vorherigen Checkpoint-Höhe darstellen. Die zweite Ebene, die Seiteninkremente, stellt alle Änderungen seit diesem Checkpoint dar und wird im RAM gespeichert.
Beim Lesen von PageMap werden die zurückgegebenen Daten entweder aus den Seiteninkrementen abgerufen oder aus den Checkpoint-Dateien gelesen (falls sie fehlen). Das Schreiben in die PageMap erfolgt durch das Modifizieren der Seiteninkremente mit neuen Daten.
Lebenszyklus eines Checkpoints
Die Hauptaufgabe der Speicherebene besteht darin, Checkpoints auf die Festplatte zu schreiben und alle PageMaps auf dem neuesten Stand zu halten. Wenn ein neuer Checkpoint geschrieben wird, werden alle Seiteninkremente auf die Festplatte aktualisiert, wodurch der Speicherteil aller PageMaps aktualisiert wird.
Um sicherzustellen, dass alle Daten gespeichert werden, müssen Repliken immer den neuesten Checkpoint, der mit einer Schwellenwertsignatur versehen wurde, aufbewahren. Dies bedeutet, dass es nicht möglich ist, einfach die alte Checkpoint-Datei zu überschreiben, da jede solche Modifikation den vorherigen Checkpoint vor dem vollständigen Schreiben des neuen Checkpoints ändern würde, was das Risiko eines Datenverlusts birgt. Darüber hinaus wird die Kosten, einen vollständigen Checkpoint (bis zu 1 TB) alle 500 Runden auf die Festplatte zu schreiben, sehr hoch sein. Im Gegensatz dazu umfasst die Erstellung eines neuen Checkpoints 3 grundlegende Schritte:
Kopiere den alten Checkpoint in einen temporären Ordner, der als Hinweis bezeichnet wird;
Modifiziere den Hinweis, um die Daten des neuen Checkpoints darzustellen;
Benennen Sie den Hinweis in das neue Checkpoint-Verzeichnis um (um einen neuen Checkpoint atomar zu erstellen).
Der erste Schritt könnte der teuerste sein, denn je größer der Zustand, desto länger dauert es, die Dateien zu kopieren, und desto größer wird die Checkpoint-Datei.
Genau hier kommt das Dateiformat von Checkpoints und log-strukturierten Merge-Bäumen ins Spiel. Durch die Verwendung von LSMT ist dieser Schritt kostengünstig und skaliert nicht mit der Größe des Zustands. Im Vergleich dazu war dieser Schritt langsam und unvorhersehbar, bevor die LSMT-Speicherebene neu gestaltet wurde.
Log-Struktur-Merge-Baum
Der log-strukturierte Merge-Baum (LSMT) ist eine weit verbreitete Datenstruktur, die besonders für Datenbanken geeignet ist. Auf dem Internet Computer werden sie als Grundlage für den Speicherteil der PageMaps verwendet. Ein spezielles Problem, das sie lösen können, ist, dass sie den "Kopierschritt" im Lebenszyklus von Checkpoints vereinfachen, da alle Dateien nur einmal geschrieben und niemals geändert werden.
Mit LSMT wird der (logische) Zustand durch Schreiben zusätzlicher Überschreibungsdateien geändert. Um den Wert einer Seite zu lesen, überprüft der Algorithmus zunächst die zuletzt geschriebenen Überschreibungsdateien, um zu sehen, ob die Seite in dieser Datei vorhanden ist. Wenn ja, wird der Wert der Seite aus dieser Überschreibungsdatei gelesen. Andernfalls wird die nächste ältere Überschreibungsdatei überprüft. In der Implementierung, die im Internet Computer verwendet wird, wird eine Seite, die in keiner Überschreibungsdatei vorhanden ist, als Null gelesen.
Die folgende Abbildung zeigt eine Gruppe von drei Überschreibungsdateien, die den Zustand eines Containers repräsentieren, wobei die vertikalen Pfeile verschiedene Lesevorgänge von Daten und die Datei, die schließlich die Daten liest, anzeigen.
Der Lebenszyklus der Checkpoints von LSMT ist wie folgt:
Verlinken Sie alle Dateien des vorherigen Checkpoints in einen temporären Ordner, der als Hinweis bezeichnet wird;
Schreiben Sie eine neue Überschreibungsdatei, die alle Änderungen seit dem letzten Checkpoint enthält;
Benennen Sie den Hinweis in das neue Checkpoint-Verzeichnis um (um die Atomizität zu gewährleisten).
Der Schlüssel liegt darin, dass jede Überschreibungsdatei nur einmal geschrieben und niemals geändert wird. Daher ist es sicher, mehrere Checkpoints auf der Festplatte zu setzen und einige Dateien zwischen ihnen über harte Links zu teilen. Beachten Sie, dass dieser Prozess nicht funktioniert, wenn der Lebenszyklus von Checkpoints versucht, eine Datei zu ändern. Wenn eine Datei mehrere harte Links hat, wird eine Änderung an einem von ihnen alle Daten in allen harten Links ändern, was die zuvor zertifizierten Checkpoints manipuliert.
Log-Struktur-Merge-Bäume können mehrere Versionen desselben Datenbereichs speichern, was zu Speicherkosten führt, die definiert sind als das Verhältnis der Größe aller Überschreibungsdateien zur logischen Größe der dargestellten Daten. Darüber hinaus können Daten in mehreren Dateien verteilt sein.
Mit zunehmenden Speicherkosten oder der Anzahl der Überschreibungsdateien wird die Implementierung der Speicherebene zusammengeführt. Die Zusammenführung reorganisiert die Daten, indem eine Gruppe von Überschreibungsdateien genommen und durch eine einzelne Datei ersetzt wird, die nur die neuesten Versionen jeder Datenzeile enthält. Die Zusammenführung wird für PageMaps mit besonders hohen Speicherkosten oder Dateianzahlen angeordnet und im Hintergrund ausgeführt, damit sie die Ausführung von Container-Nachrichten nicht stört.
Das vorherige Design, das Reflinks verwendete
Die ursprüngliche Speicherebene des Internet Computers basierte nicht auf LSMT. Von der Geburt des Internet Computers im Jahr 2021 bis 2024 war die Speicherebene stark von der erneuten Verknüpfung abhängig.
Das erneute Verknüpfen, auch als Copy-on-Write bezeichnet, ist eine Dateisystemoperation, die zum Kopieren von Dateien verwendet wird, wobei bestimmte Dateisysteme diese Operation unterstützen. Die Repliken des Internet Computers verwenden das XFS-Dateisystem, das diese Operation unterstützt. Das erneute Verknüpfen unterscheidet sich von der normalen Datei-Kopie darin, dass es den gesamten Inhalt der Datei nicht kopiert. Stattdessen merkt sich das Dateisystem, welche Daten zwischen der Originaldatei und der neuen Datei geteilt werden, und das erneute Verknüpfen unterscheidet sich auch von harten Links, da beide Dateien unabhängig voneinander geändert werden können.
Im Design der alten Speicherebene funktionierte der Lebenszyklus eines Checkpoints wie folgt:
Verlinken Sie alle Dateien des vorherigen Checkpoints in einen temporären Ordner, der als Hinweis bezeichnet wird;
Ändern Sie die Dateien im Hinweis basierend auf allen Änderungen seit dem letzten Checkpoint;
Benennen Sie den Hinweis in das neue Checkpoint-Verzeichnis um.
Ein potenzieller Vorteil ist, dass PageMap durch eine einzelne Datei im Checkpoint dargestellt wird, was die Speicherkosten vermeidet. Um jedoch die Datei an die neue Checkpoint-Höhe anzupassen, muss die entsprechende Datei des vorherigen Checkpoints erneut verknüpft werden, anstatt sie hart zu verlinken.
Vorteile von LSMT im Vergleich zu Reflinks
Prinzipiell garantiert das erneute Verknüpfen die Geschwindigkeit von harten Links und die Verfügbarkeit von Replikationen. Leider ist das erneute Verknüpfen aus verschiedenen Gründen ein Leistungsengpass, da die Datenanforderungen des Internet Computers (sei es I/O-Durchsatz oder gesamte Datenmenge) ständig steigen.
1. Langsame Geschwindigkeit beim Erneuten Verknüpfen: Die Zeit, die für das erneute Verknüpfen von Dateien benötigt wird, kann stark variieren. In einigen Fällen kann es nur einige Sekunden dauern, aber in Experimenten haben wir auch beobachtet, dass das erneute Verknüpfen von 370 GB bis zu 10 Stunden dauern kann. In der alten Checkpoint-Logik des Internet Computers führte der 10-stündige erneute Verknüpfungsprozess dazu, dass das gesamte Subnetz 10 Stunden lang stillstand.
Fragmentierung kann zu einem schlechten Geschwindigkeitsverhältnis beim Erneuten Verknüpfen führen. Intern pflegt das XFS-Dateisystem eine Datenstruktur, die verschiedene Teile von Dateien den tatsächlichen Datenblöcken auf der Festplatte zuordnet. Wenn die Kosten für das Durchlaufen dieser Datenstrukturen hoch werden, tritt Fragmentierung auf und die Geschwindigkeit beim erneuten Verknüpfen verringert sich.
Fragmentierung kann insbesondere durch folgende Sequenzen ausgelöst werden: Eine große Menge an Dateioperationsschreibungen, gefolgt von einer erneuten Verknüpfung, dann eine große Menge an Schreibvorgängen in eine der Kopien und erneut eine Verknüpfung usw. Leider wird bei der Checkpoint-Workflow auf dem Internet Computer eine große Nutzung von Containern genau dieses Verhalten auslösen.
Auf der anderen Seite bieten harte Links eine konsistente Leistung, die nicht von Fragmentierungsproblemen betroffen ist.
Vor der Einführung des log-strukturierten Merge-Baums wurden viele provisorische Lösungen implementiert, darunter manuelles Defragmentieren von Dateien (durch Lesen und Zurückschreiben von Dateien) sowie Schreiben von Dateien auf größere zusammenhängende Abschnitte. Beide Ansätze haben jedoch eine größere Schreibverstärkung zur Folge und können dennoch zu Ausfallzeiten von bis zu 30 Minuten führen.
2. Maximale Zustandgröße: Neben der sehr langen erneuten Verknüpfungszeit aufgrund von übermäßiger Fragmentierung korreliert die erneute Verknüpfungszeit auch mit der gesamten Menge der im Subnetz gespeicherten Daten, selbst bei moderater Fragmentierung. In der vorherigen Implementierung der Speicherebene wurde festgelegt, dass die Speichermenge eines Subnetzes 700 GB nicht überschreiten durfte. Diese Zahl hängt zum großen Teil davon ab, wie viele moderate Fragmente innerhalb von 20-30 Sekunden erneut verknüpft werden können.
Bei der Verwendung von harten Links dehnt sich die Checkpoint-Zeit nicht auf die gleiche Weise mit der Datenmenge aus, wodurch dieser Engpass beseitigt wird.
3. Schlechte Mehrfadenleistung: Eines der Ziele der Checkpoint-Logik ist es, Synchronisationsoperationen so weit wie möglich zu vermeiden, da während des Checkpoints die Ausführung des Containers stillsteht. Natürlich muss berücksichtigt werden, ob das erneute Verknüpfen im Hintergrund ausgeführt werden kann, während die Ausführung fortgesetzt wird (selbst wenn es langsam ist). Leider zeigt die Erfahrung, dass es nicht möglich ist, Dateien gleichzeitig erneut zu verknüpfen und zu lesen, sodass das parallele Erneute Verknüpfen zu einer Verlangsamung der Ausführung führt.
Im neuen Design der Speicherebene erfolgt das erneute Verknüpfen parallel zur Ausführung, und sie verlangsamen sich nicht gegenseitig.
4. Cache: Wie oben erwähnt, wird das Lesen von Daten aus dem Speicher eines Containers sowohl von RAM als auch von den zugrunde liegenden Checkpoint-Dateien durchgeführt (wenn sie fehlen). Das wiederholte Lesen der gleichen Datei führt normalerweise nicht dazu, dass Daten mehrmals von der physischen Festplatte oder SSD gelesen werden müssen. Stattdessen werden diese Daten vom Betriebssystem zwischengespeichert. Leider stört das erneute Verknüpfen den Cache, da das Erneute Verknüpfen von Dateien und das anschließende Lesen aus der neuen Replik den Cache nicht verwendet. Daher werden im Internet Computer nach dem Schreiben eines Checkpoints viele (langsame) Spitzen bei Festplattenlesevorgängen beobachtet, da alle Lesevorgänge auf die neuen Dateien umschalten. Darüber hinaus profitiert auch die explizite Berechnung (d.h. das Berechnen aller Checkpoint-Dateien für den Konsens) erheblich von einem besseren Cache.
Im Gegensatz dazu werden bei der Verlinkung von harten Dateien alle Caches beibehalten, und alle kürzlich gelesenen oder geschriebenen Daten, selbst die, die während früherer Checkpoint-Intervalle aufgetreten sind, werden weiterhin zwischengespeichert, sodass sie schnell abgerufen werden können.
Ergebnisse
Die LSMT-Speicherebene wurde innerhalb weniger Wochen im zweiten Quartal 2024 auf alle Subnetze des Internet Computers ausgerollt. Die folgende Abbildung zeigt die Metriken vor und nach dem Upgrade des Replikcodes, wobei die rote vertikale Linie den Zeitpunkt angibt, an dem die LSMT-Speicherebene aktiviert wurde.
Die erste Abbildung zeigt die Checkpoint-Zeit des w4rem-Subnetzes, das Container für die Bitcoin-Integration hostet. Im Vergleich zu vielen anderen Subnetzen haben die Container, die im Bitcoin-Subnetz gehostet werden, eine speicherintensive Arbeitslast, sowohl im Heap- als auch im stabilen Speicher, weshalb Fragmentierung ein besonders besorgniserregendes Problem für dieses Subnetz darstellt.
Aus der Sicht der Metriken hat sich die Checkpoint-Zeit von über 20 Sekunden auf nur 1-2 Sekunden verkürzt, was hauptsächlich darauf zurückzuführen ist, dass der Schritt des erneuten Verknüpfens beseitigt wurde, der 20 Sekunden der gesamten Zeit in Anspruch nahm.
Für Benutzer von Bitcoin-Containern ist der Vorteil eine schnellere Reaktionszeit. Während des Checkpoints verarbeitet das Subnetz keine Aktualisierungsaufrufe oder Kopieranfragen. Wenn ein Benutzer beim Start des Checkpoints einen Aktualisierungsaufruf oder eine Kopieranfrage an den Bitcoin-Container sendet, dauert es mindestens 20 Sekunden, um eine Antwort zu erhalten. Die Verwendung der LSMT-Speicherebene kann solche inkonsistenten Reaktionszeiten im Wesentlichen beseitigen.
Die zweite Abbildung zeigt die Abschlussquote im k44fs-Subnetz. Die Abschlussquote oder Blockrate ist die Anzahl der Blöcke, die das Subnetz pro Sekunde produziert.
Der Internet Computer begrenzt die Anzahl der Befehle, die pro Runde ausgeführt werden, auf einen Wert, der ungefähr dem Arbeitsaufwand entspricht, den er in einer Sekunde ausführen kann, um sicherzustellen, dass die Abschlussrate über einer Blockrate von 1 pro Sekunde bleibt.
Vor dem Upgrade auf die LSMT-Speicherebene fiel die Abschlussquote regelmäßig, was vollständig mit den Checkpoints übereinstimmt. Die Checkpoints wirken sich aus zwei Hauptgründen auf die Abschlussquote aus: Erstens die Zeit, die zum Erstellen eines Checkpoints benötigt wird, während der keine Blöcke ausgeführt werden. Nach dem Upgrade wird dieser Einfluss verringert, da die Checkpoint-Zeit in der Regel viel kürzer ist.
Der zweite Grund ist, dass das Cache-Verhalten der LSMT-Speicherebene besser ist. Insbesondere führte der Schritt des erneuten Verknüpfens in der alten Speicherebenenimplementierung zu Cache-Fehlfunktionen. Daher führt jeder Container, der nach einem Checkpoint aus dem Speicher liest, dazu, dass die Replik die Daten von der Festplatte abruft, was um viele Größenordnungen langsamer ist als dieselben Daten, die im RAM-Cache verfügbar sind. Dieses Problem tritt in der neuen LSMT-Speicherebene nicht auf.
Wie die Metriken zeigen, ist der Rückgang der Abschlussrate nach dem Upgrade deutlich geringer, da die Checkpoints selbst schneller sind, das erneute Verknüpfen nicht mehr erforderlich ist und die Dateicaches nicht mehr ungültig sind.
Für Benutzer von Containern in diesem Subnetz bedeutet dies schnellere Reaktionszeiten und höhere Durchsatzraten.
Fazit
Die Neugestaltung der Speicherebene des Internet Computers um die logische Struktur von Merge-Bäumen ist eine wichtige Investition in die Skalierbarkeit und Leistung der Plattform, da sie nicht nur einige speicherintensive Workloads ermöglicht, sondern auch dem Internet Computer erlaubt, Containern einen größeren Zustand zu bieten.
Im Kontext der Ausführung großer Sprachmodelle im Bereich der künstlichen Intelligenz und on-chain ist es besonders interessant, Container zu betreiben, die mit großen Datenmengen arbeiten. Solche Container hängen nicht nur von großen Datenspeicherungen ab, sondern sind auch stark auf I/O-Durchsatz angewiesen.
Darüber hinaus legt es den Grundstein für nachfolgende Verbesserungen, indem es durch eine bessere Nutzung der Parallelität die Arbeitslast auf dem kritischen Pfad verringert, was die Reaktionsgeschwindigkeit des Internet Computers erhöht. Die Erfahrungen mit der ursprünglichen Speicherebene zeigen, dass es entscheidend ist, das erneute Verknüpfen zu vermeiden, und die LSMT-Datenstruktur kann dies tun.
Hat Ihnen dieser Artikel gefallen? Teilen Sie Ihre Gedanken im DFINITY Developers X-Kanal und schließen Sie sich uns morgen auf unserer Stellarator-Reise Teil 2 an, um mit Luc Bläser über verbesserte orthogonale Persistenz zu diskutieren.
IC-Inhalte, die Sie interessieren
Technologische Fortschritte | Projektinformationen | Globale Aktivitäten
Folgen Sie dem IC Binance-Kanal
Bleiben Sie auf dem neuesten Stand
