He sanovat, että kaikki elämässä on kokeilemisen arvoista ainakin kerran. Ja jos olet tottunut työskentelemään relaatiotietokantajärjestelmien kanssa, niin NoSQL:ään kannattaa tutustua käytännössä, ainakin yleisen kehityksen kannalta. Nyt tämän tekniikan nopean kehityksen vuoksi aiheesta on paljon ristiriitaisia mielipiteitä ja kiivasta keskustelua, mikä herättää erityisesti kiinnostusta.
Jos perehdyt kaikkien näiden riitojen olemukseen, voit nähdä, että ne johtuvat väärästä lähestymistavasta. Ne, jotka käyttävät NoSQL-tietokantoja juuri siellä, missä niitä tarvitaan, ovat tyytyväisiä ja saavat kaikki tämän ratkaisun edut. Ja kokeilijat, jotka luottavat tähän tekniikkaan ihmelääkenä siellä, missä sitä ei voida soveltaa ollenkaan, ovat pettyneitä, koska he ovat menettäneet relaatiotietokantojen vahvuudet saamatta merkittäviä etuja.
Kerron kokemuksistamme Cassandra DBMS:ään perustuvan ratkaisun käyttöönotosta: mitä jouduimme kohtaamaan, kuinka selvisimme vaikeista tilanteista, pystyimmekö hyötymään NoSQL:n käytöstä ja mihin jouduimme investoimaan lisäpanostuksia/varoja .
Alkutehtävä on rakentaa järjestelmä, joka tallentaa puhelut jonkinlaiseen muistiin.
Järjestelmän toimintaperiaate on seuraava. Syöte sisältää tietyn rakenteen omaavia tiedostoja, jotka kuvaavat kutsun rakenteen. Sovellus varmistaa sitten, että tämä rakenne on tallennettu asianmukaisiin sarakkeisiin. Tallennettuja puheluita käytetään jatkossa tilaajien liikenteen kulutuksen (maksut, puhelut, saldohistoria) näyttämiseen.
On aivan selvää, miksi he valitsivat Cassandran - hän kirjoittaa kuin konekivääri, on helposti skaalautuva ja vikasietoinen.
Joten tämän kokemuksen meille antoi
Kyllä, epäonnistunut solmu ei ole tragedia. Tämä on Cassandran vikasietoisuuden ydin. Mutta solmu voi olla elossa ja samalla alkaa kärsiä suorituskyvystään. Kuten kävi ilmi, tämä vaikuttaa välittömästi koko klusterin suorituskykyyn.
Cassandra ei suojele sinua siellä, missä Oracle pelasti sinut rajoitteineen. Ja jos sovelluksen kirjoittaja ei ymmärtänyt tätä etukäteen, Cassandralle saapunut tupla ei ole huonompi kuin alkuperäinen. Kun se on saapunut, laitamme sen sisään.
IB ei pitänyt kovasti ilmaisesta Cassandrasta ulos laatikosta: Käyttäjän toimintoja ei kirjata lokiin, oikeuksia ei erotella. Puhelutiedot katsotaan henkilötiedoiksi, mikä tarkoittaa, että kaikki yritykset pyytää/muuttaa niitä millään tavalla on kirjattava ja mahdollista myöhempään tarkastukseen. Sinun on myös oltava tietoinen tarpeesta erottaa oikeudet eri tasoilla eri käyttäjille. Yksinkertaisella käyttösuunnittelijalla ja pääkäyttäjällä, joka voi vapaasti poistaa koko avaintilan, on eri roolit, erilaiset vastuut ja pätevyydet. Ilman tällaista käyttöoikeuksien eriyttämistä tiedon arvo ja eheys tulevat välittömästi kyseenalaiseksi nopeammin kuin MILLOIN johdonmukaisuustasolla.
Emme ottaneet huomioon, että kutsut vaativat sekä vakavaa analytiikkaa että säännöllistä näytteenottoa erilaisissa olosuhteissa. Koska valitut tietueet on sitten tarkoitus poistaa ja kirjoittaa uudelleen (osana tehtävää meidän on tuettava tietojen päivitysprosessia, kun tiedot alun perin tulivat silmukkaan väärin), Cassandra ei ole ystävämme täällä. Cassandra on kuin säästöpossu - siihen on kätevä laittaa tavaroita, mutta siihen ei voi laskea.
Havaitsimme ongelman tietojen siirtämisessä testivyöhykkeille (5 solmua testissä vs. 20 promootiossa). Tässä tapauksessa kaatopaikkaa ei voi käyttää.
Ongelma Cassandraan kirjoittavan sovelluksen tietoskeeman päivittämisessä. Peruutus synnyttää paljon hautakiviä, mikä voi johtaa tuottavuuden menetyksiin arvaamattomilla tavoilla.. Cassandra on optimoitu tallennusta varten, eikä ajattele paljon ennen kirjoittamista. Mikä tahansa operaatio olemassa olevan datan kanssa on myös tallennus. Eli poistamalla tarpeettomat tuotamme yksinkertaisesti vielä enemmän levyjä ja vain osa niistä merkitään hautakivillä.
Aikakatkaisut lisättäessä. Cassandra on kaunis äänitteessä, mutta joskus saapuva virta voi hämmentää häntä merkittävästi. Tämä tapahtuu, kun sovellus alkaa kiertää useita tietueita, joita ei jostain syystä voida lisätä. Ja tarvitsemme todellisen DBA:n, joka tarkkailee gc.logia, järjestelmä- ja virheenkorjauslokeja hitaiden kyselyjen varalta, tiivistämisen mittareita.
Useita palvelinkeskuksia klusterissa. Mistä lukea ja mistä kirjoittaa?
Ehkä jakautuminen lukemiseen ja kirjoittamiseen? Ja jos on, pitäisikö kirjoitus- tai lukemissovellusta olla lähempänä DC:tä? Ja emmekö päädy todelliseen jakautuneeseen aivoon, jos valitsemme väärän johdonmukaisuustason? On paljon kysymyksiä, paljon tuntemattomia asetuksia, mahdollisuuksia, joiden kanssa todella haluat puuhailla.
Kuinka päätimme
Solmun uppoamisen estämiseksi SWAP poistettiin käytöstä. Ja nyt, jos muistista puuttuu, solmun pitäisi mennä alas eikä luoda suuria gc-taukoja.
Emme siis enää luota tietokannan logiikkaan. Sovelluskehittäjät kouluttavat itseään uudelleen ja alkavat ryhtyä aktiivisesti varotoimiin omassa koodissaan. Ihanteellinen selkeä ero tiedon tallennuksen ja käsittelyn välillä.
Ostimme tuen DataStaxilta. Boxed Cassandran kehitys on jo päättynyt (edellinen sitoumus oli helmikuussa 2018). Samaan aikaan Datastax tarjoaa erinomaista palvelua ja suuren määrän muunneltuja ja mukautettuja ratkaisuja olemassa oleviin IP-ratkaisuihin.
Haluan myös huomauttaa, että Cassandra ei ole kovin kätevä valintakyselyihin. Tietenkin CQL on iso askel eteenpäin käyttäjille (verrattuna Triftiin). Mutta jos sinulla on kokonaisia osastoja, jotka ovat tottuneet sellaisiin käteviin liitoksiin, ilmaiseen suodatukseen minkä tahansa kentän mukaan ja kyselyn optimointiominaisuuksiin, ja nämä osastot pyrkivät ratkaisemaan valituksia ja onnettomuuksia, Cassandra-ratkaisu vaikuttaa heistä vihamieliseltä ja tyhmältä. Ja aloimme päättää, kuinka kollegojemme pitäisi tehdä näytteitä.
Harkitsimme kahta vaihtoehtoa: ensimmäisessä vaihtoehdossa kirjoitamme puhelut paitsi C*:n lisäksi myös arkistoituun Oracle-tietokantaan. Vain toisin kuin C*, tämä tietokanta tallentaa vain kuluvan kuukauden puhelut (riittävä puhelujen tallennussyvyys latauskoteloiden lataamiseen). Tässä näimme heti seuraavan ongelman: jos kirjoitamme synkronisesti, menetämme kaikki C*:n nopeaan lisäykseen liittyvät edut; jos kirjoitamme asynkronisesti, ei ole mitään takeita siitä, että kaikki tarvittavat puhelut pääsivät Oracleen ollenkaan. Siinä oli yksi plussa, mutta iso: toimintaan jää sama tuttu PL/SQL Developer, eli käytännössä toteutamme "Facade" -mallin.Vaihtoehtoinen vaihtoehto. Toteutamme mekanismin, joka purkaa puhelut C*:sta, hakee rikastettaviksi tietoja Oraclen vastaavista taulukoista, yhdistää tuloksena olevat näytteet ja antaa meille tuloksen, jota sitten jollakin tavalla käytämme (palaa taaksepäin, toista, analysoi, ihaile). Miinukset: prosessi on melko monivaiheinen, eikä käyttöliittymää ole käyttöhenkilöstölle.
Lopulta päädyimme toiseen vaihtoehtoon. Apache Sparkia käytettiin näytteiden ottamiseen eri purkkeista. Mekanismin ydin on pelkistetty Java-koodiksi, joka käyttämällä määritettyjä avaimia (tilaaja, soittoaika - osionäppäimet) vetää tiedot C*:sta sekä rikastamiseen tarvittavat tiedot mistä tahansa muusta tietokannasta. Tämän jälkeen se yhdistää ne muistiinsa ja näyttää tuloksen tuloksena olevassa taulukossa. Piirsimme verkkopinnan kipinän päälle ja siitä tuli varsin käyttökelpoinen.
Ratkaiseessamme teollisten testitietojen päivitysongelmaa harkitsimme jälleen useita ratkaisuja. Sekä siirto Sstloaderin kautta että mahdollisuus jakaa testivyöhykkeellä oleva klusteri kahteen osaan, joista kumpikin kuuluu vuorotellen samaan klusteriin promootioklusterin kanssa, joten se saa virtansa siitä. Testiä päivitettäessä suunniteltiin niiden vaihtoa: testissä toiminut osa tyhjennetään ja viedään tuotantoon, ja toinen alkaa työskennellä tietojen kanssa erikseen. Uudelleen mietittyämme arvioimme kuitenkin järkevämmin siirron arvoista dataa ja huomasimme, että puhelut itsessään ovat epäjohdonmukainen kokonaisuus testeille, jotka generoidaan tarvittaessa nopeasti, ja juuri mainosaineistolla ei ole arvoa siirrettäväksi testata. Siirtämisen arvoisia säilytysesineitä on useita, mutta nämä ovat kirjaimellisesti pari pöytää, eivätkä kovin raskaita. Siksi me ratkaisuna tuli jälleen apuun Spark, jonka avulla kirjoitimme ja alettiin aktiivisesti käyttää skriptiä tiedon siirtämiseen taulukoiden välillä, prom-test.
Nykyinen käyttöönottokäytäntömme mahdollistaa työskentelyn ilman peruutuksia. Ennen promoa on pakollinen koeajo, jossa virhe ei ole niin kallis. Epäonnistumisen sattuessa voit aina pudottaa tapaustilan ja rullata koko kaavion alusta.
Cassandran jatkuvan saatavuuden varmistamiseksi tarvitset dba:n etkä vain häntä. Jokaisen sovelluksen parissa työskentelevän on ymmärrettävä, mistä ja miten nykytilannetta tarkastellaan ja kuinka ongelmat voidaan diagnosoida ajoissa. Käytämme tähän aktiivisesti DataStax OpsCenteriä (työkuormien hallinta ja valvonta), Cassandra Driver -järjestelmän mittareita (C*:een kirjoittamisen aikakatkaisujen määrä, C*:sta lukemisen aikakatkaisujen määrä, maksimiviive jne.), valvomme toimintaa itse sovelluksesta työskentelemällä Cassandran kanssa.
Kun mietimme edellistä kysymystä, ymmärsimme, missä suurin riskimme saattaa olla. Nämä ovat tietojen näyttölomakkeita, jotka näyttävät tietoja useista itsenäisistä kyselyistä tallennustilaan. Näin voimme saada melko epäjohdonmukaista tietoa. Mutta tämä ongelma olisi yhtä tärkeä, jos työskentelemme vain yhden datakeskuksen kanssa. Joten järkevintä tässä on tietysti luoda erätoiminto tietojen lukemiseen kolmannen osapuolen sovelluksessa, mikä varmistaa tietojen vastaanottamisen yhdessä ajassa. Mitä tulee suorituskyvyn jakautumiseen lukemiseen ja kirjoittamiseen, meitä pysäytti riski, että DC:iden välisen yhteyden katketessa voisimme päätyä kahteen klusteriin, jotka ovat täysin ristiriidassa keskenään.
Tämän seurauksena toistaiseksi pysähtynyt johdonmukaisuustasolle kirjoittamista varten EACH_QUORUM, lukemista varten - LOCAL_QUORUM
Lyhyet vaikutelmat ja johtopäätökset
Arvioidaksemme tuloksena olevaa ratkaisua toiminnallisen tuen ja jatkokehitysnäkymien näkökulmasta päätimme pohtia, missä muualla tällaista kehitystä voitaisiin soveltaa.
Heti heti, sitten tietojen pisteytys ohjelmille, kuten "Maksa kun se sopii" (lataamme tiedot C*:een, laskemme Spark-skripteillä), vaatimusten laskeminen alueittain koottuna, roolien tallentaminen ja käyttäjien käyttöoikeuksien laskeminen roolin perusteella. matriisi.
Kuten näette, ohjelmisto on laaja ja monipuolinen. Ja jos valitsemme NoSQL:n kannattajien/vastustajien leirin, liitymme kannattajien joukkoon, koska saimme etumme ja juuri siellä, missä odotimme.
Jopa valmiina oleva Cassandra-vaihtoehto mahdollistaa vaakasuuntaisen skaalauksen reaaliajassa, mikä ratkaisee täysin kivuttomasti järjestelmän tietojen lisääntymisen. Pystyimme siirtämään erittäin suuren kuormituksen mekanismin puheluaggregaattien laskemiseen erilliseen piiriin ja myös erottamaan sovellusskeeman ja logiikan, jolloin pääsimme eroon huonosta käytännöstä kirjoittaa mukautettuja töitä ja objekteja itse tietokantaan. Saimme mahdollisuuden valita ja konfiguroida, nopeuttaa, millä DC:illä teemme laskelmia ja mihin tallennamme tietoja, vakuutimme itsemme sekä yksittäisten solmujen että koko DC:n kaatumisilta.
Soveltaessani arkkitehtuuriamme uusiin projekteihin ja jo jonkin verran kokemusta, haluaisin heti ottaa huomioon yllä kuvatut vivahteet ja estää virheitä, tasoittaa joitain teräviä kulmia, joita ei aluksi voitu välttää.
Esimerkiksi seurata Cassandran päivityksiä ajoissakoska monet kohtaamistamme ongelmista oli jo tiedossa ja korjattu.
Älä sijoita sekä itse tietokantaa että Sparkia samoihin solmuihin (tai jakaa tiukasti sallitulla resurssinkäytöllä), koska Spark voi syödä odotettua enemmän OP:ta ja saamme nopeasti ongelman numero 1 listaltamme.
Paranna seurantaa ja toiminnallista osaamista projektin testausvaiheessa. Ota aluksi mahdollisimman paljon huomioon kaikki ratkaisumme mahdolliset kuluttajat, koska tästä tietokannan rakenne lopulta riippuu.
Pyöritä tuloksena olevaa piiriä useita kertoja mahdollista optimointia varten. Valitse, mitkä kentät voidaan sarjottaa. Ymmärrä, mitä lisätaulukoita meidän tulisi tehdä, jotta otamme huomioon mahdollisimman oikein ja optimaalisesti, ja anna sitten pyydettäessä tarvittavat tiedot (esim. olettaen, että voimme tallentaa samat tiedot eri taulukoihin, ottaen huomioon erilaiset jaottelut eri kriteereillä, voimme säästää huomattavasti CPU-aikaa lukupyyntöihin).
Ei paha Varaa välittömästi TTL:n liittäminen ja vanhentuneiden tietojen puhdistaminen.
Ladattaessa tietoja Cassandrasta Sovelluslogiikan tulisi toimia FETCH-periaatteella, jotta kaikkia rivejä ei ladata kerralla muistiin, vaan ne valitaan erissä.
On suositeltavaa ennen projektin siirtämistä kuvattuun ratkaisuun Tarkista järjestelmän vikasietoisuus suorittamalla sarja törmäystestejä, kuten tietojen katoaminen yhdessä palvelinkeskuksessa, vaurioituneiden tietojen palauttaminen tietyn ajan kuluessa, verkon katkeaminen palvelinkeskusten välillä. Tällaisten testien avulla ei vain voi arvioida ehdotetun arkkitehtuurin hyviä ja huonoja puolia, vaan ne tarjoavat myös hyviä lämmittelykäytäntöjä niitä suorittaville insinööreille, ja hankittu taito ei ole läheskään tarpeeton, jos järjestelmävikoja toistetaan tuotannossa.
Jos työskentelemme kriittisten tietojen kanssa (kuten laskutustiedot, tilaajavelan laskeminen), kannattaa myös kiinnittää huomiota työkaluihin, jotka vähentävät DBMS:n ominaisuuksista johtuvia riskejä. Käytä esimerkiksi nodesync-apuohjelmaa (Datastax), kun olet kehittänyt optimaalisen strategian sen käyttöä varten johdonmukaisuuden vuoksi älä kuormita Cassandraa liikaa ja käytä sitä vain tietyissä taulukoissa tietyn ajanjakson aikana.
Mitä Cassandralle tapahtuu kuuden kuukauden elämän jälkeen? Yleisesti ottaen ratkaisemattomia ongelmia ei ole. Emme myöskään salli vakavia onnettomuuksia tai tietojen menetystä. Kyllä, jouduimme miettimään joidenkin ongelmien kompensoimista, joita ei ollut aiemmin ilmaantunut, mutta loppujen lopuksi tämä ei suuresti hämärtänyt arkkitehtonista ratkaisuamme. Jos haluat ja et pelkää kokeilla jotain uutta, etkä samalla halua olla liian pettynyt, valmistaudu siihen, että mikään ei ole ilmaista. Sinun tulee ymmärtää, perehtyä dokumentaatioon ja koota oma yksilöllinen harava enemmän kuin vanhassa vanhassa ratkaisussa, eikä mikään teoria kerro etukäteen, mikä harava sinua odottaa.
Lähde: will.com