de verkeerde manier om Cassandra DB op te schalen als er secundaire indexen zijn
Cassandra is om vele redenen Mijn favoriete (niet beheerde) database: Het heeft geen single point of failure (SPoF), ondersteunt multi-region, goed voor lezen en schrijven ops, flexibel over lezen en schrijven consistentieniveaus, schaalt lineair en niet te complex om te beheren voor dagelijkse operaties.
zoals elke database, moet u Cassandra gebruiken op basis van uw toegangspatronen, dus als u een flexibele database nodig hebt voor ad-hoc query ‘ s of aanpasbaar genoeg voor voortdurende veranderingen in het databasemodel, moet u andere opties overwegen.
Cassandra is een kolom-georiënteerde DB en het is echt krachtig wanneer u uw gegevens queries al gedefinieerd. Datastax, het bedrijf dat Cassandra ondersteunt, raadt u aan om te beginnen met het ontwerpen van uw query ‘ s en vervolgens uw datamodel in Cassandra. Ondanks het feit van uw zuilvormige structuur, ondersteunt Cassandra veel datastructuren als een kolom(s) type, zoals kaarten.
Cassandra is een primaire sleuteldatabase, wat betekent dat uw gegevens worden bewaard en georganiseerd rond een cluster op basis van de hashwaarde (de partitiesleutel) van de primaire sleutel. Voor tabellen die meer dan één PK hebben, beschouwt Cassandra alleen het eerste deel van de PK als zijn partitiesleutel. Meer informatie over samengestelde toetsen vindt u hier.
om duidelijker te zijn, laten we teruggaan naar een van de belangrijkste kenmerken van een Cassandra DB: het is architectuur en het feit dat het geen SPoF heeft.
een Cassandra-cluster bestaat uit knopen (3 of meer) en die knopen vormen samen een ring van knopen:
Elk knooppunt op een Cassandra ‘ s cluster werkt “zelfstandig”, maar de verschillende knooppunten te kunnen bewaren dezelfde gegevens dienovereenkomstig de replicatie factor (RF) configuratie geconfigureerd voor het cluster.
om te weten waar (welk knooppunt) uw gegevens blijven staan, gebruikt Cassandra de hashwaarde (token) berekend door middel van een consistente hash-functie met behulp van de PK-kolom van een bepaalde tabel.
wanneer u een query uitvoert, zal het coördinator knooppunt (normaal gesproken het dichtst bij een van uw applicatieinstanties) zoeken naar welke knooppunten in een ring uw gegevens bevatten, op die manier kan een ander knooppunt uw gegevens dienen (RF ≥2). Dat is de magie van een meesterloze benadering, waarbij elk knooppunt in een ring gelijk is in termen van lezen en schrijven.
dit concept over PK en de replicatiefactor is erg belangrijk om te begrijpen hoe u uw Cassandra cluster kunt schalen wanneer uw toepassing onder hoge belastingomstandigheden is.
secundaire registers
Cassandra heeft ook het begrip secundaire registers. In relationele databases, kunt u veel indexen in een bepaalde tabel, de kosten van een secundaire index wordt geassocieerd met schrijf operaties, niet voor lezen operaties. In Cassandra is dit niet waar.
secundaire indexen in Cassandra kunnen nuttig en verleidelijk zijn wanneer uw datamodel is veranderd en u een zoekopdracht moet uitvoeren op basis van een nieuwe kolom.
Op die manier, met een secundaire index, kon u een query uitvoert zoals dat:
SELECTEER * UIT mijn_tabel WAAR SECONDARY_INDEX = ‘waarde’;
Het probleem over het gebruik van een Secundaire Index
Stel je het scenario: je bent in een Blackfriday/CyberMonday en uw Cassandra cluster is het lijden van peak events en je nodig hebt om meer toe te voegen knooppunten op de schaal van uw database, balanceren beter uw verkeer en… overleven. Goed, toch?
normaal is het een normale situatie in een zeer schaalbare toepassing. Maar hoe zit het als uw applicatie draait queries met behulp van een secundaire index?
Ja, je snapt het wel.
Weet je nog dat ik zei dat Cassandra gegevens in een ring distribueert met behulp van de partitiesleutel? Dit gebeurt al, maar het probleem is wanneer u een secundaire index in uw zoekopdracht. Secundaire indexen maken geen deel uit van een partitiesleutel, en Cassandra weet waar je gegevens door de partitiesleutel leven. Wanneer je een query uitvoert die dit soort index gebruikt, zoekt Cassandra naar elk knooppunt in je ring om je query te voldoen.
Real Scenario
tijdens een Blackfriday waren onze toepassingen met hoge belastingen. Veel en veel klanten die willen profiteren van de enorme kortingen die worden geboden door een Blackfriday-evenement.
we namen een kijkje op onze APM en alle analyse leidde ons tot onze volharding, in dit geval een Cassandra DB. We hebben lange periodes van latency, maar niet voor elk verzoek, alleen voor sommige.
proberen om dingen weer terug te houden naar de normale toestand, onze eerste manoeuvre was om meer knooppunten toe te voegen aan onze Cassandra cluster.
We voegden toe en we lijden nog steeds aan latency problemen. De vraag was: waarom gebeurt dit nog steeds?
we hadden het mis. Het was een simplistische conclusie en we zorgden niet voor een zeer belangrijk detail: dit gedrag gebeurde niet in alle verzoeken, maar in sommige van hen.
als u dacht aan de secundaire index, bingo! Dat was precies het probleem.
het toevoegen van knooppunten zou het probleem nooit oplossen, omdat het probleem niet gerelateerd was aan alle query ‘ s die in de database kwamen, was het probleem in sommige en dat waren de echte die de prestaties van de database verslechterden. Het was een Pareto ding.
gedetailleerde beschrijving van het probleem en hoe we het oplossen
Eén moment voor de Blackfriday-gebeurtenis moesten we ons datamodel wijzigen. We regionaliseerden onze applicatie en de regio van de klant begon voor ons belangrijk te worden, we moesten gegevens opvragen op basis van een product of regio.
terugkijkend en de punten met elkaar verbonden, konden we ons realiseren dat we zeer waardevol waren over de implementatie omdat we dit nieuwe gedrag wilden weerspiegelen, niet alleen in de API-laag (new query param), maar ook in de manier waarop we toegang hadden tot de gegevens in Cassandra.
en waarom waren we zo kostbaar? Want zelfs gezien het feit dat onze Vraag tijd niet zo veel toegenomen, we deden de verandering.
die implementatie verhoogde niet alleen onze query tijd door het gebruik van een secundaire index, maar genereerde ook meer problemen volgens we opgeschaald Cassandra ‘ s Infrastructuur. Aangezien we meer knooppunten in ons cluster hebben toegevoegd, betekende dit meer knooppunten om op te zoeken om de gegevens te vinden, waardoor het probleem exponentieel toenam.
om het probleem te beperken, namen we het aantal knooppunten terug dat we eerder hadden en verhoogden we de replicatiefactor voor de meerderheid van onze knooppunten in het cluster.
we hebben ook ons leesconsistentieniveau gewijzigd om minder consistent te zijn. We gebruikten *QUORUM en in plaats daarvan veranderden we in een. Dit hielp ons om de belasting in knooppunten te verlagen.
toen we onze applicaties dagen voor de gebeurtenis bevroor, wisten we dat we geen nieuwe gegevens hadden (schrijfbewerkingen) en dat de gegevens consistent zouden zijn in hun huidige toestand.
de dagen erna en de DB-modeloplossing
als onderdeel van de uiteindelijke oplossing moesten we (opnieuw)nadenken over ons databasemodel en de wijzigingen die we deden terugdraaien als mitigatiepad tijdens het evenement.
voor de gebeurtenis gebruikten we de product ID (PID) als de partitiesleutel, wat een goede beslissing was, omdat de PID goede attributen heeft om een PK te zijn vanwege zijn aard over het feit dat het een sequentieel getal (hoge kardinaliteit) is, en op die manier de gegevens gelijkmatig over het cluster verspreidde.
over het nieuwe veld “Regio” gebruiken we Cassandra collections-gegevenstype en gebruikten we een kaart voor elke regio als kolom in onze producttabel.
secundaire indexen zijn altijd een slecht idee?
het korte antwoord is nee.
om iets beter uit te leggen, zijn er twee soorten indexen in Cassandra: lokale en globale indexen.
een lokale index zoals de naam al zegt is een soort index die alleen lokaal bestaat, dat wil zeggen in een knooppunt. Wanneer u een secundaire index maakt, maakt Cassandra een nieuwe (verborgen) tabel waar de secundaire een primaire sleutel in deze tabel wordt. De zichtbaarheid van deze nieuwe tabel is in termen van een knoop, niet een ring (cluster). Dat is het geval bij secundaire indexen.
aan de andere kant heeft een globale index ringzicht via zijn partitiesleutel, dus Cassandra weet waar je gegevens in een ring zijn via die partitiesleutel.
secundaire indexen kunnen een alternatief zijn, wanneer u in een query zowel: primaire als secundaire indexen hebt. In dat geval Weet Cassandra waar uw gegevens zich bevinden (welk knooppunt) via de partitiesleutel en zoekt vervolgens de lokale tabel op in het knooppunt dat verwijst naar de (lokale) secundaire indexen.
er zijn ook enkele andere nuances over secundaire indexen die hier zeer goed worden uitgelegd, maar de beste praktijk is om ze te vermijden door uw datamodel te denormaliseren.
