Poslední příspěvky

21

Hardware / Re:Doporučte NAS alebo alternatívu

« Poslední příspěvek od Michal Šmucr kdy 27. 04. 2025, 14:32:38 »

@Mlocik97

Jo, to je asi optimální si to takhle přímo vyzkoušet sám dopředu.

TrueNAS může být fajn a ano, je jednoduchý na naklikání, má spoustu předpřipravených věcí. Obsluhu ZFS datasetů, sdílených složek, práv. Také často používané aplikace (Plex, Home Assistant, MinIO..) jsou tam v podstatě ihned rovnou dostupné.

Na stranu druhou to nemusí být vždy úplně ideální volba na malý NAS. Je to podobně jako např. u komunitní verze pfSense odvozené z placeného produktu, co je primárně určen na jejich hardware. Vývoj reflektuje jejich požadavky pro tyhle velké produkty a servery.
Tzn. to, na co jste narazil, není žádný bug. Počítá se tím, že máte NAS s dedikovaným diskem (resp. mirrorem) jen pro systém. Vezme si ho to celý, udělá systémový pool, ale uživatelská data se předpokládají na dalších discích.
Můžete se pokusit to nějak ohackovat, aby instalátor na prvním disku udělal menší ZFS oddíl, pak zkusit udělat další oddíl(y) a nějak mu to vnutit. Ale důrazně to nedoporučuji, za prvé z hlediska ZFS samotného - dva vdevy na jednom fyzickém zařízení, za druhé se vám to snadno může rozdrbat při nějakém dalším updatu.

Mluvím o tom i proto, že jsem historicky řešil poměrně pár DIY TrueNASů, kdy se to někomu rozsypalo při updatu sytému, i třeba minor verze a pak mi to někdo donesl. Nikdy se nepřišlo o žádná data (ZFS pooly byly v pohodě), ale spíš šlo o nějaký neošetřený stav (nevím, různé konfigurace) v tom aktualizačním skriptu (což je taky radost třeba půl hodiny koukat jak tam běží nějaký Python skript, co zdálnivě nic nedělá a bez možnosti jakékoliv interakce). Někdy pak bylo nutné nainstalovat TrueNAS z gruntu, naimportovat existující pooly, případně zálohu nastavení (pokud existovala).
Ale jak už jsem tu někde zmiňoval, šlo o starší verze a založené na FreeBSD (ne aktuální Scale, co je vlastně Debian Bookworm).
V rámci toho vývoje to šlo od FreeNASu (první jen komunitní verze), přes přesun k TrueNAS už jen pod hlavičkou iX Systems, kdy pak citelně omezili HW konfigurace (a např. i to přiřazení disků). Pak pár let dichotomie s Linux/BSD verzí, různými kontejnerovými a virtulizačními nástroji (byhve a jaily na BSD, pak libvirtd a Docker na Linuxu, teď zas experimentálně Incus z Ubuntu).
Pro sebe jsem si následně vyhodnotil, že mi to moc výhod nepřináší, pokud bych si tedy nekoupil do firmy jejich server s podporou, a používám standardní FreeBSD nebo Linuxové distribuce, kde to mám pod kontrolou (ale beru, že pro někoho dává smysl to UI) a s nějakým predikovatelným vývojem.
Byť oceňuji, že iX systems má velkou zásluhu (finanční, lidské zroje) na spousty věcech v OpenZFS a FreeBSD.

Finálně k tomu HW.. a souvisí to také s tím rozdělením disků a celkovou cenou.
Pro typické malé NASy resp. malé univerzální domácí servery mi pořád all flash varianta nepřijde jako optimální. Velmi často vychází líp hybrid, kdy je systém a určitá část dat na SSD (virtuály, databáze, cokoli kde oceníte více IOPS) a velká bulk data pak na točivých discích (zálohy různých zařízení, filmy atp.). Samozřejmě pokud někdo chce mít rychlý S3 server pro své věci a vývoj, jak zmiňoval Tomáš Chronek, nebo potřebuje okamžitý přistup ke všem datům, dává to smysl. Ale to bude spíš pořád výjimka.
Sice se ty SSD zlevňují, ale pořád to může být velmi velmi drahé pro větší kapacity, zvlášť pokud člověk nebere ty úplně nejlacinější disky (různé OEM, dramless hrůzy z AliExpresu a eBaye, které se třeba pro kontinuální sekvenční zápis dokážou po desítkách GB dostat rychlostně i pod točivé disky). Zároveň se také zvyšuje kapacita v zařízeních (notebooky, telefony, počítače) a cloudových účtech, co jsou třeba zálohovat, takže při nějaké retenci záloh je třeba navýšit kapacitu síťových úložišť.

Tzn. pro malý server mi vychází optimum 2x SSD + 2x HDD nebo třeba 2x SSD + 4x HDD. (hraničně by šlo i 1xSSD s tím, že se to třeba jednou denně odzálohuje na HDD). Tomu víceméně odpovídá i nabídka různých vhodných desek (s Alder Lake Intelem nebo notebookovým Ryzenem) a celých malých serverů. Pokud by mi ta SSD měl sežrat jen samotný systém bez možnosti použití na uživatelská data, je to trochu problém.
Klasický NUC mi pak pořád připadá pro ukládání dat jako kravina, zvlášť když jsou k dispozici lepší produkty v podobné cenové relaci.

22

Vývoj / Re:SQL: vypis susedov

« Poslední příspěvek od Pavel... kdy 27. 04. 2025, 14:04:24 »

Zobrazit 1000+ radek v prohlizeci zase neni takovy problem.

podla mojho pozorovania spravania prehliadacov je jednoducho to zvycajne meratelne dlho renderuje, v nejednom pripade scrollovanie laguje a tak.
Ale som ochotny uznat, ze problem je pri vacsom pocte riadkov, nikdy som si nerobil statistiku.

Otazka je jestli o to uzivatel doopravdy stoji.

samozrejme, ze nestoji
problem je na inej strane: niekedy jednoducho ma uzivatel usecase, ze potrebuje nieco na co programator nepomysel.
(ked programator pomysli, tak samozrejme uzivatel ma k dispozicii lahko pouzitelne spravne filtrovanie a nepotrebuje zobrazovat viac nez povedzme 30 zaznamov)

U strankovani nekde zobrazujete x/y, kde "x" je aktualni stranka a "y" je celkovy pocet stranek. Spocitat to y byva casto velmi narocne na vykon a uzivatele to casto ani nezajima. Projde jen prvnich 3-5 stranek a pak zada jiny dotaz.

svet nie je len nasepkavac v googli

U nekonecneho strankovani si zapamatujete posledni zobrazene ID a to pak pridavate do filtru where clausule:
...

Takze ked chcem vidiet posledny 1000ci prvok, tak mi skusate nahovorit, ze mam byt nadseny, ze budem 19x riesit problem pomaleho scrollovania (kedze zakazdym doplnite 50 zaznamov), kde  zakazdym bezi pomaly dotaz na server a do databazy? (bez ohladu na optimalizaciu, rezia je sama o sebe neprijemna)

---

ok, chapem, ze ak je gro vasej prace robenie veci ako nasepkavac, tak rozumiem, ze "nekonecne scrollovanie" je fajn.
Len na zaciatku ste sformulovali ultimatnu myslienku, ze to je vo vseobecnosti jedine spravne riesenie.
Tak ma zaujalo, nakolko prehanate.

Priklad z praxe: mam zoznam o tak 500 prvkoch, vzdy hladam jeden konkretny. Tu by ma asi uzivatelia zabili, keby som im ponukol vami preferovane riesenie.

23

Studium a uplatnění / Re:Jak se zbavit problémového kolegy?

« Poslední příspěvek od Tomáš Crhonek kdy 27. 04. 2025, 13:49:00 »

Feldou jezdi socky na pracák a geekové do Kaufu.

Mimochodem, pracuji jako IT pro MPSV právě v areálu (Kosmonautů 8 ) úřadu práce Olomouc, hned vedle nás je Krajské ředitelství policie, kde se starám o projektor a zvuk v přednáškovém sále, Kaufland je 20m přes cestu z ulice Vejdovského. Kdo tam jezdí bávem nevím, já to mám do práce 40 minut pohodlné chůze z jižní části Olomouce a do Kauflandu chodím pro víkendový nákup v pátek pěšky. Takže socky možná jezdí bávem a nesocka IT na MPSV chodí pěšky :-D

Fábie se zbavuju, jestli ji někdo chcete, přijdte si v úterý pro klíče, já zruším domluvený šrot, hned vedle policie je úřad registru vozidel, tam to během obědové pauzy vyřídíme. Myslím to zcela vážně. Ve čtvrtek si někdo z Olmiku odvezl můj starý PC Case chieftec, a doma ve svém bytě mám ještě další dvě PC bedny + Intel NUC a ten si nechávám. Takže do roka půjde pryč stříbrný Chieftec, ve čt se odvezl modrý. Až to bude, tak dám info sem do bazaru na root.cz.

24

Vývoj / Re:SQL: vypis susedov

« Poslední příspěvek od Ivan Brezina kdy 27. 04. 2025, 13:31:38 »

Vim ze je to nevyzadana rada, ale strankovani je spatne z mnoha duvodu. Vykon databaze je jen z nich.
Mnohem lepsi a modernejsi pristup je "inifine scolling". Je to mnohem jednodusi a pro uzivatele je to i prehlednejsi.

hmm... ako to funguje s niecim, co je potencialne tabulka o 1000+ riadkoch?

Zobrazit 1000+ radek v prohlizeci zase neni takovy problem. Otazka je jestli o to uzivatel doopravdy stoji.
U nekonecneho scrolovani mate vyhodu ze uzivateli nerikate kolik zaznamu jste nasli.

U strankovani nekde zobrazujete x/y, kde "x" je aktualni stranka a "y" je celkovy pocet stranek. Spocitat to y byva casto velmi narocne na vykon a uzivatele to casto ani nezajima. Projde jen prvnich 3-5 stranek a pak zada jiny dotaz.

U nekonecneho strankovani si zapamatujete posledni zobrazene ID a to pak pridavate do filtru where clausule:

Kód: [Vybrat]

WHERE 1=1
and ID > :last_diplayed_id
and <... dalsi podminky hledani >
FETCH FIRST 50 ROWS ONLY;

Pokud mate dobre udelane indexy, tak se pouzije INDER RANGE SCAN a databaze nemusi znovu prochazet zaznamy ktere uz byly zobrazene predchozim dotazem. To je totiz hlavni problem se strankovanim. Pro zobrazeni x-te stranky databaze musi stejne projit stranky 1 az (x-1). Ke zobrazeni celkoveho poctu stranek databaze prochazi uplne vsechny nalezene zaznamy a pak posle uzivateli jen maly vyrez dat.

25

Studium a uplatnění / Re:Jak se zbavit problémového kolegy?

« Poslední příspěvek od Zdeno Sekerák kdy 27. 04. 2025, 12:55:03 »

"nosi ponozky v sandalech"
Co je na tom spatne? ja nosim take ponozky v sandalech i kdyz nejsem rodili cech.

26

Server / Re:Používá se ještě databáze Firebird?

« Poslední příspěvek od Tomáš Crhonek kdy 27. 04. 2025, 12:39:43 »

Jsem se rozkecal

Ale pěkně. Nechceš to tady nechat vydat jako článek? Myslím to vážně, doma si píšu webovou apku v Golangu a SQLite a taky se chystám na článek. K sobě na blog, ale klidně i sem na roota (není nutné, u mě to bude roky k disposici všem a možná i s odkazem na GitHub).

27

Server / Re:Používá se ještě databáze Firebird?

« Poslední příspěvek od Michal Šmucr kdy 27. 04. 2025, 12:09:23 »

Ano, používá.
Byť, jak už tu zaznělo, tak má dnes spíš své specifické oblasti, kde se hodí nasadit.
Má docela dlouhou historii a její přímí předchůdci byly jedny z prvních databází, co měly v 80. letech transakce a MVCC (MGA). Dlouho se vyvíjela pod Borlandem jako Interbase, takže minimálně v devadesátých a nultých letech byla velice populární u vývojářů, co pracovali v Pascalu s Delphi. Tuhle roli pak z větší části přebral MS SQL server v Compact, Express a LocalDB variantě, když se to posouvalo k vývoji pod .NET.
Od r. 2000 pak existuje a vyvíjí se jako Firebird - open source fork Interbase.

Na embeddované použití to může být pro určitá použití zajímavý kompromis, není tak minimalistická jako SQLite, ale pořád je velmi kompaktní. Také nemá tvrdá velikostní a paměťová omezení jako ty varianty MS SQL serveru (plus je samozřejmě open-source a multiplatformní). Historicky tam byly zajímavé i další funkce toho systému (aut. segmentování podle velikosti a paralelní zápis do různých db souborů kvůli obnově).

Jinak se dá vcelku úspěšně nasadit i do víceuživatelského prostředí. I když samozřejmě záleží na konkrétní situaci.
Není (většinou) tak rychlá a vertikálně škálovatelná jako MySQL s InnoDB a nemá ani zdaleka tolik možností jako PostgreSQL, který je za mě mezi open source projekty asi nejblíž těm velkým systémům jako např. od Oracle.

V porovnání s MySQL měl Firebird lepší procedurální SQL, vytváření interních funkcí, window funkce (byť to se zásadně změnilo v MySQL . Umí také velmi dlouho eventy, které se dají použít např. na asynchronní notifikace klientů ze serveru, když se změní dataset (volá se to z triggeru nebo procedury).
Jak zmínil Pavel Stěhule, tak se Firebird pořád vyvíjí, optimalizuje se a přidávají se další funkce. Verze 5 má např. partial (filtrované) indexy, předchozí verze 4 přinesla vestavěnou replikaci (bez dalších nástrojů nebo vlastního řešení logické replikace) a vestavěnou plnou podporu časových zón. Průběžně se vylepšují monitorovací nástroje, chování a syntaxe podle SQL standardu atp.

Osobně Firebird používám asi 20 let pro své projekty (od data driven grafiky pro TV/streaming, přes nějaké analytické věci, až po jednoúčelové věci na nějakou telemetrii). Je to také velmi fajn na menší použití (řádově desítky klientů), kdy se hodí dělat větší manipulace s daty na databázové vrstvě (např. proto, že okolo jsou proprietární aplikace které mají např. jen ODBC a minimální možnosti úprav dat). Bylo to pro mě také velmi spolehlivé.
Ale jak jsem zmiňoval, opravdu záleží na specifickém použití. Samozřejmě pokud je třeba přímá podpora (tzn. ne přes BLOBy) pro specifické datové typy (JSON, XML, spatial data), vybere se něco jiného.
Stejně tak, pokud člověk chce maximální výkon pro čtení a zápis, nepoužívá v databázi žádný nebo minimální data processing, tak třeba MySQL (resp. embedded SQLite) může být lepší.
Někdy také může rozhodnout přímá podpora MySQL, Postgresu v určitých ORM knihovnách, webových frameworkách atp.

Také se s ním lze občas potkat pod aplikacemi, zařízeními (typově sdílená databáze klipů ve video serveru). Vím, že jsou na tom postavené také různé účetní a lékařské systémy.

Jinak rozšíření také trochu záleží na regionu, zemi. Firebird je relativně hodně populární v Rusku (a zemích okolo), Brazílii, ale také Německu. To Rusko má pragmatický důvod i v tom, že v určité době začali měnit proprietární systémy od převážně amerických firem za OSS nástroje, kde můžou ovlivnit vývoj. Takže existují i speciální verze Firebirdu, co jsou certifikované pro provoz v ruské státní správě a bankách, rozšířené např. o jejich specifické šifry. Spousta změn byla nejdřív v těchhle specifických variantách s komerční podporou a pak se následně upstreamovaly do další major verze databáze. Takže třeba u nich na tom běží i docela rozsáhlé systémy a většina core vývojářů je odtamtud.
Jinak u nás jsou také skvělí vývojáři, co přímo přispívají do projektu, pánové Pavel Císař (autor Python driveru a jediné české knížky, člen Firebird Foundation a největší nadšenec ) a Jiří Činčura (píše .NET driver).

Jsem se rozkecal

28

Studium a uplatnění / Re:Jak se zbavit problémového kolegy?

« Poslední příspěvek od Tomáš Crhonek kdy 27. 04. 2025, 11:47:22 »

Problémový kolega teď jezdí Fabkou za 2litry na sto? Toho bych se nezbavoval, ten bude cajk.Dementi jezdí frantíkem nebo starým bávem. Feldou jezdi socky na pracák a geekové do Kaufu. A podle spotřeby to je klidný a vyrovnaný člověk.

Já to tady píšu hlavně proto, že s kolegy v kanclu to máme stejně. Jsme 4 a každý jiné povahy. Jeden bydlí 1km od práce a chodí pěšky, já to mám 4km pěšky, takže chodím pěšky a další dva bydlí 8 a 30km od Olomouce. V kanclu to máme všichni vyřešené ke spokojenosti všech. Proto o tom píšu i sem a pokud zítra zjistím, že tazatel anonym je kolega, který bydlí 30km od Olomouce a už nemá na naftu, tak mu rovnou dám klíče od Fábie, technická je OK, další termín za rok a půl a zaplatí si jen mnohem levnější povinné ručení na benzínový tříválec místo nafťáku. Já se té Fábie chci zbavit, další povinné ručení už nemám zaplacené a končí v květnu a na konec května mám domluvený šrot i s termínem příjezdu. Takže zítra předám klíče, hned ve vedlejší budově v úterý uděláme přepis a já budu nejspokojenější člověk v celé budově.

29

Studium a uplatnění / Re:Jak se zbavit problémového kolegy?

« Poslední příspěvek od Martin Poljak kdy 27. 04. 2025, 11:41:57 »

Že se s jedničkovou Fabií 1.4MPI dalo při troše snahy přiblížit ke 3 litrům můžu potvrdit.
Sám jsem před cca 25 lety za podobnou spotřebu jel třeba z Litomyšli do Poděbrad [...] nebo z Vrchlabí do Mladé Boleslavi

Vždyť obojí je dvě třetiny cesty z kopce. Od nás z jižní Vysočiny do Brna s dvoutunovým mikrobusem taky takhle dojedu za čtyři na sto když na to přijde i když normálně jezdí za sedm osm.

30

Vývoj / Re:SQL: vypis susedov

« Poslední příspěvek od Pavel... kdy 27. 04. 2025, 10:56:02 »

K čemu by bylo zobrazení tabulky, která má víc než 1 000 řádků? Bude to nějaký uživatel procházet očima řádek po řádku? Pokud chcete uživateli zobrazit tabulku s více než tisíci řádky, není potřeba řešit, jak mu to zobrazit, ale jak mu umožnit zadat takové filtrovací či vyhledávací podmínky, aby našel, co hledá.

no ved to nechcem
z praktickeho hladiska je strankovanie jedna z praktickych moznosti ako to lahko a efektivne "filtrovat".

Predrecnik tvrdil, ze "strankovanie je zlo". Ale uz nedodal: musite zabit kopu casu a namahy pre vyrobenie velmi dobreho filtrovania, pretoze rozumny limit je povedzme 100 zaznamov.