<\/a><\/noindex><\/p>\nNun, das hat uns die Erfahrung gelehrt.<\/h2>\n <\/p>\n
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.<\/b>Wie sich herausstellte, wirkt sich das sofort auf die Leistung des gesamten Clusters aus.<\/p>\n
<\/p>\n
Cassandra kann nicht dort absichern, wo Oracle mit seinen Constraints gerettet hat.<\/b>Und wenn der Autor der Anwendung das im Voraus nicht verstanden hat, ist ein eingehender Duplikat f\u00fcr Cassandra nicht weniger g\u00fcltig als das Original. Kommt es, wird es eingesetzt.<\/p>\n
<\/p>\n
Die kostenlose Cassandra \u201eout of the box\u201c gefiel der IT-Sicherheit pl\u00f6tzlich gar nicht. Es gibt kein Benutzungsprotokoll und keine Rechteverteilung.<\/b>. Informationen zu Anrufen fallen unter personenbezogene Daten, was bedeutet, dass alle Versuche, diese in irgendeiner Weise anzufordern oder zu \u00e4ndern, protokolliert werden m\u00fcssen, um eine sp\u00e4tere \u00dcberpr\u00fcfung zu erm\u00f6glichen. Zudem ist es notwendig, die Rechte auf verschiedene Ebenen f\u00fcr unterschiedliche Benutzer zu differenzieren. Ein einfacher Betriebstechniker und ein Superadmin, der das gesamte Keyspace problemlos l\u00f6schen kann, sind unterschiedliche Rollen mit verschiedenen Verantwortlichkeiten und Kompetenzen. Ohne eine solche Trennung der Zugriffsrechte wird der Wert und die Integrit\u00e4t der Daten schneller in Frage gestellt, als es bei einem Konsistenzniveau von ANY der Fall w\u00e4re. <\/p>\n
<\/p>\n
Wir haben nicht ber\u00fccksichtigt, dass f\u00fcr Anrufe sowohl ernsthafte Analysen als auch regelm\u00e4\u00dfige Stichproben unter verschiedenen Bedingungen erforderlich sind. Da die ausgew\u00e4hlten Aufzeichnungen sp\u00e4ter gel\u00f6scht und \u00fcberschrieben werden sollen (im Rahmen dieser Aufgabe m\u00fcssen wir den Prozess der Aktualisierung von Daten unterst\u00fctzen, wenn uns urspr\u00fcnglich falsche Daten zugef\u00fchrt wurden), ist Cassandra hier nicht unser Freund. Cassandra ist wie eine Sparkasse \u2013 man kann sie bequem f\u00fcllen, aber man kann damit nicht z\u00e4hlen.<\/b><\/p>\n
<\/p>\n
Haben Sie Probleme beim \u00dcbertragen von Daten in Testumgebungen?<\/b> (5 Knoten im Test im Vergleich zu 20 in der Produktion). In diesem Fall kann das Dumpen nicht verwendet werden.<\/p>\n
<\/p>\n
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\u00e4chtigen kann.<\/b>. Cassandra ist f\u00fcr das Schreiben optimiert und denkt vor dem Schreiben nicht viel nach. Jede Operation mit bestehenden Daten ist ebenfalls ein Schreibvorgang. Das hei\u00dft, wenn wir \u00dcberfl\u00fcssiges l\u00f6schen, erzeugen wir einfach noch mehr Schreibvorg\u00e4nge, und nur ein Teil davon wird als Tombstone markiert.<\/p>\n
<\/p>\n
Timeouts beim Einf\u00fcgen. Cassandra ist beim Schreiben hervorragend, aber manchmal kann der eingehende Datenstrom erheblich verwirrend sein.<\/b>. Dies geschieht, wenn die Anwendung anf\u00e4ngt, einige Datens\u00e4tze im Kreis zu bearbeiten, die aus bestimmten Gr\u00fcnden nicht eingef\u00fcgt werden k\u00f6nnen. Und wir ben\u00f6tigen einen echten DBA, der gc.log, System- und Debug-Logs auf langsame Abfragen und Metriken zu ausstehenden Kompaktierungen \u00fcberwacht.\n<\/p>\n
<\/p>\n
Mehrere Rechenzentren im Cluster. Woher lesen und wohin schreiben?<\/b>
<\/p>\n
Wie wir es gel\u00f6st haben<\/h2>\n <\/p>\n
Um die Knotenschwankungen zu vermeiden, haben wir SWAP deaktiviert<\/b>. Und nun sollte der Knoten bei Speichermangel ausfallen, anstatt gro\u00dfe gc-Pausen zu erzeugen.<\/p>\n
<\/p>\n
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.<\/b> Eine ideale klare Trennung von Speicherung und Verarbeitung von Daten.<\/p>\n
<\/p>\n
Wir haben Unterst\u00fctzung von DataStax erworben.<\/b> Die Boxed Cassandra wird nicht mehr weiterentwickelt (letzter Commit im Februar 2018). Gleichzeitig bietet DataStax einen ausgezeichneten Service sowie eine Vielzahl an angepassten und \u00fcberarbeiteten L\u00f6sungen f\u00fcr bestehende IT-Systeme.<\/p>\n
<\/p>\n
Ich m\u00f6chte auch darauf hinweisen, dass Cassandra nicht besonders benutzerfreundlich f\u00fcr Abfragen ist. Nat\u00fcrlich ist CQL ein gro\u00dfer Schritt in Richtung Benutzerfreundlichkeit (im Vergleich zu Trift). Wenn jedoch ganze Abteilungen daran gew\u00f6hnt sind, mit solchen bequemen Joins zu arbeiten, frei nach beliebigen Feldern filtern zu k\u00f6nnen und Optimierungsm\u00f6glichkeiten f\u00fcr Abfragen zu haben, erscheint ihnen eine L\u00f6sung mit Cassandra feindlich und unklug. Wir haben begonnen, zu kl\u00e4ren, wie wir unseren Kollegen bei der Datenauswahl helfen k\u00f6nnen. <\/p>\n
<\/p>\n
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\u00e4lt diese Datenbank jedoch nur die Aufrufe des aktuellen Monats (eine ausreichende Speicherdauer f\u00fcr die Tarifierungsf\u00e4lle). Hierbei trat sofort folgendes Problem auf: Wenn wir synchron schreiben, verlieren wir alle Vorteile von C*, die mit der schnellen Einf\u00fcgung verbunden sind; wenn wir asynchron arbeiten, gibt es keine Garantie, dass alle ben\u00f6tigten Aufrufe \u00fcberhaupt in Oracle gelangen. Es gab jedoch einen gro\u00dfen Vorteil: F\u00fcr den Betrieb bleibt der vertraute PL\/SQL Developer, das hei\u00dft, wir k\u00f6nnen das Muster \u201eFassade\u201c 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\u00fchrt und uns das Ergebnis liefert, das wir dann auf irgendeine Weise verwenden (rollbacken, wiederholen, analysieren, bewundern). Nachteile: Der Prozess ist ziemlich mehrstufig, au\u00dferdem fehlt eine Benutzeroberfl\u00e4che f\u00fcr die Betriebstechnik.<\/p>\n
<\/p>\n
Letztendlich haben wir uns doch f\u00fcr die zweite Option entschieden. F\u00fcr Abfragen aus verschiedenen Quellbanken verwendeten wir Apache Spark.<\/b> Der Mechanismus basiert auf Java-Code, der anhand der angegebenen Schl\u00fcssel (Abonnent, Zeitpunkt des Anrufs \u2013 Schl\u00fcssel des Abschnitts) Daten aus C* abruft sowie ben\u00f6tigte Informationen aus einer anderen Datenbank f\u00fcr die Anreicherung. Anschlie\u00dfend werden diese in seinem Speicher zusammengef\u00fchrt und das Ergebnis in einer Ergebnistabelle ausgegeben. \u00dcber Spark wurde eine Weboberfl\u00e4che erstellt, die sich als gut nutzbar herausgestellt hat.<\/p>\n
\n
Bei der Bew\u00e4ltigung der Datenaktualisierungsaufgabe hat das Team erneut mehrere L\u00f6sungsans\u00e4tze in Betracht gezogen. Sowohl der Transfer \u00fcber 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 \u00fcberf\u00fchrt, w\u00e4hrend der andere separat mit den Daten arbeitet. Aber nach weiterer \u00dcberlegung haben wir die Daten, die es wert sind, \u00fcbertragen zu werden, als wertvoller eingesch\u00e4tzt und erkannt, dass die Aufrufe selbst eine inkonsistente Entit\u00e4t f\u00fcr Tests darstellen, die im Bedarfsfall schnell generiert werden. Der Produktionsdatensatz hat daher keinen Wert f\u00fcr 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\u00df sind. Daher ist Spark erneut zur L\u00f6sung gekommen, mit dessen Hilfe wir ein Skript zum Transfer von Daten zwischen den Tabellen in der Produktions- und Testumgebung geschrieben und aktiv genutzt haben.<\/b><\/p>\n
<\/p>\n
Unsere aktuelle Deployment-Politik erm\u00f6glicht es uns, ohne Rollbacks zu arbeiten.<\/b> Vor der Promotion ist ein obligater Testlauf notwendig, bei dem Fehler weniger gravierend sind. Im Falle eines Misserfolgs kann der Case Space immer gel\u00f6scht und das gesamte Schema neu aufgesetzt werden.<\/p>\n
<\/p>\n
Um eine durchgehende Verf\u00fcgbarkeit von Cassandra zu gew\u00e4hrleisten, 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 \u00fcberpr\u00fcfen und Probleme rechtzeitig diagnostizieren k\u00f6nnen.<\/b> Daf\u00fcr nutzen wir aktiv DataStax OpsCenter (Verwaltung und \u00dcberwachung der Workloads), systemmetriken des Cassandra Drivers (Anzahl der Schreib-Timeouts in C*, Anzahl der Lese-Timeouts 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, wurde uns klar, wo unser Haupt Risiko liegen k\u00f6nnte. Es sind die Datenanzeigeformate, die Informationen aus mehreren unabh\u00e4ngigen Anfragen an den Speicher abrufen. Dadurch k\u00f6nnen wir recht inkonsistente Informationen erhalten. Dieses Problem w\u00e4re jedoch ebenso relevant, wenn wir nur mit einem einzelnen Rechenzentrum arbeiten w\u00fcrden. Daher ist es in diesem Fall am sinnvollsten, eine Batch-Funktion f\u00fcr 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\u00fcbergehenden Verbindungsverlust zwischen den Rechenzentren zwei v\u00f6llig inkonsistente Cluster entstehen k\u00f6nnten.<\/p>\n
<\/p>\n
Daher haben wir derzeit uns f\u00fcr den Konsistenzgrad FOR_WRITE EACH_QUORUM und f\u00fcr das Lesen LOCAL_QUORUM entschieden.<\/b><\/p>\n
<\/p>\n
Kurze Eindr\u00fccke und Schlussfolgerungen<\/h2>\n <\/p>\n
Um die entstandene L\u00f6sung hinsichtlich der Betriebskosten und der Perspektiven f\u00fcr die Weiterentwicklung zu bewerten, haben wir \u00fcberlegt, wo wir eine solche Entwicklung noch anwenden k\u00f6nnten.<\/p>\n
<\/p>\n
Wenn wir schnell darauf eingehen, bezieht sich das Scoring von Daten f\u00fcr 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. <\/p>\n
<\/p>\n
Wie wir sehen, ist das Repertoire breit und vielf\u00e4ltig. Wenn es um die Wahl zwischen Anh\u00e4ngern und Gegnern von NoSQL geht, schlie\u00dfen wir uns den Bef\u00fcrwortern an, da wir die Vorteile erfahren haben, genau dort, wo wir es erwartet haben.<\/p>\n
<\/p>\n
Selbst die Cassandra-Variante \"out of the box\" erm\u00f6glicht eine horizontale Skalierung in Echtzeit und l\u00f6st problemlos das Problem der Datenvergr\u00f6\u00dferung im System. Es ist uns gelungen, einen sehr stark belasteten Mechanismus zur Berechnung der Aggregate f\u00fcr Anrufe in einen eigenen Bereich auszulagern und zudem das Schema und die Logik der Anwendung zu trennen, wodurch wir von der sch\u00e4dlichen Praxis der Erstellung von benutzerdefinierten Jobs und Objekten in der Datenbank Abstand genommen haben. Wir haben die M\u00f6glichkeit erhalten, auszuw\u00e4hlen und zu konfigurieren, in welchen Rechenzentren wir Berechnungen durchf\u00fchren und in welchen wir Daten speichern, und uns dadurch vor Ausf\u00e4llen sowohl einzelner Knoten als auch des gesamten Rechenzentrums abgesichert.<\/p>\n
<\/p>\n
Wenn wir unsere Architektur auf neue Projekte anwenden und bereits \u00fcber erste Erfahrungen verf\u00fcgen, sollten wir die oben beschriebenen Nuancen sofort ber\u00fccksichtigen, um Fehler zu vermeiden und Schwierigkeiten, die von Anfang an nicht zu vermeiden waren, zu gl\u00e4tten.<\/p>\n
<\/p>\n
Zum Beispiel Die Aktualisierungen von Cassandra rechtzeitig verfolgen<\/b>, denn viele Probleme, die wir erfahren haben, waren bereits bekannt und wurden behoben.<\/p>\n
<\/p>\n
Datenbank und Spark nicht auf denselben Knoten installieren<\/b> (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.<\/p>\n
<\/p>\n
Die \u00dcberwachung und das Betriebswissen bereits in der Testphase des Projekts ausbauen. <\/b>Von Anfang an m\u00f6glichst alle potenziellen Nutzer unserer L\u00f6sung ber\u00fccksichtigen<\/b>, denn davon wird letztendlich die Struktur der Datenbank abh\u00e4ngen.<\/p>\n
<\/p>\n
\u00dcberpr\u00fcfen Sie das entstehende Schema mehrmals auf m\u00f6gliche Optimierungen. Identifizieren Sie, welche Felder serialisiert werden k\u00f6nnen. Verstehen Sie, welche zus\u00e4tzlichen 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\u00f6nnen, wobei verschiedene Kriterien ber\u00fccksichtigt werden, kann dies die CPU-Zeit f\u00fcr Leseanfragen erheblich einsparen).<\/p>\n
<\/p>\n
Nicht schlecht Planen Sie sofort die Implementierung von TTL und die Bereinigung veralteter Daten ein.<\/b><\/p>\n
<\/p>\n
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\u00e4hlt werden.<\/b><\/p>\n
<\/p>\n
Es ist ratsam, vor der Umstellung des Projekts auf die beschriebene L\u00f6sung die Ausfallsicherheit des Systems zu \u00fcberpr\u00fcfen, indem eine Reihe von Stresstests durchgef\u00fchrt werden.<\/b>, wie etwa Datenverluste in einem Rechenzentrum, die Wiederherstellung besch\u00e4digter Daten \u00fcber einen bestimmten Zeitraum sowie Netzwerkprobleme zwischen den Rechenzentren. Solche Tests erm\u00f6glichen nicht nur eine Bewertung der Vor- und Nachteile der vorgeschlagenen Architektur, sondern bieten auch wertvolle praktische Erfahrungen f\u00fcr die Ingenieure, die sie durchf\u00fchren. Die erlernten F\u00e4higkeiten werden von unsch\u00e4tzbarem Wert sein, falls Systemausf\u00e4lle in der Praxis eintreten.<\/p>\n
<\/p>\n
Wenn wir mit sensibler Information arbeiten (wie etwa Daten f\u00fcr 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\u00f6nnte die Nutzung des Tools nodesync (Datastax) in Erw\u00e4gung gezogen werden, w\u00e4hrend wir eine optimale Strategie f\u00fcr dessen Verwendung entwickeln, um aus Gr\u00fcnden der Konsistenz keine \u00fcberm\u00e4\u00dfige Last auf Cassandra zu erzeugen<\/b> und es ausschlie\u00dflich f\u00fcr bestimmte Tabellen zu bestimmten Zeiten zu verwenden.<\/p>\n
<\/p>\n
Nun, nach einem halben Jahr mit Cassandra? Insgesamt gibt es keine ungel\u00f6sten Probleme. Schwere Ausf\u00e4lle und Datenverlust haben wir ebenfalls vermieden. Ja, wir mussten \u00fcber Kompensationen f\u00fcr einige zuvor nicht aufgetretene Probleme nachdenken, aber letztendlich hat das unsere Architekturentscheidung nicht wesentlich getr\u00fcbt. Wenn Sie bereit sind, etwas Neues auszuprobieren und nicht entt\u00e4uscht werden wollen, sollten Sie sich darauf einstellen, dass nichts umsonst ist. Sie werden mehr Zeit damit verbringen m\u00fcssen, sich einzuarbeiten, die Dokumentation zu studieren und Ihre eigenen H\u00fcrden zu identifizieren als bei alten Legacy-L\u00f6sungen, und keine Theorie kann Ihnen im Voraus sagen, welche H\u00fcrden Sie konkret erwarten.<\/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