Weitere Informationen zur Persistenz in Cassandra und anderen NoSQL-Datenbanken finden Sie unter Was ist NoSQL?
Das Verständnis der Bedeutung von Persistenz ist wichtig für die Bewertung verschiedener Datenspeichersysteme. Angesichts der Bedeutung des Datenspeichers in den meisten modernen Anwendungen kann eine schlecht informierte Entscheidung erhebliche Ausfallzeiten oder Datenverluste bedeuten. In diesem Beitrag werden Persistenz- und Datenspeicherdesignansätze erläutert und Hintergrundinformationen zu diesen im Kontext von Cassandra bereitgestellt.
Persistenz ist „das Fortbestehen einer Wirkung, nachdem ihre Ursache beseitigt ist“. Im Zusammenhang mit der Speicherung von Daten in einem Computersystem bedeutet dies, dass die Daten überleben, nachdem der Prozess, mit dem sie erstellt wurden, beendet ist. Mit anderen Worten, damit ein Datenspeicher als persistent angesehen werden kann, muss er in einen nichtflüchtigen Speicher schreiben.
Wenn Sie Persistenz in Ihrem Datenspeicher benötigen, müssen Sie auch die vier grundlegenden Designansätze verstehen, die ein Datenspeicher verwenden kann, und wie (oder ob) diese Designs Persistenz bieten:
-
Reines In-Memory, überhaupt keine Persistenz, wie Memcaches oder Scalaris
-
In-Memory mit periodischen Snapshots wie Oracle Coherence oder Redis
-
Festplattenbasiert mit Update-in-Place-Schreibvorgängen wie MySQL ISAM oder MongoDB
-
Commitlog-basiert, wie alle traditionellen OLTP-Datenbanken (Oracle, SQL Server, etc.)
In-Memory-Ansätze können eine hohe Geschwindigkeit erreichen, jedoch auf Kosten der Beschränkung auf einen relativ kleinen Datensatz. Die meisten Workloads haben eine relativ kleine „heiße“ (aktive) Teilmenge ihrer Gesamtdaten; Systeme, bei denen die gesamte Datenmenge in den Speicher passen muss und nicht nur der aktive Teil, eignen sich gut für Caches, sind jedoch für die meisten anderen Anwendungen schlecht geeignet. Da sich die Daten nur im Speicher befinden, überleben sie die Prozessbeendigung nicht. Daher werden diese Arten von Datenspeichern nicht als persistent angesehen.
Die einfachste Möglichkeit, einem In-Memory-System Persistenz hinzuzufügen, sind periodische Snapshots auf der Festplatte in einem konfigurierbaren Intervall. So können Sie bis zu diesem Intervall im Wert von Updates verlieren.
Update-in-Place- und Commitlog-basierte Systeme werden sofort im nichtflüchtigen Speicher gespeichert, aber nur Commitlog-basierte Persistenz bietet Haltbarkeit – das D in ACID – mit jedem Schreibvorgang, der beibehalten wird, bevor der Erfolg an den Client zurückgegeben wird.
Cassandra implementiert ein Commit-Log-basiertes Persistenzdesign, bietet aber gleichzeitig abstimmbare Haltbarkeitsstufen. Auf diese Weise können Sie entscheiden, was der richtige Kompromiss zwischen Sicherheit und Leistung ist. Sie können für jeden Schreibvorgang auswählen, ob das Update in den Arbeitsspeicher gepuffert, auf einem einzelnen Computer auf die Festplatte geschrieben, auf mehreren Computern auf die Festplatte geschrieben oder sogar auf mehreren Computern in verschiedenen Rechenzentren auf die Festplatte geschrieben werden soll. Oder Sie können Schreibvorgänge so schnell wie möglich akzeptieren und deren Empfang unmittelbar bestätigen, bevor sie vollständig aus dem Netzwerk deserialisiert wurden.
Am Ende des Tages sind Sie der einzige, der weiß, was der richtige Kompromiss zwischen Leistung und Haltbarkeit für Ihre Daten ist. Eine fundierte Entscheidung über Datenspeichertechnologien zu treffen, ist entscheidend, um diesen Kompromiss zu Ihren Bedingungen anzugehen. Da Cassandra eine solche Abstimmbarkeit bietet, ist es eine logische Wahl für Systeme, die einen dauerhaften, performanten Datenspeicher benötigen.