{"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 \/>\nDeri n\u00eb koh\u00ebt e fundit, n\u00eb Odnoklassniki u ruajt\u00ebn rreth 50 TB t\u00eb dh\u00ebnash q\u00eb p\u00ebrpunoheshin n\u00eb koh\u00eb reale n\u00eb SQL Server. P\u00ebr nj\u00eb volum t\u00eb till\u00eb, sigurimi i nj\u00eb qendra t\u00eb t\u00eb dh\u00ebnave t\u00eb shpejt\u00eb dhe t\u00eb besueshme, p\u00ebr m\u00eb tep\u00ebr t\u00eb q\u00ebndrueshme ndaj d\u00ebshtimeve, duke p\u00ebrdorur nj\u00eb DBMS SQL, \u00ebsht\u00eb thuajse e pamundur. N\u00eb raste t\u00eb tilla zakonisht p\u00ebrdoren nj\u00eb nga ruajtjet NoSQL, por nuk gjith\u00e7ka mund t\u00eb jet\u00eb e transferueshme n\u00eb NoSQL: disa entitete k\u00ebrkojn\u00eb garanci ACID p\u00ebr transaksionet. <\/p>\n<p>Kjo na \u00e7oi n\u00eb p\u00ebrdorimin e nj\u00eb ruajtje NewSQL, dmth nj\u00eb DBMS q\u00eb ofron q\u00ebndrueshm\u00ebri, shkall\u00ebzueshm\u00ebri dhe shpejt\u00ebsi t\u00eb sistemeve NoSQL, por q\u00eb ruan gjithashtu garancit\u00eb ACID q\u00eb jemi m\u00ebsuar t\u00eb p\u00ebrdorim n\u00eb sistemet tradicionale. Sistemet industriale q\u00eb funksionojn\u00eb nga kjo klas\u00eb t\u00eb re jan\u00eb pak, prandaj ne realizuam nj\u00eb sistem t\u00eb till\u00eb vet\u00eb dhe e lan\u00e7uam at\u00eb n\u00eb prodhim. <\/p>\n<p>Si funksionon dhe \u00e7far\u00eb \u00ebsht\u00eb arritur - lexoni m\u00eb posht\u00eb.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\nSot, audienca mujore e \"Odnoklassniki\" kap m\u00eb shum\u00eb se 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 nd\u00ebr pes\u00eb<\/a><\/noindex> rrjetet sociale m\u00eb t\u00eb m\u00ebdha n\u00eb bot\u00eb, dhe n\u00eb dvigjithja m\u00eb e madhe e faqeve n\u00eb t\u00eb cilat p\u00ebrdoruesit kalojn\u00eb m\u00eb shum\u00eb koh\u00eb. Infrastruktur\u00ebn e \"OK\" e p\u00ebrpunon ngarkesa shum\u00eb t\u00eb larta: m\u00eb shum\u00eb se nj\u00eb milion k\u00ebrkesa HTTP\/s n\u00eb frontet. Pjes\u00ebt e parkut t\u00eb server\u00ebve q\u00eb p\u00ebrb\u00ebhen nga m\u00eb shum\u00eb se 8000 nj\u00ebsi jan\u00eb t\u00eb vendosura af\u00ebr nj\u00ebri-tjetrit - n\u00eb kat\u00ebr qendra t\u00eb t\u00eb dh\u00ebnave n\u00eb Mosk\u00eb, \u00e7ka lejon sigurimin e nj\u00eb vonese rrjeti m\u00eb pak se 1 ms mes tyre.<\/p>\n<p>Ne kemi p\u00ebrdorur Cassandra q\u00eb nga viti 2010, duke filluar me versionin 0.6. Sot, n\u00eb p\u00ebrdorim jan\u00eb disa dhjet\u00ebra grupe. Grupi m\u00eb i shpejt\u00eb p\u00ebrpunon m\u00eb shum\u00eb se 4 milion operacione n\u00eb sekond\u00eb, nd\u00ebrsa grupi m\u00eb i madh ruan 260 TB. <\/p>\n<p>Megjithat\u00eb, t\u00eb gjitha k\u00ebto jan\u00eb grupe t\u00eb zakonshme NoSQL, q\u00eb p\u00ebrdoren p\u00ebr ruajtjen e <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\">t\u00eb dh\u00ebnave me konsistenc\u00eb t\u00eb ul\u00ebt.<\/a><\/noindex> Ne d\u00ebshironim t\u00eb z\u00ebvend\u00ebsonim ruajtjen kryesore t\u00eb konsistenc\u00ebs, Microsoft SQL Server, e cila \u00ebsht\u00eb p\u00ebrdorur q\u00eb nga themelimi i \"Odnoklassniki\". Ruajtja p\u00ebrb\u00ebhej nga m\u00eb shum\u00eb se 300 makina SQL Server Standard Edition, t\u00eb cilat mbajt\u00ebn 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 mbi nodet SQL Server ne p\u00ebrdor\u00ebm si vertikalen ashtu edhe <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Partition_(database)\">particionimin horizontal.<\/a><\/noindex> (shardimi). Historically, we used a simple data sharding scheme: each entity was assigned a token \u2014 a function of the entity's ID. Entities with the same token were placed on the same SQL server. The master-detail relationship was implemented so that the tokens of the primary and derived records always matched and were located on the same server. In a social network, almost all records are generated on behalf of the user \u2014 meaning all user data within one functional subsystem is stored on one server. Therefore, in business transactions, tables from the same SQL server were almost always involved, which allowed us to ensure data consistency using local ACID transactions without the need for <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Two-phase_commit_protocol\">slow and unreliable<\/a><\/noindex> distributed ACID transactions.<\/p>\n<p>Thanks to sharding and to speed up SQL performance:<\/p>\n<ul>\n<li>We do not use Foreign key constraints, as with sharding the entity ID may reside on another server.<\/li>\n<li>We do not use stored procedures and triggers due to the additional load on the DBMS CPU.<\/li>\n<li>We do not use JOINs because of all the above and the numerous random disk reads.<\/li>\n<li>Outside of transactions, to reduce deadlocks, we use the Read Uncommitted isolation level.<\/li>\n<li>We only execute short transactions (on average shorter than 100 ms).<\/li>\n<li>We do not use multi-row UPDATE and DELETE due to the high number of deadlocks \u2014 we update only one record at a time.<\/li>\n<li>Queries are always executed only using indexes \u2014 a query with a full table scan plan means an overload of the DB and its failure.<\/li>\n<\/ul>\n<p>\nThese steps allowed us to extract almost maximum performance from SQL servers. However, the problems kept increasing. Let's take a look at them.<\/p>\n<h2>Problems with SQL<\/h2>\n<p><\/p>\n<ul>\n<li>Since we used custom sharding, adding new shards was performed manually by administrators. During this time, scalable data replicas did not handle queries. <\/li>\n<li>As the number of records in the table increases, the speed of inserts and modifications decreases; adding indexes to an existing table drastically reduces speed, and creating and recreating indexes comes with downtime.<\/li>\n<li>Having a small number of Windows for SQL Server in production complicates infrastructure management.<\/li>\n<\/ul>\n<p>\nBut the main problem is \u2014 <\/p>\n<h2>Q\u00ebndrueshm\u00ebri<\/h2>\n<p>\nKlasik SQL server ka nj\u00eb q\u00ebndrim t\u00eb dob\u00ebt ndaj d\u00ebshtimeve. Le t\u00eb themi se keni vet\u00ebm nj\u00eb server databaze, dhe ai d\u00ebshton nj\u00eb her\u00eb \u00e7do tre vjet. Gjat\u00eb k\u00ebtij kohe, faqja e internetit nuk funksionon p\u00ebr 20 minuta, kjo \u00ebsht\u00eb e pranueshme. N\u00ebse keni 64 server\u00eb, faqja e internetit nuk funksionon nj\u00eb her\u00eb \u00e7do tri jav\u00eb. Dhe n\u00ebse keni 200 server\u00eb, faqja e internetit 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\u00ebndrueshm\u00ebrin\u00eb e SQL serverit? Wikipedia na sugjeron t\u00eb nd\u00ebrtojm\u00eb <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/High-availability_cluster\">nj\u00eb klaster 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 rezerv\u00eb.<\/p>\n<p>Kjo k\u00ebrkon nj\u00eb park t\u00eb pajisjeve t\u00eb shtrenjta: shum\u00eb kopje, fibra optike, depozita t\u00eb p\u00ebrbashk\u00ebta, dhe madje edhe aktivizimi i rezerv\u00ebs funksionon n\u00eb m\u00ebnyr\u00eb t\u00eb pasigurt: rreth 10% e aktivizimeve p\u00ebrfundojn\u00eb me d\u00ebshtimin e nod\u00ebs rezerv\u00eb duke e ndjekur nod\u00ebn kryesore. <\/p>\n<p>Por disavantazhi kryesor i nj\u00eb klasteri me disponueshm\u00ebri t\u00eb lart\u00eb \u00ebsht\u00eb se nuk ka disponueshm\u00ebri n\u00eb rastin e d\u00ebshtimit t\u00eb qendr\u00ebs s\u00eb t\u00eb dh\u00ebnave ku ndodhet. \u2018Odnoklassniki\u2019 ka kat\u00ebr qendra t\u00eb t\u00eb dh\u00ebnave, dhe \u00ebsht\u00eb e nevojshme t\u00eb sigurojm\u00eb funksionimin n\u00eb nj\u00eb d\u00ebshtim t\u00eb plot\u00eb n\u00eb nj\u00eb prej tyre.<\/p>\n<p>P\u00ebr k\u00ebt\u00eb, mund t\u00eb aplikojm\u00eb <noindex><a rel=\"nofollow\" href=\"https:\/\/technet.microsoft.com\/en-us\/library\/ms151196.aspx\">Multi-Master<\/a><\/noindex> replikimin e 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 vuan nga problemet e njohura t\u00eb replikimit - vonesa t\u00eb paparashikueshme t\u00eb transaksioneve gjat\u00eb replikimit sinkron dhe vonesa n\u00eb aplikimin e replikimeve (dhe, si rrjedhoj\u00eb, modifikime t\u00eb humbura) gjat\u00eb replikimit asinkron. N\u00ebnkuptimi i <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\">zgjidhjes manuale t\u00eb konflikteve<\/a><\/noindex> e b\u00ebn k\u00ebt\u00eb variant plot\u00ebsisht t\u00eb papranuesh\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, duhet t\u00eb njohim at\u00eb q\u00eb kryesisht b\u00ebn SQL Server - transaksionet.<\/p>\n<h2>Transaksioni i thjesht\u00eb<\/h2>\n<p>\nLe t\u00eb shqyrtojm\u00eb nj\u00eb transaksion t\u00eb thjesht\u00eb, n\u00eb m\u00ebnyr\u00eb t\u00eb thjesht\u00eb p\u00ebr programuesin SQL: shtimi i nj\u00eb fotografie n\u00eb album. Albumet dhe fotografit\u00eb ruajten n\u00eb tabela t\u00eb ndryshme. Albumi ka nj\u00eb num\u00ebrator p\u00ebr fotografit\u00eb publike. At\u00ebher\u00eb ky transaksion ndahet n\u00eb hapat e m\u00ebposht\u00ebm: <\/p>\n<ol>\n<li>Bllokojm\u00eb albumin sipas \u00e7el\u00ebsit.<\/li>\n<li>Krijojm\u00eb nj\u00eb rekord n\u00eb tabel\u00ebn e fotografive. <\/li>\n<li>N\u00ebse fotografia ka status publik, rrisim num\u00ebratorin p\u00ebr fotografit\u00eb publike n\u00eb album, p\u00ebrdit\u00ebsojm\u00eb regjistrin dhe konfirmojm\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>\nNe e \u00e7uditshme q\u00eb skenari m\u00eb i zakonsh\u00ebm i transaksioneve t\u00eb biznesit \u2014 t\u00eb lexosh t\u00eb dh\u00ebnat nga DB n\u00eb memorien e serverit t\u00eb aplikatave, t\u00eb b\u00ebsh disa ndryshime dhe t\u00eb ruash 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 ndodh\u00eb modifikimi kompetitiv i t\u00eb nj\u00ebjtave t\u00eb dh\u00ebna nga nj\u00eb sistem tjet\u00ebr. P\u00ebr shembull, Antispam mund t\u00eb vendos\u00eb se p\u00ebrdoruesi \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 statusi i fotos duhet t\u00eb ndryshohet n\u00eb nj\u00eb vler\u00eb tjet\u00ebr dhe t\u00eb kthjellohen num\u00ebruesit p\u00ebrkat\u00ebs. \u00cbsht\u00eb e qart\u00eb se n\u00ebse kjo operacion ndodh pa garanci p\u00ebr atomizmin e aplikimit dhe izolimin e modifikimeve konkuruese, si n\u00eb <noindex><a rel=\"nofollow\" href=\"https:\/\/ru.wikipedia.org\/wiki\/ACID\">ACID<\/a><\/noindex>, at\u00ebher\u00eb rezultati do t\u00eb jet\u00eb ai q\u00eb nuk \u00ebsht\u00eb i nevojsh\u00ebm \u2014 ose num\u00ebruesi i fotove do t\u00eb tregoj\u00eb nj\u00eb vler\u00eb t\u00eb gabuar, 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 manipulat me entitete t\u00eb ndryshme biznesi brenda nj\u00eb transaksioni, \u00ebsht\u00eb shkruar shum\u00eb gjat\u00eb ekzistenc\u00ebs s\u00eb Odnoklassnikov. Nga p\u00ebrvoja e migrimeve n\u00eb NoSQL me <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Eventual_consistency\">Konsistenca e Vonshme<\/a><\/noindex> ne e dim\u00eb se problemet m\u00eb t\u00eb m\u00ebdha (dhe kostot e koh\u00ebs) shkaktohen nga nevoja p\u00ebr t\u00eb zhvilluar kod q\u00eb mban konsistenc\u00ebn e t\u00eb dh\u00ebnave. Prandaj, k\u00ebrkesa kryesore p\u00ebr magazin\u00ebn e re ishte t\u00eb ofronte p\u00ebr logjik\u00ebn aplikative transaksione t\u00eb v\u00ebrteta ACID. <\/p>\n<p>K\u00ebrkesat e tjera, po aq t\u00eb r\u00ebnd\u00ebsishme, ishin:<\/p>\n<ul>\n<li>N\u00eb rast t\u00eb d\u00ebshtimit t\u00eb qendr\u00ebs s\u00eb t\u00eb dh\u00ebnave, duhet t\u00eb jen\u00eb t\u00eb disponueshme si leximi ashtu edhe shkrimi n\u00eb magazin\u00ebn e re.<\/li>\n<li>Ruajtja e shpejt\u00ebsis\u00eb aktuale t\u00eb zhvillimit. Kjo do t\u00eb thot\u00eb se pun\u00ebn me magazin\u00ebn e re duhet t\u00eb ket\u00eb nj\u00eb sasi t\u00eb ngjashme kodi, nuk duhet t\u00eb shfaqet nevoja p\u00ebr t\u00eb shkruar di\u00e7ka t\u00eb re n\u00eb magazin\u00eb, t\u00eb zhvillosh algoritme p\u00ebr zgjidhjen e konflikteve, ruajtjen e indekseve sekondare, etj. <\/li>\n<li>Shpejt\u00ebsia e funksionimit t\u00eb magazin\u00ebs s\u00eb re duhet t\u00eb jet\u00eb mjaft e lart\u00eb, si p\u00ebr leximin e t\u00eb dh\u00ebnave ashtu edhe p\u00ebr p\u00ebrpunimin e transaksioneve, \u00e7ka do t\u00eb thot\u00eb se zgjidhjet akademike t\u00eb sakta, universale, por t\u00eb ngadalshme, si p\u00ebr shembull, <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Two-phase_commit_protocol\">komiteti me dy faza<\/a><\/noindex>.<\/li>\n<li>Skalimi automatikisht n\u00eb koh\u00eb reale. <\/li>\n<li>P\u00ebrdorimi i server\u00ebve t\u00eb zakonsh\u00ebm t\u00eb lir\u00eb, pa pasur nevoj\u00eb t\u00eb blihen pajisje ekzotike. <\/li>\n<li>Mund\u00ebsia p\u00ebr t\u00eb zhvilluar ruajtjen nga zhvilluesit e kompanis\u00eb. N\u00eb fjal\u00eb t\u00eb tjera, prioriteti i \u00ebsht\u00eb dh\u00ebn\u00eb zgjidhjeve t\u00eb brendshme ose atyre me kod t\u00eb hapur, preferohet n\u00eb Java.<\/li>\n<\/ul>\n<p><\/p>\n<h2>Zgjidhjet, zgjidhjet<\/h2>\n<p>\nDuke analizuar mund\u00ebsit\u00eb e zgjidhjeve, ne arrit\u00ebm n\u00eb dy mund\u00ebsi p\u00ebr arkitektur\u00ebn:<\/p>\n<p>E para \u2014 t\u00eb marrim \u00e7do server SQL dhe t\u00eb realizojm\u00eb q\u00ebndrueshm\u00ebrin\u00eb e nevojshme, mekanizmin e \u043c\u0430\u0441\u0448\u0442\u0430\u0431\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u00eb, klasterin e q\u00ebndruesh\u00ebm, zgjidhjen e konflikt\u00ebve dhe transaksionet ACID t\u00eb shp\u00ebrndara, t\u00eb besueshme dhe t\u00eb shpejta. Ne e vler\u00ebsuam k\u00ebt\u00eb variant si mjaft t\u00eb nd\u00ebrlikuar dhe t\u00eb pun\u00ebs intensive.<\/p>\n<p>Varianti i dyt\u00eb \u2014 t\u00eb marrim nj\u00eb ruajtje NoSQL t\u00eb gatshme me skalim t\u00eb implementuar, nj\u00eb klaster t\u00eb q\u00ebndruesh\u00ebm, zgjidhje konfliktesh dhe t\u00eb realizojm\u00eb transaksionet dhe SQL vet\u00eb. Me sa duket, edhe detyra e implementimit t\u00eb SQL, p\u00ebr t\u00eb mos p\u00ebrmendur transaksionet ACID, duket si nj\u00eb sfid\u00eb p\u00ebr disa vite. Por m\u00eb pas kuptuam se grupi i mund\u00ebsive t\u00eb SQL q\u00eb ne p\u00ebrdorim n\u00eb praktik\u00eb \u00ebsht\u00eb shum\u00eb larg nga 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 e shqyrtuar m\u00eb nga af\u00ebr CQL, kuptuam se \u00ebsht\u00eb mjaft i af\u00ebrt me at\u00eb q\u00eb na nevojitet.<\/p>\n<h2>Cassandra dhe CQL<\/h2>\n<p>\nPra, \u00e7far\u00eb e b\u00ebn Cassandra interesante, cilat jan\u00eb mund\u00ebsit\u00eb e saj?<\/p>\n<p>S\u00eb pari, k\u00ebtu mund t\u00eb krijoni tabela me mb\u00ebshtetje p\u00ebr lloje t\u00eb ndryshme t\u00eb t\u00eb dh\u00ebnave, mund t\u00eb b\u00ebni SELECT ose UPDATE sipas \u00e7el\u00ebsit 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 q\u00ebndrueshm\u00ebrin\u00eb e t\u00eb dh\u00ebnave t\u00eb replikave, Cassandra p\u00ebrdor <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Quorum_(distributed_computing)\">pranimin me shumic\u00eb<\/a><\/noindex>N\u00eb rastin m\u00eb t\u00eb thjesht\u00eb, kjo do t\u00eb thot\u00eb se kur vendosim tre replika t\u00eb t\u00eb nj\u00ebjtit rresht n\u00eb nodet e ndryshme t\u00eb klasterit, regjistrimi konsiderohet i suksessh\u00ebm n\u00ebse shumica e nodave (dmth dy nga tre) konfirmojn\u00eb suksesin e k\u00ebtij operacioni t\u00eb regjistrimit. T\u00eb dh\u00ebnat e rreshtit konsiderohen t\u00eb koordinuara n\u00ebse gjat\u00eb leximit shumica e nodave jan\u00eb pyetur dhe kan\u00eb konfirmuar ato. K\u00ebshtu, me tre replika, garanton nj\u00eb konsistenc\u00eb t\u00eb plot\u00eb dhe t\u00eb menj\u00ebhershme t\u00eb t\u00eb dh\u00ebnave n\u00eb rast se nj\u00eb nod d\u00ebshtonte. Ky qasje na lejon 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 gjitha tre replikat, duke pritur p\u00ebrgjigjen nga dy m\u00eb t\u00eb shpejtat. P\u00ebrgjigja e ngadalt\u00eb e tret\u00eb t\u00eb replikes n\u00eb k\u00ebt\u00eb rast p\u00ebrjashtohet. Noda me p\u00ebrgjigjen e ngadalt\u00eb mund t\u00eb ket\u00eb probleme serioze \u2014 ngadal\u00ebsime, grumbullim mbetjeje n\u00eb JVM, rikuperim t\u00eb memories direkte n\u00eb kernelin linux, d\u00ebshtim t\u00eb harduerit, \u00e7\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 nodave, dhe 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 panevojshme d\u00ebrgohet edhe para se t\u00eb \"shk\u00ebputet\". <\/p>\n<p>Nj\u00eb tjet\u00ebr p\u00ebrpar\u00ebsi e Cassandra \u00ebsht\u00eb Batchlog \u2014 mekanizmi q\u00eb garanton ose aplikimin e plot\u00eb, ose mosaplikimin e plot\u00eb t\u00eb paket\u00ebs s\u00eb ndryshimeve q\u00eb ju b\u00ebni. Kjo na lejon t\u00eb zgjidhim A n\u00eb ACID \u2014 atomiku nga kutia.<\/p>\n<p>M\u00eb af\u00ebr transaksioneve n\u00eb Cassandra \u00ebsht\u00eb e ashtuquajtura &#171;<noindex><a rel=\"nofollow\" href=\"https:\/\/docs.datastax.com\/en\/cql\/3.3\/cql\/cql_using\/useInsertLWT.html\">transaksione t\u00eb lehta<\/a><\/noindex>&#171;. Por nga \"transaksionet e v\u00ebrteta\" ACID, ato jan\u00eb t\u00eb larg\u00ebta: n\u00eb t\u00eb v\u00ebrtet\u00eb, kjo \u00ebsht\u00eb nj\u00eb mund\u00ebsi p\u00ebr t\u00eb b\u00ebr\u00eb <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 nga protokolli i r\u00ebnd\u00eb Paxos. Prandaj, shpejt\u00ebsia e k\u00ebtyre transaksioneve \u00ebsht\u00eb e vog\u00ebl. <\/p>\n<h2>\u00c7far\u00eb na mungoi n\u00eb Cassandra<\/h2>\n<p>\nPra, ne duhet t\u00eb realizojm\u00eb n\u00eb Cassandra transaksione t\u00eb v\u00ebrteta ACID. Me p\u00ebrdorim t\u00eb cilave mund t\u00eb realizonim leht\u00ebsisht dy mund\u00ebsi t\u00eb tjera t\u00eb favorshme t\u00eb DBMS klasik: indekse konsistente t\u00eb shpejta, q\u00eb do t\u00eb na lejonin t\u00eb b\u00ebnim k\u00ebrkesa t\u00eb dh\u00ebnash jo vet\u00ebm sipas \u00e7el\u00ebsit primar dhe nj\u00eb gjenerator t\u00eb zakonsh\u00ebm t\u00eb ID-ve monotone auto-increment.<\/p>\n<h4>C*One<\/h4>\n<p>\nK\u00ebshtu lindi nj\u00eb DBMS e re <b>C*One<\/b>, e b\u00ebr\u00eb nga tre lloje nodash server\u00ebsh:<\/p>\n<ul>\n<li>Marr\u00ebsit \u2014 server\u00eb (gati) standard\u00eb Cassandra, t\u00eb cil\u00ebt jan\u00eb p\u00ebrgjegj\u00ebs p\u00ebr ruajtjen e t\u00eb dh\u00ebnave n\u00eb disqet lokale. Nd\u00ebrsa rritet ngarkesa dhe sasia e t\u00eb dh\u00ebnave, numri i tyre mund t\u00eb shkall\u00ebzohet leht\u00ebsisht n\u00eb dhjet\u00ebra e qindra.<\/li>\n<li>Koordinator\u00ebt e transaksioneve - sigurojn\u00eb realizimin e transaksioneve. <\/li>\n<li>Klient\u00ebt - server\u00ebt e aplikacioneve q\u00eb realizojn\u00eb operacione biznesi dhe iniciatativat e transaksioneve. Mund t\u00eb ket\u00eb mij\u00ebra klient\u00eb t\u00eb till\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 \/>\nServer\u00ebt e t\u00eb gjitha llojeve jan\u00eb t\u00eb lidhur n\u00eb nj\u00eb klas\u00ebr t\u00eb p\u00ebrbashk\u00ebt, p\u00ebrdorin protokollin e brendsh\u00ebm t\u00eb mesazheve Cassandra p\u00ebr komunikim mes tyre dhe <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Gossip_protocol\">protokolli<\/a><\/noindex> p\u00ebr shk\u00ebmbimin e informacionit t\u00eb klasit. Me ndihm\u00ebn e Heartbeat, server\u00ebt m\u00ebsojn\u00eb p\u00ebr d\u00ebshtimet e nd\u00ebrsjella, mbajn\u00eb nj\u00eb skem\u00eb t\u00eb p\u00ebrbashk\u00ebt t\u00eb t\u00eb dh\u00ebnave - tabelat, struktur\u00ebn dhe replikimin e tyre; skem\u00ebn e ndarje, topologjin\u00eb e klasit, 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 drejtuesve standard\u00eb, p\u00ebrdoret modaliteti Fat Client. Ky nod nuk ruan t\u00eb dh\u00ebna, por mund t\u00eb funksionoj\u00eb si koordinator i realizimit t\u00eb k\u00ebrkesave, pra Klienti vet\u00eb kryen funksionin e koordinat\u00ebs s\u00eb k\u00ebrkesave t\u00eb tij: shqyrton replikat e magazin\u00ebs dhe zgjidh konfliktet. Ky modalitet jo vet\u00ebm q\u00eb \u00ebsht\u00eb m\u00eb i besuesh\u00ebm dhe m\u00eb i shpejt\u00eb se drejtuesi standard, q\u00eb k\u00ebrkon komunikim me nj\u00eb koordinator t\u00eb larg\u00ebt, por gjithashtu lejon menaxhimin e p\u00ebrcjelljes s\u00eb k\u00ebrkesave. P\u00ebrve\u00e7se p\u00ebr transaksionin e hapur n\u00eb klient, k\u00ebrkesat drejtohen n\u00eb magazina. N\u00ebse klienti ka hapur nj\u00eb transaksion, t\u00eb gjitha k\u00ebrkesat brenda transaksionit drejtohen 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>\nKoordinator - kjo \u00ebsht\u00eb ajo q\u00eb 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 aplikimit t\u00eb transaksioneve.<\/p>\n<p>P\u00ebr \u00e7do transaksion q\u00eb sh\u00ebrbehet, koordinator gjeneron nj\u00eb vul\u00eb t\u00eb p\u00ebrkohshme: \u00e7do e ardhshme \u00ebsht\u00eb m\u00eb e madhe se e m\u00ebparshmja. Duke qen\u00eb se n\u00eb sistemin Cassandra, sistemi i zgjidhjes s\u00eb konflikteve bazohen n\u00eb vulat e koh\u00ebs (nga dy regjistrime konfliktuale, e sakta konsiderohet ajo me vul\u00eb m\u00eb t\u00eb vonshme), konflikti gjithmon\u00eb do t\u00eb zgjidhet n\u00eb favor t\u00eb transaksionit t\u00eb ardhsh\u00ebm. K\u00ebshtu e realizuam <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\u00ebn e Lamportit<\/a><\/noindex> \u2013 nj\u00eb m\u00ebnyr\u00eb e lir\u00eb p\u00ebr zgjidhjen e konflikteve 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 - bllokimet pesimiste sipas \u00e7el\u00ebsit primar t\u00eb regjistrimit. N\u00eb fjal\u00eb t\u00eb tjera, brenda transaksionit, regjistrimi duhet fillimisht t\u00eb bllokohet, pastaj t\u00eb lexohet, modifikohet dhe t\u00eb ruhet. Vet\u00ebm pas nj\u00eb komitimi t\u00eb suksessh\u00ebm, regjistrimi mund t\u00eb p\u00ebrshtatet, n\u00eb m\u00ebnyr\u00eb q\u00eb transaksionet kompetuese t\u00eb mund ta p\u00ebrdorin at\u00eb.<\/p>\n<p>Zbatimi i nj\u00eb bllokimi t\u00eb till\u00eb \u00ebsht\u00eb i thjesht\u00eb n\u00eb nj\u00eb ambient jo t\u00eb shp\u00ebrndar\u00eb. N\u00eb nj\u00eb sistem t\u00eb shp\u00ebrndar\u00eb ka dy rrug\u00eb kryesore: ose t\u00eb realizohet nj\u00eb bllokim i shp\u00ebrndar\u00eb n\u00eb klaster, ose t\u00eb shp\u00ebrndahen transaksionet n\u00eb m\u00ebnyr\u00eb q\u00eb transaksionet q\u00eb p\u00ebrfshijn\u00eb nj\u00eb rekord t\u00eb caktuar gjithmon\u00eb t\u00eb sh\u00ebrbehen nga i nj\u00ebjti koordinatori.<\/p>\n<p>Pasi q\u00eb n\u00eb rastin ton\u00eb t\u00eb dh\u00ebnat jan\u00eb tashm\u00eb t\u00eb shp\u00ebrndara n\u00eb grupe lokal\u00ebsh transaksionesh n\u00eb SQL, u vendos q\u00eb t'u caktohet koordinator\u00ebve grupet e transaksioneve lokale: nj\u00eb koordinator kryen t\u00eb gjitha transaksionet me num\u00ebr token nga 0 n\u00eb 9, tjetri nga 10 n\u00eb 19, dhe k\u00ebshtu me radh\u00eb. Si rezultat, \u00e7do nj\u00ebsi e koordinatorit b\u00ebhet master e grupit t\u00eb transaksioneve. <\/p>\n<p>At\u00ebher\u00eb bllokimet mund t\u00eb zbatohen si nj\u00eb HashMap e thjesht\u00eb n\u00eb memorie t\u00eb koordinatorit.<\/p>\n<h2>D\u00ebshtimet e koordinator\u00ebve<\/h2>\n<p>\nPasi q\u00eb nj\u00eb koordinator sh\u00ebrben ekskluzivisht 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 rinisur transaksionin t\u00eb p\u00ebrfshihet n\u00eb afatin e p\u00ebrcaktuar. Q\u00ebllimi \u00ebsht\u00eb q\u00eb kjo t\u00eb jet\u00eb e shpejt\u00eb dhe e besueshme, prandaj ne p\u00ebrdor\u00ebm nj\u00eb protokoll qorrheti t\u00eb l\u00ebvizsh\u00ebm me kvorum:<\/p>\n<p>N\u00eb \u00e7do qend\u00ebr t\u00eb t\u00eb dh\u00ebnave vendosen t\u00eb pakt\u00ebn dy nyje koordinator\u00ebsh. Periodikisht, \u00e7do koordinator d\u00ebrgon nj\u00eb mesazh heartbeat te koordinator\u00ebt e tjer\u00eb dhe i informon ata p\u00ebr funksionimin e tij, si dhe p\u00ebr cilat mesazhe heartbeat nga koordinator\u00ebt e tjer\u00eb n\u00eb klaster ka marr\u00eb p\u00ebr her\u00eb t\u00eb fundit. <\/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 heartbeat, \u00e7do koordinator vendos vet\u00eb se cilat nyje t\u00eb klasterit jan\u00eb funksionale dhe cilat jo, duke u drejtuar nga parimi i kvorumit: n\u00ebse nyja X ka marr\u00eb nga shumica e nyjeve n\u00eb klaster informacionin p\u00ebr marrjen normale t\u00eb mesazheve nga nyja Y, at\u00ebher\u00eb Y \u00ebsht\u00eb funksionale. Dhe anasjelltas, sapo shumica t\u00eb njoftoj\u00eb p\u00ebr humbjen e mesazheve nga nyja Y, at\u00ebher\u00eb Y ka d\u00ebshtuar. \u00cbsht\u00eb interesante se n\u00ebse kvorumi i thot\u00eb nyj\u00ebs X se nuk po merr m\u00eb mesazhe prej saj, at\u00ebher\u00eb vet\u00eb nyja X do ta konsideroj\u00eb veten si t\u00eb d\u00ebshtuar.<\/p>\n<p>Mesazhet e heartbeat d\u00ebrgohet 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 gjat\u00ebzis\u00eb krahasuese t\u00eb ndalimeve q\u00eb shkaktohen nga mbledh\u00ebsi i plehrave. Kemi arritur t\u00eb kemi k\u00ebt\u00eb koh\u00eb reagimi duke p\u00ebrdorur mbledh\u00ebsin e plehrave G1, i cili lejon p\u00ebrcaktimin e nj\u00eb objekti p\u00ebr gjat\u00ebsi ndalimi t\u00eb GC. Megjithat\u00eb, ndonj\u00ebher\u00eb, mjaft rrall\u00eb, ndalimet e mbledh\u00ebsit kalojn\u00eb 50 ms, gj\u00eb q\u00eb mund t\u00eb \u00e7oj\u00eb n\u00eb zbulim t\u00eb rrem\u00eb t\u00eb d\u00ebshtimit. P\u00ebr t\u00eb shmangur k\u00ebt\u00eb, koordinatori nuk njofton p\u00ebr d\u00ebshtimin e nodit t\u00eb larg\u00ebt me humbjen e mesazhit t\u00eb par\u00eb heartbeat prej tij, vet\u00ebm n\u00ebse humbasin disa radhazi. K\u00ebshtu, kemi arritur t\u00eb zbulojm\u00eb d\u00ebshtimin e nodit koordinues brenda 200 ms. <\/p>\n<p>Por \u00ebsht\u00eb e pamjaftueshme t\u00eb kuptosh shpejt se cili nod ka pushuar s\u00eb funksionuari. Duhet t\u00eb b\u00ebjm\u00eb di\u00e7ka p\u00ebr k\u00ebt\u00eb. <\/p>\n<h2>Rezervimi<\/h2>\n<p>\nSkema klasike parashikon q\u00eb n\u00eb rast d\u00ebshtimi t\u00eb masterit t\u00eb fillohen zgjedhjet e reja me 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\"> algoritmet e 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\">unike<\/a><\/noindex> Megjithat\u00eb, k\u00ebtyre algoritmeve u njihen mir\u00eb problemet e konvergjenc\u00ebs n\u00eb koh\u00eb dhe gjat\u00ebsi t\u00eb procesit t\u00eb zgjedhjeve. K\u00ebto vonesa shtes\u00eb ia kemi arritur t\u00eb shmangim duke p\u00ebrdorur nj\u00eb skem\u00eb z\u00ebvend\u00ebsimi p\u00ebr koordinatoret n\u00eb nj\u00eb rrjet t\u00eb plot\u00eb:<\/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 \/>\nLe t\u00eb supozojm\u00eb se duam t\u00eb kryejm\u00eb nj\u00eb transaksion n\u00eb grupin 50. N\u00eb m\u00ebnyr\u00eb paraprake p\u00ebrcaktojm\u00eb skem\u00ebn e z\u00ebvend\u00ebsimit, duke p\u00ebrcaktuar se cilat nod do t\u00eb kryejn\u00eb transaksionet e grupit 50 n\u00eb rast d\u00ebshtimi t\u00eb koordinatoret kryesor. Q\u00ebllimi yn\u00eb \u00ebsht\u00eb t\u00eb ruajm\u00eb funksionalitetin e sistemit n\u00eb rastin e d\u00ebshtimit t\u00eb datacenter-it. Le t\u00eb p\u00ebrcaktojm\u00eb se rezevarti i par\u00eb do t\u00eb jet\u00eb nj\u00eb nod nga nj\u00eb datacenter tjet\u00ebr, dhe rezevarti i dyt\u00eb do t\u00eb jet\u00eb nj\u00eb nod nga nj\u00eb datacenter t\u00eb tret\u00eb. Kjo skem\u00eb zgjidhet nj\u00eb her\u00eb dhe nuk ndryshon derisa t\u00eb ndryshohet topologjia e klasterit, q\u00eb do t\u00eb thot\u00eb derisa t\u00eb hyjn\u00eb nodet e reja (gj\u00eb q\u00eb ndodh shum\u00eb rrall\u00eb). Rendi i zgjedhjes s\u00eb nj\u00eb masteri aktiv t\u00eb ri n\u00eb rast d\u00ebshtimi t\u00eb nj\u00eb t\u00eb vjetri do t\u00eb jet\u00eb gjithmon\u00eb ky: masteri aktiv do t\u00eb b\u00ebhet rezevarti i par\u00eb dhe n\u00ebse ai ka pushuar gjithashtu s\u00eb funksionuari - rezevarti i dyt\u00eb. <\/p>\n<p>Kjo skem\u00eb \u00ebsht\u00eb m\u00eb e besueshme se algoritmi universal, pasi 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 si e kuptojne klientet, cili nga mjeshtrit po punon tani? N\u00eb 50 ms \u00ebsht\u00eb e pamundur t\u00eb d\u00ebrgosh informacion n\u00eb mij\u00ebra klient\u00eb. Mund t\u00eb ndodhi q\u00eb nj\u00eb klient d\u00ebrgon nj\u00eb k\u00ebrkes\u00eb p\u00ebr hapjen e nj\u00eb transaksioni, pa e ditur ende se ky mjesht\u00ebr nuk po funksionon m\u00eb, dhe k\u00ebrkesa do t\u00eb ngec\u00eb n\u00eb nj\u00eb skadim kohor. P\u00ebr t\u00eb parandaluar k\u00ebt\u00eb, klient\u00ebt d\u00ebrgojn\u00eb spekulativisht k\u00ebrkes\u00ebn p\u00ebr hapjen e transaksionit p\u00ebrkat\u00ebs n\u00eb grupin e mjeshtrit dhe n\u00eb dy rezervat e tij, por do t\u00eb p\u00ebrgjigjet vet\u00ebm ai q\u00eb \u00ebsht\u00eb mjesht\u00ebr aktiv n\u00eb at\u00eb moment. T\u00eb gjith\u00eb komunikimet e m\u00ebtejshme brenda transaksionit do t'i kryej\u00eb klienti vet\u00ebm me mjeshtrin aktiv.<\/p>\n<p>Mjeshtrit rezerv\u00eb q\u00eb marrin k\u00ebrkesat p\u00ebr transaksione q\u00eb nuk jan\u00eb t\u00eb tyre i vendosin ato n\u00eb nj\u00eb radh\u00eb t\u00eb transaksioneve t\u00eb paralindura, ku ato ruhen p\u00ebr nj\u00eb koh\u00eb t\u00eb caktuar. N\u00ebse mjeshtri aktiv vdes, at\u00ebher\u00eb mjeshtri i ri merr k\u00ebrkesat p\u00ebr hapjen e transaksioneve nga radh\u00eb e tij dhe i p\u00ebrgjigjet klientit. N\u00ebse klienti tashm\u00eb ka hapur nj\u00eb transaksion me mjeshtrin e vjet\u00ebr, at\u00ebher\u00eb p\u00ebrgjigja 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 transaksioni<\/h2>\n<p>\nSupozoni se klienti i ka d\u00ebrguar koordinatorit nj\u00eb k\u00ebrkes\u00eb p\u00ebr hapjen e nj\u00eb transaksioni p\u00ebr nj\u00eb entitet t\u00eb caktuar me nj\u00eb \u00e7el\u00ebs primar t\u00eb caktuar. Koordinatori e bllokon k\u00ebt\u00eb entitet dhe e vendos n\u00eb tabel\u00ebn e bllokimeve n\u00eb memorjen e tij. N\u00ebse \u00ebsht\u00eb e nevojshme, koordinatori e lexon k\u00ebt\u00eb entitet nga depoja dhe ruan t\u00eb dh\u00ebnat e marra n\u00eb gjendjen e transaksionit n\u00eb memorjen e koordinatorit.<\/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 brenda transaksionit, ai d\u00ebrgon nj\u00eb k\u00ebrkes\u00eb p\u00ebr modifikimin e entitetit te koordinatori, dhe ai vendos t\u00eb dh\u00ebnat e reja n\u00eb tabel\u00ebn e gjendjes s\u00eb transaksioneve n\u00eb memorje. N\u00eb k\u00ebt\u00eb pik\u00eb, 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 tij t\u00eb modifikuara brenda nj\u00eb transaksioni aktiv, koordinatori vepron si m\u00eb posht\u00eb: <\/p>\n<ul>\n<li>n\u00ebse ID tashm\u00eb ekziston 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 mungojn\u00eb lexohen nga nodet e depozitave, bashkohen me ato q\u00eb tashm\u00eb ekzistojn\u00eb n\u00eb memorje, dhe rezultati i jepet klientit. <\/li>\n<\/ul>\n<p>\nK\u00ebshtu, klienti mund t\u00eb lexoj\u00eb ndryshimet e tij, nd\u00ebrsa klient\u00ebt e tjer\u00eb nuk i shohin k\u00ebto ndryshime, sepse ato ruhen vet\u00ebm n\u00eb memorjen e koordinatorit, n\u00eb nodet e Cassandra ato ende nuk kan\u00eb mb\u00ebrritur.<\/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 q\u00eb kishte n\u00eb kujtes\u00eb sh\u00ebrbimi, ruhet nga koordinatori n\u00eb logged batch, dhe n\u00eb form\u00ebn e logged batch d\u00ebrgohet n\u00eb magazinat Cassandra. Magazinat b\u00ebjn\u00eb gjith\u00e7ka t\u00eb nevojshme q\u00eb ky paket\u00eb t\u00eb aplikohet n\u00eb m\u00ebnyr\u00eb atomike (plotsisht), dhe kthejn\u00eb nj\u00eb p\u00ebrgjigje koordinatori, i cili \u00e7liron bllokimet dhe konfirmon suksesin e transaksionit p\u00ebr klientin.<\/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 t\u00eb \u00e7liroj\u00eb vet\u00ebm kujtes\u00ebn e z\u00ebn\u00eb nga gjendja e transaksionit.<\/p>\n<p>Si rezultat i p\u00ebrmir\u00ebsimeve t\u00eb p\u00ebrmendura m\u00eb lart, ne realizuam parimet ACID:<\/p>\n<ul>\n<li><b>Atomizmi<\/b>. Kjo \u00ebsht\u00eb nj\u00eb garanci q\u00eb asnj\u00eb transaksion nuk do t\u00eb regjistrohet pjes\u00ebrisht n\u00eb sistem, do t\u00eb executohen t\u00eb gjitha n\u00ebn-operacionet e tij, ose nuk do t\u00eb ekzekutohet asnj\u00ebra. Ky princip respektohet nga logged batch n\u00eb Cassandra.<\/li>\n<li><b>Konsistenca<\/b>. \u00c7do transaksion i suksessh\u00ebm p\u00ebr definicion regjistron vet\u00ebm rezultate t\u00eb lejuara. N\u00ebse pas hapjes s\u00eb transaksionit dhe kryerjes s\u00eb disa operacioneve, zbulohet se rezultati \u00ebsht\u00eb i papranuesh\u00ebm, kryhet nj\u00eb rikthim.<\/li>\n<li><b>Izolimi<\/b>. Gjat\u00eb ekzekutimit t\u00eb nj\u00eb transaksioni, transaksionet paralele nuk duhet t\u00eb ndikojn\u00eb n\u00eb rezultatin e tij. Transaksionet konkurruese jan\u00eb t\u00eb izoluara p\u00ebrmes bllokimeve pesimiste n\u00eb koordinatore. P\u00ebr leximet jasht\u00eb transaksionit respektohet parimi i izolimit n\u00eb nivelin Read Committed.<\/li>\n<li><b>Q\u00ebndrueshm\u00ebria<\/b>. Pavar\u00ebsisht nga problemet n\u00eb nivelet e poshtme \u2014 nd\u00ebrprerja e energjis\u00eb, defekti n\u00eb pajisje \u2014 ndryshimet e b\u00ebra nga nj\u00eb transaksion i p\u00ebrfunduar me sukses duhet t\u00eb mbahen t\u00eb ruajtura pas rim\u00ebk\u00ebmbjes 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), pronari dhe data e ndryshimit. Duhet t\u00eb b\u00ebjm\u00eb nj\u00eb k\u00ebrkes\u00eb shum\u00eb t\u00eb thjesht\u00eb \u2014 t\u00eb selektojm\u00eb t\u00eb dh\u00ebnat sipas pronarit me dat\u00ebn e ndryshimit \"n\u00eb 24 or\u00ebt e fundit\". <\/p>\n<pre><code>SELECT *\nWHERE owner=?\nAND modified&gt;?<\/code><\/pre>\n<p>\nP\u00ebr ta b\u00ebr\u00eb nj\u00eb k\u00ebrkes\u00eb t\u00eb till\u00eb t\u00eb operoj\u00eb shpejt, n\u00eb nj\u00eb DBMS klasik SQL ne duhet t\u00eb nd\u00ebrtojm\u00eb nj\u00eb indeks mbi kolonat (owner, modified). K\u00ebt\u00eb do ta b\u00ebjm\u00eb mjaft leht\u00ebsisht, tani q\u00eb kemi garantuar ACID!<\/p>\n<h2>Indekset n\u00eb C*One<\/h2>\n<p>\nEkziston tabela origjinale 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 origjinales. \u00c7el\u00ebsi p\u00ebrputhet me shprehjen indeksuese, pasi p\u00ebrfshin gjithashtu \u00e7el\u00ebsin primar t\u00eb regjistrimit nga tabela origjinale:<\/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 tash n\u00eb \u00abpronarin e 24 or\u00ebve t\u00eb fundit\u00bb mund t\u00eb riktheni si nj\u00eb select nga nj\u00eb tabel\u00eb 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 t\u00eb tabel\u00ebs fillestare photos dhe indeksit i1 mbahet automatikisht nga koordinatori. Bazuar vet\u00ebm n\u00eb skem\u00ebn e t\u00eb dh\u00ebnave, kur merrni ndryshime, koordinatori gjeneron dhe ruan ndryshimin jo vet\u00ebm t\u00eb tabel\u00ebs kryesore, por edhe ndryshimet e kopjeve. Asnj\u00eb veprim shtes\u00eb me tabel\u00ebn e indeksit nuk kryhet, logjet nuk lexohen, bllokimet nuk p\u00ebrdoren. Kjo do t\u00eb thot\u00eb q\u00eb shtimi i indekseve konsumon pothuajse asnj\u00eb burim dhe ka pak ndikim n\u00eb shpejt\u00ebsin\u00eb e aplikimit t\u00eb modifikimeve.<\/p>\n<p>Me ACID arrit\u00ebm t\u00eb implementojm\u00eb indekse \u00absi n\u00eb SQL\u00bb. Ato kan\u00eb konsistenc\u00eb, mund t\u00eb shkall\u00ebzohen, punojn\u00eb shpejt, mund t\u00eb jen\u00eb t\u00eb p\u00ebrb\u00ebra dhe t\u00eb integruara n\u00eb gjuh\u00ebn e pyetjeve CQL. P\u00ebr mb\u00ebshtetje t\u00eb indekseve nuk \u00ebsht\u00eb e nevojshme t\u00eb b\u00ebni ndryshime n\u00eb kodin aplikativ. Gjith\u00e7ka \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 t\u00eb tabel\u00ebs fillestare t\u00eb transaksioneve.<\/p>\n<h2>\u00c7far\u00eb rezultati kemi arritur<\/h2>\n<p>\nNe zhvilluam C*One tre vjet m\u00eb par\u00eb dhe e vendos\u00ebm n\u00eb p\u00ebrdorim industrial. <\/p>\n<p>\u00c7far\u00eb e kemi arritur n\u00eb fund? Le t\u00eb e vler\u00ebsojm\u00eb k\u00ebt\u00eb p\u00ebrmes sistemit 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 nj\u00eb rrjet social. B\u00ebhet fjal\u00eb jo p\u00ebr trupat e fotografive, por p\u00ebr t\u00eb gjitha metainformatat. Tani n\u00eb \u00abOdnoklassniki\u00bb ka rreth 20 miliard\u00eb t\u00eb tilla regjistrimesh, sistemi p\u00ebrpunon 80,000 pyetje leximi n\u00eb sekond\u00eb, deri n\u00eb 8,000 ACID-transaksione n\u00eb sekond\u00eb, t\u00eb lidhura me modifikimin e t\u00eb dh\u00ebnave. <\/p>\n<p>Kur p\u00ebrdor\u00ebm SQL me replication factor = 1 (por n\u00eb RAID 10), metainformatat e fotografive ruheshin n\u00eb nj\u00eb klaster me 32 makina me Microsoft SQL Server (plus 11 rezerv\u00eb). Gjithashtu, ishin caktuar 10 servera p\u00ebr ruajtjen e backup-eve. N\u00eb total 50 makina t\u00eb kushtueshme. Sidoqoft\u00eb, sistemi punonte me ngarkes\u00eb nominale, pa rezerv\u00eb.<\/p>\n<p>Pas migrimit n\u00eb sistemin e ri, ne mor\u00ebm replication factor = 3 \u2014 nj\u00eb kopje n\u00eb \u00e7do data-center. Sistemi p\u00ebrb\u00ebhet nga 63 nodet e ruajtjes Cassandra dhe 6 makina koordinatores, gjithsej 69 servera. Por k\u00ebto makina jan\u00eb ndjesh\u00ebm m\u00eb t\u00eb lira, shuma totale e kostos \u00ebsht\u00eb rreth 30% e kostos s\u00eb sistemit n\u00eb SQL. Nd\u00ebrkoh\u00eb, ngarkesa q\u00ebndron n\u00eb 30%.<\/p>\n<p>Me implementimin e C*One, vonesat jan\u00eb zvog\u00ebluar: operacioni i shkruajtes n\u00eb SQL z\u00eb rreth 4.5 ms. N\u00eb C*One \u2014 rreth 1.6 ms. Koha mesatare e transaksionit \u00ebsht\u00eb m\u00eb pak se 40 ms, komiti ekzekutohet p\u00ebr 2 ms, koha e leximit dhe shkruajtes \u00ebsht\u00eb mesatarisht 2 ms. Percentili i 99-t\u00eb \u00ebsht\u00eb vet\u00ebm 3-3.1 ms, numri i koh\u00eb-mandeve \u00ebsht\u00eb zvog\u00ebluar 100 her\u00eb \u2014 fal\u00eb p\u00ebrdorimit t\u00eb gjer\u00eb t\u00eb spekulimeve. <\/p>\n<p>Derisa, tani, pjesa m\u00eb e madhe e nyjeve t\u00eb SQL Server \u00ebsht\u00eb hequr nga p\u00ebrdorimi, 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 cloud-in ton\u00eb. <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/company\/odnoklassniki\/blog\/346868\/\">one-cloud<\/a><\/noindex>, e cila ka lejuar q\u00eb t\u00eb shpejtoj\u00eb nd\u00ebrtimin e klaster\u00ebve t\u00eb rinj, t\u00eb thjesht\u00ebsoj\u00eb konfigurimin dhe t\u00eb automatizoj\u00eb operimin. Pa kodin burimor, kjo do t\u00eb kishte qen\u00eb ndjesh\u00ebm m\u00eb e nd\u00ebrlikuar dhe m\u00eb e \u00e7uditshme. <\/p>\n<p>Tani jemi duke punuar p\u00ebr t\u00eb transferuar magazinat e tjera n\u00eb cloud \u2014 por kjo \u00ebsht\u00eb nj\u00eb histori krejt ndryshe.<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.2.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.\" \/>\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.2.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.\" \/>\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":"Derisa disa koh\u00eb m\u00eb par\u00eb, n\u00eb Odnoklassniki kishte rreth 50 TB t\u00eb dh\u00ebnash q\u00eb ishin duke u p\u00ebrpunuar.","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.","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}]}}