Sie sagen, dass es im Leben alles wert ist, mindestens einmal versucht zu werden. Und wenn Sie es gewohnt sind, mit relationalen DBMS zu arbeiten, lohnt es sich, sich in der Praxis mit NoSQL vertraut zu machen, zumindest für die allgemeine Entwicklung. Aufgrund der rasanten Entwicklung dieser Technologie gibt es jetzt viele widersprüchliche Meinungen und hitzige Debatten zu diesem Thema, was besonders das Interesse weckt.
Wenn Sie sich mit dem Wesen all dieser Streitigkeiten befassen, können Sie sehen, dass sie aufgrund des falschen Ansatzes entstehen. Diejenigen, die NoSQL-Datenbanken genau dort verwenden, wo sie benötigt werden, sind zufrieden und profitieren von all diesen Vorteilen dieser Lösung. Experimentatoren, die sich auf diese Technologie als Allheilmittel verlassen, wenn sie überhaupt nicht anwendbar ist, sind enttäuscht, die Stärken relationaler Datenbanken zu verlieren, ohne wesentliche Vorteile zu erzielen.
Ich werde Ihnen über unsere Erfahrungen bei der Implementierung einer auf dem Cassandra DBMS basierenden Lösung berichten: Was wir zu bewältigen hatten, wie wir aus schwierigen Situationen herausgekommen sind, haben wir es geschafft, von NoSQL zu profitieren und wo mussten wir zusätzlichen Aufwand / Geld investieren.
Die erste Aufgabe besteht darin, ein System zu erstellen, das Aufrufe an einen bestimmten Speicher aufzeichnet.
Das Prinzip des Systems ist wie folgt. Dateien mit einer bestimmten Struktur, die die Struktur des Aufrufs beschreibt, kommen zur Eingabe. Anschließend stellt die Anwendung sicher, dass diese Struktur in den entsprechenden Spalten gespeichert wird. In Zukunft werden gespeicherte Anrufe verwendet, um Informationen zum Verkehrsverbrauch für Teilnehmer anzuzeigen (Gebühren, Anrufe, Kontostandverlauf).
Warum Kassandra ausgewählt wurde, ist verständlich - sie schreibt als Maschinengewehr, leicht skalierbar und fehlertolerant.
Hier ist also, was uns die Erfahrung gegeben hat
Ja, der abgestürzte Knoten ist keine Tragödie. Das ist die Essenz von Cassandras Fehlertoleranz. Der Knoten kann jedoch aktiv sein und gleichzeitig die Leistung beeinträchtigen . Wie sich herausstellte, wirkt sich dies sofort auf die Leistung des gesamten Clusters aus.
Cassandra sichert nicht ab, wo Oracle mit seinen Konstanten gespeichert hat . Und wenn der Autor des Antrags dies nicht im Voraus verstanden hat, ist die geflogene Einstellung für Cassandra nicht schlechter als das Original. Sobald er gekommen ist, werden wir es einfügen.
Die kostenlose Kassandra „out of the box“ mochte die Informationssicherheit nicht besonders: Es gibt keine Protokollierung von Benutzeraktionen und auch keine Differenzierung von Rechten . Informationen zu Anrufen beziehen sich auf personenbezogene Daten. Dies bedeutet, dass alle Versuche, diese in irgendeiner Weise anzufordern / zu ändern, mit der Möglichkeit einer anschließenden Prüfung protokolliert werden sollten. Außerdem müssen Sie sich der Notwendigkeit bewusst sein, Rechte auf verschiedenen Ebenen für verschiedene Benutzer zu trennen. Ein einfacher Betriebsingenieur und ein Superadministrator, der den gesamten Schlüsselbereich frei entfernen kann, haben unterschiedliche Rollen, unterschiedliche Verantwortlichkeiten und Kompetenzen. Ohne eine solche Differenzierung der Zugriffsrechte werden der Wert und die Integrität der Daten sofort schneller in Frage gestellt als mit JEDER Konsistenzstufe.
Wir haben nicht berücksichtigt, dass Anrufe ernsthafte Analysen sowie regelmäßige Stichproben für eine Vielzahl von Bedingungen erfordern. Da die ausgewählten Datensätze dann gelöscht und neu geschrieben werden sollen (im Rahmen der Aufgabe müssen wir den Prozess der Aktualisierung der Daten unterstützen, wenn die Datenschleife ursprünglich falsch eingegeben wurde), ist Kassandra hier nicht unsere Freundin. Cassandra lässt sich wie ein Sparschwein bequem hineinstecken, aber Sie können nicht damit rechnen.
Konfrontiert mit dem Problem der Übertragung von Daten in Testzonen (5 Knoten im Test gegenüber 20 im Abschlussball). In diesem Fall kann kein Speicherauszug verwendet werden.
Das Problem der Aktualisierung des Datenschemas einer Anwendung, die in Kassandra schreibt. Durch das Rollback entstehen sehr viele Grabsteine, die auf unvorhersehbare Weise unsere Produktivität senken können . Cassandra ist für die Aufnahme optimiert und denkt vor der Aufnahme nicht viel nach. Jede Operation mit vorhandenen Daten ist ebenfalls ein Datensatz. Das heißt, nachdem wir den Überschuss entfernt haben, erzeugen wir einfach noch mehr Datensätze, und nur ein Teil davon wird mit Grabsteinen markiert.
Zeitüberschreitungen beim Einfügen. Cassandra ist wunderschön in der Aufnahme, aber manchmal kann der eingehende Stream für sie sehr verwirrend sein . Dies geschieht, wenn die Anwendung mehrere Datensätze umkreist, die aus irgendeinem Grund nicht eingefügt werden können. Und wir brauchen einen echten DBA, der gc.log-, System- und Debug-Protokollen für langsame Abfragen und Metriken für die anstehende Komprimierung folgt.
Mehrere Rechenzentren in einem Cluster. Wo lesen und wo schreiben?
Vielleicht in Lesen und Schreiben unterteilt? Und wenn ja, sollte es einen DC zum Schreiben oder Lesen in der Nähe der Anwendung geben? Und werden wir nicht ein wirklich gespaltenes Gehirn bekommen, wenn wir den Grad der Konsistenz falsch wählen? Viele Fragen, viele unerforschte Einstellungen, Funktionen, die ich wirklich verdrehen möchte.
Wie haben wir uns entschieden?
Dass der Knoten nicht verschwendet hat, hat SWAP deaktiviert . Und jetzt, wo es an Speicher mangelt, muss sich der Knoten hinlegen und darf keine großen GC-Pausen erzeugen.
Wir hoffen also nicht mehr auf Logik in der Datenbank. Anwendungsentwickler lernen neu und beginnen, in ihrem eigenen Code aktiv Sicherheit zu schaffen. Perfekte klare Trennung von Datenspeicherung und -verarbeitung.
Wir haben Support von DataStax gekauft. Die Boxed Kassandra hat bereits ihre Entwicklung eingestellt (das letzte Commit im Februar 2018). Gleichzeitig bietet Datastax exzellenten Service und eine Vielzahl modifizierter und an vorhandene IC-Lösungen angepasster Lösungen.
Ich möchte auch darauf hinweisen, dass Kassandra für die Abfrage von Proben nicht sehr praktisch ist. Natürlich ist CQL ein großer Schritt in Richtung Benutzer (im Vergleich zu Trift). Wenn Sie jedoch ganze Abteilungen haben, die an solche bequemen Verknüpfungen gewöhnt sind, kostenlos nach Feld- und Abfrageoptimierungsoptionen filtern und diese Abteilungen daran arbeiten, Ansprüche und Unfälle zu schließen, scheint ihm die Entscheidung für Kassandra feindlich und dumm zu sein. Und wir begannen uns mit der Frage zu befassen, wie unsere Kollegen Proben herstellen können.
Wir haben zwei Optionen in Betracht gezogen. Bei der ersten Option schreiben wir Aufrufe nicht nur in C *, sondern auch in die Oracle-Archivdatenbank. Im Gegensatz zu C * werden Anrufe nur für den aktuellen Monat in dieser Datenbank gespeichert (ausreichende Anrufspeichertiefe für Fälle von erneuter Zertifizierung). Hier haben wir sofort das folgende Problem gesehen: Wenn Sie synchron schreiben, verlieren wir alle Vorteile von C *, die mit dem schnellen Einfügen verbunden sind. Wenn asynchron, gibt es keine Garantie dafür, dass alle erforderlichen Aufrufe im Allgemeinen Oracle treffen. Es gab ein Plus, aber ein großes: Für die Nutzung bleibt derselbe bekannte PL / SQL-Entwickler übrig, dh wir implementieren praktisch das Muster „Fassade“. Eine alternative Option. Wir implementieren einen Mechanismus, der Aufrufe von C * entlädt, einige Daten zur Anreicherung aus den entsprechenden Tabellen in Oracle abruft, die empfangenen Samples zusammenfügt und uns das Ergebnis liefert, das wir dann irgendwie verwenden (Rollbacks, Wiederholungen, Analysen, Bewunderungen). Nachteile: Der Prozess ist ziemlich mehrstufig und außerdem gibt es keine Schnittstelle für das Bedienpersonal.
Infolgedessen haben wir uns immer noch für die zweite Option entschieden. Apache Spark wurde für Proben aus verschiedenen Dosen verwendet. Die Essenz des Mechanismus beruhte auf dem Java-Code, der mit den angegebenen Schlüsseln (Teilnehmer, Anrufzeit - Abschnittsschlüssel) Daten aus C * sowie die für die Anreicherung erforderlichen Daten aus einer anderen Datenbank abruft. Dann verbindet es sie in seinem Speicher und zeigt das Ergebnis in der resultierenden Tabelle an. Über den Funken wurde eine Netzmündung gezogen, die sich als recht brauchbar herausstellte.
Bei der Lösung eines Problems mit der Aktualisierung von Daten wurden in einem Promo-Test erneut mehrere Lösungen untersucht. Sowohl die Übertragung durch Sstloader als auch die Option, den Cluster in der Testzone in zwei Teile zu unterteilen, von denen jeder abwechselnd in denselben Cluster wie der Promo-Cluster eingeht und somit von diesem mit Strom versorgt wird. Bei der Aktualisierung des Tests war geplant, die Position zu ändern: Der Teil, der im Test gearbeitet hat, wird gelöscht und in den Abschlussball eingegeben, und der andere Teil beginnt separat mit den Daten zu arbeiten. Wenn wir jedoch noch einmal darüber nachdenken, haben wir die zu übertragenden Daten rationaler bewertet und festgestellt, dass die Aufrufe selbst eine inkonsistente Einheit für Tests sind, die bei Bedarf schnell generiert werden, und dass es sich um den Promo-Datensatz handelt, der es nicht wert ist, auf den Test übertragen zu werden. Es gibt mehrere Speicherobjekte, die es wert sind, verschoben zu werden, aber dies sind buchstäblich ein paar Tische und keine sehr schweren. Daher kam Spark uns erneut als Lösung zu Hilfe, mit deren Hilfe wir die Datenübertragung zwischen Tabellen-Prom-Test-Skripten geschrieben und aktiv genutzt haben.
Unsere aktuelle Bereitstellungsrichtlinie ermöglicht es uns, ohne Rückschläge zu arbeiten. Vor dem Abschlussball gibt es einen obligatorischen Rollover zum Test, bei dem der Fehler nicht so teuer ist. Im Fehlerfall können Sie den Fallbereich jederzeit löschen und das gesamte Schema von Anfang an rollen.
Um die kontinuierliche Verfügbarkeit von Cassandra sicherzustellen, benötigen Sie dba und nicht nur diese. Jeder, der mit der Anwendung arbeitet, sollte verstehen, wo und wie er die aktuelle Situation betrachten und Probleme rechtzeitig diagnostizieren kann. Zu diesem Zweck verwenden wir aktiv DataStax OpsCenter (Verwaltung und Überwachung von Workloads), Cassandra Driver-Systemmetriken (Anzahl der Zeitüberschreitungen beim Schreiben in C *, Anzahl der Zeitüberschreitungen beim Lesen aus C *, maximale Latenz usw.), Überwachung die Arbeit der Anwendung selbst, in Zusammenarbeit mit Kassandra.
Als wir über die vorherige Frage nachdachten, stellten wir fest, wo unser Hauptrisiko liegen könnte. Hierbei handelt es sich um Datenanzeigeformulare, die Daten von mehreren voneinander unabhängigen Speicheranforderungen ausgeben. Auf diese Weise können wir ziemlich inkonsistente Informationen erhalten. Dieses Problem wäre jedoch genauso relevant, wenn wir nur mit einem Rechenzentrum arbeiten würden. Das Vernünftigste dabei ist natürlich, die Batch-Funktion zum Lesen von Daten in einer Drittanbieteranwendung auszuführen, um sicherzustellen, dass die Daten in einem einzigen Zeitraum empfangen werden. Was die Trennung von Lesen und Schreiben in Bezug auf die Leistung betrifft, wurden wir hier durch das Risiko gestoppt, dass wir mit einem gewissen Verbindungsverlust zwischen DCs zwei völlig inkonsistente Cluster erhalten können.
Infolgedessen haben wir im Moment die Konsistenzstufe für den Datensatz EACH_QUORUM angehalten, um - LOCAL_QUORUM zu lesen
Kurze Eindrücke und Schlussfolgerungen
Um die resultierende Lösung unter dem Gesichtspunkt der operativen Unterstützung und der Aussichten für eine weitere Entwicklung zu bewerten, haben wir uns entschlossen, darüber nachzudenken, wo eine solche Entwicklung sonst noch angewendet werden könnte.
Wenn Sie unterwegs sind, können Sie Daten für Programme wie „Bezahlen, wenn es Ihnen passt“ bewerten (C * -Informationen laden, Berechnung mithilfe von Spark-Skripten), Ansprüche mit Aggregation nach Anweisungen abrechnen, Rollen speichern und Benutzerzugriffsrechte mithilfe der Rollenmatrix berechnen.
Wie Sie sehen, ist das Repertoire breit und vielfältig. Und wenn wir das Lager der Unterstützer / Gegner von NoSQL wählen, werden wir uns den Unterstützern anschließen, da wir unsere Pluspunkte haben und genau dort, wo wir es erwartet haben.
Selbst die sofort einsatzbereite Cassandra-Option ermöglicht eine horizontale Skalierung in Echtzeit und löst so schmerzlos das Problem der Datenerhöhung im System. Es ist uns gelungen, einen sehr hoch aufgeladenen Mechanismus zur Berechnung von Aggregaten für Aufrufe in einen separaten Schaltkreis zu integrieren und das Schema und die Logik der Anwendung zu trennen, um die bösartige Praxis des Schreibens benutzerdefinierter Jobs und Objekte in die Datenbank selbst zu beseitigen. Wir hatten die Möglichkeit zu wählen und zu konfigurieren, um zu beschleunigen, auf welchen DCs wir berechnen und auf welchen Datensätzen wir uns für die Ausfälle sowohl einzelner Knoten als auch des gesamten DC versichern.
Wenn ich unsere Architektur auf neue Projekte anwende und bereits Erfahrung habe, möchte ich die oben beschriebenen Nuancen sofort berücksichtigen und einige Fehler vermeiden sowie einige scharfe Ecken glätten, die anfangs nicht vermieden werden konnten.
Behalten Sie beispielsweise die Aktualisierungen von Cassandra rechtzeitig im Auge , da einige Probleme, die wir erhalten haben, bereits bekannt und behoben waren.
Platzieren Sie die Datenbank selbst und Spark nicht auf denselben Knoten (oder teilen Sie sie streng durch die Menge der akzeptablen Ressourcennutzung), da Spark mehr als das erwartete OP essen kann und wir Problem Nummer 1 schnell von unserer Liste erhalten.
Pumpenüberwachung und Betriebskompetenz in der Phase der Projektprüfung. Berücksichtigen Sie zunächst das Maximum aller potenziellen Verbraucher unserer Lösung , da die Datenbankstruktur letztendlich davon abhängt.
Drehen Sie die resultierende Schaltung mehrmals, um eine mögliche Optimierung zu erreichen. Wählen Sie aus, welche Felder serialisiert werden können. Wenn Sie verstehen, welche zusätzlichen Tabellen wir tun können, um die korrektesten und optimalsten zu berücksichtigen, und dann auf Anfrage die erforderlichen Informationen zurückgeben (z. B. unter der Annahme, dass wir dieselben Daten in verschiedenen Tabellen speichern können, wobei unterschiedliche Aufschlüsselungen nach unterschiedlichen Kriterien berücksichtigt werden, können erhebliche Einsparungen erzielt werden Prozessorzeit für Leseanforderungen).
Es ist eine gute Idee, TTL sofort bereitzustellen und veraltete Daten zu bereinigen.
Beim Entladen von Daten aus Cassandra sollte die Anwendungslogik nach dem FETCH-Prinzip funktionieren, damit nicht alle Zeilen gleichzeitig in den Speicher geladen, sondern stapelweise ausgewählt werden.
Bevor Sie das Projekt auf die beschriebene Lösung übertragen, sollten Sie die Systemfehlertoleranz überprüfen, indem Sie eine Reihe von Crashtests durchführen , z. B. Datenverlust in einem Rechenzentrum, Wiederherstellung beschädigter Daten für einen bestimmten Zeitraum und Netzwerkausfall zwischen Rechenzentren. Mit solchen Tests können Sie nicht nur die Vor- und Nachteile der vorgeschlagenen Architektur beurteilen, sondern auch den Ingenieuren, die sie durchführen, eine gute Aufwärmpraxis bieten. Die erworbenen Fähigkeiten sind keineswegs überflüssig, wenn die Systemfehler im Abschlussball reproduziert werden.
Wenn wir mit kritischen Informationen arbeiten (z. B. Abrechnungsdaten, Berechnung der Abonnentenschulden), sollten auch Tools berücksichtigt werden, mit denen die Risiken verringert werden, die aufgrund der Merkmale des DBMS entstehen. Verwenden Sie beispielsweise das Dienstprogramm nodeync (Datastax), das eine optimale Strategie für seine Verwendung entwickelt hat, damit Cassandra aus Gründen der Konsistenz nicht übermäßig belastet wird und nur für bestimmte Tabellen in einem bestimmten Zeitraum verwendet wird.
Nun, nach sechs Monaten mit Cassandra? Im Allgemeinen gibt es keine ungelösten Probleme. Schwere Unfälle und Datenverlust haben wir auch nicht zugelassen. Ja, ich musste darüber nachdenken, einige Probleme zu kompensieren, die zuvor nicht aufgetreten waren, aber am Ende hat es unsere architektonische Lösung nicht überschattet. Wenn Sie wollen und keine Angst haben, etwas Neues auszuprobieren, und gleichzeitig nicht sehr enttäuscht sein wollen, dann machen Sie sich bereit für die Tatsache, dass nichts umsonst passiert. Sie müssen herausfinden, in der Dokumentation stöbern und Ihren individuellen Rechen sammeln als in der alten Legacy-Lösung, und keine Theorie wird Ihnen im Voraus genau sagen, welcher Rechen auf Sie wartet.