{"id":73949,"date":"2020-03-13T02:42:07","date_gmt":"2020-03-12T23:42:07","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/kak-my-v-sportmastere-vybirali-sistemu-keshirovaniya-chast-1"},"modified":"2020-03-13T02:42:07","modified_gmt":"2020-03-12T23:42:07","slug":"kak-my-v-sportmastere-vybirali-sistemu-keshirovaniya-chast-1","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sk\/blog\/administrirovanie\/kak-my-v-sportmastere-vybirali-sistemu-keshirovaniya-chast-1","title":{"rendered":"Ako sme v \u0160portmastere vyberali syst\u00e9m cacheovania. \u010cas\u0165 1","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ahoj! Vol\u00e1m sa Alexej Pjankov a som v\u00fdvoj\u00e1r v spolo\u010dnosti Sportmaster. V tomto pr\u00edspevku<\/a><\/noindex> som hovoril o tom, ako sa za\u010dala pr\u00e1ca na webovej str\u00e1nke Sportmaster v roku 2012, ak\u00e9 iniciat\u00edvy sa podarilo \"presadi\u0165\" a naopak, ak\u00e9 probl\u00e9my sme narazili.<\/p>\n

Dnes sa chcem podeli\u0165 o my\u0161lienky, ktor\u00e9 s\u00favisia s in\u00fdm t\u00e9matom \u2013 v\u00fdberom syst\u00e9mu cache pre java backend v administr\u00e1cii webovej str\u00e1nky. T\u00e1to t\u00e9ma m\u00e1 pre m\u0148a osobitn\u00fd v\u00fdznam \u2013 hoci sa pr\u00edbeh odohr\u00e1val len dva mesiace, tieto 60 dn\u00ed sme pracovali 12-16 hod\u00edn bez jedin\u00e9ho d\u0148a vo\u013ena. Nikdy predt\u00fdm som si nemyslel a nemohol ani predstavi\u0165, \u017ee sa d\u00e1 pracova\u0165 takto ve\u013ea.<\/p>\n

Preto text del\u00edm na dve \u010dasti, aby som to \u00faplne nezavalil. Naopak, prv\u00e1 \u010das\u0165 bude ve\u013emi jednoduch\u00e1 \u2014 pr\u00edprava, \u00favod, niektor\u00e9 \u00favahy o tom, \u010do je caching. Ak ste u\u017e sk\u00fasen\u00fd v\u00fdvoj\u00e1r alebo ste pracovali s cache, z technick\u00e9ho h\u013eadiska tu pravdepodobne ni\u010d nov\u00e9 nebude. Pre juniora v\u0161ak m\u00f4\u017ee by\u0165 tento mal\u00fd preh\u013ead u\u017eito\u010dn\u00fd, ak sa ocitne na takej kri\u017eovatke.<\/p>\n

\"Ako<\/a><\/noindex>
\n<\/a><\/noindex>
\nKe\u010f bola nov\u00e1 verzia webovej str\u00e1nky Sportmaster uveden\u00e1 do produkcie, d\u00e1ta pr\u00fadili sp\u00f4sobom, jemne povedan\u00e9, nie ve\u013emi pohodln\u00fdm. Z\u00e1kladom boli tabu\u013eky, ktor\u00e9 boli pripraven\u00e9 pre predch\u00e1dzaj\u00facu verziu webu (Bitrix), a ktor\u00e9 bolo potrebn\u00e9 prenies\u0165 do ETL, upravi\u0165 do nov\u00e9ho form\u00e1tu a obohati\u0165 r\u00f4znymi prvkami z desiatich \u010fal\u0161\u00edch syst\u00e9mov. Aby sa nov\u00e1 fotografia alebo popis produktu dostali na web, bolo potrebn\u00e9 \u010daka\u0165 do nasleduj\u00faceho d\u0148a \u2014 aktualiz\u00e1cia bola iba raz za noc, raz denne.<\/p>\n

Na za\u010diatku sme mali to\u013eko starost\u00ed v prv\u00fdch t\u00fd\u017ed\u0148och po uveden\u00ed do produkcie, \u017ee tak\u00e9to nepr\u00edjemnosti pre content managerov boli mali\u010dkos\u0165ou. Ale hne\u010f, ako sa v\u0161etko usadilo, pokra\u010doval rozvoj projektu \u2014 o nieko\u013eko mesiacov, na za\u010diatku roku 2015 sme za\u010dali akt\u00edvne vyv\u00edja\u0165 administr\u00e1ciu. V rokoch 2015 a 2016 v\u0161etko ide dobre, pravidelne vyd\u00e1vame aktualiz\u00e1cie a administr\u00e1cia pokr\u00fdva \u010doraz v\u00e4\u010d\u0161iu \u010das\u0165 pr\u00edpravy d\u00e1t a pripravujeme sa na to, \u017ee \u010doskoro na\u0161ej t\u00edmu zveria to najd\u00f4le\u017eitej\u0161ie a najn\u00e1ro\u010dnej\u0161ie \u2013 produktov\u00fd r\u00e1mec (\u00fapln\u00e1 pr\u00edprava a spr\u00e1va d\u00e1t pre v\u0161etky produkty). Ale v lete 2017, tesne pred spusten\u00edm produktov\u00e9ho r\u00e1mca, sa projekt ocitne v ve\u013emi zlo\u017eitej situ\u00e1cii \u2013 pr\u00e1ve kv\u00f4li probl\u00e9mom s cache. O tomto epiz\u00f3de chcem rozpr\u00e1va\u0165 v druhej \u010dasti tejto dvojdielnej publik\u00e1cie.<\/p>\n

V tomto pr\u00edspevku za\u010dnem z dia\u013eky a zhrniem niektor\u00e9 my\u0161lienky \u2013 predstavy o caching, ktor\u00e9 by bolo dobr\u00e9 prejs\u0165 pred ve\u013ek\u00fdm projektom.<\/p>\n

Ke\u010f nastane \u00faloha caching<\/h2>\n

\n\u00daloha caching sa neobjavuje len tak. Sme v\u00fdvoj\u00e1ri, p\u00ed\u0161eme softv\u00e9rov\u00fd produkt a chceme, aby bol \u017eiadan\u00fd. Ak je produkt \u017eiadan\u00fd a \u00faspe\u0161n\u00fd, u\u017e\u00edvatelia prich\u00e1dzaj\u00fa. A znovu prich\u00e1dzaj\u00fa, a e\u0161te raz. A ke\u010f je u\u017e\u00edvate\u013eov ve\u013ea, produkt sa st\u00e1va vysokon\u00e1ro\u010dn\u00fdm.<\/p>\n

V po\u010diato\u010dn\u00fdch f\u00e1zach nemysl\u00edme na optimaliz\u00e1ciu a v\u00fdkon k\u00f3du. Hlavn\u00e9 je \u2013 funk\u010dnos\u0165, r\u00fdchlo zavies\u0165 pilot a overi\u0165 hypot\u00e9zy. A ke\u010f sa za\u0165a\u017eenie zvy\u0161uje, vylep\u0161ujeme hardv\u00e9r. Zvy\u0161ujeme ho dvakr\u00e1t, trikr\u00e1t, p\u00e4\u0165kr\u00e1t, nech aj desa\u0165kr\u00e1t. Kdesi na tomto mieste \u2013 financie u\u017e nebud\u00fa sta\u010di\u0165. A ko\u013ekokr\u00e1t sa zv\u00fd\u0161i po\u010det pou\u017e\u00edvate\u013eov? Nebude to len 2-5-10, ale v pr\u00edpade \u00faspechu to bude od 100-1000 a a\u017e po 100 tis\u00edc. To znamen\u00e1, \u017ee sk\u00f4r alebo nesk\u00f4r sa vy\u017eaduje optimaliz\u00e1cia.<\/p>\n

Predpokladajme, \u017ee ur\u010dit\u00e1 \u010das\u0165 k\u00f3du (nazvime t\u00fato \u010das\u0165 funkciou) pracuje nepr\u00edjemne dlho a chceme skr\u00e1ti\u0165 \u010das vykon\u00e1vania. Funkcia \u2013 to m\u00f4\u017ee by\u0165 pr\u00edstup k datab\u00e1ze, m\u00f4\u017ee to by\u0165 vykon\u00e1vanie nejakej zlo\u017eitej logiky \u2013 hlavn\u00e9 je, \u017ee trv\u00e1 dlho. O ko\u013eko m\u00f4\u017eeme skr\u00e1ti\u0165 \u010das vykon\u00e1vania? V limite \u2013 m\u00f4\u017eeme skr\u00e1ti\u0165 na nulu, ni\u010d \u010falej. A ako m\u00f4\u017eeme skr\u00e1ti\u0165 \u010das vykon\u00e1vania na nulu? Odpove\u010f: \u00faplne vyl\u00fa\u010di\u0165 vykon\u00e1vanie. Namiesto toho \u2013 okam\u017eite vr\u00e1ti\u0165 v\u00fdsledok. A ako z\u00edska\u0165 v\u00fdsledok? Odpove\u010f: bu\u010f vypo\u010d\u00edta\u0165, alebo niekde nahliadnu\u0165. Vypo\u010d\u00edta\u0165 \u2013 to trv\u00e1 dlho. A nahliadnu\u0165 \u2013 to je napr\u00edklad zapam\u00e4ta\u0165 si ten v\u00fdsledok, ktor\u00fd funkcia vr\u00e1tila naposledy pri volan\u00ed s rovnak\u00fdmi parametrami.<\/p>\n

To put it simply, the implementation of the function doesn't matter to us. It's enough to know which parameters affect the result. Then, if we represent the parameter values as an object that can be used as a key in some storage \u2014 we can save the computation result and retrieve it the next time we call. If the read-write performance is faster than executing the function \u2013 we gain speed benefits. The gain can reach up to 100, 1000, or even 100,000 times (10^5 is more of an exception, but in the case of a heavily lagging database - it's quite possible).<\/p>\n

Basic requirements for the caching system<\/h2>\n

\nThe first requirement that might apply to the caching system is fast read speed and, to a lesser extent, write speed. This is true, but only until we roll the system into production.<\/p>\n

Let's consider a case.<\/p>\n

Suppose we provided the hardware for the current load and are now gradually implementing caching. The user base grows slightly, load increases \u2013 we add caches here and there. This continues for a while, and now heavy functions are hardly called \u2014 the main load falls entirely on the cache. The number of users has increased N times during this period.<\/p>\n

And if the initial hardware capacity could have been 2-5 times, then with the help of caching, we could have boosted performance by 10 times or, in the best case, by 100 times, and in some instances, even 1000 times. That is, on the same hardware \u2013 we're processing 100 times more requests. Wonderful, we deserve a reward!<\/p>\n

But now, at one point, by chance, the system failed and the cache crashed. Nothing unusual \u2013 after all, the cache was chosen based on the requirement of 'high read and write speed, the rest doesn't matter.'<\/p>\n

Regarding the initial load, we had a 2-5 times hardware capacity, while the load during this time increased by 10-100 times. With the help of caching, we eliminated calls for heavy functions, and therefore everything was running smoothly. But now, without the cache \u2013 how much will our system drop? What will happen? The system will crash.<\/p>\n

Even if our cache didn't crash, but just cleared for a period \u2013 it will need to be warmed up, and that will take some time. During that time, the main load will fall on the functionality.<\/p>\n

V\u00fdstup: vysoko za\u0165a\u017een\u00e9 projekty v produkcii vy\u017eaduj\u00fa od syst\u00e9mu cachingu nielen vysok\u00fa r\u00fdchlos\u0165 \u010d\u00edtania a z\u00e1pisu, ale aj zachovanie d\u00e1t a odolnos\u0165 vo\u010di chyb\u00e1m.<\/p>\n

M\u00faky v\u00fdberu<\/h2>\n

\nV projekte s administr\u00e1torsk\u00fdm rozhran\u00edm \u2013 v\u00fdber prebiehal takto: najsk\u00f4r sme nain\u0161talovali Hazelcast, preto\u017ee sme u\u017e mali s t\u00fdmto produktom sk\u00fasenosti z hlavnej str\u00e1nky. Ale tak\u00fdto v\u00fdber sa uk\u00e1zal by\u0165 ne\u0161\u0165astn\u00fd \u2013 pod na\u0161\u00edm za\u0165a\u017een\u00edm funguje Hazelcast nielen pomaly, ale hrozne pomaly. A s term\u00ednmi uvedenia do produkcie sme sa u\u017e v tom \u010dase zaviazali.<\/p>\n

Spoiler: ako sa vlastne vyvinuli okolnosti, \u017ee sme prehliadli tak\u00fato nev\u00fdhodu a dostali sa do \u0165a\u017ekej a nap\u00e4tej situ\u00e1cie \u2013 o tom poviem v druhej \u010dasti \u2013 a ako sme sa dostali, a ako sme sa vymotali. Ale teraz \u2013 poviem len to, \u017ee to bol siln\u00fd stres a \u201eprem\u00fd\u0161\u013ea\u0165 \u2013 akosi sa mi nechce, trasieme f\u013ea\u0161ou\u201c. \u201eTraseme f\u013ea\u0161ou\u201c \u2013 to je tie\u017e spoiler, viac o tom nesk\u00f4r.<\/p>\n

\u010co sme urobili:<\/p>\n

    \n
  1. Sklad\u00e1me zoznam v\u0161etk\u00fdch syst\u00e9mov, ktor\u00e9 odpor\u00fa\u010da Google a StackOverflow. Nie\u010do viac ako 30.<\/li>\n
  2. P\u00ed\u0161eme testy so z\u00e1\u0165a\u017eou, ktor\u00e1 je typick\u00e1 pre produkciu. Na tento \u00fa\u010del sme zaznamenali d\u00e1ta, ktor\u00e9 prech\u00e1dzaj\u00fa syst\u00e9mom v produk\u010dnom prostred\u00ed \u2013 tak\u00fd sniff\u00e9r pre d\u00e1ta nie v sieti, ale v r\u00e1mci syst\u00e9mu. Do testov sme spustili presne tieto d\u00e1ta.<\/li>\n
  3. Cel\u00fd t\u00edm, ka\u017ed\u00fd si vyber\u00e1 \u010fal\u0161\u00ed syst\u00e9m zo zoznamu, nastavuje ho, sp\u00fa\u0161\u0165a testy. Ak test neprejde, nezvl\u00e1da z\u00e1\u0165a\u017e \u2013 vyrad\u00edme, prejdeme na \u010fal\u0161\u00ed v porad\u00ed.<\/li>\n
  4. Na 17. syst\u00e9me bolo jasn\u00e9, \u017ee to v\u0161etko je bezn\u00e1dejne. Dos\u0165 trasenia f\u013ea\u0161ou, je \u010das zamyslie\u0165 sa v\u00e1\u017ene.<\/li>\n<\/ol>\n

    \nAle to je varianta, ke\u010f treba vybra\u0165 syst\u00e9m, ktor\u00fd \u201eprejde r\u00fdchlos\u0165ou\u201c v vopred pripraven\u00fdch testoch. A \u010do ak tak\u00e9 testy e\u0161te nie s\u00fa a chcete vybra\u0165 r\u00fdchlo?<\/p>\n

    Modelujeme tak\u00fato variantu (\u0165a\u017eko si predstavi\u0165, \u017ee mid-level+ v\u00fdvoj\u00e1r \u017eije v pr\u00e1zdne, a v \u010dase v\u00fdberu e\u0161te nem\u00e1 jasne stanoven\u00e9 preferencie, ak\u00fd produkt vysk\u00fa\u0161a\u0165 ako prv\u00fd \u2014 preto, \u010fal\u0161ie \u00favahy s\u00fa sk\u00f4r teoretick\u00e9ho charakteru\/filosofia\/o juniorovi).<\/p>\n

    Ujasnime si po\u017eiadavky a za\u010dneme vybera\u0165 rie\u0161enie z krabice. Pre\u010do vynach\u00e1dza\u0165 koleso: p\u00f4jdeme a vezmeme hotov\u00fd syst\u00e9m cachingu.<\/p>\n

    Ak sa len za\u010d\u00ednate a budete googli\u0165, porad\u00edm v\u00e1m pribli\u017en\u00fa sekvenciu. Najprv natraf\u00edte na Redis, ktor\u00fd je ve\u013emi zn\u00e1my. Potom zist\u00edte, \u017ee existuje EhCache, najstar\u0161\u00ed a osved\u010den\u00fd syst\u00e9m. \u010ealej budeme hovori\u0165 o Tarantool, dom\u00e1cej technol\u00f3gii s unik\u00e1tnym pr\u00edstupom. A takisto o Ignite, preto\u017ee moment\u00e1lne za\u017e\u00edva vzostup popularity a m\u00e1 podporu SberTechu. Nakoniec sa spomenie aj Hazelcast, preto\u017ee sa \u010dasto objavuje vo svete podnikov.<\/p>\n

    T\u00fdmto zoznam nekon\u010d\u00ed, existuje desiatky syst\u00e9mov. My si vezmeme len jeden. Vyberieme si 5 syst\u00e9mov na \"s\u00fa\u0165a\u017e kr\u00e1sy\" a uskuto\u010dn\u00edme v\u00fdber. Kto sa stane v\u00ed\u0165azom?<\/p>\n

    K\u013eu\u010d-hodnota<\/h3>\n

    \n\u010c\u00edtame, \u010do p\u00ed\u0161u na ofici\u00e1lnom webe.
    \n    K\u013eu\u010d-hodnota<\/a><\/noindex> \u2014 opensource projekt. Pon\u00faka in-memory \u00falo\u017eisko, mo\u017enos\u0165 ukladania na disk, automatick\u00e9 rozdelenie na part\u00edcie, vysok\u00fa dostupnos\u0165 a obnovu po sie\u0165ov\u00fdch preru\u0161eniach.<\/p>\n

    V\u0161etko sa zd\u00e1 by\u0165 skvel\u00e9, m\u00f4\u017eeme ho vzia\u0165 a implementova\u0165 \u2014 rob\u00ed v\u0161etko, \u010do potrebujeme. Ale pozrime sa len tak pre zauj\u00edmavos\u0165 na ostatn\u00fdch kandid\u00e1tov.<\/p>\n

    EhCache<\/h3>\n

    \nEhCache<\/a><\/noindex> \u2014 \"naj\u0161ir\u0161ie pou\u017e\u00edvan\u00e1 cache pre Java\" (preklad sloganu z ofici\u00e1lnej str\u00e1nky). Taktie\u017e opensource. Tu ch\u00e1peme, \u017ee Redis nie je ur\u010den\u00fd pre Java, ide o v\u0161eobecn\u00fd syst\u00e9m, a na jeho interakciu potrebuje obal. EhCache by bola pohodlnej\u0161ia. \u010co e\u0161te syst\u00e9m s\u013eubuje? Spo\u013eahlivos\u0165, preverenos\u0165, plnofunk\u010dnos\u0165. A je najroz\u0161\u00edrenej\u0161ia, cacheuje terabajty d\u00e1t.<\/p>\n

    Redis bol zabudnut\u00fd, som pripraven\u00fd zvoli\u0165 EhCache.<\/p>\n

    Ale pocit patriotizmu ma nab\u00e1da pozrie\u0165 sa, \u010do je dobr\u00e9 na Tarantool.<\/p>\n

    Tarantool<\/h3>\n

    \nTarantool<\/a><\/noindex> \u2014 zav\u00e1dza n\u00e1s ozna\u010den\u00edm \"Platforma na integr\u00e1ciu d\u00e1t v re\u00e1lnom \u010dase\". Znie to ve\u013emi zlo\u017eito, preto si d\u00f4kladne pre\u010d\u00edtame str\u00e1nku a nach\u00e1dzame siln\u00e9 vyhl\u00e1senie: \"Cacheuje 100% d\u00e1t v opera\u010dnej pam\u00e4ti\". To by malo vzbudzova\u0165 ot\u00e1zky \u2014 preto\u017ee d\u00e1t m\u00f4\u017ee by\u0165 omnoho viac, ne\u017e je pam\u00e4\u0165. Vysvetlen\u00edm je, \u017ee pri z\u00e1pise d\u00e1t na disk z pam\u00e4te Tarantool neprech\u00e1dza serializ\u00e1ciou. Namiesto toho vyu\u017e\u00edva n\u00edzko\u00farov\u0148ov\u00e9 vlastnosti syst\u00e9mu, ke\u010f je pam\u00e4\u0165 jednoducho mapovan\u00e1 na s\u00faborov\u00fd syst\u00e9m s ve\u013emi dobr\u00fdmi ukazovate\u013emi I\/O. Skr\u00e1tka, urobili to celkom \u00fa\u017easne a \u0161ikovne.<\/p>\n

    Pozrime sa na realiz\u00e1cie: Mail.ru firemn\u00e1 dia\u013enica, Avito, Beeline, MegaFon, Alfa-Bank, Gazprom\u2026<\/p>\n

    Ak e\u0161te existovali nejak\u00e9 pochybnosti o Tarantool, tak implement\u00e1cia v Mastercard ma definit\u00edvne presvied\u010da. Beriem Tarantool.<\/p>\n

    Ale predsa len\u2026<\/p>\n

    Ignite<\/h3>\n

    \n\u2026 s\u00fa tu e\u0161te Ignite<\/a><\/noindex>, deklarovan\u00e9 ako \u201ein-memory v\u00fdpo\u010dtov\u00e1 platforma\u2026 in-memory r\u00fdchlosti na petabajtoch d\u00e1t\u201c. Aj tu je ve\u013ea v\u00fdhod: distribuovan\u00fd in-memory cache, najr\u00fdchlej\u0161ie key-value \u00falo\u017eisko a cache, horizont\u00e1lne \u0161k\u00e1lovanie, vysok\u00e1 dostupnos\u0165, pr\u00edsna integrita. V skratke, najr\u00fdchlej\u0161\u00ed je Ignite.<\/p>\n

    Implement\u00e1cie: Sberbank, American Airlines, Yahoo! Japan. A potom sa e\u0161te dozved\u00e1m, \u017ee Ignite nie je len tak implementovan\u00fd v Sberbank, ale t\u00edm SberTechu posiela svojich \u013eud\u00ed do t\u00edmu samotn\u00e9ho Ignite, aby vylep\u0161ili produkt. To ma \u00faplne presvied\u010da a som pripraven\u00fd zobra\u0165 Ignite.<\/p>\n

    \u00daplne mi nie je jasn\u00e9, pre\u010do sa pozer\u00e1m na piaty bod.<\/p>\n

    Hazelcast<\/h3>\n

    \nVstupujem na str\u00e1nku Hazelcast<\/a><\/noindex>, \u010d\u00edtam. A ukazuje sa, \u017ee najr\u00fdchlej\u0161ie rie\u0161enie pre distribuovan\u00e9 cacheovanie je Hazelcast. Je r\u00e1dovo r\u00fdchlej\u0161\u00ed ako v\u0161etky ostatn\u00e9 rie\u0161enia a je skuto\u010dn\u00fdm l\u00eddrom v oblasti in-memory data grid. V tomto kontexte vzia\u0165 nie\u010do in\u00e9 \u2014 nebra\u0165 sa v\u00e1\u017ene. A navy\u0161e pou\u017e\u00edva redundantn\u00e9 ulo\u017eenie \u00fadajov pre nepretr\u017eit\u00fa prev\u00e1dzku klastrov bez straty \u00fadajov.<\/p>\n

    Vsetko, som pripraven\u00fd zobra\u0165 Hazelcast.<\/p>\n

    Porovnanie<\/h2>\n

    \nAle ak sa pozrieme, v\u0161etk\u00fdch p\u00e4\u0165 kandid\u00e1tov je pop\u00edsan\u00fdch tak, \u017ee ka\u017ed\u00fd z nich je najlep\u0161\u00ed. Ako si vybra\u0165? M\u00f4\u017eeme sa pozrie\u0165, ktor\u00fd z nich je najpopul\u00e1rnej\u0161\u00ed, h\u013eada\u0165 porovnania a boles\u0165 hlavy sa rozplynie.<\/p>\n

    N\u00e1jdeme tak\u00fd preh\u013ead<\/a><\/noindex>, vyber\u00e1me na\u0161ich 5 syst\u00e9mov.<\/p>\n

    \"Ako
    \n
    \nTu s\u00fa zoraden\u00e9: na vrchu Redis, na druhom mieste \u2014 Hazelcast, z\u00edskavaj\u00fa popularitu Tarantool a Ignite, EhCache zost\u00e1va na rovnakom mieste. <\/p>\n

    Ale pozrime sa na met\u00f3du v\u00fdpo\u010dtu<\/a><\/noindex>: odkazy na webov\u00e9 str\u00e1nky, v\u0161eobecn\u00fd z\u00e1ujem o syst\u00e9m, pracovn\u00e9 ponuky \u2014 skvel\u00e9! Teda, ke\u010f mi syst\u00e9m spadne, poviem: \u201eNie, je predsa spo\u013eahliv\u00fd! Tu je ve\u013ea pracovn\u00fdch pon\u00fak\u2026\u201c. Tak\u00e9to jednoduch\u00e9 porovnanie sa nehod\u00ed.<\/p>\n

    V\u0161etky tieto syst\u00e9my nie s\u00fa len syst\u00e9my na cacheovanie. Maj\u00fa tie\u017e ve\u013emi ve\u013ea funkci\u00ed, vr\u00e1tane \u2013 ke\u010f nie s\u00fa d\u00e1ta posielan\u00e9 klientovi na spracovanie, ale opa\u010dne: k\u00f3d, ktor\u00fd treba vykona\u0165 na \u00fadajoch, sa pren\u00e1\u0161a na server, tam sa vykon\u00e1va a v\u00fdsledok sa vracia. A ako samostatn\u00fd syst\u00e9m pre cacheovanie sa \u010dasto ani neber\u00fa do \u00favahy.<\/p>\n

    Dobre, nevzd\u00e1vame sa, n\u00e1jdeme priamu kompar\u00e1ciu syst\u00e9mov. Zoberieme dva najvy\u0161\u0161ie varianty \u2014 Redis a Hazelcast. Zauj\u00edma n\u00e1s r\u00fdchlos\u0165, pod\u013ea tohto parametra ich porovn\u00e1me.<\/p>\n

    Hz vs Redis<\/h3>\n

    \nN\u00e1jdeme tak\u00fa porovnanie<\/a><\/noindex>:
    \n\"Ako
    \n
    \nModr\u00e1 je Redis, \u010derven\u00e1 je Hazelcast. Hazelcast neust\u00e1le vyhr\u00e1va a to m\u00e1 svoje d\u00f4vody: je viacvl\u00e1knov\u00fd, vysoko optimalizovan\u00fd, ka\u017ed\u00fd vl\u00e1kno pracuje so svojou part\u00edciou, preto s\u00fa tam \u017eiadne z\u00e1mky. Redis je jednovl\u00e1knov\u00fd, nevyu\u017e\u00edva v\u00fdhody modern\u00fdch viacjadrov\u00fdch CPU. Hazelcast m\u00e1 asynchr\u00f3nne I\/O, zatia\u013e \u010do Redis-Jedis pracuje s blokuj\u00facimi socketmi. Nakoniec, Hazelcast pou\u017e\u00edva bin\u00e1rny protokol, zatia\u013e \u010do Redis je orientovan\u00fd na text, tak\u017ee je menej efekt\u00edvny.<\/p>\n

    Pre istotu sa pozrime na \u010fal\u0161\u00ed zdroj porovnania. \u010co n\u00e1m uk\u00e1\u017ee?<\/p>\n

    Redis vs Hz<\/h3>\n

    \nE\u0161te jedno porovnanie<\/a><\/noindex>:
    \n\"Ako
    \n
    \nTu je naopak, \u010derven\u00e1 je Redis. To znamen\u00e1, \u017ee Redis po v\u00fdkonnostnej str\u00e1nke prekon\u00e1va Hazelcast. V prvom porovnan\u00ed vyhr\u00e1val Hazelcast, v druhom \u2013 Redis.     Tu je<\/a><\/noindex> ve\u013emi presne vysvetlen\u00e9, pre\u010do v predch\u00e1dzaj\u00facom porovnan\u00ed vyhral Hazelcast.<\/p>\n

    Ukazuje sa, \u017ee v\u00fdsledok prv\u00e9ho bol vlastne fal\u0161ovan\u00fd: Redis bol pou\u017eit\u00fd v z\u00e1kladnej verzii, zatia\u013e \u010do Hazelcast bol prisp\u00f4soben\u00fd testovaciemu pr\u00edpadu. Tak\u017ee dost\u00e1vame: po prv\u00e9, nikomu sa ned\u00e1 veri\u0165, a po druh\u00e9, ke\u010f si u\u017e vyberieme syst\u00e9m, mus\u00edme ho e\u0161te spr\u00e1vne nastavi\u0165. Tieto nastavenia zah\u0155\u0148aj\u00fa desiatky, takmer stovky parametrov.<\/p>\n

    Treseme f\u013ea\u0161u<\/h2>\n

    \nA cel\u00fd proces, ktor\u00fd sme teraz vykonali, m\u00f4\u017eem vysvetli\u0165 takouto metaforou: \"Treseme f\u013ea\u0161u\". To znamen\u00e1, \u017ee teraz nie je potrebn\u00e9 programova\u0165, teraz je najd\u00f4le\u017eitej\u0161ie vedie\u0165 \u010d\u00edta\u0165 stackoverflow. A m\u00e1m v t\u00edme \u010dloveka, profesion\u00e1la, ktor\u00fd presne takto pracuje v kritick\u00fdch momentoch.<\/p>\n

    \u010co rob\u00ed? Vid\u00ed nefunk\u010dn\u00fd komponent, vid\u00ed stack trace, vyberie niektor\u00e9 slov\u00e1 z neho (ak\u00e9 presne \u2013 to je jeho expert\u00edza v programe), h\u013ead\u00e1 v Google, n\u00e1jde stackoverflow medzi odpove\u010fami. Ne\u010d\u00edtaj\u00fac, nepre\u017e\u00edvaj\u00fac, medzi odpove\u010fami na ot\u00e1zku \u2013 vyberie nie\u010do, \u010do je najviac podobn\u00e9 n\u00e1vrhu \"urobi\u0165 toto a toto\" (vybra\u0165 tak\u00fa odpove\u010f \u2013 to je jeho talent, preto\u017ee to nie v\u017edy je presne t\u00e1 odpove\u010f, ktor\u00e1 dostala najviac hlasov), aplikuje, pozrie: ak sa nie\u010do zmenilo, tak je to skvel\u00e9. Ak sa nezmenilo \u2013 vraciame sa sp\u00e4\u0165. A opakujeme spustenie-kontrolu-h\u013eadanie. A t\u00fdmto intu\u00edciou dosiahne, \u017ee za nejak\u00fd \u010das k\u00f3d funguje. Nevie pre\u010do, nevie, \u010do spravil, nevie to vysvetli\u0165. Ale! Ten z\u00e1zrak funguje. A \"po\u017eiar je uhasen\u00fd\". Teraz rozober\u00e1me, \u010do sme spravili. Ke\u010f program funguje \u2013 je to stokr\u00e1t jednoduch\u0161ie. A v\u00fdrazne \u0161etr\u00ed \u010das.<\/p>\n

    Tento sp\u00f4sob sa ve\u013emi dobre ilustruje na takomto pr\u00edklade.<\/p>\n

    Niekedy bolo ve\u013emi popul\u00e1rne sklada\u0165 plachetnicu do f\u013ea\u0161e. Plachetnica je pritom ve\u013ek\u00e1 a krehk\u00e1, a hrdlo f\u013ea\u0161e je ve\u013emi \u00fazke, ned\u00e1 sa jej tam dosta\u0165. Ako ju teda zlo\u017ei\u0165?<\/p>\n

    \"Ako
    \n
    \nExistuje tak\u00e1 met\u00f3da, ve\u013emi r\u00fdchla a ve\u013emi efekt\u00edvna.<\/p>\n

    Lo\u010f sa sklad\u00e1 z mno\u017estva drobnost\u00ed: pali\u010diek, \u0161n\u00fariek, plachiet, lepidla. To v\u0161etko d\u00e1me do f\u013ea\u0161e.
    \nBereme f\u013ea\u0161u oboma rukami a za\u010dneme ju trasenie. Traseme ju, traseme. A zvy\u010dajne \u2013 dopad\u00e1 to \u00faplne zle. Ale niekedy. Niekedy to dopadne ako lo\u010f! Presnej\u0161ie, nie\u010do, \u010do vyzer\u00e1 ako lo\u010f.<\/p>\n

    To nie\u010do ukazujeme niekomu: \u201eSeroha, vid\u00ed\u0161!?\u201c. A naozaj, z dia\u013eky \u2013 vyzer\u00e1 to ako lo\u010f. Ale \u010falej to nie je mo\u017en\u00e9 pusti\u0165.<\/p>\n

    Existuje aj in\u00fd sp\u00f4sob. Pou\u017e\u00edvaj\u00fa ho pokro\u010dilej\u0161\u00ed, tak\u00ed hakeri.<\/p>\n

    Dal som tak\u00e9mu chlapcovi \u00falohu, on to v\u0161etko urobil a odi\u0161iel. A pozrie\u0161 sa \u2013 akoby to bolo hotov\u00e9. Ale po chv\u00edli, ke\u010f treba dodato\u010dne spracova\u0165 k\u00f3d \u2013 za\u010dne tam tak\u00e9 nie\u010do kv\u00f4li nemu... Na\u0161\u0165astie, u\u017e bol dos\u0165 \u010faleko pre\u010d. T\u00edto chlapci robia na pr\u00edklade f\u013ea\u0161e takto: vid\u00edte, tam, kde je dno \u2013 sklo sa oh\u00fdba. A nie je celkom jasn\u00e9, \u010di je prieh\u013eadn\u00e9 alebo nie. Tak \u201ehakeri\u201c zre\u017e\u00fa toto dno, vlo\u017eia tam lo\u010f, dno potom op\u00e4\u0165 prilepia a vyzer\u00e1 to, akoby to tak malo by\u0165.<\/p>\n

    Z poh\u013eadu zadania \u00falohy sa v\u0161etko zd\u00e1 spr\u00e1vne. Ale na pr\u00edklade lod\u00ed: pre\u010do v\u00f4bec robi\u0165 t\u00fa lo\u010f, komu to vlastne sl\u00fa\u017ei? F\u0443\u043d\u043a\u010dnos\u0165 nem\u00e1 \u017eiadnu. Zvy\u010dajne s\u00fa tak\u00e9to lode dary ve\u013emi vysokopostaven\u00fdm osob\u00e1m, ktor\u00e9 si ich vystavuj\u00fa na polici nad sebou ako symbol, ako znak. A ak tak\u00fdto \u010dlovek, ved\u00faci ve\u013ek\u00e9ho podniku alebo vysokopostaven\u00fd \u00faradn\u00edk, m\u00e1 tak\u00fato katastrofu so zrezan\u00fdm hrdlom ako vlajku, bude lep\u0161ie, ak sa o tom nikdy nedozvie. Tak, a ako sa nakoniec robia tieto lode, ktor\u00e9 je mo\u017en\u00e9 darova\u0165 d\u00f4le\u017eitej osobnosti?<\/p>\n

    Jedin\u00e9 miesto, s ktor\u00fdm sa naozaj ned\u00e1 ni\u010d robi\u0165, je trup. A trup lode prech\u00e1dza pr\u00e1ve cez hrdlo. Zatia\u013e \u010do sa lo\u010f sklad\u00e1 mimo f\u013ea\u0161e. Ale nie je to len tak, posklada\u0165 lo\u010f, to je skuto\u010dn\u00e9 umeleck\u00e9 remeslo. Do jej s\u00fa\u010dast\u00ed sa prid\u00e1vaj\u00fa \u0161peci\u00e1lne p\u00e1ky, ktor\u00e9 potom umo\u017e\u0148uj\u00fa ich zdvihn\u00fa\u0165. Napr\u00edklad sa zlo\u017eia plachty, starostlivo sa vlo\u017eia dovn\u00fatra, a potom sa pomocou pinzety ve\u013emi prec\u00edzne, presne, vytiahnu a zdvihn\u00fa. V\u00fdsledkom je umeleck\u00e9 dielo, ktor\u00e9 mo\u017eno s \u010dist\u00fdm svedom\u00edm a hrdos\u0165ou darova\u0165.<\/p>\n

    A ak chceme, aby bol projekt \u00faspe\u0161n\u00fd \u2013 v t\u00edme by mal by\u0165 aspo\u0148 jeden zlatn\u00edk. Ten, kto sa star\u00e1 o kvalitu produktu a zoh\u013ead\u0148uje v\u0161etky aspekty, ani v stresov\u00fdch momentoch, ke\u010f okolnosti vy\u017eaduj\u00fa, aby sa nie\u010do urobilo r\u00fdchlo na \u00fakor d\u00f4le\u017eit\u00e9ho. V\u0161etky \u00faspe\u0161n\u00e9 projekty, ktor\u00e9 s\u00fa odoln\u00e9 a pre\u017eili sk\u00fa\u0161ku \u010dasom, s\u00fa postaven\u00e9 na tomto princ\u00edpe. Maj\u00fa v sebe nie\u010do ve\u013emi presn\u00e9 a jedine\u010dn\u00e9, nie\u010do, \u010do vyu\u017e\u00edva v\u0161etky dostupn\u00e9 mo\u017enosti. V pr\u00edpade lode vo f\u013ea\u0161i sa hr\u00e1 s t\u00fdm, \u017ee trup lode prech\u00e1dza cez hrdlo.<\/p>\n

    Vr\u00e1tim sa k \u00falohe v\u00fdberu n\u00e1\u0161ho cache servera, ako by sa tento pr\u00edstup dal aplikova\u0165? Navrhujem tak\u00fa mo\u017enos\u0165 v\u00fdberu zo v\u0161etk\u00fdch syst\u00e9mov, ktor\u00e9 s\u00fa \u2013 netraseme so f\u013ea\u0161ou, nevyber\u00e1me, ale pozrieme sa, \u010do v nich v\u00f4bec je, na \u010do je potrebn\u00e9 d\u00e1va\u0165 pozor pri v\u00fdbere syst\u00e9mu.<\/p>\n

    Kde h\u013eada\u0165 bottleneck<\/h2>\n

    \nSk\u00fasme netrias\u0165 f\u013ea\u0161ou, nepreh\u013ead\u00e1va\u0165 v\u0161etko, \u010do m\u00e1me po porad\u00ed, ale pozrime sa, ak\u00e9 \u00falohy vznikn\u00fa, ak n\u00e1hodou, pre svoju \u00falohu \u2013 navrhn\u00fa\u0165 tak\u00fd syst\u00e9m samostatne. Samozrejme, nesklad\u00e1me bicykel, ale vyu\u017eijeme t\u00fato sch\u00e9mu, aby sme sa zorientovali, na ktor\u00e9 aspekty sa zamera\u0165 v popisoch produktov. Narysujeme tak\u00fa sch\u00e9mu.<\/p>\n

    \"Ako
    \n
    \nAk je syst\u00e9m distribuovan\u00fd, znamen\u00e1 to, \u017ee budeme ma\u0165 viac serverov (6). Predpokladajme, \u017ee \u0161tyri (je to pohodln\u00e9 zobrazi\u0165 na obr\u00e1zku, ale samozrejme, ich m\u00f4\u017ee by\u0165 ko\u013eko chce). Ak s\u00fa servery na r\u00f4znych uzloch, znamen\u00e1 to, \u017ee na nich v\u0161etk\u00fdch be\u017e\u00ed nejak\u00fd k\u00f3d, ktor\u00fd zais\u0165uje, aby tieto uzly vytvorili klaster a v pr\u00edpade preru\u0161enia \u2013 sa spojili, spoznali navz\u00e1jom.<\/p>\n

    E\u0161te potrebujeme k\u00f3d-logiku (2), ktor\u00e1 sa t\u00fdka cacheovania. S t\u00fdmto k\u00f3dom interaguj\u00fa klienti prostredn\u00edctvom ist\u00e9ho API. Klientsky k\u00f3d (1) m\u00f4\u017ee by\u0165 ako v r\u00e1mci tej istej JVM, tak sa na\u0148 m\u00f4\u017ee odkazova\u0165 aj cez sie\u0165. Logika implementovan\u00e1 vo vn\u00fatri spo\u010d\u00edva v rozhodovan\u00ed, ktor\u00e9 objekty v cache necha\u0165 a ktor\u00e9 odstr\u00e1ni\u0165. Na uchov\u00e1vanie cache pou\u017e\u00edvame pam\u00e4\u0165 (3), ale ak bude potrebn\u00e9, \u010das\u0165 d\u00e1t m\u00f4\u017eeme ulo\u017ei\u0165 aj na disku (4).<\/p>\n

    Pozrime sa, v ktor\u00fdch \u010dastiach bude doch\u00e1dza\u0165 k za\u0165a\u017eeniu. Vlastne, za\u0165a\u017eovan\u00e9 bud\u00fa ka\u017ed\u00e1 \u0161\u00edpka a ka\u017ed\u00fd uzol. Po prv\u00e9, medzi klientsk\u00fdm k\u00f3dom a API, ak ide o sie\u0165ov\u00fa interakciu, pokles m\u00f4\u017ee by\u0165 dos\u0165 v\u00fdrazn\u00fd. Po druh\u00e9, v r\u00e1mci samotn\u00e9ho API \u2013 ak to prehn\u00e1me s komplexnou logikou, m\u00f4\u017eeme narazi\u0165 na CPU. A bolo by dobr\u00e9, aby logika nepou\u017e\u00edvala pam\u00e4\u0165 zbyto\u010dne. A zost\u00e1va interakcia so s\u00faborov\u00fdm syst\u00e9mom \u2013 v be\u017enej variantu to je serializova\u0165 \/ obnovi\u0165 a zap\u00edsa\u0165 \/ pre\u010d\u00edta\u0165.<\/p>\n

    \u010ealej interakcia s klastrom. Pravdepodobne bude v tej istej s\u00fastave, ale m\u00f4\u017ee by\u0165 aj oddelene. Tu je tie\u017e potrebn\u00e9 zoh\u013eadni\u0165 prenos d\u00e1t k nemu, r\u00fdchlos\u0165 serializ\u00e1cie d\u00e1t a interakci\u00ed medzi klastrom.<\/p>\n

    Teraz, z jednej strany \u2013 m\u00f4\u017eeme si predstavi\u0165, \"ak\u00e9 kolieska sa bud\u00fa to\u010di\u0165\" v cache-syst\u00e9me pri sprac\u00favan\u00ed po\u017eiadaviek od n\u00e1\u0161ho k\u00f3du, a z druhej strany \u2013 m\u00f4\u017eeme odhadn\u00fa\u0165, ak\u00e9 a ko\u013eko po\u017eiadaviek n\u00e1\u0161 k\u00f3d na tento syst\u00e9m vygeneruje. To je dostato\u010dn\u00e9 na to, aby sme urobili viac-menej rozumn\u00fd v\u00fdber \u2013 prisp\u00f4sobi\u0165 syst\u00e9m na\u0161ej potrebe.<\/p>\n

    Hazelcast<\/b><\/p>\n

    Pozrime sa, ako tak\u00e9 rozlo\u017eenie aplikova\u0165 na n\u00e1\u0161 zoznam. Napr\u00edklad, Hazelcast.<\/p>\n

    Aby sme mohli ulo\u017ei\u0165 \/ z\u00edska\u0165 d\u00e1ta z Hazelcast, klientsky k\u00f3d sa obracia (1) na API. Hz umo\u017e\u0148uje spusti\u0165 server ako embedded, a v tomto pr\u00edpade je pr\u00edstup k API \u2013 to je volanie met\u00f3dy vo vn\u00fatri JVM, \u010do m\u00f4\u017eeme pova\u017eova\u0165 za bezplatn\u00e9.<\/p>\n

    Aby logika v (2) fungovala, Hz sa opiera o hash z bajtov\u00e9ho po\u013ea serializovan\u00e9ho k\u013e\u00fa\u010da \u2013 to znamen\u00e1, \u017ee serializ\u00e1cia k\u013e\u00fa\u010da prebehne v ka\u017edom pr\u00edpade. To je nevyhnutn\u00fd overhead pre Hz.
    \nEviction-strat\u00e9gie s\u00fa dobre implementovan\u00e9, ale pre \u0161peci\u00e1lne pr\u00edpady \u2013 je mo\u017en\u00e9 pripoji\u0165 aj vlastn\u00e9. O t\u00fato \u010das\u0165 sa netreba ob\u00e1va\u0165.<\/p>\n

    \u00dalo\u017eisko (4) je mo\u017en\u00e9 pripoji\u0165. Skvel\u00e9. Interakcia (5) pre embedded sa d\u00e1 pova\u017eova\u0165 za okam\u017eit\u00fa. V\u00fdmena d\u00e1t medzi uzlami v clustri (6) \u2013 \u00e1no, t\u00e1to existuje. Je to pr\u00ednos pre dostupnos\u0165 na \u00fakor r\u00fdchlosti. Zn\u00ed\u017eenie ceny umo\u017e\u0148uje Hz-funkcia Near-cache \u2013 d\u00e1ta z\u00edskan\u00e9 z in\u00fdch uzlov clustra bud\u00fa cachovan\u00e9.<\/p>\n

    \u010co je mo\u017en\u00e9 v tak\u00fdch podmienkach urobi\u0165 pre zv\u00fd\u0161enie r\u00fdchlosti?<\/p>\n

    Napr\u00edklad, aby sa predi\u0161lo serializ\u00e1cii k\u013e\u00fa\u010da v (2) \u2013 nad Hazelcast pripoji\u0165 \u010fal\u0161\u00ed cache pre najhor\u00facej\u0161ie d\u00e1ta. Vo Sportmasteri zvolili na tento \u00fa\u010del Caffeine.<\/p>\n

    Pre nastavenie na \u00farovni (6) s\u00fa v Hz navrhnut\u00e9 dva typy ukladania: IMap a ReplicatedMap.
    \n\"Ako
    \n
    \nStoj\u00ed za to poveda\u0165, ako sa Hazelcast dostal do technologick\u00e9ho stacku Sportmasteru.<\/p>\n

    V roku 2012, ke\u010f sme pracovali na prvom pilote bud\u00faceho webu, pr\u00e1ve Hazelcast sa uk\u00e1zal ako prv\u00fd odkaz, ktor\u00fd vyh\u013eadal vyh\u013ead\u00e1va\u010d. Zozn\u00e1menie sa za\u010dalo \"na prv\u00fd pokus\" \u2013 zaujalo n\u00e1s, \u017ee len dve hodiny po pripojen\u00ed Hz do syst\u00e9mu \u2013 fungoval. A fungoval dobre. Do konca d\u0148a sme dop\u00edsali nieko\u013eko testov, te\u0161ili sa. A t\u00e1to rezerva entuziazmu sta\u010dila na prekonanie prekvapen\u00ed, ktor\u00e9 Hz prin\u00e1\u0161al \u010dasom. Teraz t\u00edmu Sportmasteru nie s\u00fa d\u00f4vody, aby sa vzdali Hazelcast.<\/p>\n

    Ale tak\u00e9 argumenty, ako \u201eprv\u00fd odkaz vo vyh\u013ead\u00e1va\u010di\u201c a \u201er\u00fdchlo sme postavili HelloWorld\u201c \u2013 to je, samozrejme, v\u00fdnimka a osobitos\u0165 momentu, v ktorom prebiehal v\u00fdber. Skuto\u010dn\u00e9 sk\u00fa\u0161ky pre vybran\u00fd syst\u00e9m za\u010d\u00ednaj\u00fa s prechodom do produkcie, a tento aspekt je potrebn\u00e9 zoh\u013eadni\u0165 pri v\u00fdbere ak\u00e9hoko\u013evek syst\u00e9mu, vr\u00e1tane cache. V na\u0161om pr\u00edpade sa vlastne d\u00e1 poveda\u0165, \u017ee sme si Hazelcast vybrali n\u00e1hodou, ale potom sa uk\u00e1zalo, \u017ee sme vybrali spr\u00e1vne.<\/p>\n

    Pre produkciu je ve\u013emi d\u00f4le\u017eitej\u0161ie: monitorovanie, spracovanie zlyhan\u00ed na jednotliv\u00fdch uzloch, replik\u00e1cia d\u00e1t, n\u00e1klady na \u0161k\u00e1lovanie. Teda je potrebn\u00e9 venova\u0165 pozornos\u0165 \u00faloh\u00e1m, ktor\u00e9 vznikn\u00fa pr\u00e1ve pri podpore syst\u00e9mu \u2013 ke\u010f z\u00e1\u0165a\u017e desiatky r\u00e1z prev\u00fd\u0161i pl\u00e1novan\u00fa, ke\u010f n\u00e1hodou po\u0161leme nie\u010do nespr\u00e1vne a tam, ke\u010f bude potrebn\u00e9 nasadi\u0165 nov\u00fa verziu k\u00f3du, nahradi\u0165 d\u00e1ta a urobi\u0165 to nepozorovane pre klientov.<\/p>\n

    Pre v\u0161etky tieto po\u017eiadavky sa Hazelcast bezpochyby hod\u00ed.<\/p>\n

    Pokra\u010dovanie bude<\/h2>\n

    \nAle Hazelcast nie je v\u0161eliek. V roku 2017 sme si vybrali Hazelcast ako cache pre administr\u00e1ciu, jednoducho na z\u00e1klade pozit\u00edvneho dojmu z predch\u00e1dzaj\u00facej sk\u00fasenosti. To zohralo k\u013e\u00fa\u010dov\u00fa \u00falohu v ve\u013emi nepr\u00edjemnej situ\u00e1cii, z ktorej sme sa \"hrdinsky\" dost\u00e1vali 60 dn\u00ed. O tom v\u0161ak v \u010fal\u0161ej \u010dasti.<\/p>\n

    A zatia\u013e\u2026 \u0160\u0165astn\u00fd nov\u00fd k\u00f3d!
    \n
    Zdroj:     habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

    \u041f\u0440\u0438\u0432\u0435\u0442! \u041c\u0435\u043d\u044f \u0437\u043e\u0432\u0443\u0442 \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041f\u044c\u044f\u043d\u043a\u043e\u0432, \u044f \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a \u0432 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 \u0421\u043f\u043e\u0440\u0442\u043c\u0430\u0441\u0442\u0435\u0440. \u0412 \u044d\u0442\u043e\u043c \u043f\u043e\u0441\u0442\u0435 \u044f \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430\u043b, \u043a\u0430\u043a \u043d\u0430\u0447\u0438\u043d\u0430\u043b\u0430\u0441\u044c \u0440\u0430\u0431\u043e\u0442\u0430 \u043d\u0430\u0434 \u0441\u0430\u0439\u0442\u043e\u043c \u0421\u043f\u043e\u0440\u0442\u043c\u0430\u0441\u0442\u0435\u0440 \u0432 2012 \u0433\u043e\u0434\u0443, \u043a\u0430\u043a\u0438\u0435 \u0438\u043d\u0438\u0446\u0438\u0430\u0442\u0438\u0432\u044b \u0443\u0434\u0430\u043b\u043e\u0441\u044c \u00ab\u043f\u0440\u043e\u0442\u043e\u043b\u043a\u043d\u0443\u0442\u044c\u00bb \u0438 \u043d\u0430\u043e\u0431\u043e\u0440\u043e\u0442, \u043a\u0430\u043a\u0438\u0435 \u0433\u0440\u0430\u0431\u043b\u0438 \u043c\u044b \u0441\u043e\u0431\u0440\u0430\u043b\u0438. \u0421\u0435\u0433\u043e\u0434\u043d\u044f \u044f \u0445\u043e\u0447\u0443 \u043f\u043e\u0434\u0435\u043b\u0438\u0442\u044c\u0441\u044f \u043c\u044b\u0441\u043b\u044f\u043c\u0438, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0441\u043b\u0435\u0434\u0443\u044e\u0442 \u0437\u0430 \u0434\u0440\u0443\u0433\u0438\u043c \u0441\u044e\u0436\u0435\u0442\u043e\u043c \u2013 \u0432\u044b\u0431\u043e\u0440 \u0441\u0438\u0441\u0442\u0435\u043c\u044b \u043a\u0435\u0448\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f \u0434\u043b\u044f java-\u0431\u044d\u043a\u0435\u043d\u0434\u0430 \u0432 \u0430\u0434\u043c\u0438\u043d\u043a\u0435 \u0441\u0430\u0439\u0442\u0430. \u042d\u0442\u043e\u0442 \u0441\u044e\u0436\u0435\u0442 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":73950,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-73949","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Ako sme v Sportmasteri vyberali syst\u00e9m cache. \u010cas\u0165 1 | ProHoster","description":"Ahoj! Vol\u00e1m sa Alexej Pjan\u010din, som v\u00fdvoj\u00e1r v spolo\u010dnosti Sportmaster.","canonical_url":"https:\/\/prohoster.info\/sk\/blog\/administrirovanie\/kak-my-v-sportmastere-vybirali-sistemu-keshirovaniya-chast-1","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\u041a\u0430\u043a \u043c\u044b \u0432 \u0421\u043f\u043e\u0440\u0442\u043c\u0430\u0441\u0442\u0435\u0440\u0435 \u0432\u044b\u0431\u0438\u0440\u0430\u043b\u0438 \u0441\u0438\u0441\u0442\u0435\u043c\u0443 \u043a\u0435\u0448\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f. \u0427\u0430\u0441\u0442\u044c 1 | ProHoster","og:description":"\u041f\u0440\u0438\u0432\u0435\u0442! \u041c\u0435\u043d\u044f \u0437\u043e\u0432\u0443\u0442 \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041f\u044c\u044f\u043d\u043a\u043e\u0432, \u044f \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a \u0432 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 \u0421\u043f\u043e\u0440\u0442\u043c\u0430\u0441\u0442\u0435\u0440.","og:url":"https:\/\/prohoster.info\/sk\/blog\/administrirovanie\/kak-my-v-sportmastere-vybirali-sistemu-keshirovaniya-chast-1","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-03-12T23:42:07+00:00","article:modified_time":"2020-03-12T23:42:07+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"73949","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 18:23:51","updated":"2022-09-28 05:05:57","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\/73949","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=73949"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/posts\/73949\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/media\/73950"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/media?parent=73949"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/categories?post=73949"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/tags?post=73949"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}