Es wird gesagt, dass man im Leben alles mindestens einmal ausprobieren sollte. Wenn Sie an relationale Datenbanken gewöhnt sind, sollten Sie sich aus allgemeinem Interesse unbedingt praktisch mit NoSQL vertrautmachen. Angesichts der rasanten Entwicklung dieser Technologie gibt es zahlreiche kontroverse Meinungen und hitzige Debatten, die das Interesse an diesem Thema besonders anheizen.
Wenn man die Essenz all dieser Meinungsverschiedenheiten betrachtet, wird deutlich, dass sie auf falschen Ansätzen beruhen. Diejenigen, die NoSQL-Datenbanken dort einsetzen, wo sie sinnvoll sind, sind zufrieden und profitieren von den Vorteilen dieser Lösung. Die Experimentatoren, die auf diese Technologie als Allheilmittel setzen, wo sie überhaupt nicht anwendbar ist, erleben Enttäuschungen, verlieren die Stärken relationaler Datenbanken, ohne dabei nennenswerte Vorteile zu gewinnen.
Ich werde von unseren Erfahrungen bei der Implementierung einer auf der Cassandra-Datenbank basierenden Lösung berichten: mit welchen Herausforderungen wir konfrontiert waren, wie wir aus schwierigen Situationen herausgekommen sind, ob es uns gelungen ist, Vorteile aus der Nutzung von NoSQL zu ziehen und wo zusätzliche Anstrengungen/Mittel investiert werden mussten.
Die Ausgangsaufgabe besteht darin, ein System zu entwickeln, das Anrufe in einem bestimmten Speicher aufzeichnet.
Das Funktionsprinzip des Systems ist wie folgt. Es werden Dateien mit einer bestimmten Struktur eingelesen, die den Anruf beschreibt. Anschließend sorgt die Anwendung dafür, dass diese Struktur in die entsprechenden Spalten gespeichert wird. Die gespeicherten Anrufe werden dann verwendet, um Informationen über den Datenverbrauch der Benutzer anzuzeigen (Abrechnungen, Anrufe, Guthistorie).
Warum Cassandra gewählt wurde, ist verständlich – sie schreibt wie ein Maschinengewehr, ist leicht skalierbar und ausfallsicher.
Nun, das hat uns die Erfahrung gelehrt.
Ja, ein ausgefallener Knoten ist kein Drama. Das ist der Kern der Ausfallsicherheit von Cassandra. Aber ein Knoten kann zwar leben, aber trotzdem in der Leistung nachlassen.Wie sich herausstellte, wirkt sich das sofort auf die Leistung des gesamten Clusters aus.
Cassandra kann nicht dort absichern, wo Oracle mit seinen Constraints gerettet hat.Und wenn der Autor der Anwendung das im Voraus nicht verstanden hat, ist ein eingehender Duplikat für Cassandra nicht weniger gültig als das Original. Kommt es, wird es eingesetzt.
Die kostenlose Cassandra „out of the box“ gefiel der IT-Sicherheit plötzlich gar nicht. Es gibt kein Benutzungsprotokoll und keine Rechteverteilung.. Informationen zu Anrufen fallen unter personenbezogene Daten, was bedeutet, dass alle Versuche, diese in irgendeiner Weise anzufordern oder zu ändern, protokolliert werden müssen, um eine spätere Überprüfung zu ermöglichen. Zudem ist es notwendig, die Rechte auf verschiedene Ebenen für unterschiedliche Benutzer zu differenzieren. Ein einfacher Betriebstechniker und ein Superadmin, der das gesamte Keyspace problemlos löschen kann, sind unterschiedliche Rollen mit verschiedenen Verantwortlichkeiten und Kompetenzen. Ohne eine solche Trennung der Zugriffsrechte wird der Wert und die Integrität der Daten schneller in Frage gestellt, als es bei einem Konsistenzniveau von ANY der Fall wäre.
Wir haben nicht berücksichtigt, dass für Anrufe sowohl ernsthafte Analysen als auch regelmäßige Stichproben unter verschiedenen Bedingungen erforderlich sind. Da die ausgewählten Aufzeichnungen später gelöscht und überschrieben werden sollen (im Rahmen dieser Aufgabe müssen wir den Prozess der Aktualisierung von Daten unterstützen, wenn uns ursprünglich falsche Daten zugeführt wurden), ist Cassandra hier nicht unser Freund. Cassandra ist wie eine Sparkasse – man kann sie bequem füllen, aber man kann damit nicht zählen.
Haben Sie Probleme beim Übertragen von Daten in Testumgebungen? (5 Knoten im Test im Vergleich zu 20 in der Produktion). In diesem Fall kann das Dumpen nicht verwendet werden.
Problem mit den Aktualisierungen des Datenschemas der Anwendung, die in Cassandra schreibt. Ein Rollback kann zahlreiche Tombstones erzeugen, was auf unvorhersehbare Weise die Leistung beeinträchtigen kann.. Cassandra ist für das Schreiben optimiert und denkt vor dem Schreiben nicht viel nach. Jede Operation mit bestehenden Daten ist ebenfalls ein Schreibvorgang. Das heißt, wenn wir Überflüssiges löschen, erzeugen wir einfach noch mehr Schreibvorgänge, und nur ein Teil davon wird als Tombstone markiert.
Timeouts beim Einfügen. Cassandra ist beim Schreiben hervorragend, aber manchmal kann der eingehende Datenstrom erheblich verwirrend sein.. Dies geschieht, wenn die Anwendung anfängt, einige Datensätze im Kreis zu bearbeiten, die aus bestimmten Gründen nicht eingefügt werden können. Und wir benötigen einen echten DBA, der gc.log, System- und Debug-Logs auf langsame Abfragen und Metriken zu ausstehenden Kompaktierungen überwacht.
Mehrere Rechenzentren im Cluster. Woher lesen und wohin schreiben?
Kann man das Lesen und Schreiben möglicherweise trennen? Und wenn ja, sollte näher an der Anwendung der DC zum Schreiben oder zum Lesen sein? Und entsteht nicht ein echtes Split-Brain-Szenario, wenn wir die Konsistenzstufe falsch wählen? Es gibt viele Fragen und unerkundete Einstellungen sowie Möglichkeiten, die sehr verlockend sind.
Wie wir es gelöst haben
Um die Knotenschwankungen zu vermeiden, haben wir SWAP deaktiviert. Und nun sollte der Knoten bei Speichermangel ausfallen, anstatt große gc-Pausen zu erzeugen.
Wir setzen nicht mehr auf die Logik in der DB. Die Entwickler des Programms lernen um und beginnen aktiv, sich in ihrem eigenen Code abzusichern. Eine ideale klare Trennung von Speicherung und Verarbeitung von Daten.
Wir haben Unterstützung von DataStax erworben. Die Boxed Cassandra wird nicht mehr weiterentwickelt (letzter Commit im Februar 2018). Gleichzeitig bietet DataStax einen ausgezeichneten Service sowie eine Vielzahl an angepassten und überarbeiteten Lösungen für bestehende IT-Systeme.
Ich möchte auch darauf hinweisen, dass Cassandra nicht besonders benutzerfreundlich für Abfragen ist. Natürlich ist CQL ein großer Schritt in Richtung Benutzerfreundlichkeit (im Vergleich zu Trift). Wenn jedoch ganze Abteilungen daran gewöhnt sind, mit solchen bequemen Joins zu arbeiten, frei nach beliebigen Feldern filtern zu können und Optimierungsmöglichkeiten für Abfragen zu haben, erscheint ihnen eine Lösung mit Cassandra feindlich und unklug. Wir haben begonnen, zu klären, wie wir unseren Kollegen bei der Datenauswahl helfen können.
Wir haben zwei Optionen in Betracht gezogen. Bei der ersten Option schreiben wir die Aufrufe nicht nur in C*, sondern auch in die Archiv-Datenbank Oracle. Im Gegensatz zu C* enthält diese Datenbank jedoch nur die Aufrufe des aktuellen Monats (eine ausreichende Speicherdauer für die Tarifierungsfälle). Hierbei trat sofort folgendes Problem auf: Wenn wir synchron schreiben, verlieren wir alle Vorteile von C*, die mit der schnellen Einfügung verbunden sind; wenn wir asynchron arbeiten, gibt es keine Garantie, dass alle benötigten Aufrufe überhaupt in Oracle gelangen. Es gab jedoch einen großen Vorteil: Für den Betrieb bleibt der vertraute PL/SQL Developer, das heißt, wir können das Muster „Fassade“ praktisch umsetzen. Alternative Option: Wir implementieren einen Mechanismus, der die Aufrufe aus C* extrahiert, weitere Daten zur Anreicherung aus den entsprechenden Tabellen in Oracle abruft, die erhaltenen Abfragen zusammenführt und uns das Ergebnis liefert, das wir dann auf irgendeine Weise verwenden (rollbacken, wiederholen, analysieren, bewundern). Nachteile: Der Prozess ist ziemlich mehrstufig, außerdem fehlt eine Benutzeroberfläche für die Betriebstechnik.
Letztendlich haben wir uns doch für die zweite Option entschieden. Für Abfragen aus verschiedenen Quellbanken verwendeten wir Apache Spark. Der Mechanismus basiert auf Java-Code, der anhand der angegebenen Schlüssel (Abonnent, Zeitpunkt des Anrufs – Schlüssel des Abschnitts) Daten aus C* abruft sowie benötigte Informationen aus einer anderen Datenbank für die Anreicherung. Anschließend werden diese in seinem Speicher zusammengeführt und das Ergebnis in einer Ergebnistabelle ausgegeben. Über Spark wurde eine Weboberfläche erstellt, die sich als gut nutzbar herausgestellt hat.
Bei der Bewältigung der Datenaktualisierungsaufgabe hat das Team erneut mehrere Lösungsansätze in Betracht gezogen. Sowohl der Transfer über Sstloader als auch die Option, den Cluster in der Testumgebung in zwei Teile zu splitten, wobei jeder Teil abwechselnd in einen Cluster mit den Produktionsdaten eingebunden wird, um von dort zu speisen. Bei der Aktualisierung des Tests war geplant, die Teile zu tauschen: Der Teil, der im Test gearbeitet hat, wird bereinigt und in die Produktion überführt, während der andere separat mit den Daten arbeitet. Aber nach weiterer Überlegung haben wir die Daten, die es wert sind, übertragen zu werden, als wertvoller eingeschätzt und erkannt, dass die Aufrufe selbst eine inkonsistente Entität für Tests darstellen, die im Bedarfsfall schnell generiert werden. Der Produktionsdatensatz hat daher keinen Wert für den Transfer in den Test. Es gibt einige Speicherobjekte, die transferiert werden sollten, aber es sind wirklich nur ein paar Tabellen, die nicht allzu groß sind. Daher ist Spark erneut zur Lösung gekommen, mit dessen Hilfe wir ein Skript zum Transfer von Daten zwischen den Tabellen in der Produktions- und Testumgebung geschrieben und aktiv genutzt haben.
Unsere aktuelle Deployment-Politik ermöglicht es uns, ohne Rollbacks zu arbeiten. Vor der Promotion ist ein obligater Testlauf notwendig, bei dem Fehler weniger gravierend sind. Im Falle eines Misserfolgs kann der Case Space immer gelöscht und das gesamte Schema neu aufgesetzt werden.
Um eine durchgehende Verfügbarkeit von Cassandra zu gewährleisten, ist ein DBA erforderlich, und das ist noch nicht alles. Alle, die mit der Anwendung arbeiten, sollten verstehen, wo und wie sie die aktuelle Situation überprüfen und Probleme rechtzeitig diagnostizieren können. Dafür nutzen wir aktiv DataStax OpsCenter (Verwaltung und Überwachung der Workloads), systemmetriken des Cassandra Drivers (Anzahl der Schreib-Timeouts in C*, Anzahl der Lese-Timeouts aus C*, maximale Latenz usw.), und überwachen die Funktionalität der Anwendung, die mit Cassandra arbeitet.
Als wir über die vorherige Frage nachdachten, wurde uns klar, wo unser Haupt Risiko liegen könnte. Es sind die Datenanzeigeformate, die Informationen aus mehreren unabhängigen Anfragen an den Speicher abrufen. Dadurch können wir recht inkonsistente Informationen erhalten. Dieses Problem wäre jedoch ebenso relevant, wenn wir nur mit einem einzelnen Rechenzentrum arbeiten würden. Daher ist es in diesem Fall am sinnvollsten, eine Batch-Funktion für die Datenabfrage in einer externen Anwendung zu implementieren, die die Daten in einem einheitlichen Zeitrahmen bereitstellt. Was die Trennung von Lese- und Schreiboperationen hinsichtlich der Leistung betrifft, so wurde uns hier das Risiko bewusst, dass bei einem vorübergehenden Verbindungsverlust zwischen den Rechenzentren zwei völlig inkonsistente Cluster entstehen könnten.
Daher haben wir derzeit uns für den Konsistenzgrad FOR_WRITE EACH_QUORUM und für das Lesen LOCAL_QUORUM entschieden.
Kurze Eindrücke und Schlussfolgerungen
Um die entstandene Lösung hinsichtlich der Betriebskosten und der Perspektiven für die Weiterentwicklung zu bewerten, haben wir überlegt, wo wir eine solche Entwicklung noch anwenden könnten.
Wenn wir schnell darauf eingehen, bezieht sich das Scoring von Daten für Programme wie "Zahle, wenn es dir passt" (wir laden Informationen in S* hoch, Berechnungen erfolgen mit Spark-Skripten), auf die Erfassung von Reklamationen mit Aggregation nach Bereichen, Speicherung von Rollen und Berechnung mittels einer rollenspezifischen Zugriffsrechte-Matrix.
Wie wir sehen, ist das Repertoire breit und vielfältig. Wenn es um die Wahl zwischen Anhängern und Gegnern von NoSQL geht, schließen wir uns den Befürwortern an, da wir die Vorteile erfahren haben, genau dort, wo wir es erwartet haben.
Selbst die Cassandra-Variante "out of the box" ermöglicht eine horizontale Skalierung in Echtzeit und löst problemlos das Problem der Datenvergrößerung im System. Es ist uns gelungen, einen sehr stark belasteten Mechanismus zur Berechnung der Aggregate für Anrufe in einen eigenen Bereich auszulagern und zudem das Schema und die Logik der Anwendung zu trennen, wodurch wir von der schädlichen Praxis der Erstellung von benutzerdefinierten Jobs und Objekten in der Datenbank Abstand genommen haben. Wir haben die Möglichkeit erhalten, auszuwählen und zu konfigurieren, in welchen Rechenzentren wir Berechnungen durchführen und in welchen wir Daten speichern, und uns dadurch vor Ausfällen sowohl einzelner Knoten als auch des gesamten Rechenzentrums abgesichert.
Wenn wir unsere Architektur auf neue Projekte anwenden und bereits über erste Erfahrungen verfügen, sollten wir die oben beschriebenen Nuancen sofort berücksichtigen, um Fehler zu vermeiden und Schwierigkeiten, die von Anfang an nicht zu vermeiden waren, zu glätten.
Zum Beispiel Die Aktualisierungen von Cassandra rechtzeitig verfolgen, denn viele Probleme, die wir erfahren haben, waren bereits bekannt und wurden behoben.
Datenbank und Spark nicht auf denselben Knoten installieren (oder strikt nach der maximalen Ressourcennutzung trennen), da Spark mehr RAM verwenden kann als vorgesehen und wir schnell mit Problem Nummer 1 von unserer Liste konfrontiert werden.
Die Überwachung und das Betriebswissen bereits in der Testphase des Projekts ausbauen. Von Anfang an möglichst alle potenziellen Nutzer unserer Lösung berücksichtigen, denn davon wird letztendlich die Struktur der Datenbank abhängen.
Überprüfen Sie das entstehende Schema mehrmals auf mögliche Optimierungen. Identifizieren Sie, welche Felder serialisiert werden können. Verstehen Sie, welche zusätzlichen Tabellen erforderlich sind, um die Informationen korrekt und effizient zu erfassen und sie dann auf Anfrage bereitzustellen (unter der Annahme, dass dieselben Daten in verschiedenen Tabellen gespeichert werden können, wobei verschiedene Kriterien berücksichtigt werden, kann dies die CPU-Zeit für Leseanfragen erheblich einsparen).
Nicht schlecht Planen Sie sofort die Implementierung von TTL und die Bereinigung veralteter Daten ein.
Beim Export von Daten aus Cassandra sollte die Logik der Anwendung nach dem FETCH-Prinzip arbeiten, sodass nicht alle Zeilen auf einmal in den Speicher geladen werden, sondern in Chargen ausgewählt werden.
Es ist ratsam, vor der Umstellung des Projekts auf die beschriebene Lösung die Ausfallsicherheit des Systems zu überprüfen, indem eine Reihe von Stresstests durchgeführt werden., wie etwa Datenverluste in einem Rechenzentrum, die Wiederherstellung beschädigter Daten über einen bestimmten Zeitraum sowie Netzwerkprobleme zwischen den Rechenzentren. Solche Tests ermöglichen nicht nur eine Bewertung der Vor- und Nachteile der vorgeschlagenen Architektur, sondern bieten auch wertvolle praktische Erfahrungen für die Ingenieure, die sie durchführen. Die erlernten Fähigkeiten werden von unschätzbarem Wert sein, falls Systemausfälle in der Praxis eintreten.
Wenn wir mit sensibler Information arbeiten (wie etwa Daten für die Abrechnung oder die Berechnung von Kundenschulden), sollten wir auch den Tools Beachtung schenken, die das Risiko reduzieren, das aufgrund der Besonderheiten der Datenbankmanagementsysteme entsteht. Beispielsweise könnte die Nutzung des Tools nodesync (Datastax) in Erwägung gezogen werden, während wir eine optimale Strategie für dessen Verwendung entwickeln, um aus Gründen der Konsistenz keine übermäßige Last auf Cassandra zu erzeugen und es ausschließlich für bestimmte Tabellen zu bestimmten Zeiten zu verwenden.
Nun, nach einem halben Jahr mit Cassandra? Insgesamt gibt es keine ungelösten Probleme. Schwere Ausfälle und Datenverlust haben wir ebenfalls vermieden. Ja, wir mussten über Kompensationen für einige zuvor nicht aufgetretene Probleme nachdenken, aber letztendlich hat das unsere Architekturentscheidung nicht wesentlich getrübt. Wenn Sie bereit sind, etwas Neues auszuprobieren und nicht enttäuscht werden wollen, sollten Sie sich darauf einstellen, dass nichts umsonst ist. Sie werden mehr Zeit damit verbringen müssen, sich einzuarbeiten, die Dokumentation zu studieren und Ihre eigenen Hürden zu identifizieren als bei alten Legacy-Lösungen, und keine Theorie kann Ihnen im Voraus sagen, welche Hürden Sie konkret erwarten.
Quelle: habr.com
