Příspěvky

1

Server / Re:Přetížený disk

« kdy: 09. 09. 2019, 09:25:37 »

Dobre rano,

Prosim opravte me pokud nemam pravdu. Prijde mi ze pouziti md raid 1 na ssd neni uplne nejlepsi. Pokud budu delat raid1, tak se pri vytvareni obsah prvniho disku prepise na druhy disk na blokove urovni. Tim si druhy disk bude myslet ze je cely obsazeny. Asi by se to dalo resit tim ze pokud necham oba disky zesynchronizovat, muzu je pote zfromatovat, tam by mel zafungovat trim. Nicmene md raid musi poslat trim oboum diskum. Nevim zdali to umi.

Radek

2

Server / Re:Který NFS cluster pro replikaci na více strojů?

« kdy: 20. 08. 2019, 11:27:43 »

Ahoj,

Asi by bylo dobre si predem nadefinovat co chces v distribuovanem (file)systemu ukladat. Pokud PHP soubory, tak to asi nebude uplne nejlepsi. Ale pro ukladani treba fotek k produktum mi to prijde jako dobra volba. PHP muzes nahravat napriklad pomoci jobu na jenkins, a nebo jak nedo zminoval DRDB. Pro uloziste fotek produktu uz muze byt vhodne pouzit distribuovana reseni, viz nize.

GlusterFS nevypada spatne, mozna ho misto NFS pripojit pres FUSE. Pry by to melo mit vetsi vykon. Pripadne se podivat zdali nemaji nejake API a pote zkusit cist primo pres API a treba i udrzovat otevrena TCP spojeni na jednotlive nody a minimalizovat cas navazani spojeni. Pridal bych jeste nejakou HTTP cache/CDN(NGIX, Squid, ... )

Dalsi moznosti by mohl byt CEPH. Ten ma dokonce primo Object Storage, kde muzes komunikovat primo pres API. Opet si muzes udrzovat v poolu otevrena TCP spojeni a tim zrychlit nacitani souboru.

Jako posledni muzes zkusit nejakou databazi ktera podporuje replikacni model jako Apache Cassandra. Nastavis si replikaci treba na 3. Takze minimalne 3 nody maji ulozen dany klic. Klicem je nejake ID souboru a hodnotou obsah souboru. Pro soubory vetsi nez XX MB muzes soubor rozdelit a ulozit jako vice klicu. Je dobre mit klic hodne nahodny, treba hash. Pak se  hodnoty dobre rozprostrou po celem clusteru. U Apache Casandra dokonce pak vis i na kterych nodech dany klic lezi a muzes komunikovat primo s nody ktere maji dany klic. Pokud honis opravdu o nizkou latenci, muzes poslat dalsi pozadavek na druhy nod pokud z prvniho nedorazi odpoved do 20ms. Pote si jen vezmes data z toho pozadavku co dorazil nejdrive. Toto reseni pry dokaze hodne snizit tail latency.

Radek

3

Vývoj / Re:Váš názor na kombinaci několika technologií

« kdy: 02. 08. 2019, 11:26:24 »

Ahoj,

Predem poznamenam ze programuji uz nekolik let v Jave a posledni 4 roky ve Scale(ale ne uplne ciste funkcionalne).

Elektronu a GO bych se nebal, jsou to uz zazite technologie a google napriklad hooodne investuje do GO. Ale s ostatnima technologiema bych trosku opatrnejsi(mozna v JS casti bych sel do Typescriptu). Ted neco napises a za 2 roky budou chtit opravu a nebudou mit na upravu tolik penez a ty na tom prodelas a nebo si udelat spatnou reputaci. Budou rikat ze to stalo tolik a tolik a ted to nemuzou pouzivat protoze chces xxx za opravu. Pripadne si muzes dohodnout nejaky mesicni udrzovaci poplatek a kazdy pulrok vydat novou verzi aby jsi predesel tomu ze ti projekt nepujde zkompilovat kdyz budes potrebovat udelat hotfix. Pokud nechteji platit udrzbu, tak jim predat i zdrojovy kod a rict ze s timhle to muzes kdokoliv upravit. Napriklad u ERP se bezne plati udrzovaci poplatek 10% rocne z implementacni ceny(vcetne dodelavek).

Jinak na backendu bych se drzel typovych jazyku. GO, Java, C#, Typescript .... Dokud je aplikace mala, tak to je sranda, ale jakmile se mi rozroste, tak se blbe dela refaktoring. V typovych jazycich to kontroluje prekladac a tak se delaji nektere opravy mnohem jednoduseji. V dynamickych jazicich je potreba psat vice automatizovanych testu.

Jako databazi bych asi pouzil SQLite. Mate silu SQL databaze a navic ji bude rozumet kazdej. Nic vam nebrani do SQLite ukladat JSON. Vykonu bych se nebal. Pokud prestane staci muzete prejit na nejakou vetsi databazi. Dokud jsou data mala(<100GB), drzel bych se SQL. Je to stabilni overena technologie a nemusite resit plno omezeni noSQL.

Radek

4

Sítě / Re:Dvoupásmový router pro domácnost a hosty

« kdy: 09. 05. 2019, 11:57:14 »

Ahoj,

ja bych se take primlouval za Mikrotika. Nicmene zalezi jak moc si chcete hrat s nastavenim, mikrotik beru spis stylem tohle ma a umi a nic vic. Vice ruznych SSID umi. Dokonce to mam nasazeno na hotelu kde mame 3-5 SSID na jednom AP. Nerikam ze openwrt je spatne, pravdepodobne tam bude lepsi podpora VPN a jinych sluzeb, ale zase Mikrotik nastavim a vesmes se o nej nemusim starat, obcas update firmware. Zakladni nastaveni pre winbox zvladne kazdy. Co se tyce firmware, tak vydavaji novou verzi kazdou chvili a podporuji i zarizeni 5-7 let stara.

Radek

5

Vývoj / Re:Návrh relační databáze

« kdy: 27. 04. 2019, 12:38:52 »

Dobry den,

pridam moji odpoved, ktera sice nebude primo pro Vas(nepouziva SQL), ale nekomu se muze v budoucnu hodit.
Zkusil bych se podivat na tripplestore, RDF, a veci kolem semantickeho webu : https://en.wikipedia.org/wiki/Triplestore

Pomoci jazyka OWL jde definova neco jako "schema", nazyva se to Ontology, kde si pro kazdy objek vytvorite "tridu". Techto trid muzete mit tisice. Daji se taky ulozit do databaze. Nasledne do databaze ulozite "instance" trid, ktere mohou odkazovat jedna na druhou, delat stromove struktury, pouzivat vicenasobnou dedicnost. Navic databaze vas nijak neomezuje co kde smite ukladat. Act se to myslim da zapnout.

V programu nasledne muzete generovat rozhrani na zaklade "tridy" a jejich datovych typu. Jazyk OWL je mocny, nekdy az moc, ale zase se v nem daji definovat pravidla ktere vylucuji napriklad aby jedna "instance" nemohla byt jak auto, tak letadlo. Nasledne muzete pomoci jazyka SPARQL generovat dotazy do databaze. Jako dej mi vsechny instance tridy Auto vcetne jejich potomku (Nakladak, tahac, sportak).

https://jena.apache.org/documentation/ontology/
https://jena.apache.org/documentation/fuseki2/index.html
https://en.wikipedia.org/wiki/SPARQL

Radek