Si soen datt alles am Liewen et wäert ass op d'mannst eemol ze probéieren. A wann Dir gewinnt sidd mat relationalen DBMSen ze schaffen, dann ass et derwäert NoSQL an der Praxis kennenzeléieren, op d'mannst fir d'allgemeng Entwécklung. Elo, wéinst der rapider Entwécklung vun dëser Technologie, ginn et vill konfliktende Meenungen an hefteg Debatten iwwer dëst Thema, wat besonnesch d'Interesse bréngt.
Wann Dir an d'Essenz vun all dëse Streidereien verdéift, kënnt Dir gesinn datt se entstinn wéinst der falscher Approche. Déi, déi NoSQL-Datebanken genee benotzen, wou se gebraucht ginn, sinn zefridden a kréien all d'Virdeeler vun dëser Léisung. An Experimenter, déi op dës Technologie als Panacea vertrauen, wou et guer net applicabel ass, sinn enttäuscht, hunn d'Stäerkte vu relationalen Datenbanken verluer ouni bedeitend Virdeeler ze kréien.
Ech erzielen Iech iwwer eis Erfarung bei der Ëmsetzung vun enger Léisung baséiert op der Cassandra DBMS: wat hu mir ze konfrontéieren, wéi mir aus schwieregen Situatiounen erauskomm sinn, ob mir vun der NoSQL profitéiere konnten a wou mir zousätzlech Efforten / Fongen investéiere mussen .
Déi initial Aufgab ass e System ze bauen deen Uriff an enger Aart vu Späichere registréiert.
De Betribsprinzip vum System ass wéi follegt. Den Input enthält Dateie mat enger spezifescher Struktur déi d'Struktur vum Uruff beschreift. D'Applikatioun garantéiert dann datt dës Struktur an de passenden Sailen gespäichert ass. An Zukunft ginn déi gespäichert Uriff benotzt fir Informatioun iwwer de Verkéiersverbrauch fir Abonnente ze weisen (Käschten, Uriff, Balancegeschicht).
Et ass ganz kloer firwat se d'Cassandra gewielt hunn - si schreift wéi eng Maschinnegewier, ass liicht skalierbar a Feelertolerant.
Also, dat ass wat d'Erfahrung eis ginn huet
Jo, e gescheitert Node ass keng Tragedie. Dëst ass d'Essenz vun der Cassandra seng Feeler Toleranz. Mee engem Node kann lieweg ginn a gläichzäiteg ufänken an Leeschtung leiden. Wéi et sech erausstellt, beaflosst dëst direkt d'Leeschtung vum ganze Cluster.
Cassandra wäert Iech net schützen wou Oracle Iech mat senge Contrainten gerett huet. A wann den Auteur vun der Applikatioun dëst am Viraus net verstanen huet, dann ass d'Double, déi fir Cassandra ukomm ass, net méi schlëmm wéi d'Original. Wann et ukomm ass, setzen mir et an.
IB huet déi gratis Cassandra aus der Këscht staark net gär: Et gëtt keng Logged vu Benotzeraktiounen, keng Differenzéierung vu Rechter. Informatioun iwwer Uriff gëtt als perséinlech Donnéeën ugesinn, dat heescht datt all Versuche fir se op iergendeng Manéier ze froen / z'änneren musse mat der Méiglechkeet vu spéider Audit protokolléiert ginn. Och musst Dir bewosst sinn datt Dir Rechter op verschiddene Niveaue fir verschidde Benotzer trennt. En einfachen Operatiounsingenieur an e Super Admin, deen de ganze Schlësselraum fräi ka läschen, si verschidde Rollen, verschidde Verantwortung a Kompetenzen. Ouni esou Differenzéierung vun den Zougangsrechter, wäert de Wäert an d'Integritéit vun den Donnéeën direkt méi séier a Fro kommen wéi mat ALL Konsistenzniveau.
Mir hunn net berücksichtegt datt Uruff souwuel sérieux Analyse wéi och periodesch Proben erfuerderen fir verschidde Konditiounen. Zënter datt déi gewielte Rekorder dann geläscht an nei geschriwwe ginn (als Deel vun der Aufgab, musse mir de Prozess vun der Aktualiséierung vun Donnéeën ënnerstëtzen wann d'Donnéeën ufanks falsch an eiser Loop erakomm sinn), ass d'Cassandra net eis Frëndin hei. Cassandra ass wéi e Spuerkeess - et ass bequem Saachen ze setzen, awer Dir kënnt et net zielen.
Mir hunn e Problem begéint fir Daten an Testzonen ze transferéieren (5 Noden am Test versus 20 am Prom). An dësem Fall kann den Dump net benotzt ginn.
De Problem mam Update vum Dateschema vun enger Applikatioun déi op Cassandra schreift. Eng Rollback generéiert vill Grafsteng, wat zu Produktivitéitsverloscht op onberechenbaren Weeër féieren kann.. D'Cassandra ass optimiséiert fir opzehuelen, an denkt net vill virum Schreiwen.All Operatioun mat existéierenden Daten dran ass och eng Opnam. Dat ass, andeems mir déi onnéideg läschen, wäerte mir einfach nach méi Opzeechnunge produzéieren, an nëmmen e puer vun hinnen gi mat Grafsteen markéiert.
Timeouts beim Asetzen. Cassandra ass schéin an der Opnahmen, mä heiansdo kann den erakommen Flux hir bedeitend Puzzel. Dëst geschitt wann d'Applikatioun ufänkt ronderëm e puer records ze fueren, déi aus irgendege Grënn net agefouert kënne ginn. A mir brauche e richtegen DBA deen gc.log, System an Debug Logbicher iwwerwaacht fir lues Ufroen, Metriken iwwer Verdichtung pendend.
Verschidde Datenzenteren an engem Cluster. Vun wou liesen a wou schreiwen?
Vläicht a Liesen a Schreiwen opgedeelt? A wa jo, soll et en DC méi no bei der Applikatioun fir Schreiwen oder Liesen sinn? A wäerte mir net mat engem richtege gesplécktem Gehir ophalen wa mir de falsche Konsistenzniveau wielen? Et gi vill Froen, vill onbekannt Astellungen, Méiglechkeeten, déi Dir wierklech wëllt matmaachen.
Wéi mir decidéiert hunn
Fir ze verhënneren, datt den Node ënnerzegoen, gouf SWAP ausgeschalt. An elo, wann et e Manktem u Erënnerung ass, soll den Node erof goen an net grouss gc Pausen erstellen.
Also, mir vertrauen net méi op Logik an der Datebank. Applikatioun Entwéckler retraining selwer a fänken aktiv Virsiichtsmoossnamen an hiren eegene Code ze huelen. Ideal kloer Trennung vun Datelagerung a Veraarbechtung.
Mir hunn Ënnerstëtzung vun DataStax kaaft. D'Entwécklung vun der Box Cassandra ass scho gestoppt (déi lescht Verpflichtung war am Februar 2018). Zur selwechter Zäit bitt Datastax excellenten Service an eng grouss Zuel vu modifizéierten an adaptéierte Léisunge fir existent IP-Léisungen.
Ech wëll och bemierken datt d'Cassandra net ganz bequem ass fir Selektiounsufroen. Natierlech ass CQL e grousse Schrëtt no vir fir d'Benotzer (am Verglach zum Trift). Awer wann Dir ganz Departementer hutt, déi Gewunnecht sinn mat sou praktesche Bäitrëtter, gratis Filteren duerch all Feld an Ufrooptiméierungsfäegkeeten, an dës Departementer schaffen fir Reklamatiounen an Accidenter ze léisen, da schéngt d'Léisung op Cassandra feindlech an domm ze sinn. A mir hunn ugefaang ze entscheeden wéi eis Kollegen Proben maachen.
Mir hunn zwou Méiglechkeeten iwwerluecht: An der éischter Optioun schreiwen mir Uriff net nëmmen am C*, mä och an der archivéierter Oracle-Datebank. Nëmmen, am Géigesaz zu C *, späichert dës Datebank Uriff nëmme fir den aktuelle Mount (genügend Uruffspäicherdéift fir Opluedstatiounen). Hei hu mir direkt de folgende Problem gesinn: wa mir synchron schreiwen, da verléiere mir all d'Virdeeler vum C* verbonne mat der schneller Insertion; wa mir asynchron schreiwen, gëtt et keng Garantie datt all déi néideg Uriff iwwerhaapt an Oracle koumen. Et war e Plus, awer e groussen: fir d'Operatioun bleift dee selwechte vertraute PL/SQL Entwéckler, dh mir realiséieren praktesch d'"Facade" Muster. Eng alternativ Optioun. Mir implementéieren e Mechanismus deen d'Uriff vun C * entluet, e puer Daten fir d'Beräicherung vun den entspriechende Dëscher am Oracle zitt, bäitrieden déi resultéierend Echantillon a gëtt eis d'Resultat, dat mir dann iergendwéi benotzen (Rulle zréck, widderhuelen, analyséieren, bewonneren). Nodeeler: de Prozess ass zimlech Multi-Schrëtt, an zousätzlech gëtt et keng Interface fir Operatioun Mataarbechter.
Um Enn hu mir eis op déi zweet Optioun niddergelooss. Apache Spark gouf benotzt fir aus verschiddene Jar ze probéieren. D'Essenz vum Mechanismus gouf op Java Code reduzéiert, deen, mat de spezifizéierte Schlësselen (Abonnent, Zäit vum Uruff - Sektiounschlësselen), Daten aus C * zitt, souwéi déi néideg Donnéeën fir d'Beräicherung aus all aner Datebank. Duerno gëtt et hinnen a senger Erënnerung a weist d'Resultat an der resultéierender Tabell. Mir hunn e Web Gesiicht iwwer de Spark gezeechent an et huet sech ganz benotzbar erausgestallt.
Wann Dir de Problem vun der Aktualiséierung vun industriellen Testdaten léisen, hu mir nach eng Kéier verschidde Léisunge betruecht. Béid Transfert iwwer Sstloader an d'Optioun fir de Stärekoup an der Testzon an zwee Deeler opzedeelen, jidderee vun deenen ofwiesselnd zum selwechte Stärekoup mat der Promotioun gehéiert, sou datt se ugedriwwe ginn. Beim Aktualiséierung vum Test war et geplangt fir se auszetauschen: den Deel, deen am Test geschafft huet, gëtt geläscht an a Produktioun agefouert, an deen aneren fänkt un mat den Daten separat ze schaffen. Wéi och ëmmer, nodeems mir nach eng Kéier geduecht hunn, hu mir d'Donnéeën méi rational bewäert, déi et wäert sinn ze transferéieren, a realiséiert datt d'Uruff selwer eng inkonsistent Entitéit fir Tester sinn, séier generéiert wann néideg, an et ass de Promotiounsdatenset dee kee Wäert fir d'Transfert op den testen. Et gi verschidde Späicherobjekter déi et wäert sinn ze réckelen, awer dës si wuertwiertlech e puer Dëscher, an net ganz schwéier. Dofir mir als Léisung, Spark koum erëm op d'Rettung, mat der Hëllef vun deem mir geschriwwen an ugefaang aktiv e Skript ze benotzen fir Daten tëscht Dëscher ze transferéieren, Prom-Test.
Eis aktuell Deployment Politik erlaabt eis ouni Rollbacks ze schaffen. Virun der Promo gëtt et eng obligatoresch Testlaf, wou e Feeler net sou deier ass. Am Fall vun Echec kënnt Dir ëmmer de Casespace erofsetzen an de ganze Schema vun Ufank un rullen.
Fir eng kontinuéierlech Disponibilitéit vu Cassandra ze garantéieren, braucht Dir eng dba an net nëmmen hien. Jiddereen dee mat der Applikatioun schafft muss verstoen wou a wéi een déi aktuell Situatioun kuckt a wéi ee Probleemer fristgerecht diagnostizéiert. Fir dëst ze maachen, benotze mir aktiv DataStax OpsCenter (Administratioun an Iwwerwaachung vun Aarbechtslaascht), Cassandra Driver System Metriken (Zuel vun Timeouts fir op C * ze schreiwen, Unzuel vun Timeouts fir ze liesen aus C *, maximal latency, etc.), iwwerwaachen d'Operatioun vun der Applikatioun selwer, schafft mat Cassandra.
Wa mir un déi viregt Fro geduecht hunn, hu mir gemierkt, wou eisen Haaptrisiko kéint leien. Dëst sinn Datedisplayformen déi Daten vu verschiddenen onofhängege Ufroen op d'Späichere weisen. Op dës Manéier kënne mir zimlech inkonsistent Informatioun kréien. Mä dëse Problem wier grad esou relevant wa mir mat nëmmen engem Rechenzentrum schaffen. Also déi raisonnabelst Saach hei ass natierlech eng Batchfunktioun ze kreéieren fir Daten op enger Drëtt Partei Applikatioun ze liesen, déi garantéiert datt Daten an enger eenzeger Zäit kritt ginn. Wat d'Opdeelung an d'Liesen a Schreiwen a punkto Leeschtung ugeet, hei ware mir vum Risiko gestoppt, datt mir mat e puer Verloschter vun der Verbindung tëscht den DCen zwee Cluster ophalen, déi komplett onkonsequent matenee sinn.
Als Resultat, fir de Moment gestoppt um Konsistenzniveau fir EACH_QUORUM ze schreiwen, fir ze liesen - LOCAL_QUORUM
Kuerz Impressiounen a Conclusiounen
Fir déi resultéierend Léisung aus der Siicht vun der operationeller Ënnerstëtzung a Perspektiven fir weider Entwécklung ze evaluéieren, hu mir décidéiert iwwerzedenken, wou soss esou eng Entwécklung applizéiert ka ginn.
Direkt vun der Fliedermaus, dann Daten Scoring fir Programmer wéi "Bezuelen wann et bequem ass" (mir lueden Informatioun an C *, Berechnung mat Spark Scripten), Rechnung fir Fuerderungen mat Aggregatioun no Beräich, späichere Rollen a Berechnung vun de Benotzer Zougangsrechter baséiert op der Roll Matrixentgasung.
Wéi Dir gesitt, ass de Repertoire breet a variéiert. A wa mir de Camp vun den Supporter / Géigner vun NoSQL wielen, da wäerte mir d'Supporter bäitrieden, well mir eis Virdeeler kruten, a genau wou mir erwaart hunn.
Och d'Cassandra Optioun aus der Këscht erlaabt horizontal Skaléieren an Echtzäit, absolut schmerzlos d'Thema vun der Erhéijung vun Daten am System ze léisen. Mir konnten e ganz héich Belaaschtungsmechanismus fir d'Berechnung vun Uruffaggregaten an e separaten Circuit réckelen, an och d'Applikatiounsschema an d'Logik trennen, déi schlecht Praxis lass ze ginn fir personaliséiert Aarbechten an Objeten an der Datebank selwer ze schreiwen. Mir hunn d'Méiglechkeet ze wielen an ze konfiguréieren, fir ze beschleunegen, op wéi eng DCs mir Berechnungen ausféieren a wéi eng mir Daten ophuelen, hu mir eis géint Crashen vu béiden individuellen Noden an dem DC als Ganzt verséchert.
Eis Architektur op nei Projeten applizéieren, a schonn e bëssen Erfahrung hunn, wëll ech direkt d'Nuancen, déi uewen beschriwwen sinn, berücksichtegen, an e puer Feeler verhënneren, e puer scharf Ecker ausmaachen, déi am Ufank net vermeide konnten.
Zum Beispill, behalen d'Cassandra Updates op eng fristgerecht Manéierwell e puer vun de Problemer, déi mir kruten, ware scho bekannt a fixéiert.
Setzt net souwuel d'Datebank selwer an d'Spark op déiselwecht Wirbelen (oder streng duerch d'Quantitéit vun allowable Ressource benotzen deelen), zënter Spark kann méi OP iessen wéi erwaart, a mir wäerten séier Problem Nummer 1 aus eiser Lëscht.
Verbessert d'Iwwerwaachung an d'operationell Kompetenz an der Projektteststadium. Am Ufank, berücksichtegt sou vill wéi méiglech all potenziell Konsumenten vun eiser Léisung, well dat ass wat d'Datebankstruktur schlussendlech ofhänkt.
Rotéiert de resultéierende Circuit e puer Mol fir méiglech Optimisatioun. Wielt déi Felder déi serialiséiert kënne ginn. Verstinn wat fir zousätzlech Tabelle mir maache solle fir am meeschte korrekt an optimal Rechnung ze droen, a gitt dann op Ufro déi erfuerderlech Informatioun (zum Beispill andeems mir unhuelen datt mir déiselwecht Donnéeën a verschiddenen Dëscher kënne späicheren, andeems verschidden Ënnerdeelungen no Rechnung gedroe ginn verschidde Critèren, kënne mir däitlech CPU Zäit fir Liesen Ufroen spueren).
Net schlecht Direkt virgesinn fir TTL ze befestigen an déi aktuell Daten ze botzen.
Wann Dir Daten aus Cassandra eroflueden D'Applikatiounslogik soll nom FETCH-Prinzip funktionnéieren, sou datt net all Reihen op eemol an d'Erënnerung gelueden ginn, awer a Chargen ausgewielt ginn.
Et ass ubruecht ier Dir de Projet op déi beschriwwe Léisung transferéiert kontrolléiert d'Fehlertoleranz vum System andeems Dir eng Serie vu Crashtester ausféiert, wéi Datenverloscht an engem Datenzenter, Restauratioun vu beschiedegten Donnéeën iwwer eng gewëssen Zäit, Netzausfall tëscht Datenzenteren. Esou Tester erlaben net nëmmen d'Virdeeler an Nodeeler vun der proposéierter Architektur ze evaluéieren, awer och gutt Erwiermungspraxis fir d'Ingenieuren, déi se maachen, an déi erfuerene Fäegkeet ass wäit vun iwwerflësseg wann Systemfehler an der Produktioun reproduzéiert ginn.
Wa mir mat kriteschen Informatioune schaffen (wéi Daten fir Rechnung, Berechnung vun Abonnentscholden), ass et och derwäert oppassen op Tools déi d'Risiken reduzéieren, déi duerch d'Features vum DBMS entstinn. Zum Beispill benotzt d'Nodesync Utility (Datastax), déi eng optimal Strategie fir seng Notzung entwéckelt huet fir d'Konsistenz, erstellt keng exzessiv Laascht op Cassandra a benotzt et nëmme fir bestëmmten Dëscher an enger bestëmmter Period.
Wat geschitt mat Cassandra no sechs Méint vum Liewen? Am Allgemengen ginn et keng ongeléiste Problemer. Mir hunn och keng sérieux Accidenter oder Datenverloscht erlaabt. Jo, mir hu missen nodenken, fir e puer Problemer ze kompenséieren, déi net virdru entstane waren, awer um Enn huet dat eis architektonesch Léisung net immens gewollt. Wann Dir wëllt an net Angscht hutt eppes Neies ze probéieren, a gläichzäiteg net ze vill enttäuscht sinn, da maacht Iech prett fir datt näischt gratis ass. Dir musst verstoen, an d'Dokumentatioun verdéiwen an Ären eegene individuellen Rake méi zesummestellen wéi an der aler Legacy Léisung, a keng Theorie wäert Iech am Viraus soen wéi eng Rake op Iech waart.
Source: will.com