<\/a><\/noindex><\/p>\nSo, das hat uns die Erfahrung geschenkt<\/h2>\n <\/p>\n
Ja, ein ausgefallener Knoten ist keine Trag\u00f6die. Darin liegt die Essenz der Ausfallsicherheit von Cassandra. Aber ein Knoten kann aktiv sein und trotzdem in der Leistung nachlassen<\/b>. Wie sich herausstellte, wirkt sich das sofort auf die Leistung des gesamten Clusters aus.<\/p>\n
<\/p>\n
Cassandra wird dort nicht absichern, wo Oracle mit seinen Constraints geholfen hat<\/b>. Und wenn der Autor der Anwendung das im Voraus nicht verstanden hat, ist das eingegangene Duplikat f\u00fcr Cassandra nicht schlechter als das Original. Wenn es bereits angekommen ist, f\u00fcgen wir es einfach ein.<\/p>\n
<\/p>\n
Die kostenlose Cassandra \u201eout of the box\u201c hat der IKT schlagartig nicht gefallen: Es gibt keine Protokollierung von Benutzeraktionen, auch keine Rechteeinschr\u00e4nkungen.<\/b>. Informationen \u00fcber Anrufe gelten als personenbezogene Daten, was bedeutet, dass alle Versuche, diese in irgendeiner Weise anzufordern oder zu \u00e4ndern, protokolliert werden m\u00fcssen, um sp\u00e4ter gepr\u00fcft zu werden. Au\u00dferdem muss man sich der Notwendigkeit bewusst sein, die Rechte auf verschiedene Ebenen f\u00fcr unterschiedliche Benutzer zu trennen. Ein einfacher Betriebstechniker und ein Superadministrator, der problemlos den gesamten Keyspace l\u00f6schen kann, sind unterschiedliche Rollen mit unterschiedlicher Verantwortung und Kompetenz. Ohne diese Rechteeinschr\u00e4nkung wird der Wert und die Integrit\u00e4t der Daten schneller in Frage gestellt als bei einem Konsistenzlevel von ANY. <\/p>\n
<\/p>\n
Wir haben nicht ber\u00fccksichtigt, dass f\u00fcr Anrufe sowohl ernsthafte Analysen als auch regelm\u00e4\u00dfige Abfragen unter verschiedenen Bedingungen erforderlich sind. Da die gew\u00e4hlten Datens\u00e4tze sp\u00e4ter gel\u00f6scht und \u00fcberschrieben werden sollen (im Rahmen der Aufgabe m\u00fcssen wir den Prozess der Datenaktualisierung unterst\u00fctzen, wenn uns von Anfang an falsche Daten zugef\u00fchrt wurden), ist Cassandra hierf\u00fcr nicht geeignet. Cassandra ist wie ein Sparschwein \u2013 man kann bequem Dinge hineingeben, aber man kann nicht darin z\u00e4hlen.<\/b><\/p>\n
<\/p>\n
Wir haben ein Problem mit der Datenmigration in Testumgebungen.<\/b> (5 Knoten im Test gegen\u00fcber 20 in der Produktion). In solch einem Fall kann kein Dump verwendet werden.<\/p>\n
<\/p>\n
Das Problem mit den Aktualisierungen des Datenbankschemas der Anwendung, die in Cassandra schreibt. Ein Rollback w\u00fcrde eine gro\u00dfe Anzahl an Tombstones erzeugen, was auf unvorhersehbare Weise die Leistung beeintr\u00e4chtigen kann.<\/b>. Cassandra ist f\u00fcr das Schreiben optimiert und denkt vor dem Schreiben nicht viel nach. Jede Operation mit bestehenden Daten darin ist ebenfalls ein Schreibvorgang. Das hei\u00dft, wenn wir \u00dcberfl\u00fcssiges l\u00f6schen, erzeugen wir einfach noch mehr Datens\u00e4tze, und nur ein Teil davon wird mit Tombstones markiert.<\/p>\n
<\/p>\n
Timeouts beim Einf\u00fcgen. Cassandra ist beim Schreiben gro\u00dfartig, aber manchmal kann der eingehende Datenstrom sie erheblich verwirren.<\/b>. Dies geschieht, wenn die Anwendung beginnt, mehrere Datens\u00e4tze im Kreis zu bef\u00f6rdern, die aus irgendeinem Grund nicht eingef\u00fcgt werden k\u00f6nnen. Und wir ben\u00f6tigen einen echten DBA, der die gc.log, die System- und Debug-Logs auf langsame Abfragen und Metriken zum Kompaktieren \u00fcberwacht.\n<\/p>\n
<\/p>\n
Mehrere Rechenzentren im Cluster. Woher lesen und wohin schreiben?<\/b>
<\/p>\n
Wie wir das gel\u00f6st haben<\/h2>\n <\/p>\n
Um zu verhindern, dass der Knoten eingest\u00fcrzt, haben wir SWAP deaktiviert.<\/b>. Und jetzt sollte der Knoten bei Ged\u00e4chtnismangel ausfallen und keine langen gc-Pausen erzeugen.<\/p>\n
<\/p>\n
Also setzen wir nicht mehr auf die Logik in der Datenbank. Die Entwickler der Anwendung erlernen neue Strategien und fangen an, in ihrem eigenen Code aktiv Vorsichtsma\u00dfnahmen zu treffen.<\/b> Eine ideale klare Trennung von Speicherung und Verarbeitung der Daten.<\/p>\n
<\/p>\n
Wir haben Unterst\u00fctzung von DataStax gekauft.<\/b> Die Box-Version von Cassandra wird nicht mehr weiterentwickelt (der letzte Commit war im Februar 2018). Gleichzeitig bietet Datastax einen hervorragenden Service und eine gro\u00dfe Anzahl von \u00fcberarbeiteten und an bestehende IS-L\u00f6sungen angepassten L\u00f6sungen an.<\/p>\n
<\/p>\n
Ich m\u00f6chte auch hervorheben, dass Cassandra nicht besonders benutzerfreundlich f\u00fcr Abfragen ist. Nat\u00fcrlich ist CQL ein gro\u00dfer Schritt in Richtung Benutzerfreundlichkeit (im Vergleich zu Trift). Aber wenn man ganze Abteilungen hat, die an solch bequemen Joins, freier Filterung nach jedem Feld und M\u00f6glichkeiten zur Optimierung der Abfrage gew\u00f6hnt sind und diese Abteilungen daran arbeiten, Anspr\u00fcche und Notf\u00e4lle zu bew\u00e4ltigen, dann erscheint ihnen die Entscheidung f\u00fcr Cassandra feindlich und dumm. Und wir begannen, das Problem zu l\u00f6sen, wie unsere Kollegen Abfragen durchf\u00fchren k\u00f6nnen. <\/p>\n
<\/p>\n
Wir haben zwei Optionen betrachtet. In der ersten Option schreiben wir die Aufrufe nicht nur in C*, sondern auch in die Archivdatenbank Oracle. Aber im Gegensatz zu C* werden in dieser Datenbank nur die Aufrufe des aktuellen Monats gespeichert (eine ausreichende Speichertiefe f\u00fcr Re-Rate-F\u00e4lle). Hier zeigte sich sofort das n\u00e4chste Problem: Wenn wir synchron schreiben, verlieren wir alle Vorteile von C*, die mit schneller Einf\u00fcgung verbunden sind; bei asynchronem Schreiben gibt es keine Garantie, dass alle ben\u00f6tigten Aufrufe \u00fcberhaupt in Oracle gelangen. Es gab jedoch einen gro\u00dfen Vorteil: F\u00fcr die Nutzung bleibt der gewohnte PL\/SQL Developer, d.h. wir setzen praktisch das Muster \u201eFassade\u201c um. Alternative Option: Wir implementieren einen Mechanismus, der die Aufrufe aus C* ausgibt, einige Daten zur Anreicherung aus den entsprechenden Tabellen in Oracle zieht, die erhaltenen Abfragen zusammenf\u00fchrt und uns das Ergebnis liefert, das wir danach in irgendeiner Weise verwenden (r\u00fcckg\u00e4ngig machen, wiederholen, analysieren, bewundern). Nachteile: Der Prozess stellt sich als ziemlich mehrstufig heraus und zudem fehlt eine Schnittstelle f\u00fcr die Mitarbeiter im Betrieb.<\/p>\n
<\/p>\n
Letztendlich haben wir uns doch f\u00fcr die zweite Option entschieden. F\u00fcr die Abfragen aus verschiedenen Datenbanken haben wir Apache Spark verwendet.<\/b> Der Kernmechanismus bestand aus Java-Code, der anhand der angegebenen Schl\u00fcssel (Abonnent, Zeitpunkt des Anrufs \u2013 Schl\u00fcssel des Abschnitts) Daten aus C* abruft sowie die ben\u00f6tigten Daten f\u00fcr die Anreicherung aus einer anderen Datenbank. Danach hat er sie im Speicher zusammengef\u00fchrt und das Ergebnis in eine Ergebnistabelle ausgegeben. \u00dcber Spark haben wir eine Web-Oberfl\u00e4che erstellt, die ganz gut f\u00fcr den Betrieb geeignet ist.<\/p>\n
\n
Bei der L\u00f6sung des Problems mit der Datenaktualisierung hat das Team erneut mehrere L\u00f6sungsans\u00e4tze in Betracht gezogen. Sowohl die \u00dcbertragung \u00fcber Sstloader als auch die M\u00f6glichkeit, den Cluster im Testbereich in zwei Teile zu splitten, von denen jeder abwechselnd mit einem Cluster mit produktiven Daten verbunden wird, wodurch er sich somit von diesem speist. Bei der Aktualisierung des Tests war geplant, die beiden Teile zu tauschen: der Teil, der im Test gearbeitet hat, wird gel\u00f6scht und in die Produktion eingegeben, w\u00e4hrend der andere mit den Daten separat beginnt. Nachdem wir jedoch noch einmal dar\u00fcber nachgedacht haben, bewerteten wir die Daten, die \u00fcbertragen werden sollten, als rationaler und erkannten, dass die Anfragen an sich eine inkonsistente Entit\u00e4t f\u00fcr Tests sind, die im Bedarfsfall schnell erzeugt werden und dass der produktive Datensatz keinen Wert f\u00fcr die \u00dcbertragung in den Test hat. Es gibt einige Speicherobjekte, die es wert sind, \u00fcbertragen zu werden, aber es sind buchst\u00e4blich nur ein paar Tabellen, die zudem nicht sehr schwer sind. Daher kam als L\u00f6sung erneut Spark zur Hilfe, mit dem wir ein Skript zur Daten\u00fcbertragung zwischen den Tabellen von Produktion und Test erstellt und aktiv verwendet haben.<\/b><\/p>\n
<\/p>\n
Unsere aktuelle Deployment-Politik erlaubt es uns, ohne Rollbacks zu arbeiten.<\/b> Vor der Produktion erfolgt stets ein obligatorisches Rollout im Test, wo Fehler nicht so kostspielig sind. Im Falle eines Misserfolgs kann man immer den Keyspace l\u00f6schen und das gesamte Schema von Anfang an neu aufspielen.<\/p>\n
<\/p>\n
Um die kontinuierliche Verf\u00fcgbarkeit von Cassandra sicherzustellen, wird ein Database Administrator ben\u00f6tigt, und das ist nicht alles. Alle, die mit der Anwendung arbeiten, m\u00fcssen verstehen, wo und wie sie die aktuelle Situation \u00fcberwachen und Probleme rechtzeitig diagnostizieren k\u00f6nnen.<\/b> Zu diesem Zweck nutzen wir aktiv DataStax OpsCenter (Verwaltung und \u00dcberwachung von Workloads), die systemmetrischen Daten des Cassandra Drivers (Anzahl der Zeit\u00fcberschreitungen beim Schreiben in C*, Anzahl der Zeit\u00fcberschreitungen beim Lesen aus C*, maximale Latenz usw.), und \u00fcberwachen die Funktionalit\u00e4t der Anwendung, die mit Cassandra arbeitet.\n<\/p>\n
<\/p>\n
Als wir \u00fcber die vorherige Frage nachdachten, erkannten wir, wo das Haupt risiko verborgen sein k\u00f6nnte. Es handelt sich um die Formen der Datenanzeige, die Daten aus mehreren voneinander unabh\u00e4ngigen Abfragen an das Speichersystem abrufen. Dadurch k\u00f6nnen wir recht inkonsistente Informationen erhalten. Aber dieses Problem w\u00e4re ebenso relevant, wenn wir nur mit einem Rechenzentrum arbeiten w\u00fcrden. Daher ist es hier am sinnvollsten, eine Batch-Lese operation in einer externen Anwendung zu erstellen, die die Daten zu einem einheitlichen Zeitpunkt abruft. Was die Trennung von Lese- und Schreibvorg\u00e4ngen hinsichtlich der Leistung betrifft, so hielt uns hier das Risiko davon ab, dass wir bei einem gewissen Verlust der Verbindung zwischen den Rechenzentren zwei v\u00f6llig inkonsistente Cluster erhalten k\u00f6nnten.<\/p>\n
<\/p>\n
Insgesamt sind wir derzeit auf einer Konsistenzebene f\u00fcr die Schreiboperationen von EACH_QUORUM und f\u00fcr die Lesevorg\u00e4nge von LOCAL_QUORUM stehen geblieben.<\/b><\/p>\n
<\/p>\n
Kurze Eindr\u00fccke und Schlussfolgerungen<\/h2>\n <\/p>\n
Um die entstandene L\u00f6sung hinsichtlich des operativen Supports und der Perspektiven f\u00fcr die weitere Entwicklung zu bewerten, haben wir \u00fcberlegt, wo diese Entwicklung noch angewendet werden kann.<\/p>\n
<\/p>\n
Zur schnellen Erw\u00e4hnung k\u00f6nnten Daten-Scoring f\u00fcr Programme wie \u201eZahle, wann es dir passt\u201c (Laden von Informationen in C*, Berechnungen auf Spark-Skripten), die Erfassung von Reklamationen mit Aggregation nach Richtungen, die Speicherung von Rollen und die Berechnung nach der Rollenmatrix von Benutzerzugriffsrechten sein. <\/p>\n
<\/p>\n
Wie wir sehen, ist das Repertoire breit und vielf\u00e4ltig. Und wenn wir im Lager der Bef\u00fcrworter\/Gegner von NoSQL w\u00e4hlen m\u00fcssten, w\u00fcrden wir uns den Bef\u00fcrwortern anschlie\u00dfen, da wir die Vorteile erhalten haben, genau dort, wo wir es erwartet hatten.<\/p>\n
<\/p>\n
Sogar die Cassandra-Standardl\u00f6sung erm\u00f6glicht eine horizontale Skalierung in Echtzeit, wobei das Problem der Datenwachstums im System v\u00f6llig schmerzlos gel\u00f6st wird. Uns ist es gelungen, einen sehr stark belasteten Mechanismus zur Berechnung von Aggregaten basierend auf Anrufen in einen separaten Kontur zu extrahieren und gleichzeitig das Schema und die Logik der Anwendung zu teilen, indem wir die sch\u00e4dliche Praxis des Schreibens von benutzerdefinierten Jobs und Objekten in der Datenbank aufgegeben haben. Wir haben die M\u00f6glichkeit erhalten, auszuw\u00e4hlen und anzupassen, in welchen Rechenzentren wir Berechnungen durchf\u00fchren und wo wir Daten speichern, und uns bez\u00fcglich Ausf\u00e4llen sowohl einzelner Knoten als auch des gesamten Rechenzentrums abzusichern.<\/p>\n
<\/p>\n
Bei der Anwendung unserer Architektur auf neue Projekte und bereits mit einigem Erfahrung im Gep\u00e4ck m\u00f6chten wir die oben beschriebenen Nuancen sofort ber\u00fccksichtigen und einige Fehler vermeiden, sowie scharfe Kanten entsch\u00e4rfen, die wir anf\u00e4nglich nicht umgehen konnten.<\/p>\n
<\/p>\n
Zum Beispiel, aktuellen Updates von Cassandra rechtzeitig folgen<\/b>, denn viele Probleme, die wir gehabt haben, waren bereits bekannt und haben sich als l\u00f6sbar erwiesen.<\/p>\n
<\/p>\n
Die Datenbank und Spark nicht auf denselben Knoten setzen<\/b> oder strikte Trennung nach der zul\u00e4ssigen Ressourcennutzung, da Spark mehr RAM konsumieren kann als erlaubt, und wir schnell Problem Nummer 1 auf unserer Liste erhalten w\u00fcrden.<\/p>\n
<\/p>\n
Das Monitoring und die Betriebskompetenz bereits in der Testphase des Projekts zu verbessern. <\/b>Von Anfang an alle potenziellen Nutzer unserer L\u00f6sung maximal ber\u00fccksichtigen<\/b>, denn letztendlich wird davon die Struktur der Datenbank abh\u00e4ngen.<\/p>\n
<\/p>\n
Die entstandene Struktur mehrmals auf m\u00f6gliche Optimierungen \u00fcberpr\u00fcfen. Bestimmen, welche Felder serialisiert werden k\u00f6nnen. \u00dcberlegen, welche zus\u00e4tzlichen Tabellen wir erstellen sollten, um die ben\u00f6tigten Informationen auf die korrekte und optimale Weise zu ber\u00fccksichtigen und sie dann auf Anfrage bereitzustellen (zum Beispiel, indem wir davon ausgehen, dass wir dieselben Daten in verschiedenen Tabellen speichern k\u00f6nnen, unter Ber\u00fccksichtigung unterschiedlicher Aufteilungen nach verschiedenen Kriterien, wodurch wir erheblich CPU-Zeit bei Leseanfragen sparen k\u00f6nnen).<\/p>\n
<\/p>\n
Nicht schlecht von Anfang an TTL und die Bereinigung veralteter Daten einzuplanen.<\/b><\/p>\n
<\/p>\n
Beim Export von Daten aus Cassandra soll die Logik der Anwendung nach dem FETCH-Prinzip arbeiten, damit nicht alle Zeilen auf einmal in den Speicher geladen werden, sondern in Batches ausgew\u00e4hlt werden.<\/b><\/p>\n
<\/p>\n
Es ist w\u00fcnschenswert, vor der Migration des Projekts zu der beschriebenen L\u00f6sung die Ausfallsicherheit des Systems zu \u00fcberpr\u00fcfen, indem eine Reihe von Stresstests durchgef\u00fchrt wird<\/b>, wie etwa Datenverluste in einem Rechenzentrum, die Wiederherstellung besch\u00e4digter Daten \u00fcber einen bestimmten Zeitraum, Netzwerkausf\u00e4lle zwischen Rechenzentren. Solche Tests erm\u00f6glichen es nicht nur, die Vor- und Nachteile der vorgeschlagenen Architektur zu bewerten, sondern bieten auch eine gute Aufw\u00e4rmpraxis f\u00fcr die Ingenieure, die sie durchf\u00fchren, und die erlernten F\u00e4higkeiten werden nicht \u00fcberfl\u00fcssig sein, falls Systemausf\u00e4lle im Produkt auftreten.<\/p>\n
<\/p>\n
Wenn wir mit kritischen Informationen (wie Daten f\u00fcr die Abrechnung oder die Berechnung von Kundenschulden) arbeiten, sollten wir auch auf Werkzeuge achten, die helfen, die Risiken zu minimieren, die aufgrund der Eigenschaften von DBMS entstehen. Zum Beispiel, nutzen Sie das Tool nodesync (Datastax) und entwickeln Sie eine optimale Strategie f\u00fcr seine Nutzung, um f\u00fcr die Konsistenz keine \u00fcberm\u00e4\u00dfige Belastung f\u00fcr Cassandra zu erzeugen.<\/b> und verwenden Sie es nur f\u00fcr bestimmte Tabellen in bestimmten Zeitr\u00e4umen.<\/p>\n
<\/p>\n
Wie steht es also seit einem halben Jahr mit Cassandra? Insgesamt gibt es keine ungel\u00f6sten Probleme. Es gab auch keine ernsthaften St\u00f6rungen oder Datenverluste. Ja, wir mussten uns Gedanken \u00fcber die Kompensation einiger zuvor nicht aufgetretener Probleme machen, aber letztlich hat dies unsere architektonische Entscheidung nicht stark getr\u00fcbt. Wenn Sie bereit sind, etwas Neues auszuprobieren und keine Angst haben, dabei entt\u00e4uscht zu werden, sollten Sie sich darauf vorbereiten, dass nichts umsonst ist. Sie m\u00fcssen mehr recherchieren, sich mit der Dokumentation vertrautmachen und Ihre individuellen Stolpersteine sammeln als bei einer alten Legacy-L\u00f6sung, und keine Theorie kann Ihnen im Voraus sagen, welche Stolpersteine genau auf Sie warten.<\/p>\n
Quelle: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u0413\u043e\u0432\u043e\u0440\u044f\u0442, \u0432 \u0436\u0438\u0437\u043d\u0438 \u0432\u0441\u0435 \u0441\u0442\u043e\u0438\u0442 \u043f\u043e\u043f\u0440\u043e\u0431\u043e\u0432\u0430\u0442\u044c \u0445\u043e\u0442\u044f \u0431\u044b \u0440\u0430\u0437. \u0418 \u0435\u0441\u043b\u0438 \u0432\u044b \u043f\u0440\u0438\u0432\u044b\u043a\u043b\u0438 \u0440\u0430\u0431\u043e\u0442\u0430\u0442\u044c \u0441 \u0440\u0435\u043b\u044f\u0446\u0438\u043e\u043d\u043d\u044b\u043c\u0438 \u0421\u0423\u0411\u0414, \u0442\u043e \u043f\u043e\u0437\u043d\u0430\u043a\u043e\u043c\u0438\u0442\u044c\u0441\u044f \u043d\u0430 \u043f\u0440\u0430\u043a\u0442\u0438\u043a\u0435 \u0441 NoSQL \u0441\u0442\u043e\u0438\u0442 \u0432 \u043f\u0435\u0440\u0432\u0443\u044e \u043e\u0447\u0435\u0440\u0435\u0434\u044c \u0445\u043e\u0442\u044f \u0431\u044b \u0434\u043b\u044f \u043e\u0431\u0449\u0435\u0433\u043e \u0440\u0430\u0437\u0432\u0438\u0442\u0438\u044f. \u0421\u0435\u0439\u0447\u0430\u0441 \u0432 \u0441\u0438\u043b\u0443 \u0431\u0443\u0440\u043d\u043e\u0433\u043e \u0440\u0430\u0437\u0432\u0438\u0442\u0438\u044f \u044d\u0442\u043e\u0439 \u0442\u0435\u0445\u043d\u043e\u043b\u043e\u0433\u0438\u0438 \u043e\u0447\u0435\u043d\u044c \u043c\u043d\u043e\u0433\u043e \u043f\u0440\u043e\u0442\u0438\u0432\u043e\u0440\u0435\u0447\u0438\u0432\u044b\u0445 \u043c\u043d\u0435\u043d\u0438\u0439 \u0438 \u0433\u043e\u0440\u044f\u0447\u0438\u0445 \u0441\u043f\u043e\u0440\u043e\u0432 \u043d\u0430 \u044d\u0442\u0443 \u0442\u0435\u043c\u0443, \u0447\u0442\u043e \u043e\u0441\u043e\u0431\u0435\u043d\u043d\u043e \u043f\u043e\u0434\u043e\u0433\u0440\u0435\u0432\u0430\u0435\u0442 \u0438\u043d\u0442\u0435\u0440\u0435\u0441. \u0415\u0441\u043b\u0438 \u0432\u043d\u0438\u043a\u043d\u0443\u0442\u044c […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":28210,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-37585","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"Wie](\"\/wp-content\/uploads\/2019\/08\/4845d37a9928f888639c4ebeb7807787.jpg\")
![\"Wie](\"\/wp-content\/uploads\/2019\/08\/c7b095dc8879011adb751c96427af512.jpg\")
<\/p>\n