Man sagt, dass es sich lohnt, alles im Leben mindestens einmal auszuprobieren. Und wenn Sie es gewohnt sind, mit relationalen DBMS zu arbeiten, dann lohnt es sich, sich zumindest für die allgemeine Entwicklung zunächst in der Praxis mit NoSQL vertraut zu machen. Aufgrund der rasanten Entwicklung dieser Technologie gibt es mittlerweile viele widersprüchliche Meinungen und hitzige Debatten zu diesem Thema, was das Interesse besonders steigert.
Wenn Sie sich mit dem Wesen all dieser Streitigkeiten befassen, können Sie erkennen, dass sie auf eine falsche Herangehensweise zurückzuführen sind. Wer NoSQL-Datenbanken genau dort einsetzt, wo sie benötigt werden, ist zufrieden und erhält alle Vorteile dieser Lösung. Und Experimentatoren, die sich auf diese Technologie als Allheilmittel verlassen, wenn sie überhaupt nicht anwendbar ist, werden enttäuscht, da sie die Stärken relationaler Datenbanken verloren haben, ohne nennenswerte Vorteile zu erzielen.
Ich erzähle Ihnen von unseren Erfahrungen bei der Implementierung einer Lösung auf Basis des Cassandra DBMS: Was mussten wir bewältigen, wie wir aus schwierigen Situationen herauskamen, ob wir von der Verwendung von NoSQL profitieren konnten und wo wir zusätzliche Anstrengungen/Mittel investieren mussten .
Die erste Aufgabe besteht darin, ein System aufzubauen, das Anrufe in einer Art Speicher aufzeichnet.
Das Funktionsprinzip des Systems ist wie folgt. Die Eingabe umfasst Dateien mit einer bestimmten Struktur, die die Struktur des Anrufs beschreibt. Die Anwendung sorgt dann dafür, dass diese Struktur in den entsprechenden Spalten gespeichert wird. Zukünftig werden die gespeicherten Anrufe verwendet, um Informationen zum Verkehrsverbrauch für Teilnehmer anzuzeigen (Gebühren, Anrufe, Kontostandverlauf).
Es ist ziemlich klar, warum sie sich für Cassandra entschieden haben – sie schreibt wie ein Maschinengewehr, ist leicht skalierbar und fehlertolerant.
Das ist es also, was uns die Erfahrung gegeben hat
Ja, ein ausgefallener Knoten ist keine Tragödie. Dies ist die Essenz der Fehlertoleranz von Cassandra. Aber Ein Knoten kann aktiv sein und gleichzeitig an Leistung verlieren. Wie sich herausstellte, wirkt sich dies unmittelbar auf die Leistung des gesamten Clusters aus.
Cassandra wird Sie nicht dort schützen, wo Oracle Sie mit seinen Einschränkungen gerettet hat. Und wenn der Autor des Antrags dies im Voraus nicht verstanden hat, ist das für Cassandra angekommene Double nicht schlechter als das Original. Sobald es angekommen ist, legen wir es ein.
IB mochte die kostenlose Version von Cassandra überhaupt nicht: Es erfolgt keine Protokollierung von Benutzeraktionen, keine Differenzierung der Rechte. Informationen über Anrufe gelten als personenbezogene Daten, was bedeutet, dass alle Versuche, diese in irgendeiner Weise anzufordern/zu ändern, mit der Möglichkeit einer späteren Prüfung protokolliert werden müssen. Außerdem müssen Sie sich der Notwendigkeit bewusst sein, die Rechte für verschiedene Benutzer auf verschiedenen Ebenen zu trennen. Ein einfacher Betriebsingenieur und ein Superadministrator, der den gesamten Schlüsselraum frei löschen kann, sind unterschiedliche Rollen, unterschiedliche Verantwortlichkeiten und Kompetenzen. Ohne eine solche Differenzierung der Zugriffsrechte geraten der Wert und die Integrität der Daten sofort schneller in Frage als bei der ANY-Konsistenzstufe.
Wir haben nicht berücksichtigt, dass Anrufe sowohl ernsthafte Analysen als auch regelmäßige Probenentnahmen für eine Vielzahl von Erkrankungen 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 Datenaktualisierung unterstützen, wenn die Daten zunächst falsch in unsere Schleife gelangten), ist Cassandra hier nicht unsere Freundin. Cassandra ist wie ein Sparschwein – es ist bequem, Dinge hineinzulegen, aber man kann nicht darin zählen.
Beim Übertragen von Daten in Testzonen ist ein Problem aufgetreten (5 Knoten im Test gegenüber 20 im Abschlussball). In diesem Fall kann der Dump nicht verwendet werden.
Das Problem beim Aktualisieren des Datenschemas einer Anwendung, die in Cassandra schreibt. Bei einem Rollback werden sehr viele Tombstones generiert, was auf unvorhersehbare Weise zu Produktivitätsverlusten führen kann.. Cassandra ist für die Aufnahme optimiert und denkt vor dem Schreiben nicht viel nach. Jeder Vorgang mit vorhandenen Daten ist ebenfalls eine Aufnahme. Das heißt, durch das Löschen des Unnötigen werden wir einfach noch mehr Datensätze erstellen und nur einige davon werden mit Grabsteinen gekennzeichnet.
Timeouts beim Einfügen. Cassandra ist in der Aufnahme wunderschön, aber Manchmal kann der eingehende Strom sie erheblich verwirren. Dies geschieht, wenn die Anwendung beginnt, mehrere Datensätze zu durchlaufen, die aus irgendeinem Grund nicht eingefügt werden können. Und wir brauchen einen echten DBA, der gc.log, System- und Debug-Protokolle auf langsame Abfragen und ausstehende Komprimierungsmetriken überwacht.
Mehrere Rechenzentren in einem Cluster. Wo kann man lesen und wo schreiben?
Vielleicht aufgeteilt in Lesen und Schreiben? Und wenn ja, sollte es einen DC geben, der näher an der Anwendung zum Schreiben oder Lesen liegt? Und kommt es dann nicht zu einer echten Spaltung des Gehirns, wenn wir den falschen Konsistenzgrad wählen? Es gibt viele Fragen, viele unbekannte Einstellungen, Möglichkeiten, an denen man unbedingt herumbasteln möchte.
Wie wir uns entschieden haben
Um zu verhindern, dass der Knoten absinkt, wurde SWAP deaktiviert. Und jetzt, wenn es an Speicher mangelt, sollte der Knoten ausfallen und keine großen GC-Pausen erzeugen.
Wir verlassen uns also nicht mehr auf die Logik in der Datenbank. Anwendungsentwickler schulen sich neu und beginnen, aktiv Vorkehrungen in ihrem eigenen Code zu treffen. Ideale klare Trennung von Datenspeicherung und -verarbeitung.
Wir haben Support von DataStax erworben. Die Entwicklung von Boxed Cassandra wurde bereits eingestellt (der letzte Commit erfolgte im Februar 2018). Gleichzeitig bietet Datastax exzellenten Service und eine Vielzahl modifizierter und angepasster Lösungen für bestehende IP-Lösungen.
Ich möchte auch darauf hinweisen, dass Cassandra für Auswahlabfragen nicht sehr praktisch ist. Natürlich ist CQL ein großer Fortschritt für Benutzer (im Vergleich zu Trift). Aber wenn Sie ganze Abteilungen haben, die an solche praktischen Verknüpfungen, kostenlose Filterung nach beliebigen Feldern und Funktionen zur Abfrageoptimierung gewöhnt sind, und diese Abteilungen daran arbeiten, Beschwerden und Unfälle zu lösen, dann erscheint ihnen die Lösung auf Cassandra feindselig und dumm. Und wir begannen zu entscheiden, wie unsere Kollegen Proben herstellen sollten.
Wir haben zwei Optionen in Betracht gezogen. Bei der ersten Option schreiben wir Aufrufe nicht nur in C*, sondern auch in die archivierte Oracle-Datenbank. Nur speichert diese Datenbank im Gegensatz zu C* Anrufe nur für den aktuellen Monat (ausreichende Anrufspeichertiefe zum Nachladen von Fällen). Hier sahen wir sofort folgendes Problem: Wenn wir synchron schreiben, verlieren wir alle Vorteile von C*, die mit der schnellen Einfügung verbunden sind; wenn wir asynchron schreiben, gibt es keine Garantie dafür, dass alle notwendigen Aufrufe überhaupt in Oracle angekommen sind. Es gab ein Plus, aber ein großes: Für die Bedienung bleibt der gewohnte PL/SQL Developer bestehen, d. h. wir setzen praktisch das „Facade“-Muster um. Eine alternative Möglichkeit. Wir implementieren einen Mechanismus, der Aufrufe von C* entlädt, einige Daten zur Anreicherung aus den entsprechenden Tabellen in Oracle abruft, die resultierenden Beispiele zusammenfügt und uns das Ergebnis liefert, das wir dann irgendwie verwenden (Rollback, Wiederholen, Analysieren, Bewundern). Nachteile: Der Prozess ist recht mehrstufig und außerdem gibt es keine Schnittstelle für Betriebsmitarbeiter.
Am Ende haben wir uns für die zweite Option entschieden. Apache Spark wurde verwendet, um Proben aus verschiedenen Gläsern zu entnehmen. Das Wesentliche des Mechanismus wurde auf Java-Code reduziert, der mithilfe der angegebenen Schlüssel (Abonnent, Zeitpunkt des Anrufs – Abschnittsschlüssel) Daten aus C* sowie die für die Anreicherung erforderlichen Daten aus jeder anderen Datenbank abruft. Anschließend fügt es sie in seinem Speicher zusammen und zeigt das Ergebnis in der resultierenden Tabelle an. Wir haben ein Netzgesicht über den Funken gezeichnet und es hat sich als recht brauchbar herausgestellt.
Bei der Lösung des Problems der Aktualisierung industrieller Testdaten haben wir erneut mehrere Lösungen in Betracht gezogen. Sowohl die Übertragung per Sstloader als auch die Möglichkeit, den Cluster in der Testzone in zwei Teile aufzuteilen, die jeweils abwechselnd zum gleichen Cluster wie der Werbe-Cluster gehören und somit von diesem mit Strom versorgt werden. Bei der Aktualisierung des Tests war geplant, sie auszutauschen: Der Teil, der im Test funktioniert hat, wird freigegeben und in die Produktion übernommen, und der andere Teil beginnt separat mit den Daten zu arbeiten. Nachdem wir jedoch noch einmal darüber nachgedacht hatten, beurteilten wir die Daten, die es wert waren, übertragen zu werden, rationaler und stellten fest, dass die Anrufe selbst eine inkonsistente Einheit für Tests sind, die bei Bedarf schnell generiert werden, und dass es sich um den Werbedatensatz handelt, der keinen Wert für die Übertragung hat prüfen. Es gibt mehrere Aufbewahrungsobjekte, die einen Umzug wert sind, aber es handelt sich im wahrsten Sinne des Wortes um ein paar Tische, und zwar nicht sehr schwere. Deshalb wir Als Lösung kam erneut Spark zur Rettung, mit dessen Hilfe wir ein Skript zum Übertragen von Daten zwischen Tabellen, Prom-Test, geschrieben und aktiv zu verwenden begannen.
Unsere aktuelle Bereitstellungsrichtlinie ermöglicht es uns, ohne Rollbacks zu arbeiten. Vor der Promo gibt es einen obligatorischen Testlauf, bei dem ein Fehler nicht so teuer ist. Im Falle eines Fehlers können Sie den Casespace jederzeit löschen und das gesamte Schema von vorne beginnen.
Um die kontinuierliche Verfügbarkeit von Cassandra sicherzustellen, benötigen Sie einen DBA und nicht nur ihn. Jeder, der mit der Anwendung arbeitet, muss verstehen, wo und wie er die aktuelle Situation betrachten und Probleme rechtzeitig diagnostizieren kann. Zu diesem Zweck nutzen wir aktiv DataStax OpsCenter (Verwaltung und Überwachung von Arbeitslasten), Cassandra Driver-Systemmetriken (Anzahl der Zeitüberschreitungen beim Schreiben in C*, Anzahl der Zeitüberschreitungen beim Lesen von C*, maximale Latenz usw.) und überwachen den Vorgang der Anwendung selbst, die Arbeit mit Cassandra.
Als wir über die vorherige Frage nachdachten, wurde uns klar, wo unser Hauptrisiko liegen könnte. Hierbei handelt es sich um Datenanzeigeformulare, die Daten aus mehreren unabhängigen Abfragen an den Speicher anzeigen. Auf diese Weise können wir recht inkonsistente Informationen erhalten. Dieses Problem wäre jedoch genauso relevant, wenn wir nur mit einem Rechenzentrum arbeiten würden. Daher ist es hier natürlich am sinnvollsten, eine Batch-Funktion zum Lesen von Daten in einer Drittanbieteranwendung zu erstellen, die sicherstellt, dass die Daten in einem einzigen Zeitraum empfangen werden. Was die Aufteilung in Lesen und Schreiben im Hinblick auf die Leistung betrifft, so wurden wir hier durch das Risiko gestoppt, dass wir bei einem gewissen Verbindungsverlust zwischen den DCs zwei Cluster erhalten könnten, die völlig inkonsistent miteinander sind.
Als Ergebnis vorerst gestoppt auf der Konsistenzebene zum Schreiben EACH_QUORUM, zum Lesen - LOCAL_QUORUM
Kurze Eindrücke und Schlussfolgerungen
Um die resultierende Lösung unter dem Gesichtspunkt der Betriebsunterstützung und der Aussichten für eine weitere Entwicklung zu bewerten, haben wir beschlossen, darüber nachzudenken, wo eine solche Entwicklung sonst noch angewendet werden könnte.
Direkt dann Datenbewertung für Programme wie „Pay when it’s bequem“ (wir laden Informationen in C*, Berechnung mit Spark-Skripten), Abrechnung von Ansprüchen mit Aggregation nach Bereich, Speicherung von Rollen und Berechnung von Benutzerzugriffsrechten basierend auf der Rolle Matrix.
Wie Sie sehen, ist das Repertoire breit und vielfältig. Und wenn wir uns für das Lager der Befürworter/Gegner von NoSQL entscheiden, dann werden wir uns den Befürwortern anschließen, da wir unsere Vorteile erhalten haben, und zwar genau dort, wo wir es erwartet hatten.
Sogar die standardmäßige Cassandra-Option ermöglicht eine horizontale Skalierung in Echtzeit und löst so das Problem der zunehmenden Datenmenge im System absolut schmerzlos. Wir konnten einen sehr hochlastigen Mechanismus zur Berechnung von Aufrufaggregaten in einen separaten Schaltkreis verlagern und auch das Anwendungsschema und die Logik trennen, wodurch die schlechte Praxis, benutzerdefinierte Jobs und Objekte in die Datenbank selbst zu schreiben, entfällt. Wir hatten die Möglichkeit, auszuwählen und zu konfigurieren, auf welchen DCs wir Berechnungen durchführen und auf welchen wir Daten aufzeichnen, um die Geschwindigkeit zu erhöhen. Wir haben uns gegen Abstürze sowohl einzelner Knoten als auch des DC als Ganzes versichert.
Da ich unsere Architektur auf neue Projekte anwende und bereits über einige Erfahrungen verfüge, möchte ich die oben beschriebenen Nuancen sofort berücksichtigen, einige Fehler verhindern und einige scharfe Ecken glätten, die zunächst nicht vermieden werden konnten.
Zum Beispiel kann die Verfolgen Sie Cassandras Updates rechtzeitigdenn viele der Probleme, die wir bekamen, waren bereits bekannt und behoben.
Platzieren Sie die Datenbank selbst und Spark nicht auf denselben Knoten (oder strikt durch die Menge der zulässigen Ressourcennutzung dividieren), da Spark mehr OP fressen kann als erwartet, und wir schnell Problem Nummer 1 von unserer Liste streichen.
Verbessern Sie die Überwachungs- und Betriebskompetenz in der Projekttestphase. Berücksichtigen Sie zunächst so weit wie möglich alle potenziellen Verbraucher unserer Lösung, denn davon hängt letztendlich die Datenbankstruktur ab.
Drehen Sie den resultierenden Schaltkreis zur möglichen Optimierung mehrmals. Wählen Sie aus, welche Felder serialisiert werden können. Verstehen Sie, welche zusätzlichen Tabellen wir erstellen sollten, um sie am korrektesten und optimalsten zu berücksichtigen, und stellen Sie dann auf Anfrage die erforderlichen Informationen bereit (z. B. indem wir davon ausgehen, dass wir dieselben Daten in verschiedenen Tabellen speichern können, wobei unterschiedliche Aufschlüsselungen entsprechend berücksichtigt werden). Durch verschiedene Kriterien können wir bei Leseanfragen deutlich CPU-Zeit einsparen.
Nicht schlecht Sorgen Sie sofort für das Anhängen von TTL und das Bereinigen veralteter Daten.
Beim Herunterladen von Daten von Cassandra Die Anwendungslogik sollte nach dem FETCH-Prinzip funktionieren, sodass nicht alle Zeilen auf einmal in den Speicher geladen werden, sondern stapelweise ausgewählt werden.
Es empfiehlt sich, vor der Überführung des Projektes auf die beschriebene Lösung umzusteigen Überprüfen Sie die Fehlertoleranz des Systems, indem Sie eine Reihe von Crashtests durchführenB. Datenverlust in einem Rechenzentrum, Wiederherstellung beschädigter Daten über einen bestimmten Zeitraum, Netzwerkausfall zwischen Rechenzentren. Solche Tests ermöglichen nicht nur die Bewertung der Vor- und Nachteile der vorgeschlagenen Architektur, sondern bieten den Ingenieuren, die sie durchführen, auch eine gute Aufwärmübung, und die erworbenen Fähigkeiten werden keineswegs überflüssig sein, wenn Systemausfälle in der Produktion reproduziert werden.
Wenn wir mit kritischen Informationen arbeiten (z. B. Abrechnungsdaten, Berechnung der Abonnentenschulden), lohnt es sich auch, auf Tools zu achten, die die Risiken reduzieren, die sich aus den Funktionen des DBMS ergeben. Verwenden Sie beispielsweise das Nodesync-Dienstprogramm (Datastax), nachdem Sie eine optimale Strategie für dessen Verwendung entwickelt haben Aus Gründen der Konsistenz sollten Sie Cassandra nicht übermäßig belasten und verwenden Sie es nur für bestimmte Tabellen in einem bestimmten Zeitraum.
Was passiert mit Cassandra nach sechs Monaten ihres Lebens? Im Allgemeinen gibt es keine ungelösten Probleme. Wir haben auch keine schweren Unfälle oder Datenverluste zugelassen. Ja, wir mussten darüber nachdenken, einige Probleme zu kompensieren, die zuvor nicht aufgetreten waren, aber letztendlich hat dies unsere architektonische Lösung nicht wesentlich getrübt. Wenn Sie etwas Neues ausprobieren möchten und keine Angst haben und gleichzeitig nicht zu sehr enttäuscht werden möchten, dann machen Sie sich darauf gefasst, dass nichts umsonst ist. Sie müssen mehr als bei der alten Legacy-Lösung verstehen, sich in die Dokumentation vertiefen und Ihren individuellen Rake zusammenstellen, und keine Theorie wird Ihnen im Voraus sagen, welcher Rake auf Sie wartet.
Source: habr.com