Diuen que tot a la vida val la pena intentar-ho almenys una vegada. I si esteu acostumats a treballar amb SGBD relacionals, val la pena familiaritzar-vos amb NoSQL a la pràctica, primer de tot, almenys per al desenvolupament general. Ara, a causa del ràpid desenvolupament d'aquesta tecnologia, hi ha moltes opinions contradictòries i debats acalorats sobre aquest tema, que sobretot alimenta l'interès.
Si aprofundeixes en l'essència de totes aquestes disputes, pots veure que sorgeixen a causa d'un enfocament incorrecte. Aquells que utilitzen bases de dades NoSQL exactament on es necessiten estan satisfets i reben tots els avantatges d'aquesta solució. I els experimentadors que confien en aquesta tecnologia com a panacea on no és aplicable en absolut es deceben, havent perdut els punts forts de les bases de dades relacionals sense obtenir beneficis significatius.
Us explicaré la nostra experiència en la implementació d'una solució basada en el SGBD Cassandra: què vam haver d'afrontar, com vam sortir de situacions difícils, si vam poder beneficiar-nos de l'ús de NoSQL i on vam haver d'invertir esforços/fons addicionals. .
La tasca inicial és construir un sistema que enregistri les trucades en algun tipus d'emmagatzematge.
El principi de funcionament del sistema és el següent. L'entrada inclou fitxers amb una estructura específica que descriu l'estructura de la trucada. Aleshores, l'aplicació assegura que aquesta estructura s'emmagatzema a les columnes adequades. En el futur, les trucades desades s'utilitzen per mostrar informació sobre el consum de trànsit dels abonats (càrrecs, trucades, historial de saldo).
Està ben clar per què van triar Cassandra: escriu com una metralladora, és fàcilment escalable i tolerant errors.
Així doncs, això és el que ens ha donat l'experiència
Sí, un node fallit no és una tragèdia. Aquesta és l'essència de la tolerància a les falles de Cassandra. Però un node pot estar viu i al mateix temps començar a patir en el rendiment. Com va resultar, això afecta immediatament el rendiment de tot el clúster.
Cassandra no us protegirà on Oracle us va salvar amb les seves limitacions. I si l'autor de l'aplicació no ho va entendre per endavant, llavors el doble que va arribar a Cassandra no és pitjor que l'original. Un cop arribat, el posarem.
IB no li va agradar molt la Cassandra lliure de la caixa: No hi ha registre d'accions de l'usuari, ni diferenciació de drets. La informació sobre trucades es considera dades personals, la qual cosa significa que tots els intents de sol·licitar-la/canviar de qualsevol manera s'han de registrar amb la possibilitat d'una posterior auditoria. A més, heu de ser conscients de la necessitat de separar els drets a diferents nivells per a diferents usuaris. Un enginyer d'operacions senzill i un superadministrador que poden suprimir lliurement tot l'espai clau són diferents rols, diferents responsabilitats i competències. Sense aquesta diferenciació de drets d'accés, el valor i la integritat de les dades es posaran en qüestió immediatament més ràpidament que amb el nivell de coherència QUALSEVOL.
No vam tenir en compte que les trucades requereixen analítiques serioses i mostres periòdiques per a diverses condicions. Com que se suposa que els registres seleccionats s'han de suprimir i reescriure (com a part de la tasca, hem de donar suport al procés d'actualització de dades quan les dades inicialment van entrar incorrectament al nostre bucle), la Cassandra no és la nostra amiga aquí. Cassandra és com una guardiola: és convenient posar-hi coses, però no hi pots comptar.
Hem trobat un problema en transferir dades a zones de prova (5 nodes a la prova enfront de 20 al ball de graduació). En aquest cas, l'abocador no es pot utilitzar.
El problema amb l'actualització de l'esquema de dades d'una aplicació escrivint a Cassandra. Un retrocés generarà moltes làpides, que poden provocar pèrdues de productivitat de manera imprevisible.. Cassandra està optimitzada per gravar, i no pensa gaire abans d'escriure.Qualsevol operació amb dades existents també és una gravació. És a dir, eliminant allò innecessari, simplement produirem encara més registres, i només alguns d'ells estaran marcats amb làpides.
Temps d'espera en inserir. Cassandra és preciosa a la gravació, però de vegades el flux entrant la pot desconcertar significativament. Això passa quan l'aplicació comença a circular per diversos registres que no es poden inserir per algun motiu. I necessitarem un DBA real que supervisarà gc.log, registres del sistema i depuració de consultes lentes, mètriques de compactació pendents.
Diversos centres de dades en un clúster. Des d'on llegir i on escriure?
Potser dividit en lectura i escriptura? I si és així, hauria d'haver un DC més a prop de l'aplicació per escriure o llegir? I no acabarem amb un veritable cervell dividit si triem el nivell de consistència equivocat? Hi ha moltes preguntes, moltes configuracions desconegudes, possibilitats amb les quals realment voleu jugar.
Com vam decidir
Per evitar que el node s'enfonsi, s'ha desactivat SWAP. I ara, si hi ha falta de memòria, el node hauria de baixar i no crear grans pauses gc.
Per tant, ja no confiem en la lògica de la base de dades. Els desenvolupadors d'aplicacions s'estan reentrenant i comencen a prendre precaucions activament en el seu propi codi. Separació clara ideal d'emmagatzematge i processament de dades.
Hem comprat suport a DataStax. El desenvolupament de Cassandra en caixa ja ha cessat (l'últim compromís va ser el febrer de 2018). Al mateix temps, Datastax ofereix un servei excel·lent i un gran nombre de solucions modificades i adaptades per a les solucions IP existents.
També vull assenyalar que Cassandra no és molt convenient per a consultes de selecció. Per descomptat, CQL és un gran pas endavant per als usuaris (en comparació amb Trift). Però si teniu departaments sencers acostumats a unions tan còmodes, filtratge gratuït per qualsevol camp i capacitats d'optimització de consultes, i aquests departaments estan treballant per resoldre queixes i accidents, aleshores la solució a Cassandra els sembla hostil i estúpida. I vam començar a decidir com havien de fer mostres els nostres companys.
Hem considerat dues opcions: en la primera, escrivim les trucades no només en C*, sinó també a la base de dades Oracle arxivada. Només, a diferència de C*, aquesta base de dades només emmagatzema les trucades del mes actual (profunditat d'emmagatzematge de trucades suficient per a les maletes de recàrrega). Aquí vam veure immediatament el següent problema: si escrivim de manera sincrònica, perdem tots els avantatges de C* associats a la inserció ràpida; si escrivim de manera asíncrona, no hi ha cap garantia que totes les trucades necessàries arribin a Oracle. Hi havia un avantatge, però un gran: per al funcionament es manté el mateix desenvolupador PL/SQL familiar, és a dir, implementem pràcticament el patró "Façana", una opció alternativa. Implementem un mecanisme que descarrega les trucades de C*, extreu algunes dades per enriquir-les de les taules corresponents a Oracle, uneix les mostres resultants i ens dóna el resultat, que d'alguna manera fem servir (retrocedir, repetir, analitzar, admirar). Contres: el procés és bastant de diversos passos i, a més, no hi ha cap interfície per als empleats d'operacions.
Al final, ens hem decidit per la segona opció. Apache Spark es va utilitzar per fer mostres de diferents pots. L'essència del mecanisme s'ha reduït al codi Java, que, utilitzant les claus especificades (subscriptor, temps de trucada - tecles de secció), extreu dades de C*, així com les dades necessàries per a l'enriquiment de qualsevol altra base de dades. Després d'això, els uneix a la seva memòria i mostra el resultat a la taula resultant. Vam dibuixar una cara web sobre l'espurna i va resultar bastant utilitzable.
En resoldre el problema de l'actualització de les dades de proves industrials, vam tornar a considerar diverses solucions. Tant la transferència mitjançant Sstloader com l'opció de dividir el clúster a la zona de prova en dues parts, cadascuna de les quals pertany alternativament al mateix clúster amb el promocional, alimentant-se així per aquest. En actualitzar la prova, s'havia previst intercanviar-les: la part que funcionava a la prova s'esborra i entra en producció, i l'altra comença a treballar amb les dades per separat. No obstant això, després de pensar-ho de nou, vam valorar de manera més racional les dades que valia la pena transferir i ens vam adonar que les trucades en si són una entitat inconsistent per a les proves, que es generen ràpidament si cal, i que és el conjunt de dades promocionals que no té cap valor per a la transferència al prova. Hi ha diversos objectes d'emmagatzematge que val la pena traslladar, però aquests són literalment un parell de taules, i no gaire pesades. Per tant nosaltres Com a solució, Spark va tornar al rescat, amb l'ajuda de la qual vam escriure i vam començar a utilitzar activament un script per transferir dades entre taules, prom-test.
La nostra política de desplegament actual ens permet treballar sense retrocessos. Abans de la promoció, hi ha una prova obligatòria, on un error no és tan car. En cas de fallada, sempre podeu deixar anar l'espai de casos i tirar tot l'esquema des del principi.
Per garantir la disponibilitat contínua de Cassandra, necessiteu un dba i no només ell. Tothom que treballa amb l'aplicació ha d'entendre on i com mirar la situació actual i com diagnosticar els problemes de manera oportuna. Per fer-ho, utilitzem activament DataStax OpsCenter (Administració i seguiment de càrregues de treball), mètriques del sistema Cassandra Driver (nombre de temps d'espera per escriure a C*, nombre de temps d'espera per llegir des de C*, latència màxima, etc.), supervisar el funcionament de la pròpia aplicació, treballant amb Cassandra.
Quan vam pensar en la pregunta anterior, ens vam adonar on podria estar el nostre principal risc. Aquests són formularis de visualització de dades que mostren dades de diverses consultes independents a l'emmagatzematge. D'aquesta manera podem obtenir informació força inconsistent. Però aquest problema seria igual de rellevant si només treballéssim amb un centre de dades. Per tant, el més raonable aquí és, per descomptat, crear una funció per lots per llegir dades en una aplicació de tercers, que garantirà que les dades es rebin en un sol període de temps. Pel que fa a la divisió en lectura i escriptura pel que fa al rendiment, aquí ens va aturar el risc que amb una certa pèrdua de connexió entre els DC, poguéssim acabar amb dos clústers totalment inconsistents entre si.
Com a resultat, de moment s'ha aturat al nivell de coherència per escriure EACH_QUORUM, per llegir - LOCAL_QUORUM
Breus impressions i conclusions
Per tal d'avaluar la solució resultant des del punt de vista del suport operatiu i les perspectives de desenvolupament posterior, vam decidir pensar on més es podria aplicar aquest desenvolupament.
D'entrada, després puntuació de dades per a programes com "Paga quan sigui convenient" (carreguem informació a C*, càlcul mitjançant scripts Spark), comptabilització de reclamacions amb agregació per àrea, emmagatzematge de rols i càlcul dels drets d'accés dels usuaris en funció de la funció. matriu.
Com podeu veure, el repertori és ampli i variat. I si escollim el camp de partidaris/oponents de NoSQL, ens unirem als partidaris, ja que vam rebre els nostres avantatges, i exactament on esperàvem.
Fins i tot l'opció Cassandra fora de la caixa permet l'escala horitzontal en temps real, solucionant sense dolor el problema de l'augment de dades al sistema. Vam poder moure un mecanisme de càrrega molt elevada per calcular agregats de trucades a un circuit separat i també separar l'esquema i la lògica de l'aplicació, eliminant la mala pràctica d'escriure treballs i objectes personalitzats a la base de dades. Hem tingut l'oportunitat d'escollir i configurar, d'accelerar, en quins DC realitzarem càlculs i en quins registrarem les dades, ens hem assegurat contra accidents tant de nodes individuals com de DC en conjunt.
Aplicant la nostra arquitectura a nous projectes, i ja tenint una mica d'experiència, m'agradaria tenir en compte immediatament els matisos descrits anteriorment, evitar alguns errors, suavitzar alguns racons afilats que no es podrien evitar inicialment.
Per exemple, fer un seguiment de les actualitzacions de Cassandra de manera oportunaperquè molts dels problemes que vam tenir ja eren coneguts i solucionats.
No poseu tant la base de dades com l'Spark als mateixos nodes (o dividir estrictament per la quantitat d'ús de recursos permesos), ja que Spark pot menjar més OP del que s'esperava, i ràpidament obtindrem el problema número 1 de la nostra llista.
Millorar el seguiment i la competència operativa en l'etapa de prova del projecte. Inicialment, tingueu en compte tant com sigui possible tots els consumidors potencials de la nostra solució, perquè d'això dependrà en última instància l'estructura de la base de dades.
Gireu el circuit resultant diverses vegades per a una possible optimització. Seleccioneu quins camps es poden serialitzar. Entendre quines taules addicionals hem de fer per tenir en compte de la manera més correcta i òptima, i després proporcionar la informació requerida a petició (per exemple, assumint que podem emmagatzemar les mateixes dades en taules diferents, tenint en compte diferents desglossaments segons diferents criteris, podem estalviar molt temps de CPU per a les sol·licituds de lectura).
No està malament Proporcioneu immediatament adjuntar TTL i netejar dades obsoletes.
Quan baixeu dades de Cassandra La lògica de l'aplicació hauria de funcionar segons el principi FETCH, de manera que no totes les files es carreguen a la memòria alhora, sinó que es seleccionen per lots.
És aconsellable abans de transferir el projecte a la solució descrita comproveu la tolerància a errors del sistema realitzant una sèrie de proves de xoc, com ara la pèrdua de dades en un centre de dades, la restauració de dades danyades durant un període determinat, l'abandonament de la xarxa entre centres de dades. Aquestes proves no només permetran avaluar els avantatges i els contres de l'arquitectura proposada, sinó que també proporcionaran una bona pràctica d'escalfament per als enginyers que les duen a terme, i l'habilitat adquirida no serà superflua si es reprodueixen fallades del sistema en la producció.
Si treballem amb informació crítica (com ara dades de facturació, càlcul del deute del subscriptor), també val la pena parar atenció a les eines que reduiran els riscos derivats de les característiques del SGBD. Per exemple, utilitzeu la utilitat nodesync (Datastax), havent desenvolupat una estratègia òptima per al seu ús en ordre per motius de coherència, no creeu una càrrega excessiva a Cassandra i utilitzar-lo només per a determinades taules en un període determinat.
Què li passa a la Cassandra després de sis mesos de vida? En general, no hi ha problemes sense resoldre. Tampoc vam permetre accidents greus ni pèrdua de dades. Sí, vam haver de pensar en compensar alguns problemes que no havien sorgit abans, però al final això no va enfosquir gaire la nostra solució arquitectònica. Si voleu i no teniu por de provar alguna cosa nova i, al mateix temps, no voleu quedar-vos massa decebuts, prepareu-vos per al fet que res és gratuït. Haureu d'entendre, aprofundir en la documentació i muntar el vostre propi rastell individual més que a l'antiga solució heretada, i cap teoria us dirà per endavant quin rastell us espera.
Font: www.habr.com