Azt mondják, hogy az életben mindent érdemes legalább egyszer kipróbálni. Ha pedig relációs DBMS-ekkel szokott dolgozni, akkor érdemes a gyakorlatban is megismerkedni a NoSQL-lel, legalábbis az általános fejlesztés miatt. Jelenleg ennek a technológiának a rohamos fejlődése miatt sok egymásnak ellentmondó vélemény és heves vita folyik ebben a témában, ami különösen felkelti az érdeklődést.
Ha elmélyül ezeknek a vitáknak a lényegében, láthatja, hogy a helytelen megközelítés miatt merülnek fel. Azok, akik pontosan ott használják a NoSQL adatbázisokat, ahol szükség van rájuk, elégedettek, és minden előnyben részesülnek a megoldásból. Azok a kísérletezők pedig, akik erre a technológiára mint csodaszerre támaszkodnak ott, ahol egyáltalán nem alkalmazható, csalódottak, mivel elvesztették a relációs adatbázisok erősségeit anélkül, hogy jelentős előnyökhöz jutottak volna.
Elmesélem a Cassandra DBMS-re épülő megoldás bevezetésével kapcsolatos tapasztalatainkat: mivel kellett szembesülnünk, hogyan kerültünk ki a nehéz helyzetekből, tudtunk-e hasznot húzni a NoSQL használatából, és hová kellett további erőfeszítéseket/forrásokat fektetni. .
A kezdeti feladat egy olyan rendszer felépítése, amely valamilyen tárolóban rögzíti a hívásokat.
A rendszer működési elve a következő. A bemenet meghatározott szerkezetű fájlokat tartalmaz, amelyek leírják a hívás szerkezetét. Az alkalmazás ezután gondoskodik arról, hogy ezt a struktúrát a megfelelő oszlopokban tárolja. Az elmentett hívások a jövőben az előfizetők forgalmi fogyasztási adatainak megjelenítésére szolgálnak (díjak, hívások, egyenlegelőzmények).
Teljesen világos, hogy miért választották Cassandrát – úgy ír, mint egy géppuska, könnyen méretezhető és hibatűrő.
Szóval, ez az, amit a tapasztalat adott nekünk
Igen, a meghibásodott csomópont nem tragédia. Ez Cassandra hibatűrésének a lényege. De egy csomópont életben lehet, és ugyanakkor csökkenni kezd a teljesítményben. Mint kiderült, ez azonnal kihat a teljes klaszter teljesítményére.
Cassandra nem véd meg ott, ahol az Oracle megmentett a korlátaival. És ha az alkalmazás szerzője ezt előre nem értette, akkor a Cassandra számára érkezett dupla nem rosszabb, mint az eredeti. Ha megérkezett, betesszük.
IB-nek nagyon nem tetszett az ingyenes Cassandra a dobozból: Nincs a felhasználói műveletek naplózása, a jogok megkülönböztetése. A hívásokkal kapcsolatos információk személyes adatnak minősülnek, ami azt jelenti, hogy minden kérés/módosítási kísérletet naplózni kell az utólagos ellenőrzés lehetőségével. Ezenkívül tisztában kell lennie azzal, hogy a különböző felhasználók jogait különböző szinten kell elkülöníteni. Egy egyszerű üzemeltetési mérnök és egy szuper adminisztrátor, aki szabadon törölheti a teljes kulcsteret, különböző szerepkörrel, különböző felelősségekkel és kompetenciákkal rendelkezik. A hozzáférési jogok ilyen differenciálása nélkül az adatok értéke és sértetlensége azonnal gyorsabban megkérdőjelezhető, mint BÁRMELY konzisztencia szinten.
Nem vettük figyelembe, hogy a hívások komoly elemzést és időszakos mintavételt igényelnek különböző körülmények között. Mivel a kiválasztott rekordokat ezután törölni és újra kell írni (a feladat részeként támogatnunk kell az adatok frissítésének folyamatát, amikor az adatok kezdetben hibásan kerültek be a hurokba), Cassandra itt nem a barátunk. A Cassandra olyan, mint egy malacpersely - kényelmes belerakni a dolgokat, de nem számíthatsz bele.
Hiba történt az adatok tesztzónákba való átvitele során (5 csomópont a tesztben, szemben 20 a bálban). Ebben az esetben a dump nem használható.
Probléma a Cassandrának írt alkalmazás adatsémájának frissítésével. A visszaállítás nagyon sok sírkövet generál, ami kiszámíthatatlan módon a termelékenység csökkenéséhez vezethet.. A Cassandra felvételre van optimalizálva, és nem sokat gondolkodik írás előtt, minden olyan művelet, amelyben meglévő adatok vannak, egyben felvétel is. Vagyis a felesleges törlésével egyszerűen még több rekordot fogunk gyártani, és ezek közül csak néhány lesz sírkővel.
Időtúllépések beszúráskor. Cassandra gyönyörű a felvételen, de néha a bejövő áramlás jelentősen megzavarhatja őt. Ez akkor fordul elő, ha az alkalmazás elkezd körbejárni több olyan rekordot, amelyeket valamilyen okból nem lehet beilleszteni. És szükségünk lesz egy igazi DBA-ra, aki figyeli a gc.log-ot, a rendszer- és hibakeresési naplókat a lassú lekérdezésekhez, a mérőszámokat a tömörítés függőben.
Több adatközpont egy fürtben. Honnan érdemes olvasni és hova írni?
Talán olvasásra és írásra oszlik? És ha igen, kell-e közelebbi DC az íráshoz vagy olvasáshoz? És vajon nem lesz-e igazi megosztott agyunk, ha rossz konzisztenciaszintet választunk? Rengeteg kérdés, sok ismeretlen beállítás, lehetőség van, amivel nagyon szeretne bütykölni.
Hogyan döntöttünk
A csomópont süllyedésének megakadályozása érdekében a SWAP le van tiltva. És most, ha hiányzik a memória, a csomópontnak le kell mennie, és nem kell nagy gc szüneteket létrehoznia.
Így többé nem hagyatkozunk az adatbázis logikájára. Az alkalmazásfejlesztők átképzik magukat, és elkezdik aktívan megtenni az óvintézkedéseket saját kódjukban. Az adattárolás és -feldolgozás ideális elkülönítése.
Támogatást vásároltunk a DataStax-tól. A dobozos Cassandra fejlesztése már leállt (utolsó commit 2018 februárjában volt). Ugyanakkor a Datastax kiváló szolgáltatást és nagyszámú módosított és adaptált megoldást kínál a meglévő IP-megoldásokhoz.
Azt is szeretném megjegyezni, hogy a Cassandra nem túl kényelmes a kiválasztási lekérdezésekhez. Természetesen a CQL nagy előrelépés a felhasználók számára (a Trifthez képest). De ha vannak egész osztályai, amelyek hozzászoktak az ilyen kényelmes csatlakozásokhoz, a tetszőleges mezők szerinti ingyenes szűréshez és a lekérdezésoptimalizálási lehetőségekhez, és ezek a részlegek a panaszok és balesetek megoldásán dolgoznak, akkor a Cassandra megoldás ellenségesnek és ostobának tűnik számukra. És elkezdtük eldönteni, hogyan készítsenek mintát kollégáink.
Két lehetőséget mérlegeltünk, az elsőben nem csak C*-ban írunk hívásokat, hanem az archivált Oracle adatbázisba is. Csak a C*-val ellentétben ez az adatbázis csak az aktuális hónapra vonatkozó hívásokat tárolja (elegendő hívástárolási mélység az esetek feltöltéséhez). Itt rögtön a következő problémát láttuk: ha szinkronban írunk, akkor elveszítjük a C* gyors beszúrással járó minden előnyét, ha aszinkron módon írunk, nincs garancia arra, hogy minden szükséges hívás egyáltalán bekerült az Oracle-be. Volt egy plusz, de egy nagy: a működéshez ugyanaz a megszokott PL/SQL Developer marad, azaz gyakorlatilag a „Homlokzat” mintát valósítjuk meg. Alternatív lehetőség. Megvalósítunk egy olyan mechanizmust, amely eltávolítja a C*-ból érkező hívásokat, az Oracle megfelelő tábláiból gyűjt néhány adatot gazdagítás céljából, összekapcsolja a kapott mintákat, és megadja az eredményt, amelyet aztán valamilyen módon felhasználunk (visszatekerünk, ismételünk, elemzünk, csodálunk). Hátrányok: a folyamat meglehetősen többlépcsős, ráadásul nincs felület az üzemeltetési alkalmazottak számára.
Végül a második lehetőség mellett döntöttünk. Apache Sparkot használtak a különböző tégelyekből való mintavételhez. A mechanizmus lényege a Java kódra redukálódott, amely a megadott kulcsok (előfizető, hívási idő - szakaszkulcsok) segítségével adatokat húz ki a C*-ból, valamint a gazdagításhoz szükséges adatokat bármely más adatbázisból. Ezután egyesíti őket a memóriájában, és megjeleníti az eredményt a kapott táblázatban. Rajzoltunk egy weblapot a szikra fölé, és egész használhatónak bizonyult.
Az ipari tesztadatok frissítésének problémájának megoldása során ismét több megoldást mérlegeltünk. Mind az Sstloaderen keresztüli átvitel, mind a tesztzónában lévő fürt két részre való felosztása, amelyek felváltva ugyanahhoz a fürthöz tartoznak a promóciós fürttel, így az táplálja. A tesztfrissítésnél ezek cseréjét tervezték: a tesztben működő rész törlődik és gyártásba kerül, a másik pedig külön kezd el dolgozni az adatokkal. Újragondolva azonban racionálisabban felmértük azokat az adatokat, amelyeket érdemes volt átvinni, és rájöttünk, hogy a hívások önmagukban inkonzisztens entitást jelentenek a tesztekhez, szükség esetén gyorsan generálódnak, és a promóciós adatkészletnek nincs értéke az átvitelre. teszt. Több tároló tárgyat is érdemes mozgatni, de ezek szó szerint pár asztal, és nem túl nehézek. Ezért mi megoldásként ismét a Spark jött segítségül, aminek segítségével írtunk és elkezdtünk aktívan használni egy táblák közötti adatátvitelre alkalmas szkriptet, prom-teszt.
Jelenlegi telepítési szabályzatunk lehetővé teszi, hogy visszaállítások nélkül dolgozzunk. A promó előtt kötelező próbaüzem, ahol nem is olyan drága egy hiba. Meghibásodás esetén bármikor eldobhatja az esetteret, és az egész sémát az elejétől kezdve görgetheti.
A Cassandra folyamatos elérhetőségének biztosításához szüksége van egy dba-ra, és nem csak neki. Mindenkinek, aki az alkalmazással dolgozik, meg kell értenie, hol és hogyan tekintse meg a jelenlegi helyzetet, és hogyan diagnosztizálja időben a problémákat. Ehhez aktívan használjuk a DataStax OpsCenter-t (terhelések adminisztrációja és felügyelete), a Cassandra Driver rendszer mérőszámait (C*-ba írási időtúllépések száma, C*-ból való olvasási időkorlátok száma, maximális késleltetés stb.), figyeljük a működést. magáról az alkalmazásról, Cassandrával együttműködve.
Amikor átgondoltuk az előző kérdést, rájöttünk, hogy hol rejlik a fő kockázatunk. Ezek olyan adatmegjelenítési űrlapok, amelyek több független lekérdezés adatait jelenítik meg a tárolóban. Így meglehetősen ellentmondásos információkhoz juthatunk. De ez a probléma ugyanolyan fontos lenne, ha csak egy adatközponttal dolgoznánk. Tehát itt a legésszerűbb dolog természetesen egy kötegelt funkció létrehozása harmadik féltől származó alkalmazások adatainak olvasásához, amely biztosítja, hogy az adatok egyetlen időn belül megérkezzenek. Ami a teljesítmény tekintetében az olvasásra és írásra való felosztást illeti, itt megállított az a veszély, hogy a DC-k közötti kapcsolat némi elvesztésével két, egymással teljesen össze nem egyeztethető klaszterhez juthatunk.
Ennek eredményeként egyelőre megállt a konzisztencia szintjén az EACH_QUORUM írásnál, az olvasásnál - LOCAL_QUORUM
Rövid benyomások és következtetések
Annak érdekében, hogy az így létrejött megoldást a működési támogatás és a további fejlesztési kilátások szempontjából értékeljük, úgy döntöttünk, hogy átgondoljuk, hol lehetne még alkalmazni egy ilyen fejlesztést.
Rögtön, majd adatpontozás az olyan programoknál, mint a „Fizessen, amikor kényelmes” (információkat töltünk be C*-ba, számításokat használunk Spark-szkriptekkel), a követelések elszámolása terület szerinti összesítéssel, szerepek tárolása és felhasználói hozzáférési jogok kiszámítása a szerepkör alapján. mátrix.
Mint látható, a repertoár széles és változatos. Ha pedig a NoSQL támogatói/ellenzői táborát választjuk, akkor mi is csatlakozunk a támogatókhoz, hiszen az előnyeinket megkaptuk, és pontosan ott, ahol vártuk.
Még a dobozból kivett Cassandra opció is lehetővé teszi a vízszintes skálázást valós időben, teljesen fájdalommentesen megoldva a rendszerben lévő adatnövekedés problémáját. Sikerült egy nagyon nagy terhelésű hívási aggregátumok számítására szolgáló mechanizmust egy külön áramkörbe helyezni, valamint az alkalmazási sémát és a logikát is különválasztani, így megszabadultunk attól a rossz gyakorlattól, hogy az egyéni feladatokat és objektumokat magába az adatbázisba írjuk. Lehetőségünk volt kiválasztani és konfigurálni, felgyorsítani, hogy mely DC-ken végezzünk számításokat és melyiken rögzítsünk adatokat, biztosítottuk magunkat az egyes csomópontok és a DC egészének összeomlása ellen.
Az architektúránkat új projektekre alkalmazva, és már némi tapasztalattal szeretnék azonnal figyelembe venni a fent leírt árnyalatokat, és megelőzni néhány hibát, kisimítani néhány éles sarkot, amelyeket kezdetben nem lehetett elkerülni.
Például időben nyomon követheti Cassandra frissítéseitmert a kapott problémák közül jó néhányat már ismertek és javítottak.
Ne tegye magát az adatbázist és a Sparkot is ugyanazon a csomóponton (vagy szigorúan el kell osztani a megengedett erőforrás-felhasználással), mivel a Spark a vártnál több OP-t tud megenni, és gyorsan megkapjuk a listánk 1-es számú problémáját.
Javítani kell a felügyeletet és a működési kompetenciát a projekt tesztelési szakaszában. Kezdetben a lehető legnagyobb mértékben vegye figyelembe megoldásunk összes potenciális fogyasztóját, mert az adatbázis szerkezete végső soron ezen múlik.
A lehetséges optimalizáláshoz forgassa el többször a kapott áramkört. Válassza ki, mely mezők sorosíthatók. Értsük meg, milyen további táblázatokat kell készítenünk a leghelyesebb és optimálisabb számításba vétel érdekében, majd kérésre megadjuk a szükséges információkat (például feltételezve, hogy ugyanazokat az adatokat különböző táblákban tárolhatjuk, figyelembe véve a különböző bontásokat különböző kritériumok alapján jelentősen megtakaríthatjuk a CPU-időt az olvasási kérésekre).
nem rossz Azonnal gondoskodjon a TTL csatolásáról és az elavult adatok tisztításáról.
Amikor adatokat tölt le Cassandráról Az alkalmazási logikának a FETCH elven kell működnie, hogy ne egyszerre töltsön be minden sort a memóriába, hanem kötegenként kerüljön kiválasztásra.
Célszerű a projektnek a leírt megoldásra való átvitele előtt töréstesztek sorozatával ellenőrizze a rendszer hibatűrését, mint például az adatvesztés egy adatközpontban, a sérült adatok bizonyos időszakon keresztüli helyreállítása, az adatközpontok közötti hálózati leállás. Az ilyen tesztek nemcsak a javasolt architektúra előnyeinek és hátrányainak értékelését teszik lehetővé, hanem jó bemelegítési gyakorlatot is biztosítanak az azokat lebonyolító mérnökök számára, és az elsajátított készség korántsem lesz felesleges, ha a rendszerhibák a gyártás során újratermelődnek.
Ha kritikus információkkal dolgozunk (például számlázási adatok, előfizetői tartozás számítása), akkor érdemes odafigyelni olyan eszközökre is, amelyek csökkentik a DBMS tulajdonságaiból adódó kockázatokat. Például használja a nodesync segédprogramot (Datastax), miután kidolgozott egy optimális stratégiát a használatához. a következetesség kedvéért ne okozzon túlzott terhelést Cassandrának és csak bizonyos táblákhoz használja egy bizonyos időszakban.
Mi történik Cassandrával hat hónapos élet után? Általánosságban elmondható, hogy nincsenek megoldatlan problémák. Súlyos baleseteket vagy adatvesztést sem engedtünk meg. Igen, gondolnunk kellett néhány olyan probléma kompenzálására, amelyek korábban fel nem merültek, de ez végül nem borította el nagyon az építészeti megoldásunkat. Ha szeretnél és nem félsz valami újat kipróbálni, ugyanakkor nem akarsz nagyon csalódni, akkor készülj fel arra, hogy semmi sincs ingyen. Többet kell értenie, bele kell mélyednie a dokumentációba és össze kell állítania saját egyedi gereblyét, mint a régi, örökölt megoldásban, és egyetlen elmélet sem fogja megmondani előre, hogy melyik rake várja Önt.
Forrás: will.com