🥇NewSQL = NoSQL+ACID

Kuni hiljuti hoiti Odnoklassnikovis umbes 50 TB reaalajas töödeldud andmeid SQL Serveris. Sellise mahuga kiire ja usaldusväärse, veelgi enam, tõrgetekindla andmekeskuse juurdepääsu tagamine, kasutades SQL andmebaasi, on peaaegu võimatu. Tavaliselt kasutatakse sellistes olukordades ühte NoSQL-andmehoidlatest, kuid mitte kõike ei saa üle viia NoSQL-i: mõned üksused nõuavad ACID-tehingute garantiisi.

See viis meid NewSQL-andmehoidla kasutamiseni, st andmebaasi, mis pakub tõrketaluvust, skaleeritavust ja NoSQL-süsteemide kiirus, kuid säilitab samas klassikaliste süsteemide ACID-garantii. Tööstuslikke süsteeme selle uue klassi jaoks on vähe, seega rakendasime sellise süsteemi ise ja käivitasime selle tööstuslikuks kasutamiseks.

Kuidas see toimib ja mis välja tuli — loe edasi.

Täna on „Odnoklassnikovite” kuine publik üle 70 miljoni unikaalse külastaja. Me oleme viie suurima sotsiaalmeedia platvormi seas maailmas ja kahekümne hulgas veebisaitide seas, kus kasutajad veedavad kõige rohkem aega. „OK” infrastruktuur töötleb väga suuri koormusi: üle miljjoni HTTP-päringu sekundis frontides. Üle 8000 serveri moodustavad serveripargi, mis asuvad üksteise lähedal – neljas Moskva andmekeskuses, mis võimaldab tagada võrgu latentsuse alla 1 ms nende vahel.

Oleme Cassandra't kasutanud alates 2010. aastast, alustades versioonist 0.6. Täna on kasutuses mitukümmend klastrit. Kiireim klaster töötleb üle 4 miljoni operatsiooni sekundis, samas kui suurim salvestab 260 TB.

Kuid kõik need on tavalised NoSQL-klastrid, mida kasutatakse madala kooskõlastatuse andmete säilitamiseks. Soovisime aga asendada põhikooskõlastatud andmehoidla, Microsoft SQL Serveri, mida on kasutatud „Odnoklassnikovite” loomise hetkest. Andmehoidla koosnes rohkem kui 300 SQL Server Standard Edition masinast, millel oli 50 TB andmeid – ärilisi entiteete. Need andmed muudetakse ACID-tehingute käigus ja nõuavad kõrget kooskõlastatust..

SQL Serveri andmete jaotamiseks sõlmedesse kasutasime nii vertikaalset kui ka horisontaalset partitsioneerimist. (sharding). Ajalooliselt oleme kasutanud lihtsat andmete šardimise skeemi: igale üksusele määrati token - funktsioon üksuse ID-st. Üksused, millel on sama token, pandi ühele SQL-serverile. Master-detail tüüpi suhe rakendati nii, et põhikirje ja selle aluskirje tokenid olid alati samad ja paiknesid samal serveril. Sotsiaalvõrgustikus genereeritakse peaaegu kõik kirjed kasutaja nime alt - see tähendab, et kõiki kasutaja andmeid hoitakse ühe funktsionaalsete süsteemide raames ühel serveril. Seega osalesid äritehingutes peaaegu alati sama SQL-serveri tabelid, mis võimaldas andmete järjepidevust tagada kohalike ACID-tehingute kaudu, ilma vajaduseta kasutada aeglaseid ja ebaturvalisi jaotatud ACID-tehinguid.

Šardingu ja SQL-i töö kiirendamiseks:

Ei kasuta välismaiseid võtme piiranguid, kuna šardimise puhul võib üksuse ID olla teisel serveril.
Ei kasuta salvestatud protseduure ega trikke, kuna need koormavad andmebaasi CPU-d.
Ei kasuta JOIN-e eelnevatel põhjustel ja paljusid juhuslikke lugemisi ketast.
Välise tehingu puhul vähendame ummikute riski, kasutades Read Uncommitted isolatsiooni taset.
Teostame ainult lühikesi tehinguid (keskmiselt alla 100 ms).
Ei kasuta mitmerealisi UPDATE ja DELETE, kuna need põhjustavad palju ummikuid — uuendame ainult ühte kirjet.
Küsimused teostame alati ainult indeksite kaudu - küsimus, mille plaan näeb ette täieliku tabeli vaatamist, tähendab meie jaoks andmebaasi ülekoormust ja selle riket.

Need sammud on võimaldanud SQL-serveritest peaaegu maksimumvõimsust välja pigistada. Kuid probleeme tuli üha rohkem ja rohkem. Vaatame neid lähemalt.

SQL-i probleemid

Kuna kasutasime isekirjutatud šardimist, viidi uute šardide lisamine manuaalselt läbi administraatorite poolt. Kogu selle aja vältel ei teeninud skaleeritavad andmete koopiad päringuid.
Kuna andmete arv tabelis suureneb, väheneb lisamise ja muutmise kiirus, olemasoleva tabeli indeksite lisamisel kiirus langeb kordades, indeksite loomine ja uuesti loomine toimub seiskumisega.
Toodangu väikese arvu Windowsi SQL Serverite olemasolu raskendab infrastruktuuri haldamist

Kuid kõige suurem probleem on —

Talitluskatkestustunne

Klassikalise SQL-serveri talitlushäired on halvad. Oletame, et teil on ainult üks andmebaasi server ja see ebaõnnestub üks kord iga kolme aasta järel. Sel ajal ei tööta veebisait 20 minutit, mis on aktsepteeritav. Kui teil on 64 serverit, ei tööta veebisait juba kord iga kolme nädala järel. Ja kui teil on 200 serverit, ei tööta veebisait iga nädal. See on probleem.

Mida saab teha SQL-serveri talitlushäirete tõstatamiseks? Wikipedia soovitab meil luua kõrge kättesaadavuse klaster: kus igasuguse komponendi tõrke korral on olemas duplikaat.

See nõuab kallite seadmete parki: ulatuslikud duplikaadid, kiudoptiline kaabeldus, jagatud salvestus ja ka varu sisselülitamine ei toimi usaldusväärselt: umbes 10% sisselülitamistest lõppeb varu sõlme rikke tõttu, mis järgneb põhikliendile.

Kuid sellise kõrge kättesaadavusega klastrite peamine puudus on nullkättesaadavus andmekeskuse tõrke korral, kus see asub. "Odnoklassniki" omab nelja andmekeskust ning me peame tagama, et see töötab täieliku rikke korral ühes neist.

Selle probleemi lahendamiseks võiksime kasutada Multi-Master replikatsiooni, mis on integreeritud SQL Serverisse. See lahendus on märkimisväärselt kallim tarkvara maksumuse tõttu ja kannatab hästi tuntud replikatsiooniga seotud probleemide all — ettearvamatud tehingu viivitused sünkroonses replikatsioonis ning viivitused replikatsioonide rakendamisel (ja seega ka kadunud muudatused) asünkroonse puhul. Eeldatav käsitsi konfliktide lahendamine teeb selle valiku meie jaoks täielikult kasutamatuks.

Kõik need probleemid nõudsid radikaalset lahendust ja me alustasime nende üksikasjalikku analüüsi. Siin peame tutvuma sellega, mida SQL Server põhimõtteliselt teeb — tehingud.

Lihtne tehing

Vaatame kõige lihtsamat tehingut, vaatenurgast rakenduslikku SQL-programmeerijat: foto lisamine albumisse. Albumid ja fotod on salvestatud erinevatesse tabelitesse. Albumil on avalike fotode loend. Siis jaguneb selline tehing järgnevateks sammudeks:

Lukustame albumi selle võtme järgi.
Loome kirje fotode tabelis.
Kui fotol on avalik staatuse, siis suurendame albumis avalike fotode loendit, uuendame kirjet ja kinnitame tehingu.

Või pseudokoodina:

TX.start("Albums", 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 äritehingu stsenaarium on andmete lugemine andmebaasist rakendusserveri mällu, millegi muutmine ja uute väärtuste salvestamine tagasi andmebaasi. Tavaliselt värskendame sellises tehingus mitu üksust, mitu tabelit.

Tehingu käigus võib tekkida konkurentsiaalne muutmine sama andmebaasi andmete osas teises süsteemis. Näiteks võib antispam otsustada, et kasutaja on kahtlane ja seetõttu ei tohi kõik kasutaja fotod enam avalikud olla, need tuleb saata modereerimisele, mis tähendab, et photo.status tuleb muuta mõneks muuks väärtuseks ja vastavad loendurid tuleb tagasi keerata. Ilmselgelt, kui see operatsioon toimub ilma atomaarse rakendamise ja konkurentide muudatuste isoleerimise garantiideta, nagu ACID, ei ole tulemus 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 ärielementidega sama tehingu raames, on kogu Odnoklassniki eksisteerimise ajal kirjutatud väga palju. Kogemuse põhjal NoSQL-i migreerimisel Eventual Consistency teame, et suurimad raskused (ja ajakulu) tekivad vajadusest arendada koodi, mis tagab andmete järjepidevuse. Seetõttu pidasime uue andmebaasi peamiseks nõudeks ACID-tehingute reaalset tagamist rakendusloogika jaoks.

Muud, mitte vähem tähtsad nõuded olid:

Andmekeskuse tõrke korral peavad nii lugemine kui kirjutamine uude andmebaasi olema võimalikud.
Praeguse arenduskiirus jäätmine. See tähendab, et uue andmebaasiga töötades peaks koodihulk olema ligikaudu sama, ei tohi tekkida vajadust koguda andmebaasi, arendada konfliktide lahendamise algoritme, säilitada teise astme indekseid jne.
Uue andmebaasi töökiirus peab olema piisavalt kõrge nii andmete lugemisel kui tehingute töötlemisel, mis tõhusalt tähendab, et akadeemiliselt rangeid, universaalseid, kuid aeglaseid lahendusi, nagu näiteks kahefsaalset kinnitamist.
Automaatne skaleerimine reaalajas.
Tavapäraste odavate serverite kasutamine ilma eksootiliste seadmete ostmise vajaduseta.
Andmehoidla arendamise võimalus ettevõtte arendajate poolt. Teisisõnu, eelistasime oma või avatud lähtekoodiga lahendusi, eelistatult Java platvormil.

Lahendused, lahendused

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

Esimene — võtta mistahes SQL-server ja rakendada vajalikud vigadetaluvus, skaleerimise mehhanism, vigadetaluv klaster, konfliktide lahendamine ning jaotatud, usaldusväärsed ja kiired ACID-tehingud. Hinnasime seda valikut kui pigem keerulist ja aeganõudvat.

Teine variant — kasutada valmis NoSQL-andehoidlat, milles on rakendatud skaleerimine, vigadetaluv klaster ja konfliktide lahendamine ja rakendada tehingud ning SQL ise. Esmapilgul tundub isegi SQL-i rakendamine, rääkimata ACID-tehingutest, aastaid kestev ülesanne. Kuid hiljem mõistsime, et nende SQL-i võimaluste kogum, mida me praktikas kasutame, on kaugel ANSI SQL-ist nii kaugel kui Cassandra CQL on ANSI SQL-ist. Lähemalt uurides CQL-i, jõudsime järeldusele, et see on piisavalt lähedal sellele, mida me vajame.

Cassandra ja CQL

Nii et, mis on Cassandra huvitav, millised võimalused tal on?

Esiteks saab siin luua tabeleid, mis toetavad erinevaid andmetüüpe, võib teha SELECT või UPDATE päringuid primaarvõtme järgi.

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

Replikate andmete järjepidevuse tagamiseks kasutab Cassandra kvoorumi lähenemistKõige lihtsamas juhus tähendab see, et kolme ühe ja sama rea koopiat, mis asuvad klastris erinevates noodes, peetakse salvestamise operatsiooni edukaks, kui enamus nodes (st kaks kolmest) on kinnitanud, et see operatsioon õnnestus. Rida andmeid loetakse kooskõlastatuks, kui lugemise ajal on suur enamus noode küsitud ja need on oma kinnitused andnud. Nii tagatakse kolme koopia olemasolul andmete täielik ja kohene kooskõlastamine ühe node'i rikke korral. See lähenemine lubas meil rakendada veelgi usaldusväärsemat skeemi: alati saata päringud kõikidele kolmele koopiale, oodates vastust kahest kiireimast. Häiritud kolmanda koopia vastus jäetakse sellisel juhul tähelepanuta. Probleeme võib tekkida aeglaselt vastavaks muutuvast node'ist - näiteks viivitustest, JVM-i prügikoristusest, Linuxi kerneli otsesest mälukoristusest, riistvara riketest või võrgu katkemisest. Kuid see ei mõjuta kliendi operatsioone ega andmeid.

Lähenemist, kus pöördume kolme node'i poole ja saame vastuse kahest, nimetatakse spekulatsiooniks: päring ülearustele koopiatele saadetakse enne, kui need "maha kukuvad".

Cassandra üheks teiste eelisteks on Batchlog - mehhanism, mis garanteerib kas paketi täieliku rakendamise või täieliku rakendamata jätmise. See võimaldab meil lahendada A ACID-is - atomuaarsuse pakend.

Cassandra kõige lähemal asuvate tehingute seas on nn "kergekaalulised tehingud". Kuid nad on kaugel "päris" ACID-tehingutest: tegelikult on see võimalus teha CAS ainult ühe kirje andmetega, kasutades raskealuslike Paxose protokolli konsensust. Seetõttu ei ole nende tehingute kiirus suur.

Mida me Cassandra'st puudu tundsime

Nii olid meil plaanis rakendada Cassandra's tõelisi ACID-tehinguid. Mille abil võiksime hõlpsasti saavutada kaks muud mugavat omadust traditsioonilistes andmebaasihaldussüsteemides: järjepidevad kiired indeksid, mis võimaldaksid meil teha andmevalimisi mitte ainult esmase võtme ja tavalise monotone autonoomse ID generaatori põhjal.

C*One

Nii sündis uus andmebaasisüsteem C*One, mis koosneb kolmest tüüpi serverinode'ist:

Salvestused - (peaaegu) standardsed Cassandra serverid, mis vastutavad andmete säilitamise eest kohalikest kõvaketastest. Koormuse ja andmemahtu suurenedes on nende arvu lihtne suurendada kümnetest ja sadadest.
Tehingute koordineerimine – tagab tehingute täitmise.
Kliendid – rakenduste serverid, mis viivad ellu äriprotsesse ja käivitavad tehingud. Selliseid kliente võib olla tuhandeid.

Kõik serverid, olenemata tüübist, kuuluvad ühisesse klastrisse, kasutavad omavaheliseks suhtlemiseks sisemist sõnumite protokolli Cassandra ja gossip klastri teabe vahetamiseks. Heartbeat'i abil saavad serverid teineteise rikkeid teada, säilitavad ühtse andmeskeemi – tabelid, nende struktuur ja replikatsioon; partitsioneerimise skeem, klastrite topoloogia jne.

Kliendid

Standardsete draiverite asemel kasutatakse Fat Client režiimi. Selline sõlm ei salvesta andmeid, kuid võib toimida päringute täitmise koordinaatorina. See tähendab, et klient täidab ise oma päringute koordineerimise funktsiooni: küsib salvestuste koopiaid ja lahendab konflikte. See ei ole mitte ainult usaldusväärsem ja kiirem kui standardne draiver, mis nõuab suhtlemist kaugkoordinatsiooniga, vaid võimaldab ka päringute edastamise haldamist. Avatud tehingu korral suunatakse päringud salvestusse. Kui klient on tehingu avanud, suunatakse kõik tehingu raames tehtud päringud tehingute koordinaatorisse.

Tehingute koordinaator C*One

Koordinaator – see, mille me C*One jaoks nullist välja töötasime. Selle ülesanne on tehingute, lukustuste ja tehingute rakendamise järjekorra haldamine.

Iga teenindatava tehingu jaoks genereerib koordinaator ajatempli: iga järgneva aeg on suurem kui eelmise tehingu oma. Kuna Cassandras põhineb konfliktide lahendamise süsteem ajatemplitel (kahest konflikti allikast loetakse kehtivamaks see, millel on hilisem ajatempli väärtus), lahendatakse konflikt alati järgneva tehingu kasuks. Nii oleme me realiseerinud Lamporti kellad – odav viis konfliktide lahendamiseks jaotatud süsteemis.

Lukustused

Isolatsiooni tagamiseks otsustasime kasutada kõige lihtsamat meetodit – pessimistlikke lukustusi kirje primaarvõtme järgi. Teisisõnu, tehingu raames tuleb kirje esmalt lukustada, seejärel lugeda, muuta ja salvestada. Ainult pärast edukat kinnitamist võib kirje lukust vabastada, et konkurentsivõimelised tehingud saaksid seda kasutada.

Sellise lukustuse rakendamine on lihtne mittejaotatud keskkonnas. Jaotatud süsteemis on kaks peamist teed: kas rakendada jaotatud lukustust klastris või jaotada tehingud nii, et tehingud, mis hõlmavad ühte kirjet, teenindab alati sama koordinaator.

Kuna meie juhul on andmed juba jaotatud kohalike tehingute gruppides SQL-is, otsustati siduda iga kohaliku tehingu grupiga koordinaatorid: üks koordinaator teostab kõik tehingud, mille token on 0-9, teine - 10-19, ja nii edasi. Tulemuseks on, et iga koordinaatori eksemplar muutub tehingute grupi valitsejaks.

Siis saavad lukustused olla rakendatud nagu tavaline HashMap koordinaatori mälus.

Koordinaatorite rikke

Kuna üks koordinaator teenindab eriliselt tehingute gruppi, on väga oluline kiiresti kindlaks teha tema rike, et tehingu uuesti täitmine mahtuks ajavahemikku. Selleks, et see oleks kiire ja usaldusväärne, rakendasime täielikult ühendatud kvoorumi heartbeat protokolli:

Iga andmekeskuse kohta paikneb vähemalt kaks koordinaatori sõlme. Aeg-ajalt saadab iga koordinaator teistele koordinaatoritele heartbeat-sõnumi ja teavitab neid oma toimimisest, samuti sellest, milliseid heartbeat-sõnumeid ta viimati teistelt koordinaatoritelt klastris sai.

Saades sarnast teavet teistelt oma heartbeat-sõnumites, otsustab iga koordinaator, millised klastri sõlmed töötavad ja millised mitte, järgides kvoorumi põhimõtet: kui sõlm X sai enamiku klastri sõlmedelt teavet, et sõlm Y on sõnumid normaalselt saanud, siis Y töötab. Ja vastupidi, niipea, kui enamus teatab sõnumite kadumisest sõlmelt Y, siis Y on rikutud. Huvitav on see, et kui kvoorum teatab sõlmele X, et ta ei saa temalt enam sõnumeid, arvab see iseend, et on rikutud.

Heartbeat-õnnesõnumid saadetakse suure sagedusega, umbes 20 korda sekundis, 50 ms intervalliga. Java-s on raske tagada rakenduse vastust 50 ms jooksul, kuna prügikorjaja tekitab võrdse pikkusega pause. Õnnestus saavutada selline vastus G1 prügikorjajaga, mis võimaldab määrata GC peatuste kestuse eesmärgi. Siiski, harva, võivad prügikorjaja pausid ületada 50 ms, mis võib viia vale riketeavitamiseni. Selle vältimiseks ei teata koordinaator koheselt kaugnoodi tõrke kohta, kui esimene heartbeat-sõnum läheb kaduma, vaid ainult siis, kui mitu järjestikust on kadunud. N nii õnnestus saavutada koordinaatori noodi rikete avastamine 200 ms jooksul.

Kuid vähe on lihtsalt aru saada, milline nool on lakanud toimimast. Peame midagi ette võtma.

Varustamine

Klassikaline skeem eeldab, et juhendi rikke korral käivitame uue valimise ühega moes üldiselt algoritmidest. Sellistel algoritmidel on aga hästi teada probleemid konvergentsiga ajas ja valimiste protsessi kestuse osas. Kuigi nende lisaviivitustega oleme suutnud vältida, kasutades koordinaatorite asendamise skeemi täielikus ühenduses olevas võrgus:

Oletame, et soovime teostada tehingut rühmas 50. Määrame eelnevalt asendamise skeemi, st millised noodid viivad rühmas 50 tehingud ellu, juhul kui peamine koordinaator peaks ebaõnnestuma. Meie eesmärk on säilitada süsteemi töökindlus andmekeskuse tõrke korral. Määrame, et esmakordne varu on nool teisest andmekeskusest, ja teiseks varuks — nool kolmandast. See skeem valitakse üks kord ja ei muutu, kuni klastrite topoloogia ei muutu, st kuni ei liitu uusi noode (mis juhtub väga harva). Uue aktiivse juhendi valimise järjestus vanade tõrke korral on alati järgmine: aktiivseks juhiks saab esimene varu ning kui ka see enam ei toimi — siis teine varu.

See skeem on usaldusväärsem kui universaalne algoritm, kuna uue juhendi aktiveerimiseks piisab vana tõrke tuvastamisest.

Kuid kuidas saavad kliendid aru, kes meistritest hetkel töötab? 50 ms jooksul ei ole võimalik teavet saata tuhandetele klientidele. Võib juhtuda, et klient saadab päringu tehingu avamiseks, teadmata, et see meister ei tööta enam, ja päring lükatakse ajakavale. Selle vältimiseks saadavad kliendid spekulatiivselt päringu tehingu avamiseks kohe grupi meistrile ja tema kahe reservmeistrile, kuid vastab sellele päringule ainult see, kes on hetkel aktiivne meister. Kogu hilisem suhtlus tehingu raames toimub ainult aktiivse meistriga.

Reservmeistrid, kes saavad päringud mitte enda tehingute kohta, paigutavad need sündimata tehingute järjekorda, kus nad hoiustatakse mõnda aega. Kui aktiivne meister sureb, siis uus meister töötleb päringud tehingute avamiseks oma järjekorrast ja vastab kliendile. Kui klient on juba suutnud avada tehingu vana meistriga, siis teine vastus jäetakse tähelepanuta (ja ilmset ei saa selline tehing lõpule viidud ning klient peab seda kordama).

Kuidas tehing töötab

Oletame, et klient saatis koordinaatorile päringu tehingu avamiseks sellise entiteedi jaoks, millel on selline põhivõti. Koordinaator blokeerib selle entiteedi ja paigutab selle mälus blokeerimislauda. Vajadusel loeb koordinaator selle entiteedi salvestusest ja salvestab saadud andmed tehingu olekusse koordinaatori mällu.

Kui klient soovib tehingus andmeid muuta, saadab ta koordinaatorile päringu entiteedi muutmiseks, mille puhul koordinaator paigutab uued andmed tehingute olekute tabelisse mällu. Sellega on kirjutamine lõpetatud — salvestusse kirjutamine ei toimu.

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

kui ID on tehingus juba olemas, siis andmed võetakse mälust;
kui ID mälus puudub, siis loetakse puuduvad andmed sõlme salvestustest, ühendatakse need juba olemasolevate andmetega mälus ning tulemus antakse kliendile.

Nii saab klient lugeda enda muudatusi, kuid teised kliendid neid muudatusi ei näe, sest need on talletatud ainult koordinaatori mälus, sõlmedes Cassandra’s neid veel ei ole.

Kui klient saadab commit'i, salvestab koordinaator teenuse mälus olnud oleku logged batch'i, ja see juba logged batch'ina saadetakse Cassandra ladustamisse. Ladustamine teeb kõik vajaliku, et see pakett oleks aatomaarne (täielikult) rakendatud, ja tagastab vastuse koordinaatorile, kes vabastab lukud ja kinnitab tehingu edukuse kliendile.

Ja juhul, kui tuleb tagasivõtt, piisab koordinaatorist, et lihtsalt vabastada mälu, mis sisaldab tehingu olekut.

Ülaltoodud täiendustega oleme rakendanud ACID põhimõtteid:

Aatomaarusus. See tagab, et ükski tehing ei salvestata süsteemi osaliselt, kas kõik selle alamoperatsioonid täidetakse või ei täideta ühtegi. Meie puhul säilitatakse see põhimõte logged batch'i kaudu Casandsas.
Järjepidevus. Iga edukas tehing fikseerib määratletud tulemused. Kui pärast tehingu avamist ja osa operatsioonide täitmist leitakse, et tulemus on mittesobiv, tehakse tagasivõtt.
Isolatsioon. Tehingu täitmise ajal ei tohiks parallel-tehingud mõjutada selle tulemust. Konkurentsivõimelised tehingud on isoleeritud koordinaatori pessimistlike lukustustega. Välistehingute lugemise korral järgime isoleerituse põhimõtet Read Committed tasandil.
Püsivus. Ükskõik millised probleemid alumistel tasanditel — süsteemi voolukatkestus, seadmete tõrge —, edukalt lõpetatud tehingu muudatused peavad jääma alles pärast süsteemi taasfunktsioneerimist.

Lugemine indeksite kaudu

Võtame lihtsa tabeli:

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

Sellest tabelist on ID (esmane võti), omanik ja muutmise kuupäev. Peame tegema väga lihtsa päringu — valima andmed omaniku järgi, kelle muudatuse kuupäev on "viimase 24 tunni" jooksul.

SELECT *
WHERE owner=?
AND modified>?

Selle taolise päringu kiireks töötlemiseks peab klassikalises SQL andmebaasis ehitama indeksid veergudele (owner, modified). Me saame seda teha piisavalt lihtsalt, kuna nüüd on meil ACID garantii!

Indeksid C*One

Olemas on fotosid sisaldav algne tabel, mille kande ID on esmane võti.

Indeksi jaoks loob C*One uue tabeli, mis on algse koopia. Võti on sama, mis indeksile vastav väljend, samal ajal sisaldab see ka algse tabeli esmast võtit:

Nüüd saab päringu „omanik viimase 24 tunni jooksul“ ümber kirjutada valiku kaudu teiselt tabelilt:

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

Algse tabeli fotosid ja indeksit i1 kooskõlastatakse automaatselt koordinaatori poolt. Ainuüksi andmeskeemi alusel genereerib ja salvestab koordinaator muudatuse mitte ainult põhiteabesse, vaid ka koopiate muudatused. Täiendavaid toiminguid indeksitabeliga ei tehta, logisid ei loeta, lukustusi ei kasutata. See tähendab, et indeksite lisamine tarbib peaaegu mitte mingeid ressursse ja ei mõjuta oluliselt muudatuste rakendamise kiirus.

ACID-i abil oleme suutnud rakendada indekseid „nagu SQL-is“. Need on kooskõlastatud, skaleeritavad, töötavad kiiresti, võivad olla koostatud ja sisseehitatud CQL-päringu keelde. Indeksite toetamiseks ei ole vaja rakenduskoodi muuta. Kõik on lihtne, nagu SQL-is. Ja mis kõige tähtsam, indeksid ei mõjuta algse tehingute tabeli muudatuste täitmise kiirus.

Mis välja tuli

Me arendasime C*One välja kolm aastat tagasi ja käivitasime selle tööstuslikuks kasutuseks.

Mida me lõpuks saime? Hinnake seda meie fotode töötlemise ja salvestamise alamsüsteemi näitel, mis on sotsiaalvõrgustikus üks olulisemaid andmete tüüpe. Räägime mitte ainult fotode tegelikest kehade, vaid ka erinevatest metaandmetest. Praegu on „Odnoklassnikites“ umbes 20 miljardit sellist salvestust, süsteem töötleb 80 tuhat lugemisepäringut sekundis ja kuni 8 tuhat ACID-tehingut sekundis, mis on seotud andmete muutmisega.

Kui kasutasime SQL-i replikatsiooni teguriga = 1 (aga RAID 10. puhul), hoiti fotode metaandmed kõrge kättesaadavusega klastris, mis koosneb 32 masinast Microsoft SQL Serveriga (pluss 11 varukoopiat). Samuti oli eraldatud 10 serverit varukoopiate hoidmiseks. Kokku 50 kulukat masinat. Sel ajal töötas süsteem nominaalsel koormusel, ilma varu.

Pärast üleminekut uuele süsteemile saime replikatsiooni teguri = 3 — iga andmekeskuse kohta üks koopia. Süsteem koosneb 63 Cassandra salvestusnode'ist ja 6 masinast koordinaatoreid, kokku 69 serverit. Kuid need masinad on oluliselt odavamad, nende koguhind on umbes 30% SQL-i süsteemi hinnast. Samal ajal jääb koormus 30% tasemele.

C*One rakendamisega vähenesid ka viivitused: SQL-i kirjutamise operatsioon kestis umbes 4,5 ms. C*One-s — umbes 1,6 ms. Tehingu kestus on keskmiselt alla 40 ms, kinnitamine toimub 2 ms jooksul, lugemise ja kirjutamise kestus — keskmiselt 2 ms. 99. percentiili jaoks — vaid 3–3,1 ms, ajakulu vähenes 100 korda — kõik tänu spekulatsioonide laialdasele kasutamisele.

Käesolevaks ajaks on suurem osa SQL Serveri sõlmedest välja võetud, uusi tooteid arendatakse ainult C*One kasutades. Oleme kohandanud C*One meie pilve tööks. one-cloud, mis võimaldas kiirendada uute klastrite loomist, lihtsustada konfiguratsiooni ja automateerida hooldust. Ilma lähtekoodita oleks seda palju keerulisem ja kätšiaduslikum teha.

Käesolevalt töötame teiste meie salvestussüsteemide pilve üleviimise kallal — kuid see on juba hoopis teine lugu.

Allikas: habr.com