UusSQL = NoSQL + ACID

Kuni viimase ajani oli Odnoklassnikis umbes 50 TB andmeid, mida töötleti reaalajas, salvestatud SQL Serverisse. Sellise mahuga on kiire ja usaldusväärse ning rikkevastase andmekeskuse juurdepääsu tagamine, kasutades SQL andmebaasi, praktiliselt võimatu. Tavaliselt kasutatakse sellistes olukordades mõnd NoSQL-lahendust, kuid mitte kõik ei sobi NoSQL-i: mõned entiteedid nõuavad ACID-tehingute garantiisid.

See viis meid NewSQL-andmebaasi kasutamiseni, mis tähendab andmebaasi, mis pakub rikkevastupidavust, skaleeritavust ja NoSQL-süsteemide kiirus, kuid samas säilitab klassikaliste süsteemide jaoks tuttavad ACID-garantii. Töötavad tööstuslikud süsteemid sellest uuest klassist on haruldased, seetõttu realiseerisime sellise süsteemi ise ja lansseerisime selle tööstuslikuks kasutuseks.

Kuidas see töötab ja milline lähenemine õnnestus — loe edasi.

Täna on „Odnoklassniki“ igakuine külastajaskond üle 70 miljoni unikaalse külastaja. Me oleme viie parima seas maailma suurimad sotsiaalmeedia platvormid ja kuulub ka veebi 20 kõige rohkem külastatava saidi hulka. 'OK' infrastruktuur suudab taluda väga kõrgeid koormusi: rohkem kui miljon HTTP-päringut sekundis. Üle 8000 serveri jaguneb neljas Moskvas asuvas andmekeskuses, mis võimaldab tagada võrgu latentsuse alla 1 ms nende vahel.

Kasutame Cassandrat alates 2010. aastast, alustades versioonist 0.6. Tänaseks on kasutuses mitukümmend klastrit. Kiireim klaster töötleb rohkem kui 4 miljonit operatsiooni sekundis, samas kui suurim salvestab 260 TB.

Kuid need on tavapärased NoSQL-klastrid, mida kasutatakse andmete salvestamiseks nõrgalt kooskõlastatud andmete jaoks. Soovisime asendada peamise kooskõlastatud andmebaasi, Microsoft SQL Serveri, mida on kasutatud alates 'Odnoklassniki' asutamisest. Andmebaas koosnes enam kui 300 SQL Server Standard Edition masinast, kus oli 50 TB andmeid - ärikontseptsioone. Need andmed muudetakse ACID-tehingute raames ja vajavad kõrget kooskõlastatust.

SQL Serveri sõlmedes andmete hajutamiseks kasutasime nii vertikaalset kui ka horisontaalset partitsioneerimist (shardimine). Ajalooliselt oleme kasutanud lihtsat andmete shardimise skeemi: igale entiteedile määrati token – funktsioon entiteedi ID-st. Ühised tokenid paigutati ühele SQL-serverile. Master-detail suhe oli rakendatud nii, et põhikirje ja alakirje tokenid langevad alati kokku ja asuvad samal serveril. Sotsiaalvõrgustikus genereeritakse peaaegu kõik kirjed kasutaja nime alt – see tähendab, et kõik kasutaja andmed ühe funktsionaalse alamsüsteemi piires salvestatakse ühele serverile. See tähendab, et äritehingutes osalesid peaaegu alati sama SQL-serveri tabelid, mis võimaldas andmete järjepidevust tagada kohalike ACID-tehingute abil, ilma vajaduseta kasutada aeglaseid ja ebatäiuslikke jaotatud ACID-tehinguid.

Shardimise ja SQL töö kiirusel:

• Mitte kasutada Foreign key constraints, kuna shardimisel võib entiteedi ID asuda teisel serveril.
• Me ei kasuta salvestatud protseduure ja trügeerijaid, kuna need koormavad andmebaasi CPU-d.
• Me ei kasuta JOIN-e eeltoodud põhjustel ning paljude juhuslike lugemiste tõttu kettalt.
• Väheneme omavaheliste ummikute tagamiseks kasutame väljaspool tehingut eraldusastet Read Uncommitted.
• Teostame ainult lühikesi tehinguid (keskmiselt alla 100 ms).
• Me ei kasuta mitmerealisi UPDATE ja DELETE käske, kuna need põhjustavad palju ummikuid — värskendame ainult üht kirjet korraga.
• Küsimused täidame alati ainult indeksite kaudu — küsimus, mille plaan on kogu tabeli vaatamine, tähendab meie jaoks andmebaasi ülekoormust ja selle tõrget.

Need sammud on võimaldanud meie SQL-serveritel saavutada peaaegu maksimaalset jõudlust. Kuid probleeme sai järjest rohkem. Vaatame neid üle.

Probleemid SQL-iga

• Kuna kasutasime käsitsi kirjutatud shardingut, lisasid administraatorid uusi shard'e käsitsi. Kogu selle aja jooksul ei teenindanud skaleeritavad andmete koopiad päringuid.
• Kuna tabelisse kantavate kirjete arv kasvab, väheneb sisestamise ja muutmise kiirus, ja indeksite lisamine olemasolevale tabelile kiirus langeb märgatavalt, indeksite loomine ja uuesti loomine toimub katkestustega.
• Piiratud Windowsi olemasolu SQL Serveri jaoks tootmiskeskkonnas raskendab infrastruktuuri haldamist.

Aga peamine probleem on —

Katastroofitaluvus

Klassikalise SQL-serveri katastroofitaluvus on halb. Oletame, et teil on vaid üks andmebaasi server ja see ebaõnnestub kord kolme aasta jooksul. Sel ajal on veebileht maas 20 minutit, mis on vastuvõetav. Kui teil on 64 serverit, siis on veebileht maas kord kolme nädala jooksul. Ja kui teil on 200 serverit, siis on veebileht maas iga nädala. See on probleem.

Mida saab teha SQL-serveri katastroofitaluvuse tõstmiseks? Vikipeedia soovitab meil üles ehitada kõrge saadavusega klaster: kus ükskõik millise komponente ebaõnnestumise korral on duplikatsioon.

See nõuab kallite seadmete parki: ulatuslikud dubleerimised, kiudoptiline side, jagatud salvestusruum, ja varukoopiate aktiveerimise töökindlus on madal: umbes 10% käivitustest lõppeb varurelva kaaslasena, mis ebaõnnestub põhivõrguga.

Kuid peamine puudus sellisel kõrge kättesaadavuse klastril on nullkättesaadavus andmekeskuse tõrke korral, kus see asub. „Odnoklassniki” omab nelja andmekeskust, ja peame tagama töökindluse täieliku rikke korral ühes neist.

Selle jaoks võiks rakendada Multi-Master replikatsiooni, mis on integreeritud SQL Serverisse. See lahendus on palju kallim tarkvara hinna tõttu ja kannatab hästi tuntud replikatsiooni probleemide all — ettearvamatud tehingute viivitused sünkroonses replikatsioonis ja viivitused replikatsioonide rakendamisel (ja seega ka kadunud muudatused) asünkroonse replikatsiooni puhul. Eeldatav kätega konfliktide lahendamine teeb selle variandi meie jaoks täiesti sobimatuks.

Kõik need probleemid vajasid radikaalset lahendust ning me alustasime nende põhjalikku analüüsi. Siin peame tutvuma sellega, mis on SQL Serveri peamine ülesanne — tehingud.

Lihtne tehing

Vaatleme kõige lihtsamat tehingut, silmas pidades rakenduslikku SQL-programmeerijat: foto lisamine albamisse. Albumid ja fotod salvestatakse erinevatesse tabelitesse. Albumil on avalike fotode arvesti. Seega jaguneb see tehing järgmistesse etappidesse:

1. Lukustame albumi võtme alusel.
2. Loome kirje fotode tabelis.
3. Kui fotol on avalik staatus, siis suurendame albumis avalike fotode arvestit, uuendame kirjet ja kinnitame tehingu.

Või pseudokoode formaadis:

TX.start("Albumid", id);
Album album = albums.lock(id);
Photo photo = photos.create(…);

if (photo.status == PUBLIC) {
    album.incPublicPhotosCount();
}
album.update();

TX.commit();

Näeme, et kõige levinum ärilise tehingu stsenaarium on andmete lugemine andmebaasist rakenduste serveri mällu, nende muutmine ja uute väärtuste salvestamine tagasi andmebaasi. Tavaliselt värskendame sellise tehingu käigus mitmeid olendeid, mitmeid tabeleid.

Tehingu läbiviimisel võib esineda sama andmete konkurentsisüsteemide vahelisi muudatusi. Näiteks võib Antispam otsustada, et kasutaja on kahtlane ning seetõttu ei tohiks kõik kasutaja fotod enam avalikud olla, need tuleb saata modereerimisele, mis tähendab, et photo.status tuleb muuta teiseks väärtuseks ja vastavaid loendureid tuleb reguleerida. Ilmselt, kui see operation toimub ilma atomaarsete rakendamise ja konkureerivate muudatuste isoleerimise garantii, nagu ACID, siis tulemus ei ole see, mis on vajalik — kas fotode loendur näitab vale väärtust või ei saadeta kõik fotod modereerimisele.

Sarnast koodi, mis manipuleerib erinevate äriühendustega ühe tehingu raames, on kõikide aastate jooksul Odnoklassnikute olemasolu jooksul kirjutatud väga palju. Migratsioonide kogemuse põhjal NoSQL-le, Lõplik järjepidevus Teame, et suurimad väljakutsed (ja ajakulu) tulenevad vajadusest arendada koodi, mis tagab andmete järjepidevuse. Seetõttu pidasime uue andmesalvestuse peamiseks nõudeks rakendusloogika tõeliste ACID-tehingute toetamise.

Teised, mitte vähem olulised nõuded olid:

• Andmekeskuse tõrgete korral peavad nii lugemine kui ka kirjutamine olema uude salvestusse saadaval.
• Praeguse arenduskiirus säilitamine. See tähendab, et uue salvestusega töötades peaks koodi hulk jääma enam-vähem samaks, ilma et oleks vaja kirjutada midagi uut salvestusse, välja töötada konfliktide lahendamise algoritme, hooldada teiseseid indekseid jne.
• Uue salvestuse töökiirus peab olema piisavalt kõrge, nii andmete lugemisel kui tehingute töötlemisel, mis tõhusalt välistab akadeemiliselt rangeid, universaalseid, kuid aeglaseid lahendusi, nagu näiteks kahefaasilised millede kinnitamine.
• Automaatne reaalajas skaleerimine.
• Tavapäraste odavate serverite kasutamine, ilma et oleks vaja osta eksootilisi riistvara.
• Arenduse võimalus arendajate poolt. Teisisõnu, prioriteet anti enda või avatud lähtekoodiga lahendustele, eelistatavalt Java-s.

Lahendused, lahendused

Analüüsides võimalikke lahendusi, jõudsime kahe arhitektuurivaliku juurde:

Esimene - võtta ükskõik milline SQL-server ja rakendada vajalikud tõrkelevitus, skaleerimismehhanism, tõrkevaba klaster, konfliktide lahendamine ning jaotatud, usaldusväärsed ja kiire ACID-tehingud. Hindasime seda varianti kui üsna keerukat ja töömahukat.

Teine variant - võtta valmis NoSQL-andmehoidla, millel on rakendatud skaleerimine, tõrkevaba klaster, konfliktide lahendamine ning rakendada tehingud ja SQL ise. Esmapilgul tundub isegi SQL-i rakendamise ülesanne, rääkimata ACID-tehingutest, kui aastatepikkune projekt. Kuid hiljem saime aru, et SQL-i võimaluste komplekt, mida me praktikas kasutame, on kaugel ANSI SQL-ist, sama kaugel kui Cassandra CQL ANSI SQL-ist. Kui me vaatame CQL-i veel lähemalt, saame aru, et see on piisavalt lähedal sellele, mida me vajame.

Cassandra ja CQL

Nii et, millega Cassandra huvitav on ja milliseid võimalusi see pakub?

Esiteks on siin võimalik luua tabeleid, mis toetavad erinevaid andmetüüpe, ning teha SELECT või UPDATE põhiava põhjal.

CREATE TABLE photos (id bigint KEY, owner bigint,…);
SELECT * FROM photos WHERE id=?;
UPDATE photos SET … WHERE id=?;

Replikatsioonide andmete järjepidevuse tagamiseks kasutab Cassandra kvooti lähenemist. Lihtsustatult tähendab see, et kui kolm koopiat samast rühmast paiknevad erinevates klastrinode'is, loetakse kirje edukaiks, kui enamus noode (ehk kaks kolmest) on kinnitanud selle kirjutamise operatsiooni edukust. Rühma andmed peetakse kooskõlastatuks, kui lugemise ajal on enamus noode küsitletud ja kinnitanud need. Seega tagatakse, et kolme koopia olemasolu korral on andmete täielik ja kohene kooskõla, kui üks node kukub. See lähenemine on võimaldanud meil rakendada veelgi usaldusväärsemat skeemi: alati saata päringud kõikidele kolmele koopiale, oodates vastust kahest kiirest. Kolmanda koopia viivitatud vastust sellisel juhul ignoreeritakse. Viivitusi kogevatel noodel võivad samas olla tõsised probleemid - lag, JVM-is prügi kogumine, Linuxi kernelis otsemälu tagasivõtmine, riistvara rike, võrguühenduse katkestamine. Siiski ei mõjuta see kliendi operatsioone ega andmeid.

Lähenemine, kus me pöördume kolme node poole, kuid saame vastuse kahest, nimetatakse spekulatsiooniks: päring ülemäärastele koopiatele saadetakse veel enne, kui need 'langema' hakkavad.

Cassandra üheks eeliseks on Batchlog — mehhanism, mis tagab kas täieliku rakendamise või täieliku rakendamata jätmise teie tehtud muudatuste paketis. See võimaldab meil lahendada A ACID-is — atomaarne nagu välja pakutud.

Cassandra kõige lähedasem asjaolu tehingutele on nn «lightweight transactions« . Kuid nad on „päris“ ACID-tehingutest kaugel: tegelikult on see võimalus teha CAS ainult ühe kirje andmete kohta, kasutades raskema Paxose protokolli konsensust. Seetõttu on nende tehingute kiirus madal.

Mida me Cassandra'st puudusime

Nii pidime me rakendama Cassandra's tõelist ACID-tehingut. Mille abil saaksime kergesti rakendada kaht muud mugavat võimalust klassikalistes andmebaasihaldussüsteemides: järjepidevad kiireid indekseid, mis võimaldaksid meil andmete valimist teostada mitte ainult põhivõtme järgi, vaid ka tavalise monotoonse auto-increment ID generaatori.

C*One

Nii sündis uus andmebaasisüsteem C*One, mis koosneb kolmest tüüpi serveri solgist:

• Andmed — (peaaegu) standardiseeritud Cassandra-serverid, mis vastutavad andmete salvestamise eest kohalikesse diskidesse. Koormuse ja andmemahu suurenedes on nende arvu lihtne skaleerida kümnete ja sadade kaupa.
• Tehingukoordinaatorid — tagavad tehingute täitmise.
• Kliendid — rakendusserverid, mis teostavad äritegevust ja käivitavad tehinguid. Selliseid kliente võib olla tuhandeid.

Kõik serverid kuuluvad üldisse klastrisse, kasutavad omavaheliseks suhtlemiseks Cassandra sisemist sõnumiprotokolli ja gossip klastriteabe vahetamiseks. Heartbeat'i abil saavad serverid teada üksteise tõrgetest, säilitavad ühtse andmeskeemi — tabelid, nende struktuur ja replikatsioon; partitsioneerimise skeem, klastrite topoloogia jne.

Kliendid

Standardsete draiverite asemel kasutatakse Fat Client režiimi. Selline nod ei salvestata andmeid, vaid võib toimida päringute täitmise koordinaatorina, st Klient täidab ise oma päringute koordinaatori funktsiooni: küsib ladustamise koopiaid ja lahendab konfliktid. See on mitte ainult usaldusväärsem ja kiirem kui standardne draiver, mis nõuab suhtlemist eemal asuva koordinaatoriga, vaid võimaldab ka päringute edastamise juhtimist. Klientide avatud tehingute puhul saadetakse päringud ladustamisse. Kui klient on avadanud tehingu, siis suunatakse kõik selle tehingu päringud tehingute koordinaatorisse.

Tehingute koordinaator C*One

Koordinaator on see, mida me oleme C*One jaoks nullist välja ehitanud. Ta vastutab tehingute, lukustuste ja tehingute kehtestamise järjekorra haldamise eest.

Iga teenindatava tehingu jaoks genereerib koordinaator ajatempli: iga järgmine on suurem kui eelmise tehingu oma. Kuna Cassandras põhineb konfliktide lahendamise süsteem ajatemplitel (kaks konfliktset kirjet loetakse aktuaalseks see, millel on hilisem ajatempli väärtus), siis lahendatakse konflikt alati järgmise tehingu kasuks. Nii oleme me rakendanud Lamporti kellad — odav viis konfliktide lahendamiseks jaotatud süsteemis.

Lukud

Isolatsiooni tagamiseks otsustasime kasutada kõige lihtsamat meetodit — pessimistlikud lukud kirje põhi võtme järgi. Teisisõnu, tehingu käigus tuleb kirje esmalt lukustada, enne kui seda saab lugeda, muuta ja salvestada. Ainult pärast eduka komiteerimist võib kirje lukust vabastada, et konkurentsivõimelised tehingud saaksid seda kasutada.

Selle blokeerimise rakendamine on lihtne jaotamata keskkonnas. Jaotatud süsteemis on kaks peamist teed: kas rakendada jaotatud lukustust klastris või jaotada tehingud nii, et ühe kirje osalusega tehingud teenindatakse alati sama koordinaatori poolt.

Kuna meie juhul on andmed juba jaotatud kohalike tehingute gruppides SQL-is, otsustati määrata koordinaatoritele kohalike tehingute grupid: üks koordinaator täidab kõik tehingud tokeniga vahemikus 0 kuni 9, teine — vahemikus 10 kuni 19 ja nii edasi. Tulemuseks on see, et iga koordinaatori eksemplar muutub tehingute grupi isandaks.

Seega saavad lukustused olla rakendatud lihtsalt koordinaatori mälus olevate HashMap'ide kujul.

Koordinaatorite rikkeid

Kuna üks koordinaator teenindab eranditult tehingute gruppi, on äärmiselt oluline kiiresti tuvastada tema rike, et uue tehingu proovimine mahuks ajavahemikku. Selle kiire ja usaldusväärne tegemiseks rakendasime täieliku linkimise kvora hearbeat protokolli:

Igas andme keskuses on vähemalt kaks koordinaatori sõlme. Aeg-ajalt saadab iga koordinaator teistele koordinaatoritele südame löögi sõnumi, teavitades neid oma toimimisest ning millistelt koordinaatoritelt on ta viimati südame löögi sõnumeid saanud.

Saades sarnast teavet teistelt nende südame löögi sõnumites, otsustab iga koordinaator, millised klastris olevad sõlmed toimivad ja millised mitte, järgides kvoorumi põhimõtet: kui sõlm X on saanud enamiku sõlmede poolt klastris teavet normaalsest sõnumite vastuvõtmisest sõlmelt Y, siis toimib Y. Vastupidi, niipea kui enamus teatab sõlmelt Y sõnumite kadumisest, tähendab see, et Y on rikki läinud. Huvi pärast, kui kvoorum teatab sõlmele X, et ta ei saa temalt enam sõnumeid, hakkab sõlm X pidama end rikki läinuks.

Heartbeat-sõnumite edastamine toimub suure sagedusega, umbes 20 korda sekundis, 50 ms intervalliga. Java puhul on raske tagada rakenduse vastust 50 ms jooksul, kuna pauside kestus, mida põhjustab prügikoristaja, on sarnane. Oleme suutnud saavutada sellise vastuseaja, kasutades G1 prügikoristajat, mis võimaldab määrata GC pauside kestuse sihte. Siiski, mõnikord, harva, ületavad prügikoristaja pausid 50 ms, mis võib viia vale tõrke avastamiseni. Selle vältimiseks ei teata koordinaator kaug-noodi tõrkest kohe, kui esimene heartbeat-sõnum temalt kaob, vaid ainult siis, kui mitu järjestikkust kaduma läheb. Nii oleme suutnud saavutada koordinaatori nodi tõrke avastamise 200 ms jooksul.

Aga pole piisav lihtsalt mõista, milline nodi on lakanud töötamast. Midagi tuleb sellega ette võtta.

Varu

Klassikaline skeem eeldab meistri tõrke korral uue valimist ühe kaudu moodsa universaalse algoritmid. Kuid sellistel algoritmidel on tuntud probleemid konvergentsi ja valimiste protsessi kestusega. Selliseid täiendavaid viivitusi oleme suutnud vältida koordinaatorite asendamise skeemi abil täielikult ühendatud võrgus:

Oletame, et soovime teostada tehingut grupis 50. Eeltingimusena määratleme asendamise skeemi, st millised sõlmed teostavad grupi 50 tehingud, kui peamine koordinaator ebaõnnestub. Meie eesmärk on säilitada süsteemi töökindlus, kui andmekeskus ei tööta. Määratleme, et esimene varu on sõlm teisest andmekeskusest ja teine varu on sõlm kolmandast. See skeem valitakse üks kord ja see ei muutu, kuni klasteri topoloogia muutub, st kuni sellesse ei lisandu uusi sõlmi (mis juhtub väga harva). Uue aktiivse meistri valimise järjekord vanast ebaõnnestumise korral on alati järgmine: aktiivseks meistriks saab esimene varu, ja kui see enam ei tööta — siis teine varu.

Selline skeem on usaldusväärsem kui universaalne algoritm, kuna uue meistri aktiveerimiseks piisab vanast ebaõnnestumise fakti kindlaksmäärimisest.

Kuidas saavad kliendid aru, milline meister praegu töötab? 50 ms jooksul ei ole võimalik jagada teavet tuhandetele klientidele. Võib juhtuda, et klient saadab päringu tehingu avamiseks, teadmata, et see meister ei tööta enam, ning päring jääb ajutiseks. Selle vältimiseks saadavad kliendid spekulatiivselt päringu tehingu avamiseks kohe grupimeistrile ja mõlemale tema varumeistrile, kuid vastab sellele päringule ainult see, kes on sel hetkel aktiivne meister. Kõik edasine suhtlemine tehingu raames toimub kliendi ja ainult aktiivse meistri vahel.

Varumeistrid, kes saavad päringud mitte enda tehingute kohta, paigutavad need sündimata tehingute järjekorda, kus need hoiavad mõnda aega. Kui aktiivne meister sureb, töötleb uus meister järjekorras olevaid tehingu avamise päringuid ja vastab kliendile. Kui klient on juba jõudnud avada tehingu vana meistri kaudu, siis teist vastust ignoreeritakse (ja ilmselgelt selline tehing ei lõpeta ning kordub kliendi poolt).

Kuidas tehing töötab

Oletame, et klient saatis koordinaatorile taotluse tehingu avamiseks sellise üksuse jaoks, millel on selline esmase võtme väärtus. Koordinaator blokeerib selle üksuse ja paigutab selle mälus blokeeringute tabelisse. Kui vajalik, loeb koordinaator selle üksuse salvestusest ja salvestab saadud andmed koordinaatori mälu tehingu olekusse.

Kui klient soovib tehingus andmeid muuta, saadab ta koordinaatorile taotluse üksuse muudatuste tegemiseks, ning koordinaator paigutab uued andmed tehingute oleku tabelisse mälus. Sellega on salvestamine lõpetatud — salvestust ei toimu.

Kui klient küsib aktiivse tehingu raames oma muudetud andmeid, toimib koordinaator järgmiselt:

• kui ID on juba tehingus, siis andmed võetakse mälu;
• kui ID mälu ei ole, siis puuduvad andmed loetakse nodi salvestustest, ühendatakse olemasolevaga mälus ja tulemus antakse kliendile.

Seega võib klient lugeda oma muudatusi, kuid teised kliendid neid muudatusi ei näe, kuna need hoitakse ainult koordinaatori mälus; nodides Cassandra's neid veel ei ole.

Kliendi saadetud commit'i korral salvestab teenuse mällu jäänud oleku koordinaator logged batch'ina, mis saadetakse juba logged batch'ina Cassandra ladudesse. Ladude ülesanne on tagada, et see pakett rakendataks atomaarsetena (täielikult) ning naasta vastus koordinaatorile, kes vabastab lukud ja kinnitab tehingu edukust kliendile.

Tagasitõmbamiseks piisab koordinaatorist vaid mäluruumi vabastamisest, mis on tehingu oleku jaoks reserveeritud.

Eelnimetatud täiustuste tulemusena oleme rakendanud ACID põhimõtteid:

• Atomaarne. See tagab, et ükski tehing ei fikseerita süsteemis osaliselt: kas tehakse kõik alamoperatsioonid või ei tehta ühtegi. Meie ettevõttes järgime seda põhimõtet logged batch'i kaudu Cassandra's.
• Konsistentsus. Iga edukas tehing fikseerib määratletud tulemused. Kui tehingu avamise ja osade operatsioonide täitmise järel selgub, et tulemus on ebaseaduslik, toimub tagasivõtmine.
• Isolatsioon. Tehingu täitmisel ei tohi samal ajal toimuvad tehingud mõjutada selle tulemusi. Konkurentsivõimelised tehingud on koordinaatori pessimistic lock'dega isoleeritud. Tehinguvälised lugemised järgivad isoleerimise põhimõtet Read Committed tasemel.
• Stabiilsus. Ükskõik millised probleemid madalamatel tasemetel – süsteemi voolukatkestus, riistvara tõrge – peaksid edukalt lõpetatud tehingute muudatused jääma alles pärast süsteemi taastamist.

Lugemine indeksite kaudu

Võtame lihtsa tabeli:

CREATE TABLE photos (
id bigint primary key,
owner bigint,
modified timestamp,
…)

See sisaldab ID-d (peamine võti), omaniku ja muutmise kuupäeva. Peame tegema väga lihtsa päringu – valima andmed omaniku järgi, kelle muudatused on tehtud «viimase 24 tunni» jooksul.

SELECT *
WHERE owner=?
AND modified>?

Selle sarnase päringu kiireks töötlemiseks tuleb klassikalises SQL andmebaasis luua indeks veergude (owner, modified) alusel. Sellise ülesande täitmine on nüüd lihtne, kuna meil on ACID garantiid!

Indeksid C*One

On algne tabel fotodega, mille kirje ID on peamine võti.

C*One loob uue tabeli indeksi jaoks, mis on algse koopia. Võti vastab indeksile, samas sisaldab see ka algse tabeli peavõtit:

Nüüd saab päringu «omaniku kohta viimase 24 tunni jooksul» ümber kirjutada kui select teise tabeli jaoks:

SELECT * FROM i1_test
WHERE owner=?
AND modified>?

Algse tabeli photos ja indeksi i1 andmete kooskõla säilib automaatselt koordineerija kaudu. Üheainsa andmeskeemi alusel, kui muudetakse, genereerib koordineerija muudatuse ja meeles peab mitte ainult põhitähted, vaid ka koopiate muudatused. Täiendavaid toiminguid indeksi tabeliga ei tehta, logisid ei loeta ega lukustusi ei kasutata. Seega indekseerimise lisamine tarbib peaaegu mitte mingit ressurssi ja ei mõjuta modifikatsioonide rakendamise kiirus.

ACID tehnoloogia abil suutsime luua indekseid, nagu SQL-is. Need on järjepidevad, skaleeritavad, töötavad kiiresti, võivad olla komposiitindeksid ning on integreeritud CQL-i päringukeelde. Indeksite toetamiseks ei ole vaja rakenduskoodi muuta. Kõik on lihtne nagu SQL-is. Ja mis kõige tähtsam, indeksid ei mõjuta tehinguliste algsetabelite muudatuste täitmise kiirus.

Mis välja tuli

Arendasime C*One kolm aastat tagasi ja käivitasime selle tööstuslikuks kasutamiseks.

Kuidas oli meie tulemus? Vaadake näiteks fotode töötlemise ja salvestamise alamsüsteemi, mis on üks sotsiaalvõrgustike kõige olulisemaid andmeliike. Räägime mitte fotode füüsilisest sisust, vaid kõikidest võimalikest metaandmetest. Praegu on „Одноклассниках” umbes 20 miljardit sellist kirjet, süsteem käitleb 80 000 lugemisepäringut sekundis, kuni 8 000 ACID-tehingut sekundis, mis on seotud andmete muutmisega.

Kui kasutasime SQL-i, mille replikatsiooni faktor oli 1 (aga RAID 10), siis salvestati piltide metaandmed 32 masina kõrge kättesaadavuse klastrisse Microsoft SQL Serveriga (pluss 11 varukohta). Varukoopiate hoidmiseks eraldati 10 serverit. Kokku 50 kulukat masinat. Samal ajal töötas süsteem nominatiivsel koormusel, ilma täiendava ressurssideta.

Pärast uut süsteemi migratsiooni saime replikatsiooni faktoriks 3 — iga andmekeskuse kohta üks koopia. Süsteem sisaldab 63 Cassandra salvestusnodu ja 6 koordinaatorit, kokku 69 serverit. Kuid need masinad on oluliselt odavamad, nende koguhind on umbes 30% SQL süsteemi maksumusest. Koormus püsib 30% tasemel.

C*One rakendamisega vähenesid ka viivitused: SQL-is võttis kirjutamine aega umbes 4,5 ms. C*One-is on see umbes 1,6 ms. Tehingu kestus on keskmiselt alla 40 ms, kinnitamine toimub 2 ms jooksul, lugemise ja kirjutamise kestus — keskmiselt 2 ms. 99. protsentil on see vaid 3-3,1 ms, ajaülekande juhtumeid on vähenenud 100 korda — kõik tänu laiale spekulatsioonide rakendusele.

Praeguseks on suurem osa SQL Serveri node'dest välja lülitatud, uusi tooteid arendatakse ainult C*One kasutades. Oleme C*One'i kohandanud tööks meie pilves. one-cloud, mis on võimaldanud kiirendada uute klastrite seadistamist, lihtsustada konfiguratsiooni ja automatiseerida haldamist. Ilma lähtekoodita oleks see olnud märgatavalt keerulisem ja vaevalisem.

Praegu töötame teiste meie hoidlate pilve viimise kallal – aga see on juba hoopis teine lugu.

Allikas: habr.com