{"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\/sq\/blog\/administrirovanie\/newsql-nosql-acid","title":{"rendered":"NewSQL = NoSQL+ACID","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"NewSQL = NoSQL+ACID\" src=\"\/wp-content\/uploads\/2019\/09\/973145efa566bca10ffe7ba95733a1d5.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nDerisa, n\u00eb Odnoklassniki, m\u00eb par\u00eb kishte rreth 50 TB t\u00eb dh\u00ebnash q\u00eb procesoheshin n\u00eb koh\u00eb reale, t\u00eb ruajtura n\u00eb SQL Server. P\u00ebr nj\u00eb v\u00ebllim t\u00eb till\u00eb, t\u00eb sigurosh nj\u00eb qend\u00ebr t\u00eb dh\u00ebnash t\u00eb shpejt\u00eb, t\u00eb besueshme dhe gjithashtu t\u00eb q\u00ebndrueshme ndaj defekteve, duke p\u00ebrdorur SQL DBMS, \u00ebsht\u00eb praktikisht e pamundur. N\u00eb raste t\u00eb tilla, zakonisht p\u00ebrdoren nj\u00eb nga depot NoSQL, por jo gjith\u00e7ka mund t\u00eb transferohet n\u00eb NoSQL: disa entitete k\u00ebrkojn\u00eb garanci t\u00eb transaksioneve ACID. <\/p>\n<p>Kjo na \u00e7oi n\u00eb p\u00ebrdorimin e nj\u00eb depoje NewSQL, q\u00eb do t\u00eb thot\u00eb nj\u00eb DBMS q\u00eb ofron q\u00ebndrueshm\u00ebri, shkall\u00ebzim dhe performanc\u00eb t\u00eb sistemeve NoSQL, por q\u00eb ruan garancit\u00eb ACID t\u00eb sistemeve klasike. Ka pak sisteme industriale t\u00eb k\u00ebtij klasi t\u00eb ri q\u00eb funksionojn\u00eb, prandaj ne e realizuam nj\u00eb sistem t\u00eb till\u00eb vet\u00eb dhe e lan\u00e7uam n\u00eb operacionin industrial. <\/p>\n<p>Si funksionon dhe \u00e7far\u00eb arrit\u00ebm - lexoni m\u00eb posht\u00eb.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\nSot, audienca mujore e \"Odnoklassniki\" \u00ebsht\u00eb mbi 70 milion vizitor\u00eb unik\u00eb. Ne <noindex><a rel=\"nofollow\" href=\"https:\/\/www.similarweb.com\/top-websites\/category\/internet-and-telecom\/social-network\">jemi n\u00eb mesin e pes\u00eb<\/a><\/noindex> rrjeteve m\u00eb t\u00eb m\u00ebdha sociale n\u00eb bot\u00eb, dhe n\u00eb list\u00ebn e dyzet\u00eb t\u00eb faqeve ku p\u00ebrdoruesit kalojn\u00eb m\u00eb shum\u00eb koh\u00eb. Infrastrukturat e \"OK\" p\u00ebrpunojn\u00eb ngarkesa shum\u00eb t\u00eb larta: m\u00eb shum\u00eb se nj\u00eb milion k\u00ebrkesa HTTP\/s n\u00eb frontet. Nj\u00eb pjes\u00eb e parkut t\u00eb server\u00ebve me m\u00eb shum\u00eb se 8000 nj\u00ebsit\u00eb jan\u00eb t\u00eb vendosura af\u00ebr nj\u00ebri-tjetrit - n\u00eb kat\u00ebr qendrat e t\u00eb dh\u00ebnave n\u00eb Mosk\u00eb, gj\u00eb q\u00eb lejon sigurimin e nj\u00eb vonese rrjeti m\u00eb pak se 1 ms midis tyre.<\/p>\n<p>Ne kemi p\u00ebrdorur Cassandra q\u00eb nga viti 2010, duke filluar nga versioni 0.6. Sot, n\u00eb funksion jan\u00eb disa dhjet\u00ebra klastera. Klasteri m\u00eb i shpejt\u00eb p\u00ebrpunon m\u00eb shum\u00eb se 4 milion operacione n\u00eb sekond\u00eb, nd\u00ebrsa m\u00eb i madhi ruan 260 TB. <\/p>\n<p>Megjithat\u00eb, t\u00eb gjitha k\u00ebto jan\u00eb klastere t\u00eb zakonshme NoSQL, t\u00eb cilat p\u00ebrdoren p\u00ebr ruajtjen <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\">e t\u00eb dh\u00ebnave me konsistenc\u00eb t\u00eb ul\u00ebt.<\/a><\/noindex> Na duhej t\u00eb z\u00ebvend\u00ebsonim depozitat kryesore t\u00eb konsistenc\u00ebs, Microsoft SQL Server, t\u00eb cilat ishin p\u00ebrdorur q\u00eb nga fillimi i \"Odnoklassniki\". Deponi p\u00ebrb\u00ebhej nga m\u00eb shum\u00eb se 300 makina SQL Server Standard Edition, t\u00eb cilat mbanin 50 TB t\u00eb dh\u00ebnash - entitete biznesi. K\u00ebto t\u00eb dh\u00ebna modifikohen n\u00eb kuad\u00ebr t\u00eb transaksioneve ACID dhe k\u00ebrkojn\u00eb <noindex><a rel=\"nofollow\" href=\"https:\/\/ru.wikipedia.org\/wiki\/ACID\">konsistenc\u00eb t\u00eb lart\u00eb.<\/a><\/noindex>.<\/p>\n<p>P\u00ebr shp\u00ebrndarjen e t\u00eb dh\u00ebnave midis node-ve SQL Server p\u00ebrdor\u00ebm si <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Partition_(database)\">particionim vertikal<\/a><\/noindex> (shardim). Historikisht, ne kemi p\u00ebrdorur nj\u00eb skem\u00eb t\u00eb thjesht\u00eb t\u00eb shardimit t\u00eb t\u00eb dh\u00ebnave: \u00e7do entitet i ishte caktuar nj\u00eb token - nj\u00eb funksion nga ID e entitetit. Entitetet me t\u00eb nj\u00ebjtin token ishin vendosur n\u00eb nj\u00eb SQL server. Marr\u00ebdh\u00ebnia e tipit master-detail realizohej n\u00eb m\u00ebnyr\u00eb q\u00eb tokenet e regjistrimit kryesor dhe atij t\u00eb krijuar t\u00eb ishin gjithmon\u00eb identike dhe t\u00eb ishin n\u00eb nj\u00eb server. N\u00eb rrjetin social, pothuajse t\u00eb gjitha t\u00eb dh\u00ebnat jan\u00eb krijuar n\u00eb em\u00ebr t\u00eb p\u00ebrdoruesit - dometh\u00ebn\u00eb, t\u00eb gjitha t\u00eb dh\u00ebnat e p\u00ebrdoruesit brenda nj\u00eb n\u00ebnpro\u00e7esi funksional ruhet n\u00eb nj\u00eb server. Pra, pothuajse gjithmon\u00eb n\u00eb transaksionet biznesi merrnin pjes\u00eb tabela t\u00eb nj\u00eb SQL serveri, q\u00eb mund\u00ebsoi ruajtjen e konsistenc\u00ebs s\u00eb t\u00eb dh\u00ebnave p\u00ebrmes transaksioneve lokale ACID, pa nevoj\u00ebn e p\u00ebrdorimit <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Two-phase_commit_protocol\">t\u00eb transaksioneve ACID t\u00eb ngadalta dhe t\u00eb pasigurt.<\/a><\/noindex> Fal\u00eb shardimit dhe p\u00ebr t\u00eb p\u00ebrshpejtuar pun\u00ebn e SQL:<\/p>\n<p>Nuk p\u00ebrdorim kufizime t\u00eb \u00e7el\u00ebsit t\u00eb huaj, pasi me shardimin ID e entitetit mund t\u00eb ndodhet n\u00eb nj\u00eb server tjet\u00ebr.<\/p>\n<ul>\n<li>Nuk p\u00ebrdorim procedurat e ruajtura dhe trigger-at p\u00ebr shkak t\u00eb ngarkes\u00ebs s\u00eb shtuar n\u00eb CPU t\u00eb DBMS.<\/li>\n<li>Nuk p\u00ebrdorim JOINs p\u00ebr shkak t\u00eb t\u00eb gjitha gj\u00ebrave t\u00eb m\u00ebsip\u00ebrme dhe numrit t\u00eb madh t\u00eb leximeve t\u00eb rast\u00ebsishme nga disku.<\/li>\n<li>Jasht\u00eb transaksionit, p\u00ebr t\u00eb reduktuar bllokimet, p\u00ebrdorim nivelin e izolimit t\u00eb Leximit t\u00eb Paangazhuar.<\/li>\n<li>Kryejm\u00eb vet\u00ebm transaksione t\u00eb shkurtra (n\u00eb mesatare m\u00eb t\u00eb shkurtra se 100 ms).<\/li>\n<li>Nuk p\u00ebrdorim UPDATE dhe DELETE t\u00eb shum\u00eb regjistrave p\u00ebr shkak t\u00eb numrit t\u00eb madh t\u00eb bllokimeve - p\u00ebrdit\u00ebsojm\u00eb vet\u00ebm nj\u00eb regjist\u00ebr n\u00eb nj\u00eb koh\u00eb.<\/li>\n<li>K\u00ebrkesat gjithmon\u00eb i kryejm\u00eb vet\u00ebm p\u00ebrmes indekseve - nj\u00eb k\u00ebrkes\u00eb me planin e shikimit t\u00eb plot\u00eb t\u00eb tabel\u00ebs p\u00ebr ne do t\u00eb thot\u00eb mbingarkes\u00eb t\u00eb DB dhe refuzimin e saj.<\/li>\n<li>K\u00ebto hapa na lejuan t\u00eb nxjerrim nga SQL-serverat thuajse maksimumin e performanc\u00ebs. Megjithat\u00eb, problemet ishin gjithnj\u00eb e m\u00eb t\u00eb shumta. Le t\u00eb shikojm\u00eb ato.<\/li>\n<\/ul>\n<p>\nProblemet me SQL<\/p>\n<h2>Duke qen\u00eb se ne p\u00ebrdorim shardimin e shkruar vet\u00eb, shtimi i shardeve t\u00eb rinj b\u00ebhej manualisht nga administrator\u00ebt. Gjat\u00eb gjith\u00eb k\u00ebsaj kohe, replikat e dh\u00ebnave t\u00eb shkall\u00ebzuara nuk sh\u00ebrbenin p\u00ebr k\u00ebrkesat.<\/h2>\n<p><\/p>\n<ul>\n<li>Me rritjen e numrit t\u00eb regjistrave n\u00eb tabel\u00eb, shpejt\u00ebsia e futjes dhe modifikimit u ul, kur u shtuan indekse n\u00eb tabel\u00ebn ekzistuese, shpejt\u00ebsia ra shum\u00eb her\u00eb, krijimi dhe rikrijimi i indekseve ndodhte me downtime. <\/li>\n<li>Prania e nj\u00eb sasi t\u00eb vog\u00ebl Windows p\u00ebr SQL Server n\u00eb production v\u00ebshtir\u00ebson menaxhimin e infrastruktur\u00ebs.<\/li>\n<li>Por problemi kryesor -<\/li>\n<\/ul>\n<p>\n\u041d\u043e \u0433\u043b\u0430\u0432\u043d\u0430\u044f \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u0430 \u2014 <\/p>\n<h2>Q\u00ebndrueshm\u00ebria<\/h2>\n<p>\nServerat klasik SQL kan\u00eb q\u00ebndrushm\u00ebri t\u00eb dob\u00ebt. Supozojm\u00eb se keni vet\u00ebm nj\u00eb server baze t\u00eb dh\u00ebnash, dhe ai d\u00ebshton \u00e7do tri vjet. N\u00eb k\u00ebt\u00eb koh\u00eb, faqja e internetit nuk funksionon p\u00ebr 20 minuta, q\u00eb \u00ebsht\u00eb e pranueshme. Po sikur t\u00eb keni 64 servera, faqja nuk funksionon \u00e7do tri jav\u00eb. Nd\u00ebrsa n\u00ebse keni 200 servera, faqja nuk funksionon \u00e7do jav\u00eb. Kjo \u00ebsht\u00eb nj\u00eb problem. <\/p>\n<p>\u00c7far\u00eb mund t\u00eb b\u00ebhet p\u00ebr t\u00eb rritur q\u00ebndrushm\u00ebrin\u00eb e serverit SQL? Wikipedia na propozon t\u00eb nd\u00ebrtojm\u00eb <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/High-availability_cluster\">klastra me disponueshm\u00ebri t\u00eb lart\u00eb<\/a><\/noindex>: ku n\u00eb rastin e d\u00ebshtimit t\u00eb ndonj\u00eb komponenti ka nj\u00eb kopje rezerva.<\/p>\n<p>Kjo k\u00ebrkon nj\u00eb park t\u00eb shtrenjt\u00eb pajisjesh: shum\u00eb kopje, fibra optike, ruajtje t\u00eb p\u00ebrbashk\u00ebt, dhe madje aktivizimi i rezerv\u00ebs nuk funksionon me besueshm\u00ebri: rreth 10% e aktivizimeve p\u00ebrfundojn\u00eb me d\u00ebshtimin e nj\u00ebsis\u00eb rezerv\u00eb pas nj\u00ebsis\u00eb kryesore. <\/p>\n<p>Por e meta kryesore e nj\u00eb klasteri me disponueshm\u00ebri t\u00eb lart\u00eb \u00ebsht\u00eb se nuk ka disponueshm\u00ebri n\u00eb rast d\u00ebshtimi t\u00eb qendr\u00ebs s\u00eb t\u00eb dh\u00ebnave ku ndodhet. 'Odnoklassniki' ka kat\u00ebr qendra t\u00eb t\u00eb dh\u00ebnave, dhe na nevojitet t\u00eb sigurojm\u00eb funksionimin gjat\u00eb nj\u00eb katastrofe t\u00eb plot\u00eb n\u00eb nj\u00ebr\u00ebn prej tyre.<\/p>\n<p>P\u00ebr k\u00ebt\u00eb ne do t\u00eb mund t\u00eb aplikonim <noindex><a rel=\"nofollow\" href=\"https:\/\/technet.microsoft.com\/en-us\/library\/ms151196.aspx\">replikimin Multi-Master<\/a><\/noindex> t\u00eb integruar n\u00eb SQL Server. Ky zgjidhje \u00ebsht\u00eb shum\u00eb m\u00eb e shtrenjt\u00eb p\u00ebr shkak t\u00eb kostos s\u00eb softuerit dhe vuajti nga problemet e njohura me replikimin \u2014 vonesa t\u00eb paparashikueshme t\u00eb transaksioneve gjat\u00eb replikimit t\u00eb sinkronizuar dhe vonesa n\u00eb aplikimin e replikimeve (dhe, si pasoj\u00eb, modifikime t\u00eb humbura) gjat\u00eb replikimit asinkron. I implicit <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\">zgjidhjen manuale t\u00eb konflikteve<\/a><\/noindex> e b\u00ebn k\u00ebt\u00eb variant plot\u00ebsisht t\u00eb paaplikuesh\u00ebm p\u00ebr ne.<\/p>\n<p>T\u00eb gjitha k\u00ebto probleme k\u00ebrkonin nj\u00eb zgjidhje radikale dhe ne filluam analiz\u00ebn e tyre t\u00eb detajuar. K\u00ebtu na nevojitet t\u00eb njohim se \u00e7far\u00eb b\u00ebn kryesisht SQL Server \u2014 transaksionet.<\/p>\n<h2>Transaksioni i thjesht\u00eb<\/h2>\n<p>\nLe t\u00eb shqyrtojm\u00eb nj\u00eb transaksion shum\u00eb t\u00eb thjesht\u00eb, nga k\u00ebndv\u00ebshtrimi i zhvilluesit t\u00eb SQL: shtimi i nj\u00eb fotografie n\u00eb album. Albumet dhe fotografit\u00eb ruhen n\u00eb tavolina t\u00eb ndryshme. Albumi ka nj\u00eb num\u00ebrues t\u00eb fotografive publik. At\u00ebher\u00eb ky transaksion ndahet n\u00eb hapat e m\u00ebposht\u00ebm: <\/p>\n<ol>\n<li>Bllokojm\u00eb albumin me \u00e7el\u00ebs.<\/li>\n<li>Krijojm\u00eb nj\u00eb regjistrim n\u00eb tabel\u00ebn e fotografive. <\/li>\n<li>N\u00ebse fotografia ka status publik, p\u00ebrmir\u00ebsojm\u00eb num\u00ebruesin e fotografive publike n\u00eb album, p\u00ebrdit\u00ebsojm\u00eb regjistrimin dhe komitojm\u00eb transaksionin.<\/li>\n<\/ol>\n<p>\nOse n\u00eb form\u00ebn e pseudokodit:<\/p>\n<pre><code>TX.start(\"Albums\", 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>\nShohim se skenari m\u00eb i zakonsh\u00ebm i transaksionit t\u00eb biznesit \u00ebsht\u00eb t\u00eb lexojm\u00eb t\u00eb dh\u00ebnat nga DB n\u00eb memorien e serverit t\u00eb aplikacionit, t\u00eb ndryshojm\u00eb di\u00e7ka dhe t\u00eb ruajm\u00eb vlerat e reja p\u00ebrs\u00ebri n\u00eb DB. Zakonisht n\u00eb nj\u00eb transaksion t\u00eb till\u00eb ne p\u00ebrdit\u00ebsojm\u00eb disa entitete, disa tabela. <\/p>\n<p>Gjat\u00eb kryerjes s\u00eb transaksionit, mund t\u00eb ndodhin modifikime konkuruese t\u00eb t\u00eb nj\u00ebjtave t\u00eb dh\u00ebna nga nj\u00eb sistem tjet\u00ebr. P\u00ebr shembull, Antispami mund t\u00eb vendos\u00eb se nj\u00eb p\u00ebrdorues \u00ebsht\u00eb i dyshimt\u00eb dhe prandaj t\u00eb gjitha fotografit\u00eb e p\u00ebrdoruesit nuk duhet t\u00eb jen\u00eb m\u00eb publike, ato duhet t\u00eb d\u00ebrgohen p\u00ebr moderim, q\u00eb do t\u00eb thot\u00eb se duhet t\u00eb ndryshohet photo.status n\u00eb nj\u00eb vler\u00eb tjet\u00ebr dhe t\u00eb rregullohen num\u00ebruesit p\u00ebrkat\u00ebs. \u00cbsht\u00eb e qart\u00eb se n\u00ebse kjo operacion do t\u00eb ndodhte pa garancit\u00eb e atomaritetit t\u00eb zbatimit dhe izolimit t\u00eb modifikimeve konkurente, si n\u00eb <noindex><a rel=\"nofollow\" href=\"https:\/\/ru.wikipedia.org\/wiki\/ACID\">ACID<\/a><\/noindex>, rezultati do t\u00eb jet\u00eb jo ai q\u00eb duhet \u2014 ose num\u00ebruesi i fotografive do t\u00eb tregoj\u00eb nj\u00eb vler\u00eb t\u00eb pasakt\u00eb, ose jo t\u00eb gjitha fotografit\u00eb do t\u00eb d\u00ebrgohen p\u00ebr moderim. <\/p>\n<p>Nj\u00eb kod i till\u00eb, q\u00eb manipullon me entitete t\u00eb ndryshme biznesi brenda nj\u00eb transaksioni, \u00ebsht\u00eb shkruar shum\u00eb gjat\u00eb gjith\u00eb ekzistenc\u00ebs s\u00eb Odnoklassniki. Nga p\u00ebrvoja e migrimeve n\u00eb NoSQL me <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Eventual_consistency\">Konsistenc\u00ebn e vonuar<\/a><\/noindex> ne dim\u00eb se v\u00ebshtir\u00ebsit\u00eb m\u00eb t\u00eb m\u00ebdha (dhe shpenzimet kohore) shkaktohen nga nevoja p\u00ebr t\u00eb zhvilluar kod q\u00eb siguron konsistenc\u00ebn e t\u00eb dh\u00ebnave. Prandaj k\u00ebrkesa kryesore p\u00ebr ruajtjen e re ishte sigurimi p\u00ebr logjik\u00ebn aplikative t\u00eb transaksioneve t\u00eb v\u00ebrteta ACID. <\/p>\n<p>Nj\u00eb tjet\u00ebr, po aq e r\u00ebnd\u00ebsishme, k\u00ebrkes\u00eb ishte:<\/p>\n<ul>\n<li>N\u00eb rast d\u00ebshtimi t\u00eb qendr\u00ebs s\u00eb t\u00eb dh\u00ebnave duhet t\u00eb jen\u00eb t\u00eb disponueshme si leximi, ashtu edhe shkruarja n\u00eb ruajtjen e re.<\/li>\n<li>Ruajtja e shpejt\u00ebsis\u00eb aktuale t\u00eb zhvillimit. Kjo do t\u00eb thot\u00eb se gjat\u00eb pun\u00ebs me ruajtjen e re, sasia e kodit duhet t\u00eb jet\u00eb af\u00ebrsisht e nj\u00ebjt\u00eb, nuk duhet t\u00eb ket\u00eb nevoj\u00eb p\u00ebr t\u00eb shtuar ndonj\u00eb gj\u00eb n\u00eb ruajtje, p\u00ebr t\u00eb zhvilluar algorithma p\u00ebr zgjidhjen e konflikteve, p\u00ebr mb\u00ebshtetje t\u00eb indekseve t\u00eb dyta etj. <\/li>\n<li>Shpejt\u00ebsia e pun\u00ebs s\u00eb ruajtjes s\u00eb re duhet t\u00eb jet\u00eb mjaft e lart\u00eb, si gjat\u00eb leximit t\u00eb t\u00eb dh\u00ebnave, ashtu edhe gjat\u00eb trajtimit t\u00eb transaksioneve, q\u00eb do t\u00eb thot\u00eb q\u00eb zgjidhjet akademikisht t\u00eb sakta, universale, por t\u00eb ngadalta, si p\u00ebr shembull, <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Two-phase_commit_protocol\">komitetet me dy faza<\/a><\/noindex>.<\/li>\n<li>Automatizimi i shkall\u00ebzimit n\u00eb fluks. <\/li>\n<li>P\u00ebrdorimi i server\u00ebve t\u00eb zakonsh\u00ebm t\u00eb lir\u00eb, pa nevoj\u00ebn p\u00ebr t\u00eb bler\u00eb pajisje ekzotike. <\/li>\n<li>Mund\u00ebsia p\u00ebr t\u00eb zhvilluar depozitimin me forcat e zhvilluesve t\u00eb kompanis\u00eb. Me fjal\u00eb t\u00eb tjera, prioriteti i ishte dh\u00ebn\u00eb zgjidhjeve t\u00eb brendshme ose atyre me kod t\u00eb hapur, p\u00ebr m\u00eb tep\u00ebr n\u00eb Java.<\/li>\n<\/ul>\n<p><\/p>\n<h2>Zgjidhjet, zgjidhjet<\/h2>\n<p>\nDuke analizuar zgjidhjet e mundshme, arrit\u00ebm n\u00eb dy mund\u00ebsi arkitekture:<\/p>\n<p>E para \u2014 t\u00eb marrim ndonj\u00eb SQL-server dhe t\u00eb implementojm\u00eb q\u00ebndrueshm\u00ebrin\u00eb e nevojshme, mekanizmin e shkall\u00ebzimit, klasterin e q\u00ebndruesh\u00ebm, zgjidhjen e konflikteve dhe transaksionet ACID t\u00eb shp\u00ebrndara, t\u00eb besueshme dhe t\u00eb shpejta. Ne e vler\u00ebsuam k\u00ebt\u00eb opsion si mjaft t\u00eb nd\u00ebrlikuar dhe pun\u00eb t\u00eb madhe.<\/p>\n<p>Opsioni i dyt\u00eb \u2014 t\u00eb marrim nj\u00eb depo NoSQL t\u00eb gatshme me shkall\u00ebzim t\u00eb implementuar, klaster t\u00eb q\u00ebndruesh\u00ebm, zgjidhje konflikti dhe t\u00eb realizojm\u00eb transaksionet dhe SQL vet\u00eb. N\u00eb pamje t\u00eb par\u00eb, madje edhe detyra e realizimit t\u00eb SQL, pa p\u00ebrmendur transaksionet ACID, duket si nj\u00eb detyr\u00eb p\u00ebr vite. Por m\u00eb pas kuptuam se grupi i mund\u00ebsive SQL q\u00eb ne p\u00ebrdorim n\u00eb praktik\u00eb \u00ebsht\u00eb shum\u00eb larg ANSI SQL ashtu si <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Apache_Cassandra#Cassandra_Query_Language\">Cassandra CQL<\/a><\/noindex> \u00ebsht\u00eb e larg\u00ebt nga ANSI SQL. Duke u shqyrtuar m\u00eb me v\u00ebmendje CQL, kuptuam se \u00ebsht\u00eb mjaft af\u00ebr asaj q\u00eb na nevojitet.<\/p>\n<h2>Cassandra dhe CQL<\/h2>\n<p>\nPra, \u00e7far\u00eb \u00ebsht\u00eb interesante p\u00ebr Cassandra, \u00e7far\u00eb mund\u00ebsish ka?<\/p>\n<p>S\u00eb pari, mund t\u00eb krijosh tabela me mb\u00ebshtetje p\u00ebr lloje t\u00eb ndryshme t\u00eb t\u00eb dh\u00ebnave, mund t\u00eb b\u00ebsh SELECT ose UPDATE mbi \u00e7el\u00ebsin primar.<\/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>\nP\u00ebr t\u00eb siguruar koherenc\u00ebn e t\u00eb dh\u00ebnave t\u00eb replikave, Cassandra p\u00ebrdor <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Quorum_(distributed_computing)\">q\u00ebndrimin me shumic\u00eb<\/a><\/noindex>. N\u00eb rastin m\u00eb t\u00eb thjesht\u00eb, kjo do t\u00eb thot\u00eb se kur vendosen tre replika t\u00eb t\u00eb nj\u00ebjtit rresht n\u00eb node t\u00eb ndryshme t\u00eb klasterit, shkrimi konsiderohet i suksessh\u00ebm, n\u00ebse shumica e nodeve (dmth dy nga tre) kan\u00eb konfirmuar suksesin e k\u00ebtij operacioni t\u00eb shkrimit. T\u00eb dh\u00ebnat e rreshtit konsiderohen t\u00eb koherent\u00eb, n\u00ebse gjat\u00eb leximit shumica e nodeve jan\u00eb pyetur dhe kan\u00eb konfirmuar ato. N\u00eb k\u00ebt\u00eb m\u00ebnyr\u00eb, me tre replika garantohet koherenca e plot\u00eb dhe e menj\u00ebhershme e t\u00eb dh\u00ebnave n\u00eb rastin e d\u00ebshtimit t\u00eb nj\u00eb node. Ky qasje na lejoi t\u00eb realizojm\u00eb nj\u00eb skem\u00eb edhe m\u00eb t\u00eb besueshme: gjithmon\u00eb d\u00ebrgojm\u00eb k\u00ebrkesa n\u00eb t\u00eb tri replikat, duke pritur p\u00ebrgjigjen nga dy m\u00eb t\u00eb shpejt\u00eb. P\u00ebrgjigjja e vonuar e tret\u00eb n\u00eb k\u00ebt\u00eb rast injorohet. N\u00eb k\u00ebt\u00eb rast, node q\u00eb \u00ebsht\u00eb vonuar me p\u00ebrgjigjen mund t\u00eb ket\u00eb probleme serioze \u2014 bllokime, mbledhje plehrash n\u00eb JVM, rimarrje e memories direkte n\u00eb kernelin linux, d\u00ebshtim t\u00eb pajisjes, shk\u00ebputje nga rrjeti. Megjithat\u00eb, kjo nuk ndikon aspak n\u00eb operacionin e klientit dhe n\u00eb t\u00eb dh\u00ebna.<\/p>\n<p>Qasja, kur ne i drejtohemi tre nodeve, nd\u00ebrsa marrim p\u00ebrgjigje nga dy, quhet <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Speculative_execution\">speculacion<\/a><\/noindex>: k\u00ebrkesa p\u00ebr replika t\u00eb tep\u00ebrta d\u00ebrgohet para se t\u00eb 'bjer\u00eb'. <\/p>\n<p>Nj\u00eb tjet\u00ebr p\u00ebrfitim nga Cassandra \u00ebsht\u00eb Batchlog \u2014 nj\u00eb mekaniz\u00ebm q\u00eb garanton ose aplikimin e plot\u00eb, ose mosaplikimin e plot\u00eb t\u00eb paket\u00ebs s\u00eb ndryshimeve q\u00eb b\u00ebni. Kjo na lejon t\u00eb zgjidhim A n\u00eb ACID \u2014 atomizimi nga kutia.<\/p>\n<p>\u0421\u0430\u043c\u043e\u0435 \u0431\u043b\u0438\u0437\u043a\u043e\u0435 \u043a \u0442\u0440\u0430\u043d\u0437\u0430\u043a\u0446\u0438\u044f\u043c \u0432 Cassandra \u2014 \u044d\u0442\u043e \u0442\u0430\u043a \u043d\u0430\u0437\u044b\u0432\u0430\u0435\u043c\u044b\u0435 &#171;<noindex><a rel=\"nofollow\" href=\"https:\/\/docs.datastax.com\/en\/cql\/3.3\/cql\/cql_using\/useInsertLWT.html\">transaksionet e lehta<\/a><\/noindex>&#171;. \u041d\u043e \u043e\u0442 \u00ab\u043d\u0430\u0441\u0442\u043e\u044f\u0449\u0438\u0445\u00bb ACID-\u0442\u0440\u0430\u043d\u0437\u0430\u043a\u0446\u0438\u0439 \u043e\u043d\u0438 \u0434\u0430\u043b\u0435\u043a\u0438: \u043d\u0430 \u0441\u0430\u043c\u043e\u043c \u0434\u0435\u043b\u0435, \u044d\u0442\u043e \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e\u0441\u0442\u044c \u0441\u0434\u0435\u043b\u0430\u0442\u044c <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Compare-and-swap\">CAS<\/a><\/noindex> n\u00eb t\u00eb dh\u00ebnat e vet\u00ebm nj\u00eb regjistrimi, duke p\u00ebrdorur konsensusin p\u00ebrmes protokollit t\u00eb r\u00ebnd\u00eb Paxos. Prandaj, shpejt\u00ebsia e k\u00ebtyre transaksioneve nuk \u00ebsht\u00eb shum\u00eb e lart\u00eb. <\/p>\n<h2>\u00c7far\u00eb na mungoi n\u00eb Cassandra<\/h2>\n<p>\nPra, na duhej t\u00eb realizonim transaksione t\u00eb v\u00ebrteta ACID n\u00eb Cassandra. Duke p\u00ebrdorur ato, mund t\u00eb realizonim leht\u00ebsisht dy mund\u00ebsi t\u00eb tjera t\u00eb dobishme t\u00eb DBMS klasike: indekset e shpejta konsistente, q\u00eb do t\u00eb na lejonin t\u00eb b\u00ebnim k\u00ebrkesa p\u00ebr t\u00eb dh\u00ebna jo vet\u00ebm mbi \u00e7el\u00ebsin primar dhe nj\u00eb gjenerator t\u00eb zakonsh\u00ebm t\u00eb ID auto-incrementale monotone.<\/p>\n<h4>C*One<\/h4>\n<p>\nK\u00ebshtu lindi sistemi i ri i menaxhimit t\u00eb t\u00eb dh\u00ebnave <b>C*One<\/b>, i p\u00ebrb\u00ebr\u00eb nga tri lloje nodash server\u00ebsh:<\/p>\n<ul>\n<li>Depozitat \u2014 server\u00eb (gjasht\u00eb) standarde Cassandra, p\u00ebrgjegj\u00ebs p\u00ebr ruajtjen e t\u00eb dh\u00ebnave n\u00eb disk\u00ebt lokal\u00eb. Nd\u00ebrsa rritet ngarkesa dhe volumi i t\u00eb dh\u00ebnave, numri i tyre mund t\u00eb shkall\u00ebzohet leht\u00ebsisht n\u00eb dhjet\u00ebra dhe qindra.<\/li>\n<li>Koordinator\u00ebt e transaksioneve \u2014 sigurojn\u00eb zbatimin e transaksioneve. <\/li>\n<li>Klient\u00ebt \u2014 server\u00eb aplikacionesh, q\u00eb realizojn\u00eb operacionet e biznesit dhe nisin transaksionet. Ka mund\u00ebsi t\u00eb jen\u00eb mij\u00ebra klient\u00eb.<\/li>\n<\/ul>\n<p>\n<img decoding=\"async\" alt=\"NewSQL = NoSQL+ACID\" src=\"\/wp-content\/uploads\/2019\/09\/f3809d89404ae596c62b642dbdb9e431.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nT\u00eb gjith\u00eb server\u00ebt e llojeve t\u00eb ndryshme jan\u00eb pjes\u00eb e nj\u00eb klasteri t\u00eb p\u00ebrbashk\u00ebt, p\u00ebrdorin protokollin e brendsh\u00ebm t\u00eb mesazheve Cassandra p\u00ebr t\u00eb komunikuar me nj\u00ebri-tjetrin dhe <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Gossip_protocol\">gossip<\/a><\/noindex> p\u00ebr shk\u00ebmbimin e informacionit t\u00eb klasterit. Me ndihm\u00ebn e Heartbeat, server\u00ebt m\u00ebsojn\u00eb p\u00ebr d\u00ebshtime t\u00eb nd\u00ebrsjella, mbajn\u00eb nj\u00eb skem\u00eb t\u00eb p\u00ebrbashk\u00ebt t\u00eb t\u00eb dh\u00ebnave \u2014 tabelat, struktur\u00ebn dhe replikimin e tyre; skem\u00ebn e ndarjes, topologjin\u00eb e klasterit, etj.<\/p>\n<h4>Klient\u00ebt<\/h4>\n<p>\n<img decoding=\"async\" alt=\"NewSQL = NoSQL+ACID\" src=\"\/wp-content\/uploads\/2019\/09\/80f83358f215cf59db3b657ba1083420.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nN\u00eb vend t\u00eb drejtor\u00ebve standard\u00eb, p\u00ebrdoret modaliteti Fat Client. Kjo nyj\u00eb nuk ruan t\u00eb dh\u00ebna, por mund t\u00eb veproj\u00eb si koordinatori p\u00ebr ekzekutimin e k\u00ebrkesave, dmth. Klienti vet\u00eb kryen funksionin e koordinimit t\u00eb k\u00ebrkesave t\u00eb tij: interrogon replikat e magazin\u00ebs dhe zgjidh konfliktet. Kjo \u00ebsht\u00eb jo vet\u00ebm m\u00eb e besueshme dhe m\u00eb e shpejt\u00eb se drejtori standard, i cili k\u00ebrkon komunikim me nj\u00eb koordinator t\u00eb larg\u00ebt, por gjithashtu lejon menaxhimin e transmetimit t\u00eb k\u00ebrkesave. Jasht\u00eb nj\u00eb transaksioni t\u00eb hapur n\u00eb klient, k\u00ebrkesat d\u00ebrgohen n\u00eb magazina. N\u00eb rast se klienti hap nj\u00eb transaksion, t\u00eb gjitha k\u00ebrkesat brenda transaksionit d\u00ebrgohen n\u00eb koordinatorin e transaksioneve.<br \/>\n<img decoding=\"async\" alt=\"NewSQL = NoSQL+ACID\" src=\"\/wp-content\/uploads\/2019\/09\/709bf227eeb8f71abeff703a72780efd.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Koordinatori i transaksioneve C*One<\/h2>\n<p>\nKoordinatori \u00ebsht\u00eb ajo q\u00eb ne e kemi realizuar p\u00ebr C*One nga zero. Ai \u00ebsht\u00eb p\u00ebrgjegj\u00ebs p\u00ebr menaxhimin e transaksioneve, bllokimeve dhe rendit t\u00eb zbatimit t\u00eb transaksioneve.<\/p>\n<p>P\u00ebr \u00e7do transaksion t\u00eb sh\u00ebrbyer, koordinatori gjeneron nj\u00eb afat t\u00eb p\u00ebrkohsh\u00ebm: \u00e7do i ardhsh\u00ebm \u00ebsht\u00eb m\u00eb i madh se ai i transaksionit t\u00eb m\u00ebparsh\u00ebm. Duke qen\u00eb se n\u00eb Cassandra sistemi i zgjidhjes s\u00eb konflikteve bazohet n\u00eb afate t\u00eb p\u00ebrkohshme (nga dy regjistrime konfliktuese, regjistrimi aktual \u00ebsht\u00eb ai me afatin m\u00eb t\u00eb vonsh\u00ebm), konflikti gjithmon\u00eb do t\u00eb zgjidhet n\u00eb favor t\u00eb transaksionit t\u00eb m\u00ebvonsh\u00ebm. K\u00ebshtu e kemi realizuar <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\">or\u00ebt e Lamportit<\/a><\/noindex> \u2014 nj\u00eb m\u00ebnyr\u00eb e lir\u00eb p\u00ebr t\u00eb zgjidhur konfliktet n\u00eb nj\u00eb sistem t\u00eb shp\u00ebrndar\u00eb.<\/p>\n<h2>Bllokimet<\/h2>\n<p>\nP\u00ebr t\u00eb siguruar izolimin, ne vendos\u00ebm t\u00eb p\u00ebrdorim m\u00ebnyr\u00ebn m\u00eb t\u00eb thjesht\u00eb \u2014 bllokimet pesimiste sipas \u00e7el\u00ebsit primar t\u00eb regjistrimit. N\u00eb fjal\u00eb t\u00eb tjera, n\u00eb nj\u00eb transaksion regjistrimi duhet s\u00eb pari t\u00eb bllokohet, e m\u00eb pas t\u00eb lexohen, modifikohen dhe ruhen. Vet\u00ebm pas nj\u00eb komitimi t\u00eb suksessh\u00ebm regjistrimi mund t\u00eb \u00e7'bllokohet q\u00eb transaksionet konkurruese ta p\u00ebrdorin at\u00eb.<\/p>\n<p>Realizimi i till\u00eb i bllokimit \u00ebsht\u00eb i thjesht\u00eb n\u00eb nj\u00eb mjedis t\u00eb pa shp\u00ebrndar\u00eb. N\u00eb nj\u00eb sistem t\u00eb shp\u00ebrndar\u00eb ka dy m\u00ebnyra kryesore: ose t\u00eb realizosh bllokim t\u00eb shp\u00ebrndar\u00eb n\u00eb klaster, ose t\u00eb shp\u00ebrndash transaksionet n\u00eb m\u00ebnyr\u00eb q\u00eb transaksionet q\u00eb p\u00ebrfshijn\u00eb nj\u00eb regjistrim t\u00eb sh\u00ebrbehen gjithmon\u00eb nga i nj\u00ebjti koordinator.<\/p>\n<p>Duke qen\u00eb se n\u00eb rastin ton\u00eb t\u00eb dh\u00ebnat tashm\u00eb jan\u00eb shp\u00ebrndar\u00eb n\u00eb grupe t\u00eb transaksioneve lokale n\u00eb SQL, vendos\u00ebm t\u00eb ngelim koordinatoret p\u00ebr grupet e transaksioneve lokale: nj\u00eb koordinator kryen t\u00eb gjitha transaksionet me token nga 0 deri n\u00eb 9, tjetri \u2014 me token nga 10 deri n\u00eb 19, dhe k\u00ebshtu me radh\u00eb. Si rezultat, \u00e7do nga instancat e koordinatoreve b\u00ebhet master i grupit t\u00eb transaksioneve. <\/p>\n<p>At\u00ebher\u00eb bllokimet mund t\u00eb realizohen si nj\u00eb HashMap t\u00eb zakonshme n\u00eb memorje t\u00eb koordinatoreve.<\/p>\n<h2>D\u00ebshtimet e koordinatoreve<\/h2>\n<p>\nDuke qen\u00eb se nj\u00eb koordinator sh\u00ebrben vet\u00ebm nj\u00eb grup transaksionesh, \u00ebsht\u00eb shum\u00eb e r\u00ebnd\u00ebsishme t\u00eb p\u00ebrcaktohet shpejt fakti i d\u00ebshtimit t\u00eb tij, n\u00eb m\u00ebnyr\u00eb q\u00eb p\u00ebrpjekja p\u00ebr t\u00eb ekzekutuar transaksionin t\u00eb q\u00ebndroj\u00eb brenda afatit. P\u00ebr ta b\u00ebr\u00eb k\u00ebt\u00eb shpejt dhe besuesh\u00ebm, ne p\u00ebrdor\u00ebm nj\u00eb protokoll t\u00eb lidhur t\u00eb kvorumit t\u00eb boy-kontaktit:<\/p>\n<p>N\u00eb \u00e7do qend\u00ebr t\u00eb t\u00eb dh\u00ebnave vendosen t\u00eb pakt\u00ebn dy nova koordinatori. Periudhsh\u00ebm, \u00e7do koordinator d\u00ebrgon nj\u00eb mesazh t\u00eb boy-kontaktit tek koordinatoret e tjer\u00eb dhe i informon ata p\u00ebr funksionimin e tij, si dhe p\u00ebr mesazhet e boy-kontaktit nga cil\u00ebt koordinatoret n\u00eb klaster ai mori m\u00eb s\u00eb fundi. <\/p>\n<p><img decoding=\"async\" alt=\"NewSQL = NoSQL+ACID\" src=\"\/wp-content\/uploads\/2019\/09\/5c337e53815cad0a2071b160d98d42fa.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDuke marr\u00eb informacion t\u00eb ngjash\u00ebm nga t\u00eb tjer\u00ebt n\u00eb mesazhet e tyre t\u00eb boy-kontaktit, \u00e7do koordinator vendos p\u00ebr veten se cilat nova t\u00eb klasterit po funksionojn\u00eb dhe cilat jo, duke ndjekur parimin e kvorumit: n\u00ebse nova X ka marr\u00eb nga shumica e nova n\u00eb klaster informacion p\u00ebr marrjen normale t\u00eb mesazheve nga nova Y, at\u00ebher\u00eb Y funksionon. Dhe anasjelltas, sapo shumica t\u00eb raportojn\u00eb p\u00ebr humbjen e mesazheve nga nova Y, at\u00ebher\u00eb Y ka d\u00ebshtuar. Curiositet, n\u00ebse kvorumi i raporton nova X se nuk merr m\u00eb mesazhe nga ajo, at\u00ebher\u00eb edhe nova X do ta konsideroj\u00eb veten t\u00eb d\u00ebshtuar.<\/p>\n<p>Mesazhet e boy-kontaktit d\u00ebrgohen me nj\u00eb frekuenc\u00eb t\u00eb lart\u00eb, rreth 20 her\u00eb n\u00eb sekond\u00eb, me nj\u00eb periudh\u00eb prej 50 ms. N\u00eb Java \u00ebsht\u00eb e v\u00ebshtir\u00eb t\u00eb garantosh reagimin e aplikacionit brenda 50 ms p\u00ebr shkak t\u00eb ngecjeve t\u00eb krahasueshme q\u00eb shkakton mbledh\u00ebsi i plehrave. Na arriti t\u00eb arrijm\u00eb k\u00ebt\u00eb koh\u00eb reagimi duke p\u00ebrdorur mbledh\u00ebsin e plehrave G1, i cili lejon caktimin e nj\u00eb q\u00ebllimi p\u00ebr koh\u00ebn e ngecjeve t\u00eb GC. Megjithat\u00eb, nganj\u00ebher\u00eb, mjaft rrall\u00eb, ngecjet e mbledh\u00ebsit kalojn\u00eb p\u00ebrtej 50 ms, q\u00eb mund t\u00eb \u00e7oj\u00eb n\u00eb zbules\u00eb t\u00eb rreme t\u00eb d\u00ebshtimit. Q\u00eb t\u00eb mos ndodhte nj\u00eb e till\u00eb, koordinatori nuk e raporton d\u00ebshtimin e nj\u00eb nova t\u00eb larg\u00ebt pas humbjes s\u00eb mesazhit t\u00eb par\u00eb t\u00eb boy-kontaktit nga ajo, vet\u00ebm n\u00ebse humbet disa radhazi. K\u00ebshtu arrit\u00ebm t\u00eb arrijm\u00eb zbules\u00ebn e d\u00ebshtimit t\u00eb nova t\u00eb koordinatoreve brenda 200 ms. <\/p>\n<p>Por nuk \u00ebsht\u00eb vet\u00ebm e r\u00ebnd\u00ebsishme t\u00eb kuptohet, cila nova ka ndaluar s\u00eb funksionuari. Duhet t\u00eb b\u00ebhet di\u00e7ka me k\u00ebt\u00eb. <\/p>\n<h2>Kopjim rezerv\u00eb<\/h2>\n<p>\nSchema klasike parashikon se n\u00eb rast d\u00ebshtimi t\u00eb masterit, t\u00eb nis\u00eb zgjedhjen e nj\u00eb t\u00eb ri me ndihm\u00ebn e nj\u00eb nga<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\"> modave t\u00eb njohura<\/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\">universale<\/a><\/noindex> . Megjithat\u00eb, k\u00ebto algoritme kan\u00eb probleme t\u00eb njohura n\u00eb lidhje me konvergjenc\u00ebn n\u00eb koh\u00eb dhe gjat\u00ebsi t\u00eb procesit t\u00eb vet\u00ebzgjedhjes. K\u00ebto vonesa shtes\u00eb arrit\u00ebm t'i shmangim duke p\u00ebrdorur nj\u00eb skem\u00eb z\u00ebvend\u00ebsimi p\u00ebr koordinatoret n\u00eb nj\u00eb rrjet t\u00eb lidhur plot\u00ebsisht:<\/p>\n<p><img decoding=\"async\" alt=\"NewSQL = NoSQL+ACID\" src=\"\/wp-content\/uploads\/2019\/09\/5e2db258fa2200026390a73a414dfe81.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSupozoni se duam t\u00eb realizojm\u00eb nj\u00eb transaksion n\u00eb grupin 50. Fillimisht do t\u00eb p\u00ebrcaktojm\u00eb skem\u00ebn e z\u00ebvend\u00ebsimit, dometh\u00ebn\u00eb cilat node do t\u00eb kryejn\u00eb transaksionet e grupit 50 n\u00eb rastin e d\u00ebshtimit t\u00eb koordinatores kryesore. Q\u00ebllimi yn\u00eb \u00ebsht\u00eb t\u00eb ruajm\u00eb funksionalitetin e sistemit n\u00eb rast d\u00ebshtimi t\u00eb qendr\u00ebs s\u00eb t\u00eb dh\u00ebnave. Do t\u00eb p\u00ebrcaktojm\u00eb se rezervi i par\u00eb do t\u00eb jet\u00eb nj\u00eb node nga nj\u00eb qend\u00ebr tjera e t\u00eb dh\u00ebnave, nd\u00ebrsa rezervi i dyt\u00eb nj\u00eb node nga nj\u00eb qend\u00ebr e tret\u00eb. Kjo skem\u00eb zgjidhet nj\u00ebher\u00eb dhe nuk ndryshon derisa t\u00eb ndryshoj\u00eb topologjia e klasterit, dometh\u00ebn\u00eb derisa t\u00eb hyjn\u00eb node t\u00eb reja (di\u00e7ka q\u00eb ndodh shum\u00eb rrall\u00eb). Rregulli p\u00ebr zgjedhjen e nj\u00eb masteri t\u00eb ri aktiv n\u00eb rastin e d\u00ebshtimit t\u00eb nj\u00eb t\u00eb vjetri do t\u00eb jet\u00eb gjithmon\u00eb ky: masteri aktiv do t\u00eb jet\u00eb rezervi i par\u00eb, dhe n\u00ebse edhe ai d\u00ebshton \u2014 rezervi i dyt\u00eb. <\/p>\n<p>Kjo skem\u00eb \u00ebsht\u00eb m\u00eb e besueshme se algoritmi universal, sepse p\u00ebr aktivizimin e nj\u00eb masteri t\u00eb ri mjafton t\u00eb p\u00ebrcaktohet fakti i d\u00ebshtimit t\u00eb atij t\u00eb vjet\u00ebr.<\/p>\n<p>Por si do ta din\u00eb klient\u00ebt se cili nga masterat \u00ebsht\u00eb aktualisht aktiv? N\u00eb 50 ms \u00ebsht\u00eb e pamundur t\u00eb shp\u00ebrndahen informatat p\u00ebr mij\u00ebra klient\u00eb. Mund t\u00eb ndodh\u00eb q\u00eb nj\u00eb klient t\u00eb d\u00ebrgoj\u00eb nj\u00eb k\u00ebrkes\u00eb p\u00ebr hapjen e nj\u00eb transaksioni, pa e ditur se ky master tashm\u00eb nuk po funksionon, duke e b\u00ebr\u00eb q\u00eb k\u00ebrkesa t\u00eb ngec\u00eb n\u00eb nj\u00eb skadim kohor. P\u00ebr t\u00eb parandaluar k\u00ebt\u00eb, klient\u00ebt d\u00ebrgojn\u00eb spekulativisht nj\u00eb k\u00ebrkes\u00eb p\u00ebr hapjen e transaksionit tek masteri i grupit dhe t\u00eb dy rezervat e tij, por do t\u00eb p\u00ebrgjigjet vet\u00ebm ai q\u00eb \u00ebsht\u00eb master aktiv n\u00eb at\u00eb moment. T\u00eb gjitha komunikimet e m\u00ebtejshme brenda transaksionit klienti do t'i b\u00ebj\u00eb vet\u00ebm me masterin aktiv.<\/p>\n<p>Masterat rezerv\u00eb vendosin k\u00ebrkesat e marra p\u00ebr transaksionet q\u00eb nuk jan\u00eb p\u00ebr to n\u00eb radh\u00eb p\u00ebr transaksionet e parakohshme, ku ato ruhen p\u00ebr nj\u00eb periudh\u00eb t\u00eb caktuar. N\u00ebse masteri aktiv vdes, masteri i ri merr n\u00eb shqyrtim k\u00ebrkesat p\u00ebr hapjen e transaksioneve nga radh\u00ebt e tij dhe i p\u00ebrgjigjet klientit. N\u00ebse klienti tashm\u00eb ka hapur nj\u00eb transaksion me masterin e vjet\u00ebr, at\u00ebher\u00eb p\u00ebrgjigjia e dyt\u00eb injorohet (dhe, natyrisht, nj\u00eb transaksion i till\u00eb nuk do t\u00eb p\u00ebrfundoj\u00eb dhe do t\u00eb p\u00ebrs\u00ebritet nga klienti).<\/p>\n<h2>Si funksionon nj\u00eb transaksion<\/h2>\n<p>\nSupozoni se klienti i ka d\u00ebrguar koordinatores nj\u00eb k\u00ebrkes\u00eb p\u00ebr hapjen e nj\u00eb transaksioni p\u00ebr nj\u00eb aset t\u00eb till\u00eb me nj\u00eb \u00e7el\u00ebs t\u00eb till\u00eb. Koordinatori e bllokon k\u00ebt\u00eb aset dhe e vendos n\u00eb tabel\u00ebn e bllokimeve n\u00eb memorie. N\u00ebse \u00ebsht\u00eb e nevojshme, koordinatori lexon k\u00ebt\u00eb aset nga depoja dhe ruan t\u00eb dh\u00ebnat e marra n\u00eb gjendjen e transaksionit n\u00eb memorien e koordinatores.<\/p>\n<p><img decoding=\"async\" alt=\"NewSQL = NoSQL+ACID\" src=\"\/wp-content\/uploads\/2019\/09\/246b4a5c68a4cc886b87af784c16b9dc.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nKur klienti d\u00ebshiron t\u00eb ndryshoj\u00eb t\u00eb dh\u00ebnat n\u00eb transaksion, ai e d\u00ebrgon nj\u00eb k\u00ebrkes\u00eb p\u00ebr modifikimin e asetet tek koordinatori, dhe ai vendos t\u00eb dh\u00ebnat e reja n\u00eb tabel\u00ebn e gjendjes s\u00eb transaksioneve n\u00eb memorie. K\u00ebshtu, regjistrimi p\u00ebrfundon \u2014 regjistrimi n\u00eb depo nuk b\u00ebhet.<\/p>\n<p><img decoding=\"async\" alt=\"NewSQL = NoSQL+ACID\" src=\"\/wp-content\/uploads\/2019\/09\/4400a91af30eb71134978ff27474f745.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nKur klienti k\u00ebrkon t\u00eb dh\u00ebnat e veta t\u00eb ndryshuara brenda nj\u00eb transaksioni aktiv, koordinatori vepron k\u00ebshtu: <\/p>\n<ul>\n<li>n\u00ebse ID \u00ebsht\u00eb tashm\u00eb n\u00eb transaksion, t\u00eb dh\u00ebnat merren nga memoria; <\/li>\n<li>n\u00ebse ID nuk \u00ebsht\u00eb n\u00eb memorie, t\u00eb dh\u00ebnat e munguar lexohen nga nodet e depove, kombinohen me ato q\u00eb tashm\u00eb jan\u00eb n\u00eb memorie, dhe rezultati i dor\u00ebzohet klientit. <\/li>\n<\/ul>\n<p>\nK\u00ebshtu, klienti mund t\u00eb lexoj\u00eb ndryshimet e veta, nd\u00ebrsa klient\u00ebt e tjer\u00eb nuk i shohin k\u00ebto ndryshime, sepse ato ruhen vet\u00ebm n\u00eb memorien e koordinatores, n\u00eb nodet e Cassandra ato ende nuk ekzistojn\u00eb.<\/p>\n<p><img decoding=\"async\" alt=\"NewSQL = NoSQL+ACID\" src=\"\/wp-content\/uploads\/2019\/09\/c93fd7e8393f431a976f1f56b95e227c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nKur klienti d\u00ebrgon nj\u00eb commit, gjendja, e cila kishte qen\u00eb n\u00eb memorie te sh\u00ebrbimi, ruhet nga koordinatori n\u00eb logged batch, dhe tashm\u00eb n\u00eb form\u00ebn e logged batch d\u00ebrgohet n\u00eb depot e Cassandra. Depot b\u00ebjn\u00eb t\u00eb gjitha nevojat q\u00eb ky paket\u00eb t\u00eb aplikohet atomikisht (plot\u00ebsisht) dhe i kthejn\u00eb p\u00ebrgjigje koordinatores, e cila pastaj \u00e7liron bllokimet dhe konfirmon suksesin e transaksionit tek klienti.<\/p>\n<p><img decoding=\"async\" alt=\"NewSQL = NoSQL+ACID\" src=\"\/wp-content\/uploads\/2019\/09\/ab20487ba53ed88e2f560a2249b5d6f9.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDhe p\u00ebr t\u00eb anuluar, koordinatori ka nevoj\u00eb vet\u00ebm t\u00eb \u00e7liroj\u00eb memorjen e z\u00ebn\u00eb nga gjendja e transaksionit.<\/p>\n<p>Si rezultat i p\u00ebrmir\u00ebsimeve t\u00eb p\u00ebrshkruara m\u00eb sip\u00ebr, ne realizuam parimet ACID:<\/p>\n<ul>\n<li><b>Atomik\u00ebsia<\/b>. Kjo \u00ebsht\u00eb garancia se asnj\u00eb transaksion nuk do t\u00eb regjistrohet n\u00eb sistem pjes\u00ebrisht, do t\u00eb zbatohet ose t\u00eb gjitha n\u00ebnoperacionet e tij, ose asnj\u00ebra. Ky princip respektohet nga logged batch n\u00eb Cassandra.<\/li>\n<li><b>Konsistenca<\/b>. \u00c7do transaksion i suksessh\u00ebm, nga definicioni, regjistron vet\u00ebm rezultate t\u00eb lejueshme. N\u00ebse pas hapjes s\u00eb transaksionit dhe kryerjes s\u00eb disa operacioneve zbulohet se rezultati nuk \u00ebsht\u00eb i lejuesh\u00ebm, her\u00eb pas here b\u00ebhet nj\u00eb anulim.<\/li>\n<li><b>Izolimi<\/b>. Kur gjat\u00eb kryerjes s\u00eb transaksionit, transaksionet paralele nuk duhet t\u00eb ndikojn\u00eb n\u00eb rezultatin e tij. Transaksionet konkurruese jan\u00eb izoluar me an\u00eb t\u00eb bllokimeve pesimiste n\u00eb koordinatori. P\u00ebr leximet jasht\u00eb transaksionit, respektohet principi i izolimit n\u00eb nivelin Read Committed.<\/li>\n<li><b>Q\u00ebndrueshm\u00ebria<\/b>. Pavar\u00ebsisht problemeve n\u00eb nivelet e poshtme \u2014 ndalimi i sistemit, d\u00ebshtimi i pajisjeve \u2014 ndryshimet e b\u00ebra nga nj\u00eb transaksion i p\u00ebrfunduar me sukses duhet t\u00eb mbeten t\u00eb ruajtura pas rinisjes s\u00eb funksionimit. <\/li>\n<\/ul>\n<p><\/p>\n<h2>Leximi p\u00ebrmes indekseve<\/h2>\n<p>\nLe t\u00eb marrim nj\u00eb tabel\u00eb t\u00eb thjesht\u00eb: <\/p>\n<pre><code>CREATE TABLE photos (\nid bigint primary key,\nowner bigint,\nmodified timestamp,\n\u2026)<\/code><\/pre>\n<p>\nAjo ka nj\u00eb ID (\u00e7el\u00ebsi primar), pronar dhe dat\u00ebn e modificimit. Ne duhet t\u00eb b\u00ebjm\u00eb nj\u00eb k\u00ebrkes\u00eb shum\u00eb t\u00eb thjesht\u00eb \u2014 t\u00eb zgjedhim t\u00eb dh\u00ebnat sipas pronarit me dat\u00ebn e modifikimit \"n\u00eb 24 or\u00ebt e fundit\". <\/p>\n<pre><code>SELECT *\nWHERE owner=?\nAND modified&gt;?<\/code><\/pre>\n<p>\nP\u00ebr t\u00eb b\u00ebr\u00eb nj\u00eb k\u00ebrkes\u00eb t\u00eb till\u00eb t\u00eb punoj\u00eb shpejt, n\u00eb nj\u00eb DBMS klasik SQL, duhet t\u00eb nd\u00ebrtojm\u00eb nj\u00eb indeks sipas kolonave (owner, modified). K\u00ebshtu mund ta b\u00ebjm\u00eb mjaft leht\u00eb, pasi tani kemi garanci ACID!<\/p>\n<h2>Indekset n\u00eb C*One<\/h2>\n<p>\nKa nj\u00eb tabel\u00eb burimore me fotografi, ku ID e regjistrimit \u00ebsht\u00eb \u00e7el\u00ebsi primar. <\/p>\n<p><img decoding=\"async\" alt=\"NewSQL = NoSQL+ACID\" src=\"\/wp-content\/uploads\/2019\/09\/9f5d7c5f66882666a7ae8219f710beeb.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nP\u00ebr indeksin, C*One krijon nj\u00eb tabel\u00eb t\u00eb re, e cila \u00ebsht\u00eb nj\u00eb kopje e t\u00eb dh\u00ebnave burimore. \u00c7el\u00ebsi p\u00ebrputhet me shprehjen e indeksit, duke p\u00ebrfshir\u00eb gjithashtu \u00e7el\u00ebsin primar t\u00eb regjistrit nga tabela burimore:<\/p>\n<p><img decoding=\"async\" alt=\"NewSQL = NoSQL+ACID\" src=\"\/wp-content\/uploads\/2019\/09\/ce6df1c8407bca7ddc61fd88141455e6.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nTani, k\u00ebrkesa p\u00ebr \"pronarin n\u00eb 24 or\u00ebt e fundit\" mund t\u00eb riformulohet si nj\u00eb k\u00ebrkes\u00eb nga tabela tjet\u00ebr:<\/p>\n<pre><code>SELECT * FROM i1_test\nWHERE owner=?\nAND modified&gt;?<\/code><\/pre>\n<p>\nKonsistenca e t\u00eb dh\u00ebnave n\u00eb tabel\u00ebn burimore photos dhe indeksi i1 mbahen automatikisht nga koordinatori. Bazuar vet\u00ebm n\u00eb skem\u00ebn e t\u00eb dh\u00ebnave, kur merr nj\u00eb ndryshim, koordinatori gjeneron dhe ruan jo vet\u00ebm ndryshimin e tabel\u00ebs kryesore, por edhe ndryshimet e kopjave. Nuk k\u00ebrkohen veprime t\u00eb tjera me tabel\u00ebn e indeksit, logjet nuk lexohen, bllokimet nuk p\u00ebrdoren. K\u00ebshtu q\u00eb shtimi i indekseve nuk konsumon pothuajse burime dhe nuk ndikon n\u00eb shpejt\u00ebsin\u00eb e aplikimit t\u00eb modifikimeve.<\/p>\n<p>Me ndihm\u00ebn e ACID, arrit\u00ebm t\u00eb realizojm\u00eb indekse \"si n\u00eb SQL\". Ato kan\u00eb konsistenc\u00eb, mund t\u00eb shkall\u00ebzohen, punojn\u00eb shpejt, mund t\u00eb jen\u00eb t\u00eb p\u00ebrb\u00ebr\u00eb dhe t\u00eb integruar n\u00eb gjuh\u00ebn e k\u00ebrkesave CQL. P\u00ebr mb\u00ebshtetjen e indekseve nuk \u00ebsht\u00eb e nevojshme t\u00eb b\u00ebhen ndryshime n\u00eb kodin aplikativ. E gjith\u00eb kjo \u00ebsht\u00eb e thjesht\u00eb, si n\u00eb SQL. Dhe ajo q\u00eb \u00ebsht\u00eb m\u00eb e r\u00ebnd\u00ebsishmja, indekset nuk ndikojn\u00eb n\u00eb shpejt\u00ebsin\u00eb e ekzekutimit t\u00eb modifikimeve n\u00eb tabel\u00ebn burimore t\u00eb transaksioneve.<\/p>\n<h2>\u00c7far\u00eb rezultati u arrit<\/h2>\n<p>\nNe zhvilluam C*One tre vjet m\u00eb par\u00eb dhe e vendos\u00ebm n\u00eb prodhim. <\/p>\n<p>\u00c7far\u00eb arrit\u00ebm n\u00eb fund? Le t\u00eb e vler\u00ebsojm\u00eb k\u00ebt\u00eb n\u00eb shembullin e n\u00ebnsistemit t\u00eb p\u00ebrpunimit dhe ruajtjes s\u00eb fotografive, nj\u00eb nga llojet m\u00eb t\u00eb r\u00ebnd\u00ebsishme t\u00eb t\u00eb dh\u00ebnave n\u00eb rrjetet sociale. Nuk b\u00ebhet fjal\u00eb p\u00ebr vet\u00eb trupat e fotografive, por p\u00ebr t\u00eb gjith\u00eb metainformacionin. Aktualisht, n\u00eb \"Odnoklassniki\" ka rreth 20 miliard\u00eb t\u00eb tilla regjistrime, sistemi p\u00ebrpunon 80 mij\u00eb k\u00ebrkesa leximi n\u00eb sekond\u00eb, deri n\u00eb 8 mij\u00eb ACID-transaksione n\u00eb sekond\u00eb, t\u00eb lidhura me modifikimin e t\u00eb dh\u00ebnave. <\/p>\n<p>Kur ne p\u00ebrdor\u00ebm SQL me faktor replikimi = 1 (por n\u00eb RAID 10), metainformacioni i fotografive ruhej n\u00eb nj\u00eb grup me akses t\u00eb lart\u00eb prej 32 makinash me Microsoft SQL Server (plus 11 t\u00eb rezervuar). Gjithashtu, u rezervuan 10 servera p\u00ebr ruajtjen e backup-eve. N\u00eb total, 50 makina t\u00eb shtrenjta. N\u00eb t\u00eb nj\u00ebjt\u00ebn koh\u00eb, sistemi punonte me ngarkes\u00eb nominale, pa rezerv\u00eb.<\/p>\n<p>Pas migrimit n\u00eb sistemin e ri, ne mor\u00ebm faktor replikimi = 3 \u2014 nj\u00eb kopje n\u00eb \u00e7do qend\u00ebr t\u00eb t\u00eb dh\u00ebnave. Sistemi p\u00ebrb\u00ebhet nga 63 nodet e ruajtjes Cassandra dhe 6 makina koordinatori, n\u00eb total 69 servera. Por k\u00ebto makina jan\u00eb shum\u00eb m\u00eb t\u00eb lira, kostoja e tyre e p\u00ebrgjithshme p\u00ebrb\u00ebn rreth 30 % t\u00eb kostos s\u00eb sistemit n\u00eb SQL. N\u00eb t\u00eb nj\u00ebjt\u00ebn koh\u00eb, ngarkesa q\u00ebndron n\u00eb nivelin 30 %.<\/p>\n<p>Me implementimin e C*One vonesat gjithashtu u ul\u00ebn: n\u00eb SQL, operacioni i shkrimit zgjaste rreth 4.5 ms. N\u00eb C*One \u2014 rreth 1.6 ms. Koh\u00ebzgjatja e nj\u00eb transaksioni, n\u00eb mesatare, \u00ebsht\u00eb m\u00eb pak se 40 ms, komiti kryhet brenda 2 ms, koh\u00ebzgjatja e leximit dhe shkrimit \u2014 n\u00eb mesatare 2 ms. 99-i percentile \u00ebsht\u00eb vet\u00ebm 3-3.1 ms, numri i koh\u00ebve t\u00eb kaluar \u00ebsht\u00eb ulur 100 her\u00eb \u2014 gjith\u00e7ka p\u00ebr shkak t\u00eb p\u00ebrdorimit t\u00eb gjer\u00eb t\u00eb spekulacionit. <\/p>\n<p>Derisa n\u00eb k\u00ebt\u00eb moment, pjesa e madhe e nod\u00ebve SQL Server \u00ebsht\u00eb hequr nga funksionimi, produktet e reja zhvillohen vet\u00ebm me p\u00ebrdorimin e C*One. Ne e kemi adaptuar C*One p\u00ebr t\u00eb punuar n\u00eb re <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/company\/odnoklassniki\/blog\/346868\/\">one-cloud<\/a><\/noindex>, e cila ka lejuar p\u00ebrshpejtimin e krijimit t\u00eb grupeve t\u00eb reja, thjeshtimin e konfigurimit dhe automatizimin e operimit. Pa kodin burimor, do t\u00eb ishte shum\u00eb m\u00eb e v\u00ebshtir\u00eb dhe m\u00eb e komplikuar. <\/p>\n<p>Aktualisht, ne po punojm\u00eb p\u00ebr t\u00eb transferuar ruajtjet tona t\u00eb tjera n\u00eb re \u2014 por kjo \u00ebsht\u00eb nj\u00eb histori krejt\u00ebsisht tjet\u00ebr.<br \/>\n<br \/>Burimi: <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 5.0.0.1 - 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\/sq\/blog\/administrirovanie\/newsql-nosql-acid\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.0.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"sq_AL\" \/>\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\/sq\/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":"Deri koh\u00ebve t\u00eb fundit n\u00eb Odnoklassniki, rreth 50 TB t\u00eb dh\u00ebnash q\u00eb p\u00ebrpunoheshin n\u00eb koh\u00eb reale ruheshin n\u00eb SQL Server. Sigurimi i nj\u00eb qasjeje t\u00eb shpejt\u00eb, t\u00eb besueshme dhe t\u00eb q\u00ebndrueshme ndaj k\u00ebtyre t\u00eb dh\u00ebnave duke p\u00ebrdorur nj\u00eb SQL DB \u00ebsht\u00eb praktikisht i pamundur p\u00ebr nj\u00eb volum t\u00eb till\u00eb. Zakonisht n\u00eb k\u00ebto raste p\u00ebrdoren nj\u00eb nga depozitat NoSQL, por nuk gjith\u00e7ka mund t\u00eb transferohet n\u00eb NoSQL: disa entitete k\u00ebrkojn\u00eb","canonical_url":"https:\/\/prohoster.info\/sq\/blog\/administrirovanie\/newsql-nosql-acid","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"sq_AL","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\/sq\/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","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/posts\/37956","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/comments?post=37956"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/posts\/37956\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/media\/28484"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/media?parent=37956"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/categories?post=37956"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/tags?post=37956"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}