Ze zeggen dat alles in het leven de moeite waard is om minstens één keer te proberen. En als u gewend bent om met relationele DBMS's te werken, dan is het de moeite waard om in de praktijk kennis te maken met NoSQL, in de eerste plaats, tenminste voor algemene ontwikkeling. Nu, als gevolg van de snelle ontwikkeling van deze technologie, zijn er veel tegenstrijdige meningen en verhitte debatten over dit onderwerp, wat vooral de belangstelling wekt.
Als je je verdiept in de essentie van al deze geschillen, zie je dat ze ontstaan door een verkeerde aanpak. Degenen die NoSQL-databases precies gebruiken waar ze nodig zijn, zijn tevreden en profiteren van alle voordelen van deze oplossing. En onderzoekers die op deze technologie vertrouwen als een wondermiddel waar deze helemaal niet toepasbaar is, zijn teleurgesteld, omdat ze de sterke punten van relationele databases hebben verloren zonder noemenswaardige voordelen te behalen.
Ik zal u vertellen over onze ervaring bij het implementeren van een oplossing op basis van het Cassandra DBMS: waar we mee te maken kregen, hoe we uit moeilijke situaties kwamen, of we konden profiteren van het gebruik van NoSQL en waar we extra inspanningen/fondsen moesten investeren .
De eerste taak is het bouwen van een systeem dat oproepen in een soort opslag registreert.
Het werkingsprincipe van het systeem is als volgt. De invoer bevat bestanden met een specifieke structuur die de structuur van de oproep beschrijven. De applicatie zorgt er vervolgens voor dat deze structuur in de juiste kolommen wordt opgeslagen. In de toekomst worden de opgeslagen oproepen gebruikt om informatie over het verkeersverbruik voor abonnees weer te geven (kosten, oproepen, saldogeschiedenis).
Het is vrij duidelijk waarom ze voor Cassandra hebben gekozen: ze schrijft als een machinegeweer, is gemakkelijk schaalbaar en fouttolerant.
Dit is dus wat de ervaring ons heeft opgeleverd
Ja, een mislukt knooppunt is geen tragedie. Dit is de essentie van Cassandra's fouttolerantie. Maar een knooppunt kan in leven zijn en tegelijkertijd beginnen te lijden onder de prestaties. Het bleek dat dit onmiddellijk invloed heeft op de prestaties van het hele cluster.
Cassandra zal je niet beschermen waar Oracle je met zijn beperkingen heeft gered. En als de auteur van de aanvraag dit niet van tevoren heeft begrepen, dan is de dubbelganger die voor Cassandra arriveerde niet slechter dan het origineel. Zodra het binnen is, plaatsen wij het.
IB had een grote hekel aan de gratis Cassandra uit de doos: Er is geen registratie van gebruikersacties, geen onderscheid in rechten. Informatie over oproepen worden beschouwd als persoonlijke gegevens, wat betekent dat alle pogingen om deze op welke manier dan ook op te vragen/wijzigen, moeten worden geregistreerd met de mogelijkheid van daaropvolgende audits. U moet zich ook bewust zijn van de noodzaak om rechten op verschillende niveaus voor verschillende gebruikers te scheiden. Een eenvoudige bedieningsingenieur en een superbeheerder die de hele sleutelruimte vrijelijk kunnen verwijderen, hebben verschillende rollen, verschillende verantwoordelijkheden en bevoegdheden. Zonder een dergelijke differentiatie van toegangsrechten zullen de waarde en integriteit van de gegevens onmiddellijk en sneller in twijfel worden getrokken dan bij welk consistentieniveau dan ook.
We hebben er geen rekening mee gehouden dat oproepen zowel serieuze analyses als periodieke steekproeven vereisen voor verschillende omstandigheden. Omdat de geselecteerde records vervolgens moeten worden verwijderd en herschreven (als onderdeel van de taak moeten we het proces van het bijwerken van gegevens ondersteunen wanneer de gegevens aanvankelijk onjuist in onze lus terechtkwamen), is Cassandra hier niet onze vriend. Cassandra is als een spaarvarken: het is handig om er dingen in te stoppen, maar je kunt er niet in tellen.
Er is een probleem opgetreden bij het overbrengen van gegevens naar testzones (5 knooppunten in de test versus 20 in het bal). In dit geval kan de dump niet worden gebruikt.
Het probleem met het bijwerken van het gegevensschema van een toepassing die naar Cassandra schrijft. Een rollback zal een groot aantal grafstenen opleveren, wat op onvoorspelbare wijze tot productiviteitsverlies kan leiden.. Cassandra is geoptimaliseerd voor opname en denkt niet veel na voordat ze schrijft. Elke bewerking met bestaande gegevens erin is ook een opname. Dat wil zeggen, door het overbodige te verwijderen, zullen we eenvoudigweg nog meer records produceren, en slechts enkele daarvan zullen worden gemarkeerd met grafstenen.
Time-outs bij het invoegen. Cassandra is prachtig op de opname, maar soms kan de binnenkomende stroom haar behoorlijk in verwarring brengen. Dit gebeurt wanneer de toepassing verschillende records begint te doorlopen die om de een of andere reden niet kunnen worden ingevoegd. En we zullen een echte DBA nodig hebben die gc.log, systeem- en debug-logboeken controleert op langzame queries, terwijl statistieken over compactie in behandeling zijn.
Meerdere datacenters in een cluster. Waar te lezen en waar te schrijven?
Misschien opgesplitst in lezen en schrijven? En zo ja, moet er dan een DC dichter bij de aanvraag voor schrijven of lezen komen? En zullen we niet eindigen met een echt gespleten brein als we het verkeerde consistentieniveau kiezen? Er zijn veel vragen, veel onbekende instellingen, mogelijkheden waar je heel graag aan wilt sleutelen.
Hoe we besloten
Om te voorkomen dat het knooppunt zinkt, is SWAP uitgeschakeld. En als er nu een gebrek aan geheugen is, moet het knooppunt uitvallen en geen grote gc-pauzes veroorzaken.
We vertrouwen dus niet langer op logica in de database. Applicatieontwikkelaars herscholen zichzelf en beginnen actief voorzorgsmaatregelen te nemen in hun eigen code. Ideale duidelijke scheiding van gegevensopslag en -verwerking.
We hebben ondersteuning gekocht bij DataStax. De ontwikkeling van Cassandra in box is al gestopt (de laatste commit was in februari 2018). Tegelijkertijd biedt Datastax een uitstekende service en een groot aantal aangepaste en aangepaste oplossingen voor bestaande IP-oplossingen.
Ik wil ook opmerken dat Cassandra niet erg handig is voor selectiequery's. CQL is natuurlijk een grote stap voorwaarts voor gebruikers (vergeleken met Trift). Maar als je hele afdelingen hebt die gewend zijn aan zulke handige joins, gratis filteren op elk veld en mogelijkheden voor het optimaliseren van zoekopdrachten, en deze afdelingen werken aan het oplossen van klachten en ongelukken, dan komt de oplossing op Cassandra voor hen vijandig en dom over. En we begonnen te beslissen hoe onze collega's monsters moesten maken.
We hebben twee opties overwogen: bij de eerste optie schrijven we calls niet alleen in C*, maar ook in de gearchiveerde Oracle-database. Alleen slaat deze database, in tegenstelling tot C*, alleen oproepen op voor de huidige maand (voldoende opslagcapaciteit voor oproepen om dossiers op te laden). Hier zagen we meteen het volgende probleem: als we synchroon schrijven, verliezen we alle voordelen van C* die gepaard gaan met snelle invoeging; als we asynchroon schrijven, is er geen garantie dat alle noodzakelijke oproepen überhaupt in Oracle terecht zijn gekomen. Er was één pluspunt, maar wel een groot voordeel: voor de bediening blijft dezelfde vertrouwde PL/SQL Developer bestaan, d.w.z. we implementeren praktisch het “Facade” patroon. Een alternatieve optie. We implementeren een mechanisme dat oproepen uit C* verwijdert, wat gegevens ter verrijking uit de overeenkomstige tabellen in Oracle haalt, de resulterende voorbeelden samenvoegt en ons het resultaat geeft, dat we vervolgens op de een of andere manier gebruiken (terugdraaien, herhalen, analyseren, bewonderen). Nadelen: het proces bestaat uit meerdere stappen en bovendien is er geen interface voor operationele medewerkers.
Uiteindelijk zijn we voor de tweede optie gegaan. Apache Spark werd gebruikt om uit verschillende potten te samplen. De essentie van het mechanisme is teruggebracht tot Java-code, die met behulp van de gespecificeerde sleutels (abonnee, tijdstip van oproep - sectiesleutels) gegevens uit C* haalt, evenals de noodzakelijke gegevens voor verrijking uit elke andere database. Daarna voegt het ze samen in zijn geheugen en geeft het resultaat weer in de resulterende tabel. We tekenden een webface over de vonk en het bleek best bruikbaar.
Bij het oplossen van het probleem van het bijwerken van industriële testgegevens hebben we opnieuw verschillende oplossingen overwogen. Beide worden overgedragen via Sstloader en de mogelijkheid om het cluster in de testzone in twee delen te splitsen, die elk afwisselend tot hetzelfde cluster behoren als het promotionele cluster en er dus door worden aangedreven. Bij het updaten van de test was het de bedoeling om ze te verwisselen: het deel dat in de test werkte, wordt gewist en in productie genomen, en het andere begint afzonderlijk met de gegevens te werken. Nadat we er echter nog eens over hadden nagedacht, hebben we de gegevens die de moeite waard waren om over te dragen rationeler beoordeeld en beseften we dat de oproepen zelf een inconsistente entiteit zijn voor tests, die indien nodig snel worden gegenereerd, en dat het de promotionele dataset is die geen waarde heeft voor overdracht naar de test. Er zijn verschillende opslagobjecten die de moeite waard zijn om te verplaatsen, maar dit zijn letterlijk een paar tafels, en niet erg zware. Daarom, wij als oplossing kwam Spark opnieuw te hulp, met behulp waarvan we een script schreven en actief begonnen te gebruiken voor het overbrengen van gegevens tussen tabellen, prom-test.
Dankzij ons huidige implementatiebeleid kunnen we zonder rollbacks werken. Voorafgaand aan de promo is er een verplichte testrun, waarbij een fout niet zo duur is. In geval van een mislukking kunt u altijd de casespace laten vallen en het hele schema vanaf het begin doorrollen.
Om de continue beschikbaarheid van Cassandra te garanderen, heb je een dba nodig en niet alleen hem. Iedereen die met de applicatie werkt, moet begrijpen waar en hoe hij naar de huidige situatie moet kijken en hoe hij problemen tijdig kan diagnosticeren. Om dit te doen, maken we actief gebruik van DataStax OpsCenter (beheer en monitoring van workloads), Cassandra Driver-systeemstatistieken (aantal time-outs voor schrijven naar C*, aantal time-outs voor lezen van C*, maximale latentie, enz.), monitoren we de werking van de applicatie zelf, in samenwerking met Cassandra.
Toen we over de vorige vraag nadachten, beseften we waar ons grootste risico zou kunnen liggen. Dit zijn gegevensweergaveformulieren die gegevens van verschillende onafhankelijke query's naar de opslag weergeven. Op deze manier kunnen we tamelijk inconsistente informatie verkrijgen. Maar dit probleem zou net zo relevant zijn als we met slechts één datacenter zouden werken. Het meest redelijke hier is dus natuurlijk om een batchfunctie te creëren voor het lezen van gegevens in een applicatie van derden, die ervoor zorgt dat gegevens binnen één tijdsperiode worden ontvangen. Wat betreft de verdeling in lezen en schrijven in termen van prestaties, werden we hier tegengehouden door het risico dat we bij enig verlies van verbinding tussen de DC's zouden kunnen eindigen met twee clusters die volledig inconsistent met elkaar zijn.
Met als gevolg voorlopig gestopt op het consistentieniveau voor het schrijven van EACH_QUORUM, voor het lezen - LOCAL_QUORUM
Korte indrukken en conclusies
Om de resulterende oplossing te evalueren vanuit het oogpunt van operationele ondersteuning en vooruitzichten voor verdere ontwikkeling, besloten we na te denken over waar een dergelijke ontwikkeling nog meer zou kunnen worden toegepast.
Vervolgens worden er meteen gegevens gescoord voor programma's als 'Betaal wanneer het u uitkomt' (we laden informatie in C*, berekeningen met behulp van Spark-scripts), het verwerken van claims met aggregatie per gebied, het opslaan van rollen en het berekenen van gebruikerstoegangsrechten op basis van de rol Matrix.
Zoals je ziet is het repertoire breed en gevarieerd. En als we het kamp van voorstanders/tegenstanders van NoSQL kiezen, zullen we ons bij de aanhangers aansluiten, omdat we onze voordelen hebben ontvangen, en precies waar we hadden verwacht.
Zelfs de out-of-the-box Cassandra-optie maakt horizontaal schalen in realtime mogelijk, waardoor het probleem van de toename van de gegevens in het systeem absoluut pijnloos wordt opgelost. We waren in staat om een mechanisme met een zeer hoge belasting voor het berekenen van oproepaggregaten naar een afzonderlijk circuit te verplaatsen, en ook het applicatieschema en de logica te scheiden, waardoor de slechte gewoonte van het schrijven van aangepaste taken en objecten in de database zelf werd geëlimineerd. We kregen de mogelijkheid om te kiezen en te configureren, om te versnellen, op welke DC's we berekeningen zullen uitvoeren en op welke we gegevens zullen vastleggen, we hebben ons verzekerd tegen crashes van zowel individuele knooppunten als de DC als geheel.
Door onze architectuur toe te passen op nieuwe projecten en al enige ervaring te hebben, zou ik onmiddellijk rekening willen houden met de hierboven beschreven nuances en enkele fouten willen voorkomen, enkele scherpe hoeken willen gladstrijken die aanvankelijk niet konden worden vermeden.
Bijvoorbeeld houd Cassandra's updates tijdig in de gatenomdat een flink aantal van de problemen die we kregen al bekend en opgelost waren.
Plaats niet zowel de database zelf als Spark op dezelfde knooppunten (of strikt gedeeld door de hoeveelheid toegestaan gebruik van hulpbronnen), aangezien Spark meer OP kan eten dan verwacht, en we snel probleem nummer 1 uit onze lijst zullen halen.
Verbeter de monitoring en operationele competentie in de projecttestfase. Houd in eerste instantie zoveel mogelijk rekening met alle potentiële consumenten van onze oplossing, omdat dit is waar de databasestructuur uiteindelijk van zal afhangen.
Roteer het resulterende circuit meerdere keren voor mogelijke optimalisatie. Selecteer welke velden kunnen worden geserialiseerd. Begrijp welke extra tabellen we moeten maken om er zo correct en optimaal rekening mee te houden, en geef vervolgens op verzoek de vereiste informatie (bijvoorbeeld door aan te nemen dat we dezelfde gegevens in verschillende tabellen kunnen opslaan, rekening houdend met verschillende uitsplitsingen volgens verschillende criteria, kunnen we aanzienlijk CPU-tijd besparen voor leesverzoeken).
niet slecht Zorg direct voor het koppelen van TTL en het opschonen van verouderde gegevens.
Bij het downloaden van gegevens van Cassandra De applicatielogica zou volgens het FETCH-principe moeten werken, zodat niet alle rijen in één keer in het geheugen worden geladen, maar in batches worden geselecteerd.
Het is raadzaam voordat u het project overzet naar de beschreven oplossing controleer de fouttolerantie van het systeem door een reeks crashtests uit te voeren, zoals gegevensverlies in één datacenter, herstel van beschadigde gegevens gedurende een bepaalde periode, netwerkuitval tussen datacenters. Dergelijke tests zullen het niet alleen mogelijk maken om de voor- en nadelen van de voorgestelde architectuur te evalueren, maar zullen ook een goede voorbereiding opleveren voor de ingenieurs die ze uitvoeren, en de verworven vaardigheden zullen verre van overbodig zijn als systeemfouten zich in de productie herhalen.
Als we met kritische informatie werken (zoals gegevens voor facturering, berekening van de abonneeschuld), dan is het ook de moeite waard om aandacht te besteden aan tools die de risico's die voortvloeien uit de kenmerken van het DBMS zullen verminderen. Gebruik bijvoorbeeld het knooppuntsync-hulpprogramma (Datastax), nadat u een optimale strategie voor het gebruik ervan hebt ontwikkeld omwille van de consistentie mag u Cassandra niet overmatig belasten en gebruik het alleen voor bepaalde tafels in een bepaalde periode.
Wat gebeurt er met Cassandra na zes maanden leven? Over het algemeen zijn er geen onopgeloste problemen. We hebben ook geen ernstige ongelukken of gegevensverlies toegestaan. Ja, we moesten nadenken over het compenseren van enkele problemen die zich niet eerder hadden voorgedaan, maar uiteindelijk heeft dit onze architectonische oplossing niet erg vertroebeld. Als je iets nieuws wilt en niet bang bent, en tegelijkertijd niet al te teleurgesteld wilt zijn, bereid je dan voor op het feit dat niets gratis is. Je zult meer moeten begrijpen, je in de documentatie moeten verdiepen en je eigen individuele hark moeten samenstellen dan in de oude bestaande oplossing, en geen enkele theorie zal je van tevoren vertellen welke hark op je wacht.
Bron: www.habr.com