{"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\/cs\/blog\/administrirovanie\/raspredelyonnye-subd-dlya-enterprajza","title":{"rendered":"Distribuovan\u00e9 DB pro podniky","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>CAP teorema je z\u00e1kladn\u00edm kamenem teorie distribuovan\u00fdch syst\u00e9m\u016f. Samoz\u0159ejm\u011b, diskuze kolem n\u00ed neutichaj\u00ed: definice v n\u00ed nejsou kanonick\u00e9 a neexistuje p\u0159\u00edsn\u00fd d\u016fkaz... Nicm\u00e9n\u011b, pevn\u011b stoj\u00edce na pozic\u00edch b\u011b\u017en\u00e9ho zdrav\u00e9ho rozumu\u2122, intuitivn\u011b ch\u00e1peme, \u017ee teorema je spr\u00e1vn\u00e1.<\/p>\n<p><img decoding=\"async\" alt=\"Distribuovan\u00e9 DB pro podniky\" src=\"\/wp-content\/uploads\/2020\/07\/35c8b29bb024cbf383d78caa1af2c525.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nJedna v\u011bc v\u0161ak nen\u00ed zcela jasn\u00e1, a to v\u00fdznam p\u00edsmene \u201eP\u201c. Kdy\u017e se cluster rozd\u011bl\u00ed, rozhoduje se, zda neodpov\u00ed, dokud nebude dosa\u017eeno kv\u00f3ra, nebo zda poskytne dostupn\u00e1 data. V z\u00e1vislosti na v\u00fdsledku tohoto rozhodnut\u00ed je syst\u00e9m klasifikov\u00e1n bu\u010f jako CP, nebo jako AP. Cassandra, nap\u0159\u00edklad, se m\u016f\u017ee chovat ob\u011bma zp\u016fsoby, a to nejen v z\u00e1vislosti na nastaven\u00ed clusteru, ale i na parametrech ka\u017ed\u00e9ho konkr\u00e9tn\u00edho dotazu. Ale co kdy\u017e syst\u00e9m nen\u00ed \u201eP\u201c a rozd\u011bl\u00ed se, co se stane?<\/p>\n<p>Odpov\u011b\u010f na tuto ot\u00e1zku je pon\u011bkud p\u0159ekvapiv\u00e1: CA cluster se nem\u016f\u017ee rozd\u011blit.<br \/>\nJak\u00fd tedy je to cluster, kter\u00fd se nem\u016f\u017ee rozd\u011blit?<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\nNezbytn\u00fdm atributem takov\u00e9ho clusteru je spole\u010dn\u00fd syst\u00e9m \u00falo\u017ei\u0161t\u011b dat. Ve v\u011bt\u0161in\u011b p\u0159\u00edpad\u016f to znamen\u00e1 p\u0159ipojen\u00ed p\u0159es SAN, co\u017e omezuje pou\u017eit\u00ed CA \u0159e\u0161en\u00ed na velk\u00e9 podniky, kter\u00e9 si mohou dovolit SAN infrastrukturu. Aby n\u011bkolik <a class=\"wpil_keyword_link\" href=\"https:\/\/prohoster.info\/cs\/server\/\"   title=\"servery\" data-wpil-keyword-link=\"linked\"  data-wpil-monitor-id=\"1512\">servery<\/a> mohlo pracovat se stejn\u00fdmi daty, je pot\u0159ebn\u00fd clusterov\u00fd souborov\u00fd syst\u00e9m. Takov\u00e9 souborov\u00e9 syst\u00e9my jsou v portfoli\u00edch HPE (CFS), Veritas (VxCFS) a IBM (GPFS). <\/p>\n<h4>Oracle RAC<\/h4>\n<p>\nMo\u017enost Real Application Cluster se poprv\u00e9 objevila v roce 2001 ve verzi Oracle 9i. V takov\u00e9m clusteru n\u011bkolik instanc\u00ed <a class=\"wpil_keyword_link\" href=\"https:\/\/prohoster.info\/cs\/server\/dts-los-angeles\/\"   title=\"serveru\" data-wpil-keyword-link=\"linked\"  data-wpil-monitor-id=\"3642\">serveru<\/a> pracuje se stejnou datab\u00e1z\u00ed.<br \/>\nOracle m\u016f\u017ee pracovat jak s clusterov\u00fdm souborov\u00fdm syst\u00e9mem, tak se sv\u00fdm vlastn\u00edm \u0159e\u0161en\u00edm \u2013 ASM (Automatic Storage Management).<\/p>\n<p>Ka\u017ed\u00e1 instance vede sv\u016fj vlastn\u00ed protokol. Transakce je provedena a zaznamen\u00e1na jednou instanc\u00ed. V p\u0159\u00edpad\u011b selh\u00e1n\u00ed instance jeden z p\u0159e\u017eiv\u0161\u00edch uzl\u016f clusteru (instanc\u00ed) p\u0159e\u010dte jej\u00ed protokol a obnov\u00ed ztracen\u00e1 data \u2013 t\u00edm se zaji\u0161\u0165uje dostupnost.<\/p>\n<p>V\u0161echny instance maj\u00ed sv\u016fj vlastn\u00ed cache a stejn\u00e9 str\u00e1nky (bloky) mohou b\u00fdt z\u00e1rove\u0148 v cache n\u011bkolika instanc\u00ed. Nav\u00edc, pokud je n\u011bjak\u00e1 str\u00e1nka pot\u0159ebn\u00e1 jednou instanc\u00ed a je dostupn\u00e1 v cache jin\u00e9 instance, m\u016f\u017ee ji z\u00edskat od \u201esoused\u201c pomoc\u00ed mechanismu cache fusion, m\u00edsto aby ji \u010detla z disku.<\/p>\n<p><img decoding=\"async\" alt=\"Distribuovan\u00e9 DB pro podniky\" src=\"\/wp-content\/uploads\/2020\/07\/917cb1bfcc2c47ccf0dbb2f1e34ac921.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nCo se ale stane, pokud jednomu z instanc\u00ed bude t\u0159eba zm\u011bnit data?<\/p>\n<p>Vlastnost\u00ed Oracle je, \u017ee nem\u00e1 dedikovanou slu\u017ebu z\u00e1mk\u016f: pokud server chce zablokovat \u0159\u00e1dek, z\u00e1znam o z\u00e1mku se umis\u0165uje p\u0159\u00edmo na str\u00e1nku pam\u011bti, kde se nach\u00e1z\u00ed blokovan\u00fd \u0159\u00e1dek. D\u00edky tomuto p\u0159\u00edstupu je Oracle \u0161ampionem v v\u00fdkonu mezi monolitick\u00fdmi datab\u00e1zemi: slu\u017eba z\u00e1mk\u016f se nikdy nest\u00e1v\u00e1 \u00fazk\u00fdm m\u00edstem. V clusterov\u00e9 konfiguraci v\u0161ak m\u016f\u017ee takov\u00e1 architektura v\u00e9st k intenzivn\u00edmu s\u00ed\u0165ov\u00e9mu p\u0159enosu a vz\u00e1jemn\u00fdm z\u00e1mk\u016fm.<\/p>\n<p>Jakmile dojde k zablokov\u00e1n\u00ed z\u00e1znamu, instance informuje v\u0161echny ostatn\u00ed instance o tom, \u017ee str\u00e1nka, na kter\u00e9 se nach\u00e1z\u00ed tento z\u00e1znam, je obsazena v monopoln\u00edm re\u017eimu. Pokud jin\u00e9 instanci bude t\u0159eba zm\u011bnit z\u00e1znam na t\u00e9\u017ee str\u00e1nce, mus\u00ed \u010dekat, dokud nebudou zm\u011bny na str\u00e1nce zaps\u00e1ny, tj. informace o zm\u011bn\u011b nebude zaznamen\u00e1na do protokolu na disku (p\u0159itom transakce m\u016f\u017ee pokra\u010dovat). M\u016f\u017ee se tak\u00e9 st\u00e1t, \u017ee str\u00e1nka bude postupn\u011b m\u011bn\u011bna n\u011bkolika instancemi, a pot\u00e9, kdy\u017e dojde k z\u00e1pisu str\u00e1nky na disk, bude nutn\u00e9 zjistit, u koho se nach\u00e1z\u00ed aktu\u00e1ln\u00ed verze t\u00e9to str\u00e1nky.<\/p>\n<p>N\u00e1hodn\u00e9 aktualizace stejn\u00fdch str\u00e1nek p\u0159es r\u016fzn\u00e9 uzly RAC vedou k dramatick\u00e9mu poklesu v\u00fdkonu datab\u00e1ze \u2013 a\u017e k tomu, \u017ee v\u00fdkon clusteru m\u016f\u017ee b\u00fdt ni\u017e\u0161\u00ed ne\u017e v\u00fdkon jedin\u00e9ho instance.<\/p>\n<p>Spr\u00e1vn\u00e9 vyu\u017eit\u00ed Oracle RAC spo\u010d\u00edv\u00e1 ve fyzick\u00e9m rozd\u011blen\u00ed dat (nap\u0159\u00edklad pomoc\u00ed mechanismu partitioned tables) a p\u0159\u00edstupu k ka\u017ed\u00e9 sad\u011b partitione\u016f p\u0159es dedikovan\u00fd uzel. Hlavn\u00edm \u00fa\u010delem RAC se stalo ne horizont\u00e1ln\u00ed \u0161k\u00e1lov\u00e1n\u00ed, ale zaji\u0161t\u011bn\u00ed odolnosti proti v\u00fdpadk\u016fm.<\/p>\n<p>Pokud uzel p\u0159estane odpov\u00eddat na heartbeat, ten uzel, kter\u00fd to zjist\u00ed jako prvn\u00ed, spust\u00ed proceduru hlasov\u00e1n\u00ed na disku. Pokud se ani zde ztracen\u00fd uzel neozve, jeden z uzl\u016f p\u0159evezme povinnosti obnoven\u00ed dat:<\/p>\n<ul>\n<li>\u201ezmraz\u00ed\u201c v\u0161echny str\u00e1nky, kter\u00e9 se nach\u00e1zely v cache ztracen\u00e9ho uzlu;<\/li>\n<li>p\u0159e\u010dte protokoly (redo) ztracen\u00e9ho uzlu a znovu aplikuje zm\u011bny zapsan\u00e9 v t\u011bchto protokolech, p\u0159i\u010dem\u017e z\u00e1rove\u0148 kontroluje, zda nemaj\u00ed jin\u00e9 uzly nov\u011bj\u0161\u00ed verze m\u011bn\u011bn\u00fdch str\u00e1nek;<\/li>\n<li>vrac\u00ed ne\u00fapln\u00e9 transakce.<\/li>\n<\/ul>\n<p>\nAby se usnadnilo p\u0159ep\u00edn\u00e1n\u00ed mezi uzly, existuje v Oracle pojem slu\u017eby \u2013 virtu\u00e1ln\u00ed instance. Instance m\u016f\u017ee obsluhovat n\u011bkolik slu\u017eeb a slu\u017eba m\u016f\u017ee p\u0159esouvat mezi uzly. Instance aplikace, kter\u00e1 obsluhuje ur\u010ditou \u010d\u00e1st datab\u00e1ze (nap\u0159\u00edklad skupinu klient\u016f), pracuje s jednou slu\u017ebou, a slu\u017eba, odpov\u011bdn\u00e1 za tuto \u010d\u00e1st datab\u00e1ze, se p\u0159i v\u00fdpadku uzlu p\u0159esouv\u00e1 na jin\u00fd uzel.<\/p>\n<h4>IBM Pure Data Systems for Transactions<\/h4>\n<p>\nKlastr \u0159e\u0161en\u00ed pro DBMS se objevilo v portfoliu Modr\u00e9ho Giganta v roce 2009. Ideologicky se jedn\u00e1 o n\u00e1stupce klastru Parallel Sysplex, postaven\u00e9ho na \u201eb\u011b\u017en\u00e9m\u201c hardwaru. V roce 2009 byl uveden produkt DB2 pureScale, kter\u00fd je soubor softwaru, a v roce 2012 IBM nab\u00edz\u00ed softwarov\u011b-hardwarov\u00fd bal\u00ed\u010dek (appliance) nazvan\u00fd Pure Data Systems for Transactions. Nen\u00ed t\u0159eba jej zam\u011b\u0148ovat s Pure Data Systems for Analytics, co\u017e je nic jin\u00e9ho ne\u017e p\u0159ejmenovan\u00fd Netezza.<\/p>\n<p>Architektura pureScale na prvn\u00ed pohled p\u0159ipom\u00edn\u00e1 Oracle RAC: stejn\u011b jako n\u011bkolik uzl\u016f je p\u0159ipojeno k spole\u010dn\u00e9mu syst\u00e9mu \u00falo\u017ei\u0161t\u011b dat a na ka\u017ed\u00e9m uzlu b\u011b\u017e\u00ed vlastn\u00ed instance DBMS se sv\u00fdmi oblastmi pam\u011bti a transak\u010dn\u00edmi \u017eurn\u00e1ly. Ale na rozd\u00edl od Oracle m\u00e1 DB2 vyhrazenou slu\u017ebu zamyk\u00e1n\u00ed, prezentovanou sadou proces\u016f db2LLM*. V klastrov\u00e9 konfiguraci je tato slu\u017eba um\u00edst\u011bna na samostatn\u00e9m uzlu, kter\u00fd se v Parallel Sysplex naz\u00fdv\u00e1 coupling facility (CF), a v Pure Data \u2013 PowerHA.<\/p>\n<p>PowerHA poskytuje n\u00e1sleduj\u00edc\u00ed slu\u017eby:<\/p>\n<ul>\n<li>spr\u00e1vce z\u00e1mk\u016f;<\/li>\n<li>glob\u00e1ln\u00ed buffer cache;<\/li>\n<li>oblast meziprocesn\u00ed komunikace.<\/li>\n<\/ul>\n<p>\nPro p\u0159enos dat mezi PowerHA a uzly DB a zp\u011bt se pou\u017e\u00edv\u00e1 vzd\u00e1len\u00fd p\u0159\u00edstup do pam\u011bti, proto mus\u00ed klastrov\u00e1 interkonektivita podporovat protokol RDMA. PureScale m\u016f\u017ee pou\u017e\u00edvat jak Infiniband, tak RDMA over Ethernet.<\/p>\n<p><img decoding=\"async\" alt=\"Distribuovan\u00e9 DB pro podniky\" src=\"\/wp-content\/uploads\/2020\/07\/7757acd68445dac4a9f378d5813e663f.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPokud uzlu pot\u0159ebuje str\u00e1nku, a tato str\u00e1nka nen\u00ed v cache, uzel po\u017eaduje str\u00e1nku v glob\u00e1ln\u00ed cache, a pouze v p\u0159\u00edpad\u011b, \u017ee ani tam nen\u00ed, ji \u010dte z disku. Na rozd\u00edl od Oracle se po\u017eadavek pos\u00edl\u00e1 pouze do PowerHA, a ne na sousedn\u00ed uzly.<\/p>\n<p>Pokud instance zam\u00fd\u0161l\u00ed m\u011bnit \u0159\u00e1dek, zablokuje ho v\u00fdhradn\u00edm zp\u016fsobem a str\u00e1nku, kde se \u0159\u00e1dek nach\u00e1z\u00ed, ve sd\u00edlen\u00e9m re\u017eimu. V\u0161echny blokace jsou zaznamen\u00e1ny v glob\u00e1ln\u00edm spr\u00e1vci blokac\u00ed. Kdy\u017e transakce skon\u010d\u00ed, uzel ode\u0161le zpr\u00e1vu spr\u00e1vci blokac\u00ed, kter\u00fd zkop\u00edruje zm\u011bn\u011bnou str\u00e1nku do glob\u00e1ln\u00ed cache, zru\u0161\u00ed blokace a zneplatn\u00ed zm\u011bn\u011bnou str\u00e1nku v cache ostatn\u00edch uzl\u016f.<\/p>\n<p>Pokud je str\u00e1nka, ve kter\u00e9 se nach\u00e1z\u00ed m\u011bn\u011bn\u00fd \u0159\u00e1dek, u\u017e blokov\u00e1na, spr\u00e1vce blokac\u00ed p\u0159e\u010dte zm\u011bn\u011bnou str\u00e1nku z pam\u011bti uzlu, kter\u00fd provedl zm\u011bny, zru\u0161\u00ed blokaci, zneplatn\u00ed zm\u011bn\u011bnou str\u00e1nku v cache ostatn\u00edch uzl\u016f a vr\u00e1t\u00ed blokaci str\u00e1nky u\u017elu, kter\u00fd o ni po\u017e\u00e1dal.<\/p>\n<p>\"\u0160pinav\u00e9\", tedy zm\u011bn\u011bn\u00e9, str\u00e1nky mohou b\u00fdt zapisov\u00e1ny na disk jak z b\u011b\u017en\u00e9ho uzlu, tak z PowerHA (castout).<\/p>\n<p>P\u0159i selh\u00e1n\u00ed jednoho z uzl\u016f pureScale je obnova omezena pouze na ty transakce, kter\u00e9 v okam\u017eiku selh\u00e1n\u00ed je\u0161t\u011b nebyly dokon\u010deny: str\u00e1nky, kter\u00e9 byly zm\u011bn\u011bny t\u00edmto uzlem v dokon\u010den\u00fdch transakc\u00edch, jsou v glob\u00e1ln\u00ed cache na PowerHA. Uzel se restartuje v omezen\u00e9 konfiguraci na jednom ze server\u016f clusteru, vr\u00e1t\u00ed nezkompletovan\u00e9 transakce a uvoln\u00ed blokace.<\/p>\n<p>PowerHA pracuje na dvou serverech a hlavn\u00ed uzel synchronn\u011b replikov\u00e1v\u00e1 sv\u016fj stav. P\u0159i selh\u00e1n\u00ed hlavn\u00edho uzlu PowerHA cluster pokra\u010duje v pr\u00e1ci s rezervn\u00edm uzlem.<br \/>\nSamoz\u0159ejm\u011b, pokud se p\u0159istupuje k sad\u011b dat pouze p\u0159es jeden uzel, celkov\u00fd v\u00fdkon clusteru bude vy\u0161\u0161\u00ed. PureScale si dokonce m\u016f\u017ee pov\u0161imnout, \u017ee ur\u010dit\u00e9 \u00fazem\u00ed dat zpracov\u00e1v\u00e1 jeden uzel, a pak v\u0161echny blokace t\u00fdkaj\u00edc\u00ed se t\u00e9to oblasti budou zpracov\u00e1v\u00e1ny lok\u00e1ln\u011b bez komunikace s PowerHA. Jakmile se v\u0161ak aplikace pokus\u00ed p\u0159istupovat k t\u011bmto dat\u016fm p\u0159es jin\u00fd uzel, centralizovan\u00e9 zpracov\u00e1n\u00ed blokac\u00ed bude obnoveno.<\/p>\n<p>Intern\u00ed testy IBM na z\u00e1t\u011b\u017ei sest\u00e1vaj\u00edc\u00ed z 90% \u010dten\u00ed a 10% z\u00e1pisu, co\u017e velmi p\u0159ipom\u00edn\u00e1 re\u00e1lnou pr\u016fmyslovou z\u00e1t\u011b\u017e, ukazuj\u00ed t\u00e9m\u011b\u0159 line\u00e1rn\u00ed \u0161k\u00e1lov\u00e1n\u00ed a\u017e do 128 uzl\u016f. Podm\u00ednky testov\u00e1n\u00ed se bohu\u017eel nezve\u0159ej\u0148uj\u00ed.<\/p>\n<h4>HPE NonStop SQL<\/h4>\n<p>\nV portfoliu spole\u010dnosti Hewlett-Packard Enterprise je tak\u00e9 vysoce dostupn\u00e1 platforma. Jedn\u00e1 se o platformu NonStop, kter\u00e1 byla uvedena na trh v roce 1976 firmou Tandem Computers. V roce 1997 byla firma koupena spole\u010dnost\u00ed Compaq, kter\u00e1 se v roce 2002 spojila se spole\u010dnost\u00ed Hewlett-Packard.<\/p>\n<p>NonStop se pou\u017e\u00edv\u00e1 pro budov\u00e1n\u00ed kritick\u00fdch aplikac\u00ed \u2013 nap\u0159\u00edklad HLR nebo zpracov\u00e1n\u00ed bankovn\u00edch karet. Platforma se dod\u00e1v\u00e1 jako softwarov\u011b-hardwarov\u00fd komplex (appliance), kter\u00fd zahrnuje v\u00fdpo\u010detn\u00ed uzly, syst\u00e9m pro ukl\u00e1d\u00e1n\u00ed dat a komunika\u010dn\u00ed za\u0159\u00edzen\u00ed. S\u00ed\u0165 ServerNet (v modern\u00edch syst\u00e9mech \u2013 Infiniband) slou\u017e\u00ed jak pro komunikaci mezi uzly, tak pro p\u0159\u00edstup k syst\u00e9mu ukl\u00e1d\u00e1n\u00ed dat.<\/p>\n<p>Vran\u00fdch verz\u00edch syst\u00e9mu byly pou\u017eity propriet\u00e1rn\u00ed procesory, kter\u00e9 byly synchronizov\u00e1ny navz\u00e1jem: v\u0161echny operace byly vykon\u00e1v\u00e1ny synchronn\u011b n\u011bkolika procesory, a jakmile do\u0161lo k chyb\u011b u jednoho z procesor\u016f, byl odpojen, zat\u00edmco druh\u00fd pokra\u010doval v pr\u00e1ci. Pozd\u011bji syst\u00e9m p\u0159e\u0161el na standardn\u00ed procesory (nejprve MIPS, pak Itanium a nakonec x86) a pro synchronizaci byly pou\u017eity jin\u00e9 mechanismy:<\/p>\n<ul>\n<li>zpr\u00e1vy: ka\u017ed\u00fd syst\u00e9mov\u00fd proces m\u00e1 dvojn\u00edka-\u201est\u00edn\u201c, kter\u00e9mu aktivn\u00ed proces pravideln\u011b pos\u00edl\u00e1 zpr\u00e1vy o sv\u00e9m stavu; v p\u0159\u00edpad\u011b selh\u00e1n\u00ed hlavn\u00edho procesu za\u010d\u00edn\u00e1 st\u00ednov\u00fd proces pracovat od okam\u017eiku ur\u010den\u00e9ho posledn\u00ed zpr\u00e1vou;<\/li>\n<li>hlasov\u00e1n\u00ed: syst\u00e9m pro ukl\u00e1d\u00e1n\u00ed dat m\u00e1 speci\u00e1ln\u00ed hardwarovou komponentu, kter\u00e1 p\u0159ij\u00edm\u00e1 n\u011bkolik stejn\u00fdch po\u017eadavk\u016f a prov\u00e1d\u00ed je pouze v p\u0159\u00edpad\u011b, \u017ee se po\u017eadavky shoduj\u00ed; m\u00edsto fyzick\u00e9 synchronizace procesory pracuj\u00ed asynchronn\u011b a v\u00fdsledky jejich pr\u00e1ce se porovn\u00e1vaj\u00ed pouze v okam\u017eic\u00edch vstupu\/v\u00fdstupu.<\/li>\n<\/ul>\n<p>\nOd roku 1987 pracuje na platform\u011b NonStop rela\u010dn\u00ed DBMS \u2013 nejprve SQL\/MP a pot\u00e9 SQL\/MX.<\/p>\n<p>Cel\u00e1 datab\u00e1ze je rozd\u011blena na \u010d\u00e1sti, p\u0159i\u010dem\u017e za ka\u017edou \u010d\u00e1st odpov\u00edd\u00e1 vlastn\u00ed proces Data Access Manager (DAM). Zaji\u0161\u0165uje z\u00e1pis dat, ke\u0161ov\u00e1n\u00ed a mechanismus z\u00e1mk\u016f. Zpracov\u00e1n\u00ed dat prov\u00e1d\u011bj\u00ed procesy vykonavatel\u00e9 (Executor Server Process), kter\u00e9 b\u011b\u017e\u00ed na t\u011bch sam\u00fdch uzlech jako p\u0159\u00edslu\u0161n\u00e9 spr\u00e1vce dat. Pl\u00e1nova\u010d SQL\/MX rozd\u011bluje \u00fakoly mezi vykonavatele a kombinuje v\u00fdsledky. P\u0159i nutnosti prov\u00e1d\u011bt koordinovan\u00e9 zm\u011bny se pou\u017e\u00edv\u00e1 protokol dvouf\u00e1zov\u00e9ho potvrzen\u00ed, zaji\u0161\u0165ovan\u00fd knihovnou TMF (Transaction Management Facility).<\/p>\n<p><img decoding=\"async\" alt=\"Distribuovan\u00e9 DB pro podniky\" src=\"\/wp-content\/uploads\/2020\/07\/00e9473dd95a78c409dd5283d299fe96.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nNonStop SQL um\u00ed prioritizovat procesy tak, aby dlouh\u00e9 analytick\u00e9 dotazy nebr\u00e1nily vykon\u00e1v\u00e1n\u00ed transakc\u00ed. Jeho hlavn\u00edm ur\u010den\u00edm je v\u0161ak zpracov\u00e1n\u00ed kr\u00e1tk\u00fdch transakc\u00ed, nikoli analytika. V\u00fdvoj\u00e1\u0159 zaru\u010duje dostupnost clusteru NonStop na \u00farovni p\u011bti dev\u00edtek, co\u017e znamen\u00e1, \u017ee prostoje \u010din\u00ed pouze 5 minut ro\u010dn\u011b.<\/p>\n<h4>SAP HANA<\/h4>\n<p>\nPrvn\u00ed stabiln\u00ed vyd\u00e1n\u00ed DBMS HANA (1.0) bylo uvedeno v listopadu 2010 a bal\u00edk SAP ERP p\u0159e\u0161el na HANA od kv\u011btna 2013. Platforma je zalo\u017eena na zakoupen\u00fdch technologi\u00edch: TREX Search Engine (vyhled\u00e1v\u00e1n\u00ed v sloupcov\u00e9 datab\u00e1zi), DBMS P*TIME a MAX DB.<\/p>\n<p>Samotn\u00e9 slovo \"HANA\" je akronym, High performance ANalytical Appliance. Tento DBMS je dod\u00e1v\u00e1n ve form\u011b k\u00f3du, kter\u00fd m\u016f\u017ee b\u011b\u017eet na jak\u00fdchkoli serverech x86, av\u0161ak pr\u016fmyslov\u00e9 instalace jsou povoleny pouze na certifikovan\u00e9m hardwaru. Existuj\u00ed \u0159e\u0161en\u00ed od HP, Lenovo, Cisco, Dell, Fujitsu, Hitachi, NEC. N\u011bkter\u00e9 konfigurace Lenovo dokonce povoluj\u00ed provoz bez SAN \u2013 roli sd\u00edlen\u00e9ho \u00falo\u017ei\u0161t\u011b hraje klastr GPFS na m\u00edstn\u00edch disc\u00edch.<\/p>\n<p>Na rozd\u00edl od v\u00fd\u0161e uveden\u00fdch platforem je HANA DBMS v pam\u011bti, tedy prim\u00e1rn\u00ed obraz dat se uchov\u00e1v\u00e1 v opera\u010dn\u00ed pam\u011bti, zat\u00edmco na disk se zapisuj\u00ed pouze \u017eurn\u00e1ly a periodick\u00e9 sn\u00edmky \u2013 pro obnovu v p\u0159\u00edpad\u011b hav\u00e1rie.<\/p>\n<p><img decoding=\"async\" alt=\"Distribuovan\u00e9 DB pro podniky\" src=\"\/wp-content\/uploads\/2020\/07\/f64194ca6de13e1a93f7190dc38ad2d7.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nKa\u017ed\u00fd uzel clusteru HANA odpov\u00edd\u00e1 za svou \u010d\u00e1st dat, a mapa dat se uchov\u00e1v\u00e1 ve specializovan\u00e9 komponent\u011b \u2013 Name Server, kter\u00fd se nach\u00e1z\u00ed na koordina\u010dn\u00edm uzlu. Data mezi uzly se neduplikuje. Informace o z\u00e1mc\u00edch se tak\u00e9 uchov\u00e1vaj\u00ed na ka\u017ed\u00e9m uzlu, ale v syst\u00e9mu existuje glob\u00e1ln\u00ed detektor vz\u00e1jemn\u00fdch z\u00e1mk\u016f.<\/p>\n<p>Klient HANA p\u0159i p\u0159ipojen\u00ed k clustru na\u010d\u00edt\u00e1 jeho topologii a n\u00e1sledn\u011b se m\u016f\u017ee p\u0159\u00edmo obracet na libovoln\u00fd uzel v z\u00e1vislosti na tom, jak\u00e1 data pot\u0159ebuje. Pokud transakce zasahuje do dat jedin\u00e9ho uzlu, m\u016f\u017ee b\u00fdt provedena t\u00edmto uzlem lok\u00e1ln\u011b, ale pokud se m\u011bn\u00ed data n\u011bkolika uzl\u016f, uzel inici\u00e1tor se obrac\u00ed na uzel koordin\u00e1tor, kter\u00fd otev\u00edr\u00e1 a koordinuje distribuovanou transakci, p\u0159i\u010dem\u017e ji zafixuje pomoc\u00ed optimalizovan\u00e9ho protokolu dvouf\u00e1zov\u00e9ho zaji\u0161t\u011bn\u00ed.<\/p>\n<p>Uzel koordin\u00e1tor je duplikovan\u00fd, tak\u017ee v p\u0159\u00edpad\u011b selh\u00e1n\u00ed koordin\u00e1tora okam\u017eit\u011b nastupuje z\u00e1lo\u017en\u00ed uzel. Pokud v\u0161ak sel\u017ee uzel s daty, je jedin\u00fdm zp\u016fsobem, jak z\u00edskat p\u0159\u00edstup k jeho dat\u016fm, restartovat uzel. Obvykle se v clusterech HANA udr\u017euje z\u00e1lo\u017en\u00ed server, aby bylo mo\u017en\u00e9 co nejrychleji restartovat ztracen\u00fd uzel.<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.3 - 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\/cs\/blog\/administrirovanie\/raspredelyonnye-subd-dlya-enterprajza\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"cs_CZ\" \/>\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\/cs\/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 pro podniky | ProHoster","description":"CAP teorie je z\u00e1kladn\u00edm kamenem teorie distribuovan\u00fdch syst\u00e9m\u016f.","canonical_url":"https:\/\/prohoster.info\/cs\/blog\/administrirovanie\/raspredelyonnye-subd-dlya-enterprajza","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"cs_CZ","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\/cs\/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\/cs\/wp-json\/wp\/v2\/posts\/89872","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/cs\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/cs\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/cs\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/cs\/wp-json\/wp\/v2\/comments?post=89872"}],"version-history":[{"count":2,"href":"https:\/\/prohoster.info\/cs\/wp-json\/wp\/v2\/posts\/89872\/revisions"}],"predecessor-version":[{"id":162170,"href":"https:\/\/prohoster.info\/cs\/wp-json\/wp\/v2\/posts\/89872\/revisions\/162170"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/cs\/wp-json\/wp\/v2\/media\/89873"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/cs\/wp-json\/wp\/v2\/media?parent=89872"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/cs\/wp-json\/wp\/v2\/categories?post=89872"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/cs\/wp-json\/wp\/v2\/tags?post=89872"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}