{"id":37956,"date":"2019-10-31T22:20:47","date_gmt":"2019-10-31T19:20:47","guid":{"rendered":"https:\/\/prohoster.info\/blog\/newsql-nosql-acid\/"},"modified":"2019-10-31T22:20:47","modified_gmt":"2019-10-31T19:20:47","slug":"newsql-nosql-acid","status":"publish","type":"post","link":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/newsql-nosql-acid","title":{"rendered":"UusSQL = NoSQL + ACID","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"UusSQL = NoSQL + ACID\" src=\"\/wp-content\/uploads\/2019\/09\/973145efa566bca10ffe7ba95733a1d5.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nKuni viimase ajani oli Odnoklassnikis umbes 50 TB andmeid, mida t\u00f6\u00f6tleti reaalajas, salvestatud SQL Serverisse. Sellise mahuga on kiire ja usaldusv\u00e4\u00e4rse ning rikkevastase andmekeskuse juurdep\u00e4\u00e4su tagamine, kasutades SQL andmebaasi, praktiliselt v\u00f5imatu. Tavaliselt kasutatakse sellistes olukordades m\u00f5nd NoSQL-lahendust, kuid mitte k\u00f5ik ei sobi NoSQL-i: m\u00f5ned entiteedid n\u00f5uavad ACID-tehingute garantiisid. <\/p>\n<p>See viis meid NewSQL-andmebaasi kasutamiseni, mis t\u00e4hendab andmebaasi, mis pakub rikkevastupidavust, skaleeritavust ja NoSQL-s\u00fcsteemide kiirus, kuid samas s\u00e4ilitab klassikaliste s\u00fcsteemide jaoks tuttavad ACID-garantii. T\u00f6\u00f6tavad t\u00f6\u00f6stuslikud s\u00fcsteemid sellest uuest klassist on haruldased, seet\u00f5ttu realiseerisime sellise s\u00fcsteemi ise ja lansseerisime selle t\u00f6\u00f6stuslikuks kasutuseks. <\/p>\n<p>Kuidas see t\u00f6\u00f6tab ja milline l\u00e4henemine \u00f5nnestus \u2014 loe edasi.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\nT\u00e4na on \u201eOdnoklassniki\u201c igakuine k\u00fclastajaskond \u00fcle 70 miljoni unikaalse k\u00fclastaja. Me <noindex><a rel=\"nofollow\" href=\"https:\/\/www.similarweb.com\/top-websites\/category\/internet-and-telecom\/social-network\">oleme viie parima seas<\/a><\/noindex> maailma suurimad sotsiaalmeedia platvormid ja kuulub ka veebi 20 k\u00f5ige rohkem k\u00fclastatava saidi hulka. 'OK' infrastruktuur suudab taluda v\u00e4ga k\u00f5rgeid koormusi: rohkem kui miljon HTTP-p\u00e4ringut sekundis. \u00dcle 8000 serveri jaguneb neljas Moskvas asuvas andmekeskuses, mis v\u00f5imaldab tagada v\u00f5rgu latentsuse alla 1 ms nende vahel.<\/p>\n<p>Kasutame Cassandrat alates 2010. aastast, alustades versioonist 0.6. T\u00e4naseks on kasutuses mituk\u00fcmmend klastrit. Kiireim klaster t\u00f6\u00f6tleb rohkem kui 4 miljonit operatsiooni sekundis, samas kui suurim salvestab 260 TB. <\/p>\n<p>Kuid need on tavap\u00e4rased NoSQL-klastrid, mida kasutatakse andmete salvestamiseks <noindex><a rel=\"nofollow\" href=\"https:\/\/ru.wikipedia.org\/wiki\/%D0%A1%D0%BE%D0%B3%D0%BB%D0%B0%D1%81%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D0%BE%D1%81%D1%82%D1%8C_%D0%B2_%D0%BA%D0%BE%D0%BD%D0%B5%D1%87%D0%BD%D0%BE%D0%BC_%D1%81%D1%87%D1%91%D1%82%D0%B5\">n\u00f5rgalt koosk\u00f5lastatud<\/a><\/noindex> andmete jaoks. Soovisime asendada peamise koosk\u00f5lastatud 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 - \u00e4rikontseptsioone. Need andmed muudetakse ACID-tehingute raames ja vajavad <noindex><a rel=\"nofollow\" href=\"https:\/\/ru.wikipedia.org\/wiki\/ACID\">k\u00f5rget koosk\u00f5lastatust<\/a><\/noindex>.<\/p>\n<p>SQL Serveri s\u00f5lmedes andmete hajutamiseks kasutasime nii vertikaalset kui ka horisontaalset <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Partition_(database)\">partitsioneerimist<\/a><\/noindex> (shardimine). Ajalooliselt oleme kasutanud lihtsat andmete shardimise skeemi: igale entiteedile m\u00e4\u00e4rati token \u2013 funktsioon entiteedi ID-st. \u00dchised tokenid paigutati \u00fchele SQL-serverile. Master-detail suhe oli rakendatud nii, et p\u00f5hikirje ja alakirje tokenid langevad alati kokku ja asuvad samal serveril. Sotsiaalv\u00f5rgustikus genereeritakse peaaegu k\u00f5ik kirjed kasutaja nime alt \u2013 see t\u00e4hendab, et k\u00f5ik kasutaja andmed \u00fche funktsionaalse alams\u00fcsteemi piires salvestatakse \u00fchele serverile. See t\u00e4hendab, et \u00e4ritehingutes osalesid peaaegu alati sama SQL-serveri tabelid, mis v\u00f5imaldas andmete j\u00e4rjepidevust tagada kohalike ACID-tehingute abil, ilma vajaduseta kasutada <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Two-phase_commit_protocol\">aeglaseid ja ebat\u00e4iuslikke<\/a><\/noindex> jaotatud ACID-tehinguid.<\/p>\n<p>Shardimise ja SQL t\u00f6\u00f6 kiirusel:<\/p>\n<ul>\n<li>Mitte kasutada Foreign key constraints, kuna shardimisel v\u00f5ib entiteedi ID asuda teisel serveril.<\/li>\n<li>Me ei kasuta salvestatud protseduure ja tr\u00fcgeerijaid, kuna need koormavad andmebaasi CPU-d.<\/li>\n<li>Me ei kasuta JOIN-e eeltoodud p\u00f5hjustel ning paljude juhuslike lugemiste t\u00f5ttu kettalt.<\/li>\n<li>V\u00e4heneme omavaheliste ummikute tagamiseks kasutame v\u00e4ljaspool tehingut eraldusastet Read Uncommitted.<\/li>\n<li>Teostame ainult l\u00fchikesi tehinguid (keskmiselt alla 100 ms).<\/li>\n<li>Me ei kasuta mitmerealisi UPDATE ja DELETE k\u00e4ske, kuna need p\u00f5hjustavad palju ummikuid \u2014 v\u00e4rskendame ainult \u00fcht kirjet korraga.<\/li>\n<li>K\u00fcsimused t\u00e4idame alati ainult indeksite kaudu \u2014 k\u00fcsimus, mille plaan on kogu tabeli vaatamine, t\u00e4hendab meie jaoks andmebaasi \u00fclekoormust ja selle t\u00f5rget.<\/li>\n<\/ul>\n<p>\nNeed sammud on v\u00f5imaldanud meie SQL-serveritel saavutada peaaegu maksimaalset j\u00f5udlust. Kuid probleeme sai j\u00e4rjest rohkem. Vaatame neid \u00fcle.<\/p>\n<h2>Probleemid SQL-iga<\/h2>\n<p><\/p>\n<ul>\n<li>Kuna kasutasime k\u00e4sitsi kirjutatud shardingut, lisasid administraatorid uusi shard'e k\u00e4sitsi. Kogu selle aja jooksul ei teenindanud skaleeritavad andmete koopiad p\u00e4ringuid. <\/li>\n<li>Kuna tabelisse kantavate kirjete arv kasvab, v\u00e4heneb sisestamise ja muutmise kiirus, ja indeksite lisamine olemasolevale tabelile kiirus langeb m\u00e4rgatavalt, indeksite loomine ja uuesti loomine toimub katkestustega.<\/li>\n<li>Piiratud Windowsi olemasolu SQL Serveri jaoks tootmiskeskkonnas raskendab infrastruktuuri haldamist.<\/li>\n<\/ul>\n<p>\nAga peamine probleem on \u2014 <\/p>\n<h2>Katastroofitaluvus<\/h2>\n<p>\nKlassikalise SQL-serveri katastroofitaluvus on halb. Oletame, et teil on vaid \u00fcks andmebaasi server ja see eba\u00f5nnestub kord kolme aasta jooksul. Sel ajal on veebileht maas 20 minutit, mis on vastuv\u00f5etav. Kui teil on 64 serverit, siis on veebileht maas kord kolme n\u00e4dala jooksul. Ja kui teil on 200 serverit, siis on veebileht maas iga n\u00e4dala. See on probleem. <\/p>\n<p>Mida saab teha SQL-serveri katastroofitaluvuse t\u00f5stmiseks? Vikipeedia soovitab meil \u00fcles ehitada <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/High-availability_cluster\">k\u00f5rge saadavusega klaster<\/a><\/noindex>: kus \u00fcksk\u00f5ik millise komponente eba\u00f5nnestumise korral on duplikatsioon.<\/p>\n<p>See n\u00f5uab kallite seadmete parki: ulatuslikud dubleerimised, kiudoptiline side, jagatud salvestusruum, ja varukoopiate aktiveerimise t\u00f6\u00f6kindlus on madal: umbes 10% k\u00e4ivitustest l\u00f5ppeb varurelva kaaslasena, mis eba\u00f5nnestub p\u00f5hiv\u00f5rguga. <\/p>\n<p>Kuid peamine puudus sellisel k\u00f5rge k\u00e4ttesaadavuse klastril on nullk\u00e4ttesaadavus andmekeskuse t\u00f5rke korral, kus see asub. \u201eOdnoklassniki\u201d omab nelja andmekeskust, ja peame tagama t\u00f6\u00f6kindluse t\u00e4ieliku rikke korral \u00fches neist.<\/p>\n<p>Selle jaoks v\u00f5iks rakendada <noindex><a rel=\"nofollow\" href=\"https:\/\/technet.microsoft.com\/en-us\/library\/ms151196.aspx\">Multi-Master<\/a><\/noindex> replikatsiooni, mis on integreeritud SQL Serverisse. See lahendus on palju kallim tarkvara hinna t\u00f5ttu ja kannatab h\u00e4sti tuntud replikatsiooni probleemide all \u2014 ettearvamatud tehingute viivitused s\u00fcnkroonses replikatsioonis ja viivitused replikatsioonide rakendamisel (ja seega ka kadunud muudatused) as\u00fcnkroonse replikatsiooni puhul. Eeldatav <noindex><a rel=\"nofollow\" href=\"https:\/\/docs.microsoft.com\/en-us\/sql\/relational-databases\/replication\/transactional\/peer-to-peer-conflict-detection-in-peer-to-peer-replication\">k\u00e4tega konfliktide lahendamine<\/a><\/noindex> teeb selle variandi meie jaoks t\u00e4iesti sobimatuks.<\/p>\n<p>K\u00f5ik need probleemid vajasid radikaalset lahendust ning me alustasime nende p\u00f5hjalikku anal\u00fc\u00fcsi. Siin peame tutvuma sellega, mis on SQL Serveri peamine \u00fclesanne \u2014 tehingud.<\/p>\n<h2>Lihtne tehing<\/h2>\n<p>\nVaatleme k\u00f5ige 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\u00e4rgmistesse etappidesse: <\/p>\n<ol>\n<li>Lukustame albumi v\u00f5tme alusel.<\/li>\n<li>Loome kirje fotode tabelis. <\/li>\n<li>Kui fotol on avalik staatus, siis suurendame albumis avalike fotode arvestit, uuendame kirjet ja kinnitame tehingu.<\/li>\n<\/ol>\n<p>\nV\u00f5i pseudokoode formaadis:<\/p>\n<pre><code>TX.start(\"Albumid\", id);\nAlbum album = albums.lock(id);\nPhoto photo = photos.create(\u2026);\n\nif (photo.status == PUBLIC) {\n    album.incPublicPhotosCount();\n}\nalbum.update();\n\nTX.commit();<\/code><\/pre>\n<p>\nN\u00e4eme, et k\u00f5ige levinum \u00e4rilise tehingu stsenaarium on andmete lugemine andmebaasist rakenduste serveri m\u00e4llu, nende muutmine ja uute v\u00e4\u00e4rtuste salvestamine tagasi andmebaasi. Tavaliselt v\u00e4rskendame sellise tehingu k\u00e4igus mitmeid olendeid, mitmeid tabeleid. <\/p>\n<p>Tehingu l\u00e4biviimisel v\u00f5ib esineda sama andmete konkurentsis\u00fcsteemide vahelisi muudatusi. N\u00e4iteks v\u00f5ib Antispam otsustada, et kasutaja on kahtlane ning seet\u00f5ttu ei tohiks k\u00f5ik kasutaja fotod enam avalikud olla, need tuleb saata modereerimisele, mis t\u00e4hendab, et photo.status tuleb muuta teiseks v\u00e4\u00e4rtuseks ja vastavaid loendureid tuleb reguleerida. Ilmselt, kui see operation toimub ilma atomaarsete rakendamise ja konkureerivate muudatuste isoleerimise garantii, nagu <noindex><a rel=\"nofollow\" href=\"https:\/\/ru.wikipedia.org\/wiki\/ACID\">ACID<\/a><\/noindex>, siis tulemus ei ole see, mis on vajalik \u2014 kas fotode loendur n\u00e4itab vale v\u00e4\u00e4rtust v\u00f5i ei saadeta k\u00f5ik fotod modereerimisele. <\/p>\n<p>Sarnast koodi, mis manipuleerib erinevate \u00e4ri\u00fchendustega \u00fche tehingu raames, on k\u00f5ikide aastate jooksul Odnoklassnikute olemasolu jooksul kirjutatud v\u00e4ga palju. Migratsioonide kogemuse p\u00f5hjal NoSQL-le, <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Eventual_consistency\">L\u00f5plik j\u00e4rjepidevus<\/a><\/noindex> Teame, et suurimad v\u00e4ljakutsed (ja ajakulu) tulenevad vajadusest arendada koodi, mis tagab andmete j\u00e4rjepidevuse. Seet\u00f5ttu pidasime uue andmesalvestuse peamiseks n\u00f5udeks rakendusloogika t\u00f5eliste ACID-tehingute toetamise. <\/p>\n<p>Teised, mitte v\u00e4hem olulised n\u00f5uded olid:<\/p>\n<ul>\n<li>Andmekeskuse t\u00f5rgete korral peavad nii lugemine kui ka kirjutamine olema uude salvestusse saadaval.<\/li>\n<li>Praeguse arenduskiirus s\u00e4ilitamine. See t\u00e4hendab, et uue salvestusega t\u00f6\u00f6tades peaks koodi hulk j\u00e4\u00e4ma enam-v\u00e4hem samaks, ilma et oleks vaja kirjutada midagi uut salvestusse, v\u00e4lja t\u00f6\u00f6tada konfliktide lahendamise algoritme, hooldada teiseseid indekseid jne. <\/li>\n<li>Uue salvestuse t\u00f6\u00f6kiirus peab olema piisavalt k\u00f5rge, nii andmete lugemisel kui tehingute t\u00f6\u00f6tlemisel, mis t\u00f5husalt v\u00e4listab akadeemiliselt rangeid, universaalseid, kuid aeglaseid lahendusi, nagu n\u00e4iteks <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Two-phase_commit_protocol\">kahefaasilised millede kinnitamine<\/a><\/noindex>.<\/li>\n<li>Automaatne reaalajas skaleerimine. <\/li>\n<li>Tavap\u00e4raste odavate serverite kasutamine, ilma et oleks vaja osta eksootilisi riistvara. <\/li>\n<li>Arenduse v\u00f5imalus arendajate poolt. Teisis\u00f5nu, prioriteet anti enda v\u00f5i avatud l\u00e4htekoodiga lahendustele, eelistatavalt Java-s.<\/li>\n<\/ul>\n<p><\/p>\n<h2>Lahendused, lahendused<\/h2>\n<p>\nAnal\u00fc\u00fcsides v\u00f5imalikke lahendusi, j\u00f5udsime kahe arhitektuurivaliku juurde:<\/p>\n<p>Esimene - v\u00f5tta \u00fcksk\u00f5ik milline SQL-server ja rakendada vajalikud t\u00f5rkelevitus, skaleerimismehhanism, t\u00f5rkevaba klaster, konfliktide lahendamine ning jaotatud, usaldusv\u00e4\u00e4rsed ja kiire ACID-tehingud. Hindasime seda varianti kui \u00fcsna keerukat ja t\u00f6\u00f6mahukat.<\/p>\n<p>Teine variant - v\u00f5tta valmis NoSQL-andmehoidla, millel on rakendatud skaleerimine, t\u00f5rkevaba klaster, konfliktide lahendamine ning rakendada tehingud ja SQL ise. Esmapilgul tundub isegi SQL-i rakendamise \u00fclesanne, r\u00e4\u00e4kimata ACID-tehingutest, kui aastatepikkune projekt. Kuid hiljem saime aru, et SQL-i v\u00f5imaluste komplekt, mida me praktikas kasutame, on kaugel ANSI SQL-ist, sama kaugel kui <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Apache_Cassandra#Cassandra_Query_Language\">Cassandra CQL<\/a><\/noindex> ANSI SQL-ist. Kui me vaatame CQL-i veel l\u00e4hemalt, saame aru, et see on piisavalt l\u00e4hedal sellele, mida me vajame.<\/p>\n<h2>Cassandra ja CQL<\/h2>\n<p>\nNii et, millega Cassandra huvitav on ja milliseid v\u00f5imalusi see pakub?<\/p>\n<p>Esiteks on siin v\u00f5imalik luua tabeleid, mis toetavad erinevaid andmet\u00fc\u00fcpe, ning teha SELECT v\u00f5i UPDATE p\u00f5hiava p\u00f5hjal.<\/p>\n<pre><code>CREATE TABLE photos (id bigint KEY, owner bigint,\u2026);\nSELECT * FROM photos WHERE id=?;\nUPDATE photos SET \u2026 WHERE id=?;<\/code><\/pre>\n<p>\nReplikatsioonide andmete j\u00e4rjepidevuse tagamiseks kasutab Cassandra <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Quorum_(distributed_computing)\">kvooti l\u00e4henemist<\/a><\/noindex>. Lihtsustatult t\u00e4hendab see, et kui kolm koopiat samast r\u00fchmast paiknevad erinevates klastrinode'is, loetakse kirje edukaiks, kui enamus noode (ehk kaks kolmest) on kinnitanud selle kirjutamise operatsiooni edukust. R\u00fchma andmed peetakse koosk\u00f5lastatuks, kui lugemise ajal on enamus noode k\u00fcsitletud ja kinnitanud need. Seega tagatakse, et kolme koopia olemasolu korral on andmete t\u00e4ielik ja kohene koosk\u00f5la, kui \u00fcks node kukub. See l\u00e4henemine on v\u00f5imaldanud meil rakendada veelgi usaldusv\u00e4\u00e4rsemat skeemi: alati saata p\u00e4ringud k\u00f5ikidele kolmele koopiale, oodates vastust kahest kiirest. Kolmanda koopia viivitatud vastust sellisel juhul ignoreeritakse. Viivitusi kogevatel noodel v\u00f5ivad samas olla t\u00f5sised probleemid - lag, JVM-is pr\u00fcgi kogumine, Linuxi kernelis otsem\u00e4lu tagasiv\u00f5tmine, riistvara rike, v\u00f5rgu\u00fchenduse katkestamine. Siiski ei m\u00f5juta see kliendi operatsioone ega andmeid.<\/p>\n<p>L\u00e4henemine, kus me p\u00f6\u00f6rdume kolme node poole, kuid saame vastuse kahest, nimetatakse <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Speculative_execution\">spekulatsiooniks<\/a><\/noindex>: p\u00e4ring \u00fclem\u00e4\u00e4rastele koopiatele saadetakse veel enne, kui need 'langema' hakkavad. <\/p>\n<p>Cassandra \u00fcheks eeliseks on Batchlog \u2014 mehhanism, mis tagab kas t\u00e4ieliku rakendamise v\u00f5i t\u00e4ieliku rakendamata j\u00e4tmise teie tehtud muudatuste paketis. See v\u00f5imaldab meil lahendada A ACID-is \u2014 atomaarne nagu v\u00e4lja pakutud.<\/p>\n<p>Cassandra's transactions are closest to the so-called &#171;<noindex><a rel=\"nofollow\" href=\"https:\/\/docs.datastax.com\/en\/cql\/3.3\/cql\/cql_using\/useInsertLWT.html\">lightweight transactions<\/a><\/noindex>&#171;. However, they are far from 'true' ACID transactions: in reality, this offers the capability to make <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Compare-and-swap\">CAS<\/a><\/noindex> ainult \u00fche kirje andmete kohta, kasutades raskema Paxose protokolli konsensust. Seet\u00f5ttu on nende tehingute kiirus madal. <\/p>\n<h2>Mida me Cassandra'st puudusime<\/h2>\n<p>\nNii pidime me rakendama Cassandra's t\u00f5elist ACID-tehingut. Mille abil saaksime kergesti rakendada kaht muud mugavat v\u00f5imalust klassikalistes andmebaasihalduss\u00fcsteemides: j\u00e4rjepidevad kiireid indekseid, mis v\u00f5imaldaksid meil andmete valimist teostada mitte ainult p\u00f5hiv\u00f5tme j\u00e4rgi, vaid ka tavalise monotoonse auto-increment ID generaatori.<\/p>\n<h4>C*One<\/h4>\n<p>\nNii s\u00fcndis uus andmebaasis\u00fcsteem <b>C*One<\/b>, mis koosneb kolmest t\u00fc\u00fcpi serveri solgist:<\/p>\n<ul>\n<li>Andmed \u2014 (peaaegu) standardiseeritud Cassandra-serverid, mis vastutavad andmete salvestamise eest kohalikesse diskidesse. Koormuse ja andmemahu suurenedes on nende arvu lihtne skaleerida k\u00fcmnete ja sadade kaupa.<\/li>\n<li>Tehingukoordinaatorid \u2014 tagavad tehingute t\u00e4itmise. <\/li>\n<li>Kliendid \u2014 rakendusserverid, mis teostavad \u00e4ritegevust ja k\u00e4ivitavad tehinguid. Selliseid kliente v\u00f5ib olla tuhandeid.<\/li>\n<\/ul>\n<p>\n<img decoding=\"async\" alt=\"UusSQL = NoSQL + ACID\" src=\"\/wp-content\/uploads\/2019\/09\/f3809d89404ae596c62b642dbdb9e431.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nK\u00f5ik serverid kuuluvad \u00fcldisse klastrisse, kasutavad omavaheliseks suhtlemiseks Cassandra sisemist s\u00f5numiprotokolli ja <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Gossip_protocol\">gossip<\/a><\/noindex> klastriteabe vahetamiseks. Heartbeat'i abil saavad serverid teada \u00fcksteise t\u00f5rgetest, s\u00e4ilitavad \u00fchtse andmeskeemi \u2014 tabelid, nende struktuur ja replikatsioon; partitsioneerimise skeem, klastrite topoloogia jne.<\/p>\n<h4>Kliendid<\/h4>\n<p>\n<img decoding=\"async\" alt=\"UusSQL = NoSQL + ACID\" src=\"\/wp-content\/uploads\/2019\/09\/80f83358f215cf59db3b657ba1083420.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nStandardsete draiverite asemel kasutatakse Fat Client re\u017eiimi. Selline nod ei salvestata andmeid, vaid v\u00f5ib toimida p\u00e4ringute t\u00e4itmise koordinaatorina, st Klient t\u00e4idab ise oma p\u00e4ringute koordinaatori funktsiooni: k\u00fcsib ladustamise koopiaid ja lahendab konfliktid. See on mitte ainult usaldusv\u00e4\u00e4rsem ja kiirem kui standardne draiver, mis n\u00f5uab suhtlemist eemal asuva koordinaatoriga, vaid v\u00f5imaldab ka p\u00e4ringute edastamise juhtimist. Klientide avatud tehingute puhul saadetakse p\u00e4ringud ladustamisse. Kui klient on avadanud tehingu, siis suunatakse k\u00f5ik selle tehingu p\u00e4ringud tehingute koordinaatorisse.<br \/>\n<img decoding=\"async\" alt=\"UusSQL = NoSQL + ACID\" src=\"\/wp-content\/uploads\/2019\/09\/709bf227eeb8f71abeff703a72780efd.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Tehingute koordinaator C*One<\/h2>\n<p>\nKoordinaator on see, mida me oleme C*One jaoks nullist v\u00e4lja ehitanud. Ta vastutab tehingute, lukustuste ja tehingute kehtestamise j\u00e4rjekorra haldamise eest.<\/p>\n<p>Iga teenindatava tehingu jaoks genereerib koordinaator ajatempli: iga j\u00e4rgmine on suurem kui eelmise tehingu oma. Kuna Cassandras p\u00f5hineb konfliktide lahendamise s\u00fcsteem ajatemplitel (kaks konfliktset kirjet loetakse aktuaalseks see, millel on hilisem ajatempli v\u00e4\u00e4rtus), siis lahendatakse konflikt alati j\u00e4rgmise tehingu kasuks. Nii oleme me rakendanud <noindex><a rel=\"nofollow\" href=\"https:\/\/ru.wikipedia.org\/wiki\/%D0%A7%D0%B0%D1%81%D1%8B_%D0%9B%D1%8D%D0%BC%D0%BF%D0%BE%D1%80%D1%82%D0%B0\">Lamporti kellad<\/a><\/noindex> \u2014 odav viis konfliktide lahendamiseks jaotatud s\u00fcsteemis.<\/p>\n<h2>Lukud<\/h2>\n<p>\nIsolatsiooni tagamiseks otsustasime kasutada k\u00f5ige lihtsamat meetodit \u2014 pessimistlikud lukud kirje p\u00f5hi v\u00f5tme j\u00e4rgi. Teisis\u00f5nu, tehingu k\u00e4igus tuleb kirje esmalt lukustada, enne kui seda saab lugeda, muuta ja salvestada. Ainult p\u00e4rast eduka komiteerimist v\u00f5ib kirje lukust vabastada, et konkurentsiv\u00f5imelised tehingud saaksid seda kasutada.<\/p>\n<p>Selle blokeerimise rakendamine on lihtne jaotamata keskkonnas. Jaotatud s\u00fcsteemis on kaks peamist teed: kas rakendada jaotatud lukustust klastris v\u00f5i jaotada tehingud nii, et \u00fche kirje osalusega tehingud teenindatakse alati sama koordinaatori poolt.<\/p>\n<p>Kuna meie juhul on andmed juba jaotatud kohalike tehingute gruppides SQL-is, otsustati m\u00e4\u00e4rata koordinaatoritele kohalike tehingute grupid: \u00fcks koordinaator t\u00e4idab k\u00f5ik tehingud tokeniga vahemikus 0 kuni 9, teine \u2014 vahemikus 10 kuni 19 ja nii edasi. Tulemuseks on see, et iga koordinaatori eksemplar muutub tehingute grupi isandaks. <\/p>\n<p>Seega saavad lukustused olla rakendatud lihtsalt koordinaatori m\u00e4lus olevate HashMap'ide kujul.<\/p>\n<h2>Koordinaatorite rikkeid<\/h2>\n<p>\nKuna \u00fcks koordinaator teenindab eranditult tehingute gruppi, on \u00e4\u00e4rmiselt oluline kiiresti tuvastada tema rike, et uue tehingu proovimine mahuks ajavahemikku. Selle kiire ja usaldusv\u00e4\u00e4rne tegemiseks rakendasime t\u00e4ieliku linkimise kvora hearbeat protokolli:<\/p>\n<p>Igas andme keskuses on v\u00e4hemalt kaks koordinaatori s\u00f5lme. Aeg-ajalt saadab iga koordinaator teistele koordinaatoritele s\u00fcdame l\u00f6\u00f6gi s\u00f5numi, teavitades neid oma toimimisest ning millistelt koordinaatoritelt on ta viimati s\u00fcdame l\u00f6\u00f6gi s\u00f5numeid saanud. <\/p>\n<p><img decoding=\"async\" alt=\"UusSQL = NoSQL + ACID\" src=\"\/wp-content\/uploads\/2019\/09\/5c337e53815cad0a2071b160d98d42fa.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSaades sarnast teavet teistelt nende s\u00fcdame l\u00f6\u00f6gi s\u00f5numites, otsustab iga koordinaator, millised klastris olevad s\u00f5lmed toimivad ja millised mitte, j\u00e4rgides kvoorumi p\u00f5him\u00f5tet: kui s\u00f5lm X on saanud enamiku s\u00f5lmede poolt klastris teavet normaalsest s\u00f5numite vastuv\u00f5tmisest s\u00f5lmelt Y, siis toimib Y. Vastupidi, niipea kui enamus teatab s\u00f5lmelt Y s\u00f5numite kadumisest, t\u00e4hendab see, et Y on rikki l\u00e4inud. Huvi p\u00e4rast, kui kvoorum teatab s\u00f5lmele X, et ta ei saa temalt enam s\u00f5numeid, hakkab s\u00f5lm X pidama end rikki l\u00e4inuks.<\/p>\n<p>Heartbeat-s\u00f5numite 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\u00f5hjustab pr\u00fcgikoristaja, on sarnane. Oleme suutnud saavutada sellise vastuseaja, kasutades G1 pr\u00fcgikoristajat, mis v\u00f5imaldab m\u00e4\u00e4rata GC pauside kestuse sihte. Siiski, m\u00f5nikord, harva, \u00fcletavad pr\u00fcgikoristaja pausid 50 ms, mis v\u00f5ib viia vale t\u00f5rke avastamiseni. Selle v\u00e4ltimiseks ei teata koordinaator kaug-noodi t\u00f5rkest kohe, kui esimene heartbeat-s\u00f5num temalt kaob, vaid ainult siis, kui mitu j\u00e4rjestikkust kaduma l\u00e4heb. Nii oleme suutnud saavutada koordinaatori nodi t\u00f5rke avastamise 200 ms jooksul. <\/p>\n<p>Aga pole piisav lihtsalt m\u00f5ista, milline nodi on lakanud t\u00f6\u00f6tamast. Midagi tuleb sellega ette v\u00f5tta. <\/p>\n<h2>Varu<\/h2>\n<p>\nKlassikaline skeem eeldab meistri t\u00f5rke korral uue valimist \u00fche kaudu<noindex><a rel=\"nofollow\" href=\"https:\/\/ru.wikipedia.org\/wiki\/%D0%90%D0%BB%D0%B3%D0%BE%D1%80%D0%B8%D1%82%D0%BC_Raft\"> moodsa<\/a><\/noindex> <noindex><a rel=\"nofollow\" href=\"https:\/\/ru.wikipedia.org\/wiki\/%D0%90%D0%BB%D0%B3%D0%BE%D1%80%D0%B8%D1%82%D0%BC_%D0%9F%D0%B0%D0%BA%D1%81%D0%BE%D1%81\">universaalse<\/a><\/noindex> algoritmid. Kuid sellistel algoritmidel on tuntud probleemid konvergentsi ja valimiste protsessi kestusega. Selliseid t\u00e4iendavaid viivitusi oleme suutnud v\u00e4ltida koordinaatorite asendamise skeemi abil t\u00e4ielikult \u00fchendatud v\u00f5rgus:<\/p>\n<p><img decoding=\"async\" alt=\"UusSQL = NoSQL + ACID\" src=\"\/wp-content\/uploads\/2019\/09\/5e2db258fa2200026390a73a414dfe81.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nOletame, et soovime teostada tehingut grupis 50. Eeltingimusena m\u00e4\u00e4ratleme asendamise skeemi, st millised s\u00f5lmed teostavad grupi 50 tehingud, kui peamine koordinaator eba\u00f5nnestub. Meie eesm\u00e4rk on s\u00e4ilitada s\u00fcsteemi t\u00f6\u00f6kindlus, kui andmekeskus ei t\u00f6\u00f6ta. M\u00e4\u00e4ratleme, et esimene varu on s\u00f5lm teisest andmekeskusest ja teine varu on s\u00f5lm kolmandast. See skeem valitakse \u00fcks kord ja see ei muutu, kuni klasteri topoloogia muutub, st kuni sellesse ei lisandu uusi s\u00f5lmi (mis juhtub v\u00e4ga harva). Uue aktiivse meistri valimise j\u00e4rjekord vanast eba\u00f5nnestumise korral on alati j\u00e4rgmine: aktiivseks meistriks saab esimene varu, ja kui see enam ei t\u00f6\u00f6ta \u2014 siis teine varu. <\/p>\n<p>Selline skeem on usaldusv\u00e4\u00e4rsem kui universaalne algoritm, kuna uue meistri aktiveerimiseks piisab vanast eba\u00f5nnestumise fakti kindlaksm\u00e4\u00e4rimisest.<\/p>\n<p>Kuidas saavad kliendid aru, milline meister praegu t\u00f6\u00f6tab? 50 ms jooksul ei ole v\u00f5imalik jagada teavet tuhandetele klientidele. V\u00f5ib juhtuda, et klient saadab p\u00e4ringu tehingu avamiseks, teadmata, et see meister ei t\u00f6\u00f6ta enam, ning p\u00e4ring j\u00e4\u00e4b ajutiseks. Selle v\u00e4ltimiseks saadavad kliendid spekulatiivselt p\u00e4ringu tehingu avamiseks kohe grupimeistrile ja m\u00f5lemale tema varumeistrile, kuid vastab sellele p\u00e4ringule ainult see, kes on sel hetkel aktiivne meister. K\u00f5ik edasine suhtlemine tehingu raames toimub kliendi ja ainult aktiivse meistri vahel.<\/p>\n<p>Varumeistrid, kes saavad p\u00e4ringud mitte enda tehingute kohta, paigutavad need s\u00fcndimata tehingute j\u00e4rjekorda, kus need hoiavad m\u00f5nda aega. Kui aktiivne meister sureb, t\u00f6\u00f6tleb uus meister j\u00e4rjekorras olevaid tehingu avamise p\u00e4ringuid ja vastab kliendile. Kui klient on juba j\u00f5udnud avada tehingu vana meistri kaudu, siis teist vastust ignoreeritakse (ja ilmselgelt selline tehing ei l\u00f5peta ning kordub kliendi poolt).<\/p>\n<h2>Kuidas tehing t\u00f6\u00f6tab<\/h2>\n<p>\nOletame, et klient saatis koordinaatorile taotluse tehingu avamiseks sellise \u00fcksuse jaoks, millel on selline esmase v\u00f5tme v\u00e4\u00e4rtus. Koordinaator blokeerib selle \u00fcksuse ja paigutab selle m\u00e4lus blokeeringute tabelisse. Kui vajalik, loeb koordinaator selle \u00fcksuse salvestusest ja salvestab saadud andmed koordinaatori m\u00e4lu tehingu olekusse.<\/p>\n<p><img decoding=\"async\" alt=\"UusSQL = NoSQL + ACID\" src=\"\/wp-content\/uploads\/2019\/09\/246b4a5c68a4cc886b87af784c16b9dc.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nKui klient soovib tehingus andmeid muuta, saadab ta koordinaatorile taotluse \u00fcksuse muudatuste tegemiseks, ning koordinaator paigutab uued andmed tehingute oleku tabelisse m\u00e4lus. Sellega on salvestamine l\u00f5petatud \u2014 salvestust ei toimu.<\/p>\n<p><img decoding=\"async\" alt=\"UusSQL = NoSQL + ACID\" src=\"\/wp-content\/uploads\/2019\/09\/4400a91af30eb71134978ff27474f745.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nKui klient k\u00fcsib aktiivse tehingu raames oma muudetud andmeid, toimib koordinaator j\u00e4rgmiselt: <\/p>\n<ul>\n<li>kui ID on juba tehingus, siis andmed v\u00f5etakse m\u00e4lu; <\/li>\n<li>kui ID m\u00e4lu ei ole, siis puuduvad andmed loetakse nodi salvestustest, \u00fchendatakse olemasolevaga m\u00e4lus ja tulemus antakse kliendile. <\/li>\n<\/ul>\n<p>\nSeega v\u00f5ib klient lugeda oma muudatusi, kuid teised kliendid neid muudatusi ei n\u00e4e, kuna need hoitakse ainult koordinaatori m\u00e4lus; nodides Cassandra's neid veel ei ole.<\/p>\n<p><img decoding=\"async\" alt=\"UusSQL = NoSQL + ACID\" src=\"\/wp-content\/uploads\/2019\/09\/c93fd7e8393f431a976f1f56b95e227c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nKliendi saadetud commit'i korral salvestab teenuse m\u00e4llu j\u00e4\u00e4nud oleku koordinaator logged batch'ina, mis saadetakse juba logged batch'ina Cassandra ladudesse. Ladude \u00fclesanne on tagada, et see pakett rakendataks atomaarsetena (t\u00e4ielikult) ning naasta vastus koordinaatorile, kes vabastab lukud ja kinnitab tehingu edukust kliendile.<\/p>\n<p><img decoding=\"async\" alt=\"UusSQL = NoSQL + ACID\" src=\"\/wp-content\/uploads\/2019\/09\/ab20487ba53ed88e2f560a2249b5d6f9.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nTagasit\u00f5mbamiseks piisab koordinaatorist vaid m\u00e4luruumi vabastamisest, mis on tehingu oleku jaoks reserveeritud.<\/p>\n<p>Eelnimetatud t\u00e4iustuste tulemusena oleme rakendanud ACID p\u00f5him\u00f5tteid:<\/p>\n<ul>\n<li><b>Atomaarne<\/b>. See tagab, et \u00fckski tehing ei fikseerita s\u00fcsteemis osaliselt: kas tehakse k\u00f5ik alamoperatsioonid v\u00f5i ei tehta \u00fchtegi. Meie ettev\u00f5ttes j\u00e4rgime seda p\u00f5him\u00f5tet logged batch'i kaudu Cassandra's.<\/li>\n<li><b>Konsistentsus<\/b>. Iga edukas tehing fikseerib m\u00e4\u00e4ratletud tulemused. Kui tehingu avamise ja osade operatsioonide t\u00e4itmise j\u00e4rel selgub, et tulemus on ebaseaduslik, toimub tagasiv\u00f5tmine.<\/li>\n<li><b>Isolatsioon<\/b>. Tehingu t\u00e4itmisel ei tohi samal ajal toimuvad tehingud m\u00f5jutada selle tulemusi. Konkurentsiv\u00f5imelised tehingud on koordinaatori pessimistic lock'dega isoleeritud. Tehinguv\u00e4lised lugemised j\u00e4rgivad isoleerimise p\u00f5him\u00f5tet Read Committed tasemel.<\/li>\n<li><b>Stabiilsus<\/b>. \u00dcksk\u00f5ik millised probleemid madalamatel tasemetel \u2013 s\u00fcsteemi voolukatkestus, riistvara t\u00f5rge \u2013 peaksid edukalt l\u00f5petatud tehingute muudatused j\u00e4\u00e4ma alles p\u00e4rast s\u00fcsteemi taastamist. <\/li>\n<\/ul>\n<p><\/p>\n<h2>Lugemine indeksite kaudu<\/h2>\n<p>\nV\u00f5tame lihtsa tabeli: <\/p>\n<pre><code>CREATE TABLE photos (\nid bigint primary key,\nowner bigint,\nmodified timestamp,\n\u2026)<\/code><\/pre>\n<p>\nSee sisaldab ID-d (peamine v\u00f5ti), omaniku ja muutmise kuup\u00e4eva. Peame tegema v\u00e4ga lihtsa p\u00e4ringu \u2013 valima andmed omaniku j\u00e4rgi, kelle muudatused on tehtud \u00abviimase 24 tunni\u00bb jooksul. <\/p>\n<pre><code>SELECT *\nWHERE owner=?\nAND modified&gt;?<\/code><\/pre>\n<p>\nSelle sarnase p\u00e4ringu kiireks t\u00f6\u00f6tlemiseks tuleb klassikalises SQL andmebaasis luua indeks veergude (owner, modified) alusel. Sellise \u00fclesande t\u00e4itmine on n\u00fc\u00fcd lihtne, kuna meil on ACID garantiid!<\/p>\n<h2>Indeksid C*One<\/h2>\n<p>\nOn algne tabel fotodega, mille kirje ID on peamine v\u00f5ti. <\/p>\n<p><img decoding=\"async\" alt=\"UusSQL = NoSQL + ACID\" src=\"\/wp-content\/uploads\/2019\/09\/9f5d7c5f66882666a7ae8219f710beeb.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nC*One loob uue tabeli indeksi jaoks, mis on algse koopia. V\u00f5ti vastab indeksile, samas sisaldab see ka algse tabeli peav\u00f5tit:<\/p>\n<p><img decoding=\"async\" alt=\"UusSQL = NoSQL + ACID\" src=\"\/wp-content\/uploads\/2019\/09\/ce6df1c8407bca7ddc61fd88141455e6.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nN\u00fc\u00fcd saab p\u00e4ringu \u00abomaniku kohta viimase 24 tunni jooksul\u00bb \u00fcmber kirjutada kui select teise tabeli jaoks:<\/p>\n<pre><code>SELECT * FROM i1_test\nWHERE owner=?\nAND modified&gt;?<\/code><\/pre>\n<p>\nAlgse tabeli photos ja indeksi i1 andmete koosk\u00f5la s\u00e4ilib automaatselt koordineerija kaudu. \u00dcheainsa andmeskeemi alusel, kui muudetakse, genereerib koordineerija muudatuse ja meeles peab mitte ainult p\u00f5hit\u00e4hted, vaid ka koopiate muudatused. T\u00e4iendavaid toiminguid indeksi tabeliga ei tehta, logisid ei loeta ega lukustusi ei kasutata. Seega indekseerimise lisamine tarbib peaaegu mitte mingit ressurssi ja ei m\u00f5juta modifikatsioonide rakendamise kiirus.<\/p>\n<p>ACID tehnoloogia abil suutsime luua indekseid, nagu SQL-is. Need on j\u00e4rjepidevad, skaleeritavad, t\u00f6\u00f6tavad kiiresti, v\u00f5ivad olla komposiitindeksid ning on integreeritud CQL-i p\u00e4ringukeelde. Indeksite toetamiseks ei ole vaja rakenduskoodi muuta. K\u00f5ik on lihtne nagu SQL-is. Ja mis k\u00f5ige t\u00e4htsam, indeksid ei m\u00f5juta tehinguliste algsetabelite muudatuste t\u00e4itmise kiirus.<\/p>\n<h2>Mis v\u00e4lja tuli<\/h2>\n<p>\nArendasime C*One kolm aastat tagasi ja k\u00e4ivitasime selle t\u00f6\u00f6stuslikuks kasutamiseks. <\/p>\n<p>Kuidas oli meie tulemus? Vaadake n\u00e4iteks fotode t\u00f6\u00f6tlemise ja salvestamise alams\u00fcsteemi, mis on \u00fcks sotsiaalv\u00f5rgustike k\u00f5ige olulisemaid andmeliike. R\u00e4\u00e4gime mitte fotode f\u00fc\u00fcsilisest sisust, vaid k\u00f5ikidest v\u00f5imalikest metaandmetest. Praegu on \u201e\u041e\u0434\u043d\u043e\u043a\u043b\u0430\u0441\u0441\u043d\u0438\u043a\u0430\u0445\u201d umbes 20 miljardit sellist kirjet, s\u00fcsteem k\u00e4itleb 80 000 lugemisep\u00e4ringut sekundis, kuni 8 000 ACID-tehingut sekundis, mis on seotud andmete muutmisega. <\/p>\n<p>Kui kasutasime SQL-i, mille replikatsiooni faktor oli 1 (aga RAID 10), siis salvestati piltide metaandmed 32 masina k\u00f5rge k\u00e4ttesaadavuse klastrisse Microsoft SQL Serveriga (pluss 11 varukohta). Varukoopiate hoidmiseks eraldati 10 serverit. Kokku 50 kulukat masinat. Samal ajal t\u00f6\u00f6tas s\u00fcsteem nominatiivsel koormusel, ilma t\u00e4iendava ressurssideta.<\/p>\n<p>P\u00e4rast uut s\u00fcsteemi migratsiooni saime replikatsiooni faktoriks 3 \u2014 iga andmekeskuse kohta \u00fcks koopia. S\u00fcsteem sisaldab 63 Cassandra salvestusnodu ja 6 koordinaatorit, kokku 69 serverit. Kuid need masinad on oluliselt odavamad, nende koguhind on umbes 30% SQL s\u00fcsteemi maksumusest. Koormus p\u00fcsib 30% tasemel.<\/p>\n<p>C*One rakendamisega v\u00e4henesid ka viivitused: SQL-is v\u00f5ttis 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 \u2014 keskmiselt 2 ms. 99. protsentil on see vaid 3-3,1 ms, aja\u00fclekande juhtumeid on v\u00e4henenud 100 korda \u2014 k\u00f5ik t\u00e4nu laiale spekulatsioonide rakendusele. <\/p>\n<p>Praeguseks on suurem osa SQL Serveri node'dest v\u00e4lja l\u00fclitatud, uusi tooteid arendatakse ainult C*One kasutades. Oleme C*One'i kohandanud t\u00f6\u00f6ks meie pilves. <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/company\/odnoklassniki\/blog\/346868\/\">one-cloud<\/a><\/noindex>, mis on v\u00f5imaldanud kiirendada uute klastrite seadistamist, lihtsustada konfiguratsiooni ja automatiseerida haldamist. Ilma l\u00e4htekoodita oleks see olnud m\u00e4rgatavalt keerulisem ja vaevalisem. <\/p>\n<p>Praegu t\u00f6\u00f6tame teiste meie hoidlate pilve viimise kallal \u2013 aga see on juba hoopis teine lugu.<br \/>\n<br \/>Allikas: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/odnoklassniki\/blog\/417593\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0414\u043e \u043d\u0435\u0434\u0430\u0432\u043d\u0435\u0433\u043e \u0432\u0440\u0435\u043c\u0435\u043d\u0438 \u0432 \u041e\u0434\u043d\u043e\u043a\u043b\u0430\u0441\u0441\u043d\u0438\u043a\u0430\u0445 \u043e\u043a\u043e\u043b\u043e 50 \u0422\u0411 \u0434\u0430\u043d\u043d\u044b\u0445, \u043e\u0431\u0440\u0430\u0431\u0430\u0442\u044b\u0432\u0430\u0435\u043c\u044b\u0445 \u0432 \u0440\u0435\u0430\u043b\u044c\u043d\u043e\u043c \u0432\u0440\u0435\u043c\u0435\u043d\u0438, \u0445\u0440\u0430\u043d\u0438\u043b\u043e\u0441\u044c \u0432 SQL Server. \u0414\u043b\u044f \u0442\u0430\u043a\u043e\u0433\u043e \u043e\u0431\u044a\u0435\u043c\u0430 \u043e\u0431\u0435\u0441\u043f\u0435\u0447\u0438\u0442\u044c \u0431\u044b\u0441\u0442\u0440\u044b\u0439 \u0438 \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439, \u0434\u0430 \u0435\u0449\u0435 \u0438 \u0443\u0441\u0442\u043e\u0439\u0447\u0438\u0432\u044b\u0439 \u043a \u043e\u0442\u043a\u0430\u0437\u0443 \u0426\u041e\u0414 \u0434\u043e\u0441\u0442\u0443\u043f, \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u044f SQL \u0421\u0423\u0411\u0414, \u043f\u0440\u0430\u043a\u0442\u0438\u0447\u0435\u0441\u043a\u0438 \u043d\u0435\u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e. \u041e\u0431\u044b\u0447\u043d\u043e \u0432 \u0442\u0430\u043a\u0438\u0445 \u0441\u043b\u0443\u0447\u0430\u044f\u0445 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u044e\u0442 \u043e\u0434\u043d\u043e \u0438\u0437 NoSQL-\u0445\u0440\u0430\u043d\u0438\u043b\u0438\u0449, \u043d\u043e \u043d\u0435 \u0432\u0441\u0451 \u043c\u043e\u0436\u043d\u043e \u043f\u0435\u0440\u0435\u043d\u0435\u0441\u0442\u0438 \u0432 NoSQL: \u043d\u0435\u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0441\u0443\u0449\u043d\u043e\u0441\u0442\u0438 \u0442\u0440\u0435\u0431\u0443\u044e\u0442 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":28484,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-37956","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 4.9.10 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u0414\u043e \u043d\u0435\u0434\u0430\u0432\u043d\u0435\u0433\u043e \u0432\u0440\u0435\u043c\u0435\u043d\u0438 \u0432 \u041e\u0434\u043d\u043e\u043a\u043b\u0430\u0441\u0441\u043d\u0438\u043a\u0430\u0445 \u043e\u043a\u043e\u043b\u043e 50 \u0422\u0411 \u0434\u0430\u043d\u043d\u044b\u0445, \u043e\u0431\u0440\u0430\u0431\u0430\u0442\u044b\u0432\u0430\u0435\u043c\u044b\u0445 \u0432 \u0440\u0435\u0430\u043b\u044c\u043d\u043e\u043c \u0432\u0440\u0435\u043c\u0435\u043d\u0438, \u0445\u0440\u0430\u043d\u0438\u043b\u043e\u0441\u044c \u0432 SQL Server. \u0414\u043b\u044f \u0442\u0430\u043a\u043e\u0433\u043e \u043e\u0431\u044a\u0435\u043c\u0430 \u043e\u0431\u0435\u0441\u043f\u0435\u0447\u0438\u0442\u044c \u0431\u044b\u0441\u0442\u0440\u044b\u0439 \u0438 \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439, \u0434\u0430 \u0435\u0449\u0435 \u0438 \u0443\u0441\u0442\u043e\u0439\u0447\u0438\u0432\u044b\u0439 \u043a \u043e\u0442\u043a\u0430\u0437\u0443 \u0426\u041e\u0414 \u0434\u043e\u0441\u0442\u0443\u043f, \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u044f SQL \u0421\u0423\u0411\u0414, \u043f\u0440\u0430\u043a\u0442\u0438\u0447\u0435\u0441\u043a\u0438 \u043d\u0435\u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e. \u041e\u0431\u044b\u0447\u043d\u043e \u0432 \u0442\u0430\u043a\u0438\u0445 \u0441\u043b\u0443\u0447\u0430\u044f\u0445 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u044e\u0442 \u043e\u0434\u043d\u043e \u0438\u0437 NoSQL-\u0445\u0440\u0430\u043d\u0438\u043b\u0438\u0449, \u043d\u043e \u043d\u0435 \u0432\u0441\u0451 \u043c\u043e\u0436\u043d\u043e \u043f\u0435\u0440\u0435\u043d\u0435\u0441\u0442\u0438 \u0432 NoSQL: \u043d\u0435\u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0441\u0443\u0449\u043d\u043e\u0441\u0442\u0438 \u0442\u0440\u0435\u0431\u0443\u044e\u0442\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/newsql-nosql-acid\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 4.9.10\" \/>\n\t\t<meta property=\"og:locale\" content=\"et_EE\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47NewSQL = NoSQL+ACID | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u0414\u043e \u043d\u0435\u0434\u0430\u0432\u043d\u0435\u0433\u043e \u0432\u0440\u0435\u043c\u0435\u043d\u0438 \u0432 \u041e\u0434\u043d\u043e\u043a\u043b\u0430\u0441\u0441\u043d\u0438\u043a\u0430\u0445 \u043e\u043a\u043e\u043b\u043e 50 \u0422\u0411 \u0434\u0430\u043d\u043d\u044b\u0445, \u043e\u0431\u0440\u0430\u0431\u0430\u0442\u044b\u0432\u0430\u0435\u043c\u044b\u0445 \u0432 \u0440\u0435\u0430\u043b\u044c\u043d\u043e\u043c \u0432\u0440\u0435\u043c\u0435\u043d\u0438, \u0445\u0440\u0430\u043d\u0438\u043b\u043e\u0441\u044c \u0432 SQL Server. \u0414\u043b\u044f \u0442\u0430\u043a\u043e\u0433\u043e \u043e\u0431\u044a\u0435\u043c\u0430 \u043e\u0431\u0435\u0441\u043f\u0435\u0447\u0438\u0442\u044c \u0431\u044b\u0441\u0442\u0440\u044b\u0439 \u0438 \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439, \u0434\u0430 \u0435\u0449\u0435 \u0438 \u0443\u0441\u0442\u043e\u0439\u0447\u0438\u0432\u044b\u0439 \u043a \u043e\u0442\u043a\u0430\u0437\u0443 \u0426\u041e\u0414 \u0434\u043e\u0441\u0442\u0443\u043f, \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u044f SQL \u0421\u0423\u0411\u0414, \u043f\u0440\u0430\u043a\u0442\u0438\u0447\u0435\u0441\u043a\u0438 \u043d\u0435\u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e. \u041e\u0431\u044b\u0447\u043d\u043e \u0432 \u0442\u0430\u043a\u0438\u0445 \u0441\u043b\u0443\u0447\u0430\u044f\u0445 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u044e\u0442 \u043e\u0434\u043d\u043e \u0438\u0437 NoSQL-\u0445\u0440\u0430\u043d\u0438\u043b\u0438\u0449, \u043d\u043e \u043d\u0435 \u0432\u0441\u0451 \u043c\u043e\u0436\u043d\u043e \u043f\u0435\u0440\u0435\u043d\u0435\u0441\u0442\u0438 \u0432 NoSQL: \u043d\u0435\u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0441\u0443\u0449\u043d\u043e\u0441\u0442\u0438 \u0442\u0440\u0435\u0431\u0443\u044e\u0442\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/newsql-nosql-acid\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T19:20:47+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T19:20:47+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47NewSQL = NoSQL+ACID | ProHoster","description":"Kuni hiljutise ajani oli Odnoklassniketes umbes 50 TB andmeid, mida t\u00f6\u00f6deldi reaalajas, ja need olid salvestatud SQL Serverisse. Sellise mahu jaoks on kiire ja usaldusv\u00e4\u00e4rse, veelgi enam, t\u00f5rgete taluvusega andmekeskuse juurdep\u00e4\u00e4su tagamine SQL andmebaasis peaaegu v\u00f5imatu. T\u00fc\u00fcpiliselt kasutatakse sellistes olukordades \u00fchte NoSQL andmehoidlast, kuid mitte k\u00f5ike ei saa NoSQL-i viia: m\u00f5ned entiteedid n\u00f5uavad.","canonical_url":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/newsql-nosql-acid","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"et_EE","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47NewSQL = NoSQL+ACID | ProHoster","og:description":"\u0414\u043e \u043d\u0435\u0434\u0430\u0432\u043d\u0435\u0433\u043e \u0432\u0440\u0435\u043c\u0435\u043d\u0438 \u0432 \u041e\u0434\u043d\u043e\u043a\u043b\u0430\u0441\u0441\u043d\u0438\u043a\u0430\u0445 \u043e\u043a\u043e\u043b\u043e 50 \u0422\u0411 \u0434\u0430\u043d\u043d\u044b\u0445, \u043e\u0431\u0440\u0430\u0431\u0430\u0442\u044b\u0432\u0430\u0435\u043c\u044b\u0445 \u0432 \u0440\u0435\u0430\u043b\u044c\u043d\u043e\u043c \u0432\u0440\u0435\u043c\u0435\u043d\u0438, \u0445\u0440\u0430\u043d\u0438\u043b\u043e\u0441\u044c \u0432 SQL Server. \u0414\u043b\u044f \u0442\u0430\u043a\u043e\u0433\u043e \u043e\u0431\u044a\u0435\u043c\u0430 \u043e\u0431\u0435\u0441\u043f\u0435\u0447\u0438\u0442\u044c \u0431\u044b\u0441\u0442\u0440\u044b\u0439 \u0438 \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439, \u0434\u0430 \u0435\u0449\u0435 \u0438 \u0443\u0441\u0442\u043e\u0439\u0447\u0438\u0432\u044b\u0439 \u043a \u043e\u0442\u043a\u0430\u0437\u0443 \u0426\u041e\u0414 \u0434\u043e\u0441\u0442\u0443\u043f, \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u044f SQL \u0421\u0423\u0411\u0414, \u043f\u0440\u0430\u043a\u0442\u0438\u0447\u0435\u0441\u043a\u0438 \u043d\u0435\u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e. \u041e\u0431\u044b\u0447\u043d\u043e \u0432 \u0442\u0430\u043a\u0438\u0445 \u0441\u043b\u0443\u0447\u0430\u044f\u0445 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u044e\u0442 \u043e\u0434\u043d\u043e \u0438\u0437 NoSQL-\u0445\u0440\u0430\u043d\u0438\u043b\u0438\u0449, \u043d\u043e \u043d\u0435 \u0432\u0441\u0451 \u043c\u043e\u0436\u043d\u043e \u043f\u0435\u0440\u0435\u043d\u0435\u0441\u0442\u0438 \u0432 NoSQL: \u043d\u0435\u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0441\u0443\u0449\u043d\u043e\u0441\u0442\u0438 \u0442\u0440\u0435\u0431\u0443\u044e\u0442","og:url":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/newsql-nosql-acid","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:20:47+00:00","article:modified_time":"2019-10-31T19:20:47+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"37956","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-23 19:55:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 01:17:23","updated":"2026-01-23 19:55:19"},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts\/37956","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/comments?post=37956"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts\/37956\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/media\/28484"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/media?parent=37956"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/categories?post=37956"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/tags?post=37956"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}