Bigtable für Aerospike-Nutzer

Dieses Dokument unterstützt Softwareentwickler und Datenbankadministratoren bei der Migration vorhandener Aerospike-Anwendungen mit Bigtable als Datenbank. Dabei wird Ihr Wissen über Aerospike genutzt, um Konzepte zu beschreiben, die Sie vor der Migration zu Bigtable verstehen müssen.

Dieses Dokument soll Ihnen den Einstieg in Bigtable und Aerospike erleichtern und bietet daher Folgendes:

  • Vergleich der Terminologie zwischen Aerospike und Bigtable.
  • Übersicht über Bigtable-Vorgänge und Beschreibung des Datenlayouts in Bigtable
  • Hier werden die Datenmodellierung und wichtige Designüberlegungen erläutert.
  • Es wird erläutert, wie die Replikation erfolgt und welche Auswirkungen sie hat.

Informationen zum Migrationsprozess und zu Open-Source-Tools, die Sie für die Migration verwenden können, finden Sie unter Von Aerospike zu Bigtable migrieren.

Vergleich der Terminologie

Aerospike und Bigtable sind beides verteilte NoSQL-Datenbanken, unterscheiden sich jedoch erheblich in Design, Betrieb und Terminologie.

In Aerospike werden Daten in Datensätzen gespeichert. Jeder Datensatz enthält einen oder mehrere benannte Bins sowie Metadaten wie die Datensatzgröße (in Byte), die Gültigkeitsdauer (TTL) und die letzte Aktualisierungszeit (LUT).

Bigtable speichert Daten in skalierbaren Tabellen, von denen jede eine sortierte Zuordnung von Schlüssel/Wert-Paaren darstellt. Die Tabelle besteht aus Zeilen, die durch Zeilenschlüssel indexiert werden, und Spalten, die durch einen Spaltenqualifizierer identifiziert werden. Wenn Spalten miteinander in Beziehung stehen, können sie eine Spaltenfamilie bilden. Mit dieser Struktur können Sie mehrere Versionen eines Werts unter demselben Schlüssel speichern. Jede Version wird durch einen eindeutigen Zeitstempel identifiziert. Frühere Versionen können bei Lesevorgängen gefiltert oder durch die automatische Bereinigung gemäß den konfigurierten Richtlinien entfernt werden.

Weitere Informationen finden Sie unter Bigtable-Speichermodell.

In der folgenden Tabelle sind gemeinsame Konzepte und die entsprechende Terminologie für jedes Produkt dargestellt.

Aerospike Bigtable
Kein direkt entsprechender Artikel. Instanz: Eine verwaltete Gruppe von Clustern in verschiedenen Google Cloud -Zonen oder -Regionen, zwischen denen Replikation und Verbindungsrouting stattfinden.
Cluster: Eine Aerospike-Bereitstellung, die aus einer Sammlung von Knoten besteht. Cluster: Eine Gruppe von Knoten in derselben geografischen Google Cloud Zone.
Knoten: Ein Server, der Rechenleistung bereitstellt und dessen Speicherplatz gehört. Knoten: Ein Server, der nur Rechenleistung bereitstellt. Die Speicherung erfolgt über Colossus, ein separates verteiltes Dateisystem.
namespace: Speichert Parameter wie TTL oder Speichertyp. Innerhalb eines Namespace werden Daten in Sets und Datensätze unterteilt. table: Das ist das Äquivalent zu einem Aerospike-Namespace. Einige Parameter werden für alle Tabellen auf Clusterebene festgelegt. Eine genauere Steuerung ist auf Tabellen- oder Spaltenfamilienebene möglich.
set: Wird für die logische Aufteilung von Datensätzen und Parametern wie TTL und Obergrenze verwendet. Schlüssel müssen innerhalb eines Sets eindeutig sein. Kein direkt entsprechender Artikel.
Kein direkt entsprechender Artikel. table: Eine Ressource auf Instanzebene, die automatisch in jeden Cluster repliziert wird. Eine Tabelle enthält eine Reihe von Werten, die durch eindeutige Zeilenschlüssel identifiziert werden. Tabellen sind dünnbesetzt. Das bedeutet, dass kein zusätzlicher Speicherplatz für Spalten verwendet wird, die keine Werte enthalten.
Kein direkt entsprechender Artikel. Tabellenreihen: Ein zusammenhängender Bereich von Zeilen, die zusammen gespeichert werden. Bigtable verwendet Tabellenreihen für das Load-Balancing, indem sie Knoten zugewiesen werden. Die Grenzen von Tablets sind dynamisch und können sich im Laufe der Zeit aufteilen oder zusammenführen.
Datensatz: Eine Gruppe benannter Bins zum Speichern von Daten. Sie darf maximal 8 MB groß sein. Zeile: Eine Gruppe von Werten, die durch Spaltenfamilie, Spaltenqualifizierer und Zeitstempel identifiziert werden. Alle Operationen sind auf Zeilenebene atomar.
Kein direkt entsprechender Artikel. Spaltenfamilie: Eine Gruppe von Spalten, die in lexikografischer Reihenfolge sortiert sind. Die automatische Speicherbereinigung wird auf dieser Ebene festgelegt.
Bin: Ein Schlüssel/Wert-Paar, bei dem der Bin-Name die Kennung eines Werts in einem Datensatz ist. Spaltenqualifizierer: Ein Label für einen Wert, der in einer Tabelle gespeichert ist.
Kein direkt entsprechender Artikel. Zelle: Ein Label für einen Zeitstempelwert, der in einer Tabelle gespeichert ist.
(Datensatz-)Digest: Ein Hash eines 3‑Tupels, das einen Datensatz identifiziert: Namespace, Set und Schlüssel. Kein direkt entsprechender Artikel.
key: Eine Datensatz-ID, die innerhalb eines Sets eindeutig ist. Zeilenschlüssel: Eine Zeilen-ID, die innerhalb einer Tabelle eindeutig ist.
AQL:Ein Befehlszeilentool zum Durchsuchen von Daten und Entwickeln benutzerdefinierter Funktionen für die Aerospike-Datenbank. GoogleSQL: Eine Abfragesprache, die von mehreren Google Cloud Diensten verwendet wird, darunter Spanner, BigQuery und Bigtable.

Limits für Datentypen

In der folgenden Tabelle werden die Grenzwerte für Datentypen verglichen, die von Aerospike und Bigtable verwendet werden:

Aerospike Bigtable
namespace: Die maximale Anzahl von Namespaces für die Enterprise Edition beträgt 32. table: Eine Instanz kann bis zu 1.000 Tabellen enthalten. Ein Tabellenname darf maximal 50 Zeichen lang sein.
Sets: Ein Cluster kann bis zu 4.095 Sets haben. Ein Setname darf nicht länger als 63 Byte sein. Kein direkt entsprechender Artikel.
Datensatz: Die maximale Datensatzgröße beträgt 8 MB. row: Die maximale Zeilengröße beträgt 256 MB.
Kein direkt entsprechender Artikel. Spaltenfamilie: Die Anzahl der Spaltenfamilien ist unbegrenzt. Mehr als 100 Spaltenfamilien können jedoch die Leistung beeinträchtigen.
bin: Die Anzahl der Bins ist unbegrenzt. Jeder Bin darf jedoch nicht mehr als 1 MB Daten enthalten. Der Name des Behälters darf maximal 15 Byte lang sein. Spaltenqualifizierer: Das Limit beträgt 100 MB, es wird jedoch empfohlen, 10 MB nicht zu überschreiten. Die Anzahl der Spalten ist unbegrenzt.
key: Die maximale Schlüsselgröße beträgt 8 KB. Zeilenschlüssel: Die maximale Größe des Zeilenschlüssels beträgt 4 KB.

Weitere Informationen zu Bigtable- und Aerospike-Limits finden Sie unter Kontingente und Limits bzw. Aerospike-Systemlimits und ‑Schwellenwerte.

Architektur

Die folgenden Abschnitte bieten einen architektonischen Überblick über Bigtable und Aerospike.

Bigtable

Bigtable-Knoten sind von der Speicherebene getrennt. Das bedeutet, dass Knoten sich nicht auf die Datenbeständigkeit auswirken. Bigtable-Tabellenclients kennen die zugrunde liegende Datenverteilung nicht. Eine zusätzliche Routingebene leitet Anfragen an den richtigen Knoten weiter. Jeder Knoten verarbeitet einen Teil der Anfragen an den Cluster. Eine Bigtable-Tabelle ist in Blöcke von fortlaufenden Zeilen unterteilt, die als Tabellenreihen bezeichnet werden. Diese werden in Colossus gespeichert, einem verteilten Dateisystem, das eine hohe Langlebigkeit bietet. Jede Tabellenreihe ist einem bestimmten Knoten in Bigtable zugeordnet.

Clients im Bigtable-Cluster kommunizieren über die Routingebene mit den Knoten. Die Routingebene verteilt die Daten an den richtigen Knoten.

Die Architektur von Bigtable bietet folgende Vorteile:

  • Bigtable-Clients müssen sich nicht um die Datenverteilung und das Load-Balancing kümmern. Diese Komplexitäten werden von der Routing-Ebene behandelt.
  • Das Rebalancing erfolgt sehr schnell und die Wiederherstellung nach einem Fehler ist schnell, da die tatsächlichen Daten nicht zwischen Knoten kopiert werden.
  • Wenn ein Knoten in Bigtable fehlschlägt, gehen keine Daten verloren.

Aerospike

Im Gegensatz zu Bigtable befindet sich der Speicher von Aerospike auf den Knoten, die ihn bereitstellen. Jeder Knoten (ein Server) im Aerospike-Cluster ist identisch. Die Daten in jedem Namespace werden durch Hashing von Datensatznamen in genau 4.096 Partitionen unterteilt. Diese Partitionen sind gleichmäßig auf die Knoten verteilt.

Die Knoten kennen sich gegenseitig und gleichen gespeicherte Partitionen aus, wenn sich der Cluster ändert. Bei jeder Clusteränderung wählen die Replikate ein primäres Replikat aus, das das Neuausgleich koordinieren soll. Die Clientbibliotheken müssen nachverfolgen, auf welchem Replikat die primäre Partition gespeichert ist, und Schreibanfragen an die richtigen Replikate senden. Wenn ein Client eine Anfrage an den falschen Knoten sendet (was während des Neuausgleichs passieren kann), wird die Anfrage von den Knoten umgeleitet.

Clients im Aerospike-Cluster kommunizieren mit den Knoten, die das Neuausgleichen von Arbeitslasten verarbeiten.

Replikation

In diesem Abschnitt wird der Replikationsprozess für Aerospike und Bigtable verglichen.

Bigtable

Eine Bigtable-Instanz kann aus einem einzelnen Cluster oder mehreren replizierten Clustern bestehen. Eine Tabelle wird immer auf alle Cluster in einer Instanz repliziert. Cluster lassen sich aus einer Instanz mit minimalen Auswirkungen auf andere Cluster hinzufügen und entfernen.

Bigtable bietet Read-Your-Writes-Konsistenz innerhalb eines einzelnen Clusters. Schreibvorgänge werden auf einem einzelnen Cluster ausgeführt und sind in den anderen Clustern der Instanz letztendlich konsistent. Im Gegensatz zu Aerospike gehen in Bigtable keine Zwischenaktualisierungen verloren, da einzelne Zellen intern versioniert werden. So wird sichergestellt, dass keine Schreibvorgänge verloren gehen. Jeder Cluster stellt die Zellen mit den neuesten verfügbaren Zeitstempeln bereit.

Die Bigtable API bietet ein Konsistenztoken auf Tabellenebene, mit dem Sie prüfen können, ob alle Änderungen, die vor der Erstellung des Tokens vorgenommen wurden, vollständig repliziert wurden.

Aerospike

Aerospike verarbeitet die Replikation innerhalb eines Clusters auf Partitionsebene. Ein Namespace wird in Partitionen aufgeteilt, die gleichmäßig auf die Knoten verteilt werden. Innerhalb eines Clusters wird für starke Konsistenz gesorgt. Ein Schreibvorgang wird erst bestätigt, wenn alle Replikate im Cluster ihn bestätigt haben.

Rechenzentrumsübergreifende Replikation (Cross Data Center Replication, XDR) kann für die Datensynchronisierung zwischen verschiedenen Clustern konfiguriert werden. Die Bin-Konvergenz von Aerospike sorgt dafür, dass die Daten am Ende der Replikation in allen Rechenzentren gleich sind. Zwischenaktualisierungen können jedoch verloren gehen.

Für die Dauerhaftigkeit erfordert der auf der Liste basierende Konsistenzalgorithmus von Aerospike N+1 Kopien, um N Fehler zu beheben.

Datenmodell

In diesem Abschnitt werden die von Bigtable und Aerospike verwendeten Datenmodelle verglichen.

Flexibles Schema

In Aerospike werden keine Schemabeschränkungen erzwungen. Daher kann jeder Datensatz unterschiedliche Klassen mit verschiedenen Werttypen haben. Bigtable unterstützt auch dünnbesetzte Spalten. Für Spalten ohne Werte wird also kein Speicherplatz belegt. Es gibt zwar keine strikte Begrenzung für die Anzahl der Spalten oder Spaltenfamilien, aus Leistungsgründen empfiehlt es sich jedoch, die Anzahl der Spaltenfamilien unter 100 zu halten.

Zeilenschlüsseldesign

In Bigtable werden Zeilen anhand von Zeilenschlüsseln identifiziert, die innerhalb einer Tabelle eindeutig sein müssen. Sie werden lexikografisch sortiert und in Tablets zusammengefasst. Das unterscheidet sich von Aerospike, wo Datensätze basierend auf ihrem Hash auf Knoten verteilt werden. Zeilenschlüssel sollten so konzipiert sein, dass Zeilen, auf die häufig gemeinsam zugegriffen wird, auch gemeinsam gespeichert werden.

Datentypen

Aerospike unterstützt erweiterte Datentypen wie Skalare, GeoJSON, HyperLogLogs, Listen und verschachtelte Objekte. Diese Typen können mit Unterstützung von sekundären Indexen indexiert und abgefragt werden. Außerdem bietet Aerospike serverseitige APIs, die komplexe Operationen für diese Datentypen ermöglichen, z. B. das Filtern nach geografischem Standort oder das Bearbeiten von Listeninhalten.

Die Bigtable API konzentriert sich hauptsächlich auf die Verarbeitung von Rohbytes, mit einigen Ausnahmen. Außerdem werden INT64-Werte für Zeitstempel und Zähler verwendet, die als atomarer Vorgang inkrementiert werden können. Die Abfragesprache unterstützt auch viele komplexe Typen wie Skalare, JSON-Objekte und HLL-Bins. Erweiterte Typen werden in Zukunft möglicherweise zunehmend unterstützt. Zum Zeitpunkt der Erstellung dieses Dokuments gibt es jedoch keine Möglichkeit, solche Typen in Bigtable zu speichern. Alles wird clientseitig serialisiert. Sie können die Adapterbibliothek aus den aerospike-migration-tools verwenden, um Ihre Datentypen zu serialisieren.

Spaltenfamilie

In Bigtable wird mit Spaltenfamilien festgelegt, welche Spalten in einer Tabelle zusammen gespeichert und abgerufen werden. Für jede Tabelle muss mindestens eine Spaltenfamilie vorhanden sein. Zusammengehörige Spalten sollten in derselben Familie gruppiert werden. Daten mit unterschiedlichen Aufbewahrungsanforderungen sollten in separate Spaltenfamilien aufgeteilt werden, da Richtlinien für die automatische Speicherbereinigung auf der Ebene der Spaltenfamilien angewendet werden.

Spaltenqualifizierer

In Bigtable werden Spaltenqualifizierer innerhalb einer Spaltenfamilie verwendet, um einzelne Spalten zu definieren. Tabellen können Millionen von Spalten enthalten. Es empfiehlt sich jedoch, die Anzahl der Spalten in einer einzelnen Zeile zu begrenzen. Optional können Spaltenqualifizierer als Daten behandelt werden. So lassen sich Werte direkt in den Spaltennamen einbetten, um Platz zu sparen.

Zellen

In Bigtable ist eine Zelle die Schnittstelle des Zeilenschlüssels und des Spaltennamens (eine Spaltenfamilie in Kombination mit einem Spaltenqualifizierer). Jede Zelle enthält einen oder mehrere Zeitstempelwerte, die vom Client bereitgestellt oder automatisch vom Dienst angewendet werden.

Sekundäre Indexe

Kontinuierliche materialisierte Ansichten können als asynchrone sekundäre Indexe fungieren, sodass Tabellen mit verschiedenen Suchmustern oder Attributen abgefragt werden können. Weitere Informationen finden Sie unter Asynchronen sekundären Index erstellen.

Transaktionen

Sowohl Bigtable als auch Aerospike unterstützen keine mehrzeiligen Transaktionen, unterscheiden sich jedoch in ihren Einzeilenfunktionen. Bigtable bietet vollständig konsistente einzeilige Schreibvorgänge innerhalb eines Clusters und unterstützt einzeilige Transaktionen über „mutate-row“-Anfragen. Sie ermöglichen mehrere Vorgänge für eine einzelne Zeile, die alle atomar ausgeführt werden und entweder alle erfolgreich sind oder alle fehlschlagen. Außerdem gibt es Read-Modify-Write- und Check-and-Mutate-Vorgänge, die jedoch nicht mit Multi-Cluster-Routingprofilen verfügbar sind. Im Gegensatz dazu erweitert Aerospike Einzelzeilentransaktionen mit serverseitiger Datenbearbeitung und Ausführung clientseitig definierter Funktionen.

Load-Balancing und Failover

Aerospike verwendet Smart Client, um das Load Balancing auf der Clientseite zu verarbeiten. Ein clientseitig ausgeführter Prozess, der den Clusterstatus und die Datenverteilung kennt. Dieser Client ist für das Weiterleiten der Anfrage verantwortlich.

Wenn ein Knoten ausfällt oder ein neuer Knoten hinzugefügt wird, muss der Cluster neu ausbalanciert werden. Es wird eine temporäre primäre Instanz ausgewählt, um das Neuausgleichen und die Neuverteilung der Partitionen zwischen den Knoten zu koordinieren. Währenddessen bleibt der Cluster betriebsbereit, der Client muss jedoch die Änderungen für das Anforderungsrouting nachverfolgen. Wenn eine Anfrage den falschen Knoten erreicht, wird sie intern an den richtigen Knoten weitergeleitet.

Der Bigtable-Client ist ein Thin Client, der alle Komplexitäten wie den Clusterstatus und die Datenverteilung vor dem Nutzer verbirgt. Das Weiterleiten der Anfrage wird von der nächsten Ebene, einem Thick Client innerhalb der Google CloudBigtable-Infrastruktur, übernommen.

Ein weiterer Unterschied ist die Routingrichtlinie, die in Aerospike nicht verfügbar ist. Bigtable verwendet Anwendungsprofile zur Verwaltung des Anfrage-Routings. Mit konfigurierbaren Prioritäten lässt sich die Reihenfolge steuern, in der Anfragen bearbeitet werden. Es gibt zwei Arten von Routingrichtlinien: Single-Cluster-Routing und Multi-Cluster-Routing. Ein Multi-Cluster-Profil leitet Vorgänge an den nächstgelegenen verfügbaren Cluster weiter. Cluster in einer Region werden aus Sicht des Vorgangs-Routers als äquidistant eingestuft. Wenn der Knoten, der für den angeforderten Schlüsselbereich zuständig ist, überlastet oder in einem Cluster vorübergehend nicht verfügbar ist, bietet dieses Profil automatisches Failover. Im Gegensatz dazu bietet Aerospike kein automatisches Failover bei einem vollständigen Clusterausfall.

Sichern und wiederherstellen

Aerospike bietet externe Sicherungs- und Wiederherstellungstools namens asbackup und asrestore, mit denen clientseitig logische Sicherungen erstellt werden. Dies entspricht dem Ausführen eines Scans. Die Sicherungsverwaltung kann auch über den Aerospike Backup Service oder den Aerospike Kubernetes Operator erfolgen. Beide verwenden intern asbackup und asrestore und bieten Planung und Koordination mehrerer Prozesse. Sicherungen sind nicht atomar. Das bedeutet, dass Schreibvorgänge, die während der Sicherung erfolgen, möglicherweise nicht erfasst werden.

Bigtable bietet zwei Methoden zur Gewährleistung der allgemeinen Sicherungsanforderungen: Bigtable-Sicherungen und verwaltete Datenexporte. Aus Sicherungen werden wiederherstellbare Kopien einer Tabelle erstellt und als Mitgliederobjekte eines Clusters gespeichert. Sie können Sicherungen als neue Tabelle in dem Cluster wiederherstellen, der die Sicherung initiiert hat. Die Sicherungen sind so konzipiert, dass Wiederherstellungspunkte erstellt werden, wenn Beschädigungen auf Anwendungsebene auftreten. Bigtable-Sicherungen sind auch nicht atomar. Es kann sein, dass Änderungen in einem Abschnitt der Tabelle vorgenommen werden, den die Sicherung bereits kopiert hat.

Wichtige Unterschiede bei der Sicherung

  • Aerospike-Sicherungen werden clientseitig erstellt. Sie benötigen serverseitig keinen zusätzlichen Speicherplatz, sind aber langsamer. In Bigtable nutzt eine Sicherung den physischen Speicher mit der Quelltabelle und anderen Sicherungen der Tabelle gemeinsam.
  • Der Aerospike-Nutzer muss sich um das Exportieren, Speichern und Entfernen alter Sicherungen kümmern. Da Backups in Bigtable vollständig integriert sind, werden alle diese Aktionen automatisch vom Bigtable-Dienst ausgeführt.

Hinweise zur Leistung

Da Aerospike und Bigtable Lese- und Schreibvorgänge unterschiedlich behandeln, gibt es Leistungsunterschiede, die berücksichtigt werden müssen. Die folgende Tabelle enthält einige Beispiele für Leistungsunterschiede zwischen den beiden Datenbanken. Weitere Informationen finden Sie in den Leistungsrichtlinien für Bigtable.

Kaufbereitschaft Bigtable Aerospike
Hervorgehobene Zeilen Verteilt Tabellenreihen und Vorgänge, um die Ressourcennutzung auszugleichen. Eine häufig aufgerufene Zeile kann in einer Tabellenreihe mit einer einzelnen Zeile auf einem Knoten isoliert werden, wodurch die Auswirkungen auf andere Zeilen begrenzt werden. Verteilt Zeilen basierend auf Hashes auf alle Knoten, unabhängig vom Traffic. Eine Hot Row kann sich auf die Leistung einer gesamten Partition auswirken.
Scans über sortierte Schlüssel Daten werden lexikografisch gespeichert, was die Streaming-Effizienz sortierter Daten erhöht. Verteilt Datensätze basierend auf Hashes. Wenn Sie also viele aufeinanderfolgende Schlüssel scannen, müssen Sie mehrere Knoten abfragen und Ergebnisse zusammenfassen, was langsamer sein kann. Unterstützt Sekundärindexe, einschließlich erweiterter Typen, wodurch die Notwendigkeit von Scans reduziert werden kann.
Viele aufeinanderfolgende Tasten einfügen Daten werden lexikografisch gespeichert. Das bedeutet, dass ein einzelner Knoten viele aufeinanderfolgende Schreibvorgänge für Schlüssel verarbeitet. Daher kann ein Lese- oder Schreibmuster auf dem Knoten landen, der für das Ende des Zeilenschlüsselbereichs zuständig ist, was zu einer Überlastung führen kann. Schlüssel werden basierend auf dem Hash verteilt, wodurch die Last beim Schreiben aufeinanderfolgender Schlüssel auf mehrere Knoten verteilt wird.
Zeilen mit einer sehr großen Anzahl von Spalten Bigtable unterstützt zwar Zeilen mit einer Größe von bis zu 256 MB, die Verarbeitung großer Zeilen kann sich jedoch auf die Leistung auswirken. Bigtable ist für kleinere Zeilen optimiert. Daher sollten bei der Schemakonzeption die Zellorganisation und der Datenzugriff berücksichtigt werden, um unnötiges Verteilen von Daten auf viele Zellen zu vermeiden. Die Leistung ist suboptimal, wenn eine Zeile oder ein Datensatz mit einer sehr großen Anzahl von Spalten oder Klassen vorhanden ist.
Kaltstarts Funktioniert am besten mit großen Tabellen, auf die häufig zugegriffen wird. Wenn Sie nach einem Zeitraum der Nichtnutzung (Kaltstart) Anfragen senden, kann es zu hoher Latenz kommen. Das liegt daran, dass die Aufteilung in Tabellen und ihre Verteilung auf Knoten möglicherweise nicht optimal ist und die Caches kalt sind. Die Verteilung zwischen Knoten ist möglicherweise erst einige Minuten nach dem Kaltstart und während des Neuausgleichs optimal. Die Leistung ändert sich im Laufe der Zeit nicht, da die Datenverteilung nicht lastbasiert ist. Während Caches aufgewärmt werden müssen, werden Indexe im Arbeitsspeicher gehalten, wodurch die Festplattensuchzeit minimiert und die Bedeutung des Caching reduziert wird.
Viele kleine Tabellen Vermeiden Sie es, viele kleine Tabellen zu erstellen. Separate Tabellen sind für unterschiedliche Anwendungsfälle oder Schemas gerechtfertigt, nicht aber für ähnliche Daten, da sie das Load Balancing nicht verbessern und den Verwaltungsaufwand erhöhen. Die meisten Datensätze befinden sich in einem Namespace und sind in Gruppen unterteilt. Sets haben keine spezifischen Schemas, aber sekundäre Indexe oder Scanvorgänge können pro Set festgelegt werden. Das Aufteilen von Daten in Sets hat keine Auswirkungen auf die Leistung.
Großes Dataset Exabyte-Datasets können gespeichert werden. Die Leistung wird aufgrund der Architektur und der dynamischen Tabellenteilung nicht durch die Gesamtgröße des Datasets beeinträchtigt. Technisch gesehen haben Aerospike-Datenbanken kein Größenlimit. Aerospike speichert jedoch Indexe und Datensätze separat. Beide Arten von Daten können auf verschiedenen Arten von Speichergeräten gespeichert werden, um die Leistung zu steigern. Das Speichern von Indexen im RAM ist für niedrige Latenzen unerlässlich, ist aber bei sehr großen Datasets möglicherweise nicht möglich. Bei 4 Milliarden Objekten und einem Replikationsfaktor von 2 (RF2) beträgt der Arbeitsspeicher, der in Verbindung mit dem primären Index im Cluster in All-Flash-Konfigurationen verwendet wird, beispielsweise 2,5 GiB. Wenn wir dasselbe Beispiel in einer Hybrid Memory-Konfiguration verwenden, in der sich der primäre Index im Arbeitsspeicher befindet, werden 476,8 GiB Arbeitsspeicher verwendet.
Skalieren Verarbeitung und Speicherung sind entkoppelt und können unabhängig voneinander skaliert werden. Ein einzelner Knoten kann Datenblöcke von mehreren Hundert Terabyte oder sogar Petabyte verarbeiten. Das Speichern von Indexen im RAM ist für niedrige Latenzen unerlässlich. In diesem Fall müssen die Maschinen zusammen mit der Speicherkapazität vertikal skaliert werden, um den primären Index zu berücksichtigen.

Nächste Schritte