{"id":89872,"date":"2020-07-27T01:42:19","date_gmt":"2020-07-26T23:42:19","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/raspredelyonnye-subd-dlya-enterprajza"},"modified":"2020-07-27T01:42:19","modified_gmt":"2020-07-26T23:42:19","slug":"raspredelyonnye-subd-dlya-enterprajza","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sk\/blog\/administrirovanie\/raspredelyonnye-subd-dlya-enterprajza","title":{"rendered":"Distribuovan\u00e9 DBMS pre podniky","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>CAP-te\u00f3ria je z\u00e1kladn\u00fdm kame\u0148om te\u00f3rie distribuovan\u00fdch syst\u00e9mov. Samozrejme, diskusie okolo nej neut\u00edchaj\u00fa: defin\u00edcie v nej nie s\u00fa kanonick\u00e9 a presn\u00fd d\u00f4kaz neexistuje\u2026 Napriek tomu, pevne stojac na poz\u00edci\u00e1ch zdrav\u00e9ho rozumu&trade;, intuit\u00edvne ch\u00e1peme, \u017ee te\u00f3ria je spr\u00e1vna.<\/p>\n<p><img decoding=\"async\" alt=\"Distribuovan\u00e9 DBMS pre podniky\" src=\"\/wp-content\/uploads\/2020\/07\/35c8b29bb024cbf383d78caa1af2c525.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nJedna vec v\u0161ak nie je zrejm\u00e1, a to v\u00fdznam p\u00edsmena \u201eP\u201c. Ke\u010f sa klaster rozdel\u00ed, rozhoduje sa, \u010di neodpoveda\u0165, k\u00fdm nebude dosiahnut\u00fd kv\u00f3rum, alebo poskytn\u00fa\u0165 dostupn\u00e9 d\u00e1ta. V z\u00e1vislosti od v\u00fdsledkov tohto v\u00fdberu sa syst\u00e9m klasifikuje bu\u010f ako CP, alebo ako AP. Cassandra, napr\u00edklad, sa m\u00f4\u017ee spr\u00e1va\u0165 r\u00f4zne, a to nielen na z\u00e1klade nastaven\u00ed klastrov, ale aj na z\u00e1klade parametrov ka\u017ed\u00e9ho konkr\u00e9tneho dopytu. Ale ak syst\u00e9m nie je \u201eP\u201c a rozdelil sa, \u010do potom?<\/p>\n<p>Odpove\u010f na t\u00fato ot\u00e1zku je trochu prekvapuj\u00faca: CA-klaster sa nem\u00f4\u017ee rozdeli\u0165.<br \/>\n\u010co je to za klaster, ktor\u00fd sa nem\u00f4\u017ee rozdeli\u0165?<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\nNeodmyslite\u013en\u00fdm atrib\u00fatom tak\u00e9ho klastera je spolo\u010dn\u00fd syst\u00e9m ukladania d\u00e1t. V drvivej v\u00e4\u010d\u0161ine pr\u00edpadov to znamen\u00e1 pripojenie cez SAN, \u010do obmedzuje pou\u017eitie CA-rychl\u00fdch rie\u0161en\u00ed len na ve\u013ek\u00e9 podniky, ktor\u00e9 si m\u00f4\u017eu dovoli\u0165 SAN-infrastrukt\u00faru. Aby nieko\u013eko <a class=\"wpil_keyword_link\" href=\"https:\/\/prohoster.info\/sk\/server\/\"   title=\"serverov\" data-wpil-keyword-link=\"linked\"  data-wpil-monitor-id=\"1512\">serverov<\/a> mohlo pracova\u0165 s t\u00fdmi ist\u00fdmi d\u00e1tami, potrebn\u00fd je klastrov\u00fd s\u00faborov\u00fd syst\u00e9m. Tak\u00e9to s\u00faborov\u00e9 syst\u00e9my s\u00fa dostupn\u00e9 v portf\u00f3li\u00e1ch HPE (CFS), Veritas (VxCFS) a IBM (GPFS). <\/p>\n<h4>Oracle RAC<\/h4>\n<p>\nMo\u017enos\u0165 Real Application Cluster sa prv\u00fdkr\u00e1t objavila v roku 2001 v release Oracle 9i. V takom klasteri pracuje nieko\u013eko in\u0161tanci\u00ed <a class=\"wpil_keyword_link\" href=\"https:\/\/prohoster.info\/sk\/server\/dts-los-angeles\/\"   title=\"servera\" data-wpil-keyword-link=\"linked\"  data-wpil-monitor-id=\"3642\">servera<\/a> s jednou a tou istou datab\u00e1zou.<br \/>\nOracle m\u00f4\u017ee pracova\u0165 ako so klastrov\u00fdm s\u00faborov\u00fdm syst\u00e9mom, tak aj s vlastn\u00fdm rie\u0161en\u00edm \u2013 ASM, Automatic Storage Management.<\/p>\n<p>Ka\u017ed\u00e1 in\u0161tancia vedie svoj \u017eurn\u00e1l. Transakcia sa vykon\u00e1va a zaznamen\u00e1va jednou in\u0161tanciou. V pr\u00edpade zlyhania in\u0161tancie si jeden z pre\u017e\u00edvaj\u00facich uzlov klastera (in\u0161tanci\u00ed) pre\u010d\u00edta jeho \u017eurn\u00e1l a obnov\u00ed straten\u00e9 d\u00e1ta \u2013 t\u00fdmto sa zabezpe\u010duje dostupnos\u0165.<\/p>\n<p>V\u0161etky in\u0161tancie udr\u017eiavaj\u00fa svoj vlastn\u00fd cache a tie ist\u00e9 str\u00e1nky (bloky) m\u00f4\u017eu by\u0165 s\u00fa\u010dasne v cache viacer\u00fdch in\u0161tanci\u00ed. Viac toho, ak nejak\u00e1 str\u00e1nka je potrebn\u00e1 jednej in\u0161tancii a je v cache inej in\u0161tancie, m\u00f4\u017ee ju z\u00edska\u0165 od \u201esuseda\u201c pomocou mechanizmu cache fusion namiesto \u010d\u00edtania z disku.<\/p>\n<p><img decoding=\"async\" alt=\"Distribuovan\u00e9 DBMS pre podniky\" src=\"\/wp-content\/uploads\/2020\/07\/917cb1bfcc2c47ccf0dbb2f1e34ac921.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n\u010co sa v\u0161ak stane, ak bude jednej z in\u0161tanci\u00ed potrebn\u00e9 zmeni\u0165 \u00fadaje?<\/p>\n<p>\u0160pecifickos\u0165 Oracle spo\u010d\u00edva v tom, \u017ee nem\u00e1 vyhraden\u00fa slu\u017ebu blokovania: ak chce server zablokova\u0165 riadok, z\u00e1znam o blokovan\u00ed sa umiestni priamo na t\u00fa str\u00e1nku pam\u00e4te, kde sa nach\u00e1dza blokovan\u00fd riadok. V\u010faka tomuto pr\u00edstupu je Oracle l\u00eddrom v produktivite medzi monolitick\u00fdmi datab\u00e1zami: slu\u017eba blokovania sa nikdy nest\u00e1va \u00fazkym hrdlom. No v klastrov\u00e9j konfigur\u00e1cii m\u00f4\u017ee tak\u00e1to architekt\u00fara vies\u0165 k intenz\u00edvnej sietovej komunik\u00e1cii a vz\u00e1jomn\u00e9mu blokovaniu.<\/p>\n<p>Akon\u00e1hle je z\u00e1znam zablokovan\u00fd, in\u0161tancia upozorn\u00ed v\u0161etky ostatn\u00e9 in\u0161tancie, \u017ee str\u00e1nka, na ktorej sa nach\u00e1dza tento z\u00e1znam, bola obsaden\u00e1 v monopolnom re\u017eime. Ak bude inej in\u0161tancii potrebn\u00e9 zmeni\u0165 z\u00e1znam na tej istej str\u00e1nke, mus\u00ed \u010daka\u0165, k\u00fdm nebud\u00fa zmeny na str\u00e1nke potvrden\u00e9, t. j. inform\u00e1cia o zmene nebude zap\u00edsan\u00e1 do denn\u00edka na disku (medzit\u00fdm m\u00f4\u017ee transakcia pokra\u010dova\u0165). M\u00f4\u017ee sa sta\u0165 aj to, \u017ee str\u00e1nku bude postupne meni\u0165 nieko\u013eko in\u0161tanci\u00ed, a potom pri z\u00e1pise str\u00e1nky na disk bude potrebn\u00e9 zisti\u0165, u koho sa nach\u00e1dza aktu\u00e1lna verzia tejto str\u00e1nky.<\/p>\n<p>N\u00e1hodn\u00e9 aktualiz\u00e1cie t\u00fdch ist\u00fdch str\u00e1nok cez r\u00f4zne uzly RAC ved\u00fa k dramatick\u00e9mu poklesu v\u00fdkonu datab\u00e1zy \u2013 a\u017e do takej miery, \u017ee v\u00fdkon klastrov m\u00f4\u017ee by\u0165 ni\u017e\u0161\u00ed, ne\u017e v\u00fdkon jedin\u00e9ho in\u0161tancie.<\/p>\n<p>Spr\u00e1vne pou\u017e\u00edvanie Oracle RAC spo\u010d\u00edva vo fyzickom rozdelen\u00ed \u00fadajov (napr\u00edklad pomocou mechanizmu sekciovan\u00fdch tabuliek) a pr\u00edstupu k jednotliv\u00fdm sad\u00e1m sekci\u00ed cez vyhraden\u00fd uzol. Hlavn\u00fdm \u00fa\u010delom RAC sa stalo nie horizont\u00e1lne \u0161k\u00e1lovanie, ale zabezpe\u010denie odolnosti vo\u010di poruch\u00e1m.<\/p>\n<p>Ak uzol prestane odpoveda\u0165 na heartbeat, uzol, ktor\u00fd to prv\u00fd zist\u00ed, spust\u00ed proced\u00faru hlasovania na disku. Ak sa ani tu ch\u00fdbaj\u00faci uzol neozna\u010d\u00ed, jeden z uzlov preber\u00e1 povinnosti na obnovenie \u00fadajov:<\/p>\n<ul>\n<li>\u201ezmraz\u00ed\u201c v\u0161etky str\u00e1nky, ktor\u00e9 sa nach\u00e1dzali v cache ch\u00fdbaj\u00faceho uzla;<\/li>\n<li>\u010d\u00edta denn\u00edky (redo) ch\u00fdbaj\u00faceho uzla a op\u00e4tovne aplikuje zmeny, ktor\u00e9 s\u00fa zaznamenan\u00e9 v t\u00fdchto denn\u00edkoch, pri\u010dom kontroluje, \u010di nie s\u00fa u in\u00fdch uzlov nov\u0161ie verzie menen\u00fdch str\u00e1nok;<\/li>\n<li>vracia nedokon\u010den\u00e9 transakcie.<\/li>\n<\/ul>\n<p>\nAby sa zjednodu\u0161ilo prep\u00ednanie medzi uzlami, v Oracle existuje pojem slu\u017eby \u2013 virtu\u00e1lny in\u0161tancie. In\u0161tancia m\u00f4\u017ee obsluhova\u0165 nieko\u013eko slu\u017eieb a slu\u017eba sa m\u00f4\u017ee pres\u00fava\u0165 medzi uzlami. In\u0161tancia aplik\u00e1cie, ktor\u00e1 obsluhuje ur\u010dit\u00fa \u010das\u0165 datab\u00e1zy (napr\u00edklad skupinu z\u00e1kazn\u00edkov), pracuje s jednou slu\u017ebou, a slu\u017eba, ktor\u00e1 zodpoved\u00e1 za t\u00fato \u010das\u0165 datab\u00e1zy, sa pri v\u00fdpadku uzla pres\u00fava na in\u00fd uzol.<\/p>\n<h4>IBM Pure Data Systems for Transactions<\/h4>\n<p>\nKlastrov\u00e9 rie\u0161enie pre DBMS sa objavilo v portf\u00f3liu Modr\u00e9ho Giganta v roku 2009. Ideologicky je pokra\u010dovan\u00edm klastrovej architekt\u00fary Parallel Sysplex, postavenej na \"be\u017enom\" hardv\u00e9ri. V roku 2009 bol uveden\u00fd produkt DB2 pureScale, ktor\u00fd predstavuje s\u00fapravu softv\u00e9ru, a v roku 2012 IBM pon\u00faka programovo-hardware bal\u00edk (appliance) nazvan\u00fd Pure Data Systems for Transactions. Neda sa zamie\u0148a\u0165 s Pure Data Systems for Analytics, ktor\u00e1 nie je ni\u010d in\u00e9 ako premenovan\u00fd Netezza.<\/p>\n<p>Architekt\u00fara pureScale na prv\u00fd poh\u013ead pripom\u00edna Oracle RAC: rovnako s\u00fa nieko\u013eko uzlov pripojen\u00fdch k spolo\u010dn\u00e9mu syst\u00e9mu ukladania d\u00e1t a na ka\u017edom uzle be\u017e\u00ed svoj vlastn\u00fd in\u0161tancia DBMS so svojimi pam\u00e4\u0165ov\u00fdmi oblas\u0165ami a \u017eurn\u00e1lmi transakci\u00ed. Ale na rozdiel od Oracle m\u00e1 DB2 vyhraden\u00fa slu\u017ebu z\u00e1mkov, reprezentovan\u00fa s\u00faborom procesov db2LLM*. V klastrovej konfigur\u00e1cii je t\u00e1to slu\u017eba presunut\u00e1 na samostatn\u00fd uzol, ktor\u00fd v Parallel Sysplex naz\u00fdvame coupling facility (CF), a v Pure Data \u2013 PowerHA.<\/p>\n<p>PowerHA poskytuje nasleduj\u00face slu\u017eby:<\/p>\n<ul>\n<li>mana\u017e\u00e9r z\u00e1mkov;<\/li>\n<li>glob\u00e1lny vyrovn\u00e1vac\u00ed pam\u00e4\u0165;<\/li>\n<li>oblas\u0165 medzi procesov komunik\u00e1ci\u00ed.<\/li>\n<\/ul>\n<p>\nNa prenos d\u00e1t medzi PowerHA a uzlami datab\u00e1zy a sp\u00e4\u0165 sa pou\u017e\u00edva vzdialen\u00fd pr\u00edstup k pam\u00e4ti, preto mus\u00ed klastrov\u00e9 prepojenie podporova\u0165 protokol RDMA. PureScale m\u00f4\u017ee pou\u017e\u00edva\u0165 ako Infiniband, tak aj RDMA over Ethernet.<\/p>\n<p><img decoding=\"async\" alt=\"Distribuovan\u00e9 DBMS pre podniky\" src=\"\/wp-content\/uploads\/2020\/07\/7757acd68445dac4a9f378d5813e663f.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAk uzlu potrebn\u00e1 str\u00e1nka nie je v cache, uzol \u017eiada str\u00e1nku z glob\u00e1lnej cache, a iba v pr\u00edpade, \u017ee ani tam nie je, si ju pre\u010d\u00edta z disku. Na rozdiel od Oracle, po\u017eiadavok ide iba do PowerHA, a nie na susedn\u00e9 uzly.<\/p>\n<p>Ak sa in\u0161tancia chyst\u00e1 zmeni\u0165 riadok, zablokuje ho v exkluz\u00edvnom re\u017eime a str\u00e1nku, na ktorej sa riadok nach\u00e1dza, v zdie\u013eanom re\u017eime. V\u0161etky blok\u00e1cie s\u00fa registrovan\u00e9 v glob\u00e1lnom spr\u00e1vci blok\u00e1ci\u00ed. Po ukon\u010den\u00ed transakcie uzol po\u0161le spr\u00e1vu spr\u00e1vcu blok\u00e1ci\u00ed, ktor\u00fd skop\u00edruje zmenen\u00fa str\u00e1nku do glob\u00e1lneho cache, zru\u0161\u00ed blok\u00e1cie a invaliduje zmenen\u00fa str\u00e1nku v cache in\u00fdch uzlov.<\/p>\n<p>Ak je str\u00e1nka, na ktorej sa nach\u00e1dza menen\u00fd riadok, u\u017e zablokovan\u00e1, spr\u00e1vca blok\u00e1ci\u00ed pre\u010d\u00edta zmenen\u00fa str\u00e1nku z pam\u00e4te uzla, ktor\u00fd vykonal zmeny, zru\u0161\u00ed blok\u00e1ciu, invaliduje zmenen\u00fa str\u00e1nku v cache in\u00fdch uzlov a vyd\u00e1 blok\u00e1ciu str\u00e1nky uzlu, ktor\u00fd ju po\u017eiadal.<\/p>\n<p>Pr\u00edpadne zmenen\u00e9 str\u00e1nky m\u00f4\u017eu by\u0165 zap\u00edsan\u00e9 na disk bu\u010f z be\u017en\u00e9ho uzla, alebo pomocou PowerHA (castout).<\/p>\n<p>Pri zlyhan\u00ed jedn\u00e9ho z uzlov pureScale je obnova obmedzen\u00e1 len na tie transakcie, ktor\u00e9 v \u010dase zlyhania e\u0161te neboli dokon\u010den\u00e9: str\u00e1nky, ktor\u00e9 tento uzol zmenil v dokon\u010den\u00fdch transakci\u00e1ch, s\u00fa v glob\u00e1lnom cache na PowerHA. Uzol sa re\u0161tartuje s obmedzenou konfigur\u00e1ciou na jednom zo serverov klastre, vracia nezakompletizovan\u00e9 transakcie a uvo\u013e\u0148uje blok\u00e1cie.<\/p>\n<p>PowerHA funguje na dvoch serveroch a hlavn\u00fd uzol synchronne replik\u00e1toruje svoj stav. Pri zlyhan\u00ed hlavn\u00e9ho uzla PowerHA klaster pokra\u010duje v pr\u00e1ci s rezervn\u00fdm uzlom.<br \/>\nSamozrejme, ak sa na sadu d\u00e1t pristupuje cez jeden uzol, celkov\u00fd v\u00fdkon klastre bude vy\u0161\u0161\u00ed. PureScale dokonca m\u00f4\u017ee zisti\u0165, \u017ee ur\u010dit\u00e1 oblas\u0165 d\u00e1t je spracov\u00e1van\u00e1 jedn\u00fdm uzlom, a v\u0161etky blok\u00e1cie s\u00favisiace s touto oblas\u0165ou bud\u00fa spracovan\u00e9 uzlom lok\u00e1lne bez komunik\u00e1cie s PowerHA. Ale ak sa aplik\u00e1cia pok\u00fasi prist\u00fapi\u0165 k t\u00fdmto d\u00e1tam cez in\u00fd uzol, centralizovan\u00e9 spracovanie blok\u00e1ci\u00ed sa obnov\u00ed.<\/p>\n<p>Intern\u00e9 testy IBM na z\u00e1\u0165a\u017ei pozost\u00e1vaj\u00facej z 90% \u010d\u00edtania a 10% z\u00e1pisu, \u010do ve\u013emi pripom\u00edna re\u00e1lnu priemyseln\u00fa z\u00e1\u0165a\u017e, ukazuj\u00fa takmer line\u00e1rne \u0161k\u00e1lovanie a\u017e do 128 uzlov. Podmienky testovania, \u017eia\u013e, nie s\u00fa zverejnen\u00e9.<\/p>\n<h4>HPE NonStop SQL<\/h4>\n<p>\nVo vlastn\u00ed high-availability platformu m\u00e1 vo svojom portf\u00f3liu aj Hewlett-Packard Enterprise. Ide o platformu NonStop, ktor\u00e1 bola uveden\u00e1 na trh v roku 1976 firmou Tandem Computers. V roku 1997 bola t\u00e1to spolo\u010dnos\u0165 prevzat\u00e1 firmou Compaq, ktor\u00e1 sa v roku 2002 zl\u00fa\u010dila s Hewlett-Packard.<\/p>\n<p>NonStop sa pou\u017e\u00edva na budovanie kritick\u00fdch aplik\u00e1ci\u00ed \u2013 napr\u00edklad HLR alebo spracovanie bankov\u00fdch kariet. Platforma sa dod\u00e1va ako hardv\u00e9rovo-softv\u00e9rov\u00fd komplex (appliance), ktor\u00fd zah\u0155\u0148a v\u00fdpo\u010dtov\u00e9 uzly, syst\u00e9my ukladania d\u00e1t a komunika\u010dn\u00e9 zariadenia. Sie\u0165 ServerNet (v modern\u00fdch syst\u00e9moch \u2013 Infiniband) sl\u00fa\u017ei na v\u00fdmenu medzi uzlami aj na pr\u00edstup k syst\u00e9mu ukladania d\u00e1t.<\/p>\n<p>Vo vn\u00fatorn\u00fdch verzi\u00e1ch syst\u00e9mu sa pou\u017e\u00edvali propriet\u00e1rne procesory, ktor\u00e9 boli synchronizovan\u00e9 navz\u00e1jom: v\u0161etky oper\u00e1cie sa vykon\u00e1vali synchronne viacer\u00fdmi procesormi a ke\u010f sa jeden z procesorov pokazil, vypol sa, zatia\u013e \u010do druh\u00fd pokra\u010doval v pr\u00e1ci. Nesk\u00f4r syst\u00e9m pre\u0161iel na be\u017en\u00e9 procesory (najprv MIPS, potom Itanium a napokon x86) a na synchroniz\u00e1ciu sa za\u010dali pou\u017e\u00edva\u0165 in\u00e9 mechanizmy:<\/p>\n<ul>\n<li>spr\u00e1vy: ka\u017ed\u00fd syst\u00e9mov\u00fd proces m\u00e1 svojho duplik\u00e1tu \u2013 \u201etiene\u201c, ktor\u00e9mu akt\u00edvny proces periodicky posiela spr\u00e1vy o svojom stave; pri zlyhan\u00ed hlavn\u00e9ho procesu za\u010dne tienenie pracova\u0165 od bodu ur\u010den\u00e9ho poslednou spr\u00e1vou;<\/li>\n<li>hlasovanie: syst\u00e9m ukladania d\u00e1t m\u00e1 \u0161peci\u00e1lnu hardv\u00e9rov\u00fa s\u00fa\u010diastku, ktor\u00e1 prij\u00edma nieko\u013eko identick\u00fdch po\u017eiadaviek a vykon\u00e1va ich len v pr\u00edpade, ak sa po\u017eiadavky zhoduj\u00fa; namiesto fyzickej synchroniz\u00e1cie pracuj\u00fa procesory asynchr\u00f3nne a v\u00fdsledky ich pr\u00e1ce sa porovn\u00e1vaj\u00fa len v okamihoch vstupu\/v\u00fdstupu.<\/li>\n<\/ul>\n<p>\nOd roku 1987 na platforme NonStop funguje rela\u010dn\u00e1 DBMS \u2013 najprv SQL\/MP, nesk\u00f4r SQL\/MX.<\/p>\n<p>Cel\u00e1 datab\u00e1za sa del\u00ed na \u010dasti, pri\u010dom ka\u017ed\u00fa \u010das\u0165 spravuje svoj proces Data Access Manager (DAM). Ten zabezpe\u010duje z\u00e1pis d\u00e1t, cacheovanie a mechanizmus z\u00e1mkov. Spracovan\u00edm d\u00e1t sa zaoberaj\u00fa procesy vykon\u00e1vatelia (Executor Server Process), ktor\u00e9 funguj\u00fa na t\u00fdch ist\u00fdch uzloch ako pr\u00edslu\u0161n\u00ed mana\u017e\u00e9ri d\u00e1t. Pl\u00e1nova\u010d SQL\/MX rozde\u013euje \u00falohy medzi vykon\u00e1vate\u013eov a sp\u00e1ja v\u00fdsledky. Pri nutnosti vykona\u0165 zos\u00faladen\u00e9 zmeny sa pou\u017e\u00edva protokol s dvojf\u00e1zovou z\u00e1v\u00e4znos\u0165ou zabezpe\u010den\u00fd kni\u017enicou TMF (Transaction Management Facility).<\/p>\n<p><img decoding=\"async\" alt=\"Distribuovan\u00e9 DBMS pre podniky\" src=\"\/wp-content\/uploads\/2020\/07\/00e9473dd95a78c409dd5283d299fe96.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nNonStop SQL dok\u00e1\u017ee prioritizova\u0165 procesy tak, aby dlh\u00e9 analytick\u00e9 dotazy nebr\u00e1nili vykonaniu transakci\u00ed. Jej ur\u010den\u00edm je spracovanie kr\u00e1tkych transakci\u00ed, nie analytika. V\u00fdrobca zaru\u010duje dostupnos\u0165 klastru NonStop na \u00farovni piatich \u201edeviatok\u201c, \u010do znamen\u00e1, \u017ee prestoje predstavuj\u00fa iba 5 min\u00fat ro\u010dne.<\/p>\n<h4>SAP HANA<\/h4>\n<p>\nPrv\u00e1 stabiln\u00e1 verzia DBMS HANA (1.0) bola vydan\u00e1 v novembri 2010 a bal\u00edk SAP ERP pre\u0161iel na HANA od m\u00e1ja 2013. Platforma je zalo\u017een\u00e1 na zak\u00fapen\u00fdch technol\u00f3gi\u00e1ch: TREX Search Engine (vyh\u013ead\u00e1vanie v st\u013apcov\u00fdch \u00falo\u017eisk\u00e1ch), DBMS P*TIME a MAX DB.<\/p>\n<p>Samo slovo \u201eHANA\u201c je akronym, High performance ANalytical Appliance. Tento DBMS sa dod\u00e1va vo forme k\u00f3du, ktor\u00fd m\u00f4\u017ee fungova\u0165 na ak\u00fdchko\u013evek serveroch x86, av\u0161ak priemyseln\u00e9 in\u0161tal\u00e1cie s\u00fa povolen\u00e9 iba na certifikovanom hardv\u00e9ri. Existuj\u00fa rie\u0161enia HP, Lenovo, Cisco, Dell, Fujitsu, Hitachi, NEC. Niektor\u00e9 konfigur\u00e1cie Lenovo dokonca umo\u017e\u0148uj\u00fa prev\u00e1dzku bez SAN \u2013 \u00falohu zdie\u013ean\u00e9ho \u00falo\u017eiska pln\u00ed klaster GPFS na lok\u00e1lnych diskoch.<\/p>\n<p>Na rozdiel od vy\u0161\u0161ie uveden\u00fdch platforiem je HANA DBMS v pam\u00e4ti, to znamen\u00e1, \u017ee prim\u00e1rny obraz d\u00e1t sa uchov\u00e1va v opera\u010dnej pam\u00e4ti a na disk sa ukladaj\u00fa iba z\u00e1znamy a periodick\u00e9 sn\u00edmky \u2013 na obnovenie v pr\u00edpade hav\u00e1rie.<\/p>\n<p><img decoding=\"async\" alt=\"Distribuovan\u00e9 DBMS pre podniky\" src=\"\/wp-content\/uploads\/2020\/07\/f64194ca6de13e1a93f7190dc38ad2d7.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nKa\u017ed\u00fd uzol klastra HANA zodpoved\u00e1 za svoju \u010das\u0165 d\u00e1t, pri\u010dom mapa d\u00e1t sa uchov\u00e1va v \u0161peci\u00e1lnom komponente \u2013 Name Server, umiestnenom na koordin\u00e1torovom uzle. D\u00e1ta medzi uzlami sa neduplikuje. Inform\u00e1cie o z\u00e1mkoch sa tie\u017e uchov\u00e1vaj\u00fa na ka\u017edom uzle, ale syst\u00e9m obsahuje glob\u00e1lny detektor vz\u00e1jomn\u00fdch z\u00e1mkov.<\/p>\n<p>Klient HANA pri pripojen\u00ed k clusteru na\u010d\u00edta jeho topol\u00f3giu a n\u00e1sledne sa m\u00f4\u017ee priamo obr\u00e1ti\u0165 na ak\u00fdko\u013evek uzol v z\u00e1vislosti od toho, ak\u00e9 d\u00e1ta potrebuje. Ak transakcia zasahuje do d\u00e1t jedin\u00e9ho uzla, m\u00f4\u017ee by\u0165 vykonan\u00e1 t\u00fdmto uzlom lok\u00e1lne, ale ak sa menia d\u00e1ta nieko\u013ek\u00fdch uzlov, uzol-inici\u00e1tor sa obracia na uzol-koordin\u00e1tor, ktor\u00fd otv\u00e1ra a koordinuje distribu\u010dn\u00fa transakciu a potvrdzuje ju pomocou optimalizovan\u00e9ho protokolu dvojf\u00e1zov\u00e9ho potvrdenia.<\/p>\n<p>Uzol-koordin\u00e1tor je duplikovan\u00fd, tak\u017ee v pr\u00edpade v\u00fdpadku koordin\u00e1tora okam\u017eite za\u010dne pracova\u0165 z\u00e1lo\u017en\u00fd uzol. Ak v\u0161ak zlyh\u00e1 uzol s d\u00e1tami, jedin\u00fd sp\u00f4sob, ako z\u00edska\u0165 pr\u00edstup k jeho d\u00e1tam, je re\u0161tartova\u0165 uzol. Zvy\u010dajne v klastroch HANA udr\u017eiavaj\u00fa z\u00e1lo\u017en\u00fd (spare) server, aby \u010do najr\u00fdchlej\u0161ie re\u0161tartovali na \u0148om straten\u00fd uzol.<br \/>\n<br \/>Zdroj: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/512298\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>CAP-\u0442\u0435\u043e\u0440\u0435\u043c\u0430 \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u043a\u0440\u0430\u0435\u0443\u0433\u043e\u043b\u044c\u043d\u044b\u043c \u043a\u0430\u043c\u043d\u0435\u043c \u0442\u0435\u043e\u0440\u0438\u0438 \u0440\u0430\u0441\u043f\u0440\u0435\u0434\u0435\u043b\u0451\u043d\u043d\u044b\u0445 \u0441\u0438\u0441\u0442\u0435\u043c. \u041a\u043e\u043d\u0435\u0447\u043d\u043e, \u0441\u043f\u043e\u0440\u044b \u0432\u043e\u043a\u0440\u0443\u0433 \u043d\u0435\u0451 \u043d\u0435 \u0443\u0442\u0438\u0445\u0430\u044e\u0442: \u0438 \u043e\u043f\u0440\u0435\u0434\u0435\u043b\u0435\u043d\u0438\u044f \u0432 \u043d\u0435\u0439 \u043d\u0435 \u043a\u0430\u043d\u043e\u043d\u0438\u0447\u0435\u0441\u043a\u0438\u0435, \u0438 \u0441\u0442\u0440\u043e\u0433\u043e\u0433\u043e \u0434\u043e\u043a\u0430\u0437\u0430\u0442\u0435\u043b\u044c\u0441\u0442\u0432\u0430 \u043d\u0435\u0442\u2026 \u0422\u0435\u043c \u043d\u0435 \u043c\u0435\u043d\u0435\u0435, \u0442\u0432\u0451\u0440\u0434\u043e \u0441\u0442\u043e\u044f \u043d\u0430 \u043f\u043e\u0437\u0438\u0446\u0438\u044f\u0445 \u0431\u044b\u0442\u043e\u0432\u043e\u0433\u043e \u0437\u0434\u0440\u0430\u0432\u043e\u0433\u043e \u0441\u043c\u044b\u0441\u043b\u0430&trade;, \u043c\u044b \u0438\u043d\u0442\u0443\u0438\u0442\u0438\u0432\u043d\u043e \u043f\u043e\u043d\u0438\u043c\u0430\u0435\u043c, \u0447\u0442\u043e \u0442\u0435\u043e\u0440\u0435\u043c\u0430 \u0432\u0435\u0440\u043d\u0430. \u0415\u0434\u0438\u043d\u0441\u0442\u0432\u0435\u043d\u043d\u043e\u0435, \u0447\u0442\u043e \u043d\u0435 \u043e\u0447\u0435\u0432\u0438\u0434\u043d\u043e, \u0442\u0430\u043a \u044d\u0442\u043e \u0437\u043d\u0430\u0447\u0435\u043d\u0438\u0435 \u0431\u0443\u043a\u0432\u044b \u00abP\u00bb. \u041a\u043e\u0433\u0434\u0430 \u043a\u043b\u0430\u0441\u0442\u0435\u0440 \u0440\u0430\u0437\u0434\u0435\u043b\u0438\u043b\u0441\u044f, \u043e\u043d \u0440\u0435\u0448\u0430\u0435\u0442 \u2013 \u0442\u043e [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":89873,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-89872","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.4 - aioseo.com -->\n\t<meta name=\"description\" content=\"CAP-\u0442\u0435\u043e\u0440\u0435\u043c\u0430 \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u043a\u0440\u0430\u0435\u0443\u0433\u043e\u043b\u044c\u043d\u044b\u043c \u043a\u0430\u043c\u043d\u0435\u043c \u0442\u0435\u043e\u0440\u0438\u0438 \u0440\u0430\u0441\u043f\u0440\u0435\u0434\u0435\u043b\u0451\u043d\u043d\u044b\u0445 \u0441\u0438\u0441\u0442\u0435\u043c.\" \/>\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\/sk\/blog\/administrirovanie\/raspredelyonnye-subd-dlya-enterprajza\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.4\" \/>\n\t\t<meta property=\"og:locale\" content=\"sk_SK\" \/>\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\udd47\u0420\u0430\u0441\u043f\u0440\u0435\u0434\u0435\u043b\u0451\u043d\u043d\u044b\u0435 \u0421\u0423\u0411\u0414 \u0434\u043b\u044f \u044d\u043d\u0442\u0435\u0440\u043f\u0440\u0430\u0439\u0437\u0430 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"CAP-\u0442\u0435\u043e\u0440\u0435\u043c\u0430 \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u043a\u0440\u0430\u0435\u0443\u0433\u043e\u043b\u044c\u043d\u044b\u043c \u043a\u0430\u043c\u043d\u0435\u043c \u0442\u0435\u043e\u0440\u0438\u0438 \u0440\u0430\u0441\u043f\u0440\u0435\u0434\u0435\u043b\u0451\u043d\u043d\u044b\u0445 \u0441\u0438\u0441\u0442\u0435\u043c.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/sk\/blog\/administrirovanie\/raspredelyonnye-subd-dlya-enterprajza\" \/>\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=\"2020-07-26T23:42:19+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-07-26T23:42:19+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\udd47Distribuovan\u00e9 DB pre podniky | ProHoster","description":"CAP-t\u00e9zora je z\u00e1kladn\u00fdm kame\u0148om te\u00f3rie distribuovan\u00fdch syst\u00e9mov.","canonical_url":"https:\/\/prohoster.info\/sk\/blog\/administrirovanie\/raspredelyonnye-subd-dlya-enterprajza","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"sk_SK","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\udd47\u0420\u0430\u0441\u043f\u0440\u0435\u0434\u0435\u043b\u0451\u043d\u043d\u044b\u0435 \u0421\u0423\u0411\u0414 \u0434\u043b\u044f \u044d\u043d\u0442\u0435\u0440\u043f\u0440\u0430\u0439\u0437\u0430 | ProHoster","og:description":"CAP-\u0442\u0435\u043e\u0440\u0435\u043c\u0430 \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u043a\u0440\u0430\u0435\u0443\u0433\u043e\u043b\u044c\u043d\u044b\u043c \u043a\u0430\u043c\u043d\u0435\u043c \u0442\u0435\u043e\u0440\u0438\u0438 \u0440\u0430\u0441\u043f\u0440\u0435\u0434\u0435\u043b\u0451\u043d\u043d\u044b\u0445 \u0441\u0438\u0441\u0442\u0435\u043c.","og:url":"https:\/\/prohoster.info\/sk\/blog\/administrirovanie\/raspredelyonnye-subd-dlya-enterprajza","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":"2020-07-26T23:42:19+00:00","article:modified_time":"2020-07-26T23:42:19+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"89872","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":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 13:03:25","updated":"2026-02-22 15:29:33","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/posts\/89872","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/comments?post=89872"}],"version-history":[{"count":2,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/posts\/89872\/revisions"}],"predecessor-version":[{"id":162170,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/posts\/89872\/revisions\/162170"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/media\/89873"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/media?parent=89872"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/categories?post=89872"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/tags?post=89872"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}