Příspěvky

241

Hardware / Re:Vymena HDD za NVMe - IOPS/RAID10 vs RAID1

« kdy: 21. 06. 2019, 10:32:13 »

Do PCI-e min x4 slotu vrazit adaptér na M.2. Výběr v M.2 je podstatně větší, adaptér stojí pár korun. Na disk naplácnout chladič. Samozřejmě to není hotswap.

Adaptér jsem volil tak, aby v bracketu byly díry a lépe proudil kolem chladiče vzduch ven z bedny.

Tenhle obyč šlape v pořádku, je to jenom plošňák s konektorem a kondenzátorem https://www.ebay.com/itm/M-2-NVME-NGFF-SSD-to-PCI-E-Express-X4-X8-X16-Expansion-Converter-Adapter-Card-WY/293105837369 . Chladičů je mraky různých, volil jsem žebrovatější https://www.ebay.com/itm/Aluminium-Alloy-PCIe-NVMe-M-2-2280-SSD-Heatsinks-Laptop-PC-Memory-Cooling-Fin/253751315854 , ale je to jedno, hlavní je zajistit proud vzduchu kolem. Zrovna servery jsou na to OK, protože dělají tunel a vzduch proudí ven kolem PCI-e slotů.

242

Hardware / Re:Vymena HDD za NVMe - IOPS/RAID10 vs RAID1

« kdy: 20. 06. 2019, 21:48:11 »

Tvůj HW raid umí NVMe?

Na DB jsme do pracovních stanic místo SATA SSD dali NVMe Samsung 970 PRO 512GB a raw dd saturuje PCI-e v.2, pro plný výkon to chce v.3.. Raid10 na 8x 7200RPM dá pro nenakešovaná data kolik, 400 IOPS? Spíš míň.

Ten Samsung pro 512GB uvádí 350 tis. čtení a 50 tis. zápis. Reálně jsem to neměřil, ale s HDD opravdu nemá smysl srovnávat...

243

Studium a uplatnění / Re:Rozbitá záda, karpály

« kdy: 02. 06. 2019, 20:47:37 »

Správná výška stolu a rozumná židle jsou samozřejmě důležité. Ale základ je cvičit, něco dělat. To žádné vybavení nenahradí.

Ještě před pár lety jsem měl každou chvíli zaseknuté svaly kolem lopatek - klasická natažená ruka s myší, nahrbená záda. Objevil jsem kondiční box - prostě trénink horní poloviny těla a břicha. Dvakrát týdně hodina a od té doby jsem měl pokoj. Pak jsem vynechal půl roku a na silvestra jsem se plazil na pohotovost s houserem a škemral o injekci. Pak i na nový rok a pár dalších dnů. Klasika.

Zmiňované TRX je také super, vlastně nejlepší.

Pokud nemáš vrozené dispozice, ber cvičení jako nedílnou součást práce. Bez něj tu práci nemůžeš dlouhodobě vykonávat.

244

Bazar / Re:Prodám HW po upgradu serverovny

« kdy: 28. 05. 2019, 09:26:09 »

Ceně 900Kč rozumím https://www.ebay.com/sch/i.html?_from=R40&_trksid=m570.l1313&_nkw=Cisco+Catalyst+3560+poe+24&_sacat=0&LH_TitleDesc=0&_osacat=0&_odkw=Cisco+Catalyst+3560+peo+24&LH_BIN=1&rt=nc&LH_TitleDesc=0

245

Hardware / Re:Zkušenosti s repasovaným monitorem?

« kdy: 22. 05. 2019, 11:39:10 »

Pro FullHD (22" - 27") už spoustu let nekupujeme nic jiného než slušné repasy (dosud cca 20ks). Nelze poznat, že jsou použité, nikdy žádný neodešel. Osobně nevidím rozdíl mezi novým a repasem. Na QHD ještě repasy nejsou.

246

Server / Re:Automatické sestavení RAID1

« kdy: 06. 05. 2019, 08:26:17 »

Klasický problém, na debianu mi jej zatím vždy vyřešilo přidání definic polí do mdadm.conf (již zde uvedeno) + zavolat update-initramfs.

247

Vývoj / Re:Výběr MCU ARM Cortex M0/0+/4? konkrétně

« kdy: 29. 04. 2019, 06:58:28 »

Nejlevnější blue pill stojí s dopravou jako nedávno zavedené zlevněné poštovné v TME - něco přes 40 Kč.

248

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

« kdy: 27. 04. 2019, 13:25:52 »

OWL - zajímavé, díky.

Tohle stále ještě platí (citace z wiki)?

Limitations
No direct language support for n-ary relationships. For example, modelers may wish to describe the qualities of a relation, to relate more than 2 individuals or to relate an individual to a list. This cannot be done within OWL. They may need to adopt a pattern instead which encodes the meaning outside the formal semantics.

249

Studium a uplatnění / Re:Ktorým smerom ďalej?

« kdy: 27. 04. 2019, 13:19:23 »

Dělej, co tě baví. Jen tak v tom můžeš být opravdu dobrý.

250

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

« kdy: 25. 04. 2019, 23:04:21 »

Umím ocenit teorii, když má opravdu hodnotu. Třeba o jejím významu pro SQL ani o DB nijak nepochybuji. Nicméně dle mého názoru je celá řada návrhových vzorů úplně normální řešení, které každý slušnější vývojář použije, protože mu přijde správné a samozřejmé a vůbec nemusí ani tušit, že to má nějaký odborný název. Taková teorie jde mimo mě. Zrovna tenhle princip EAV je jedno z těch úplně normálních řešení.

V roce 2003 moc hotových ORM v javě nebylo, obzvláště ne s výkonově optimalizovanou podporou ACL pro read/write/delete/link/grant na úrovni jednotlivých objektů a z nich poskládaných stromových struktur. Defakto adresářová struktura s ACL, původně to sloužilo jako DMS pro přímé propojení se sambou - přístup přes file manager i přes prohlížeč. Dneska už práva na objektech tolik neřešíme, je to spíš na byznys vrstvě, ale občas jsou potřeba.

Design/vývoj javovského ORM 1 hodně šikovný člověk cca půl roku, způsob uložení dat do DB jsme měli již ověřený z dřívějšího projektu ještě v PHP (od r. 2000).

Dneska bych se podíval po něčem hotovém, ale osobně bych opět volil nějaké efektivní mapování ORM do klasického SQL, s pořádnou podporou kešování. Líbí se mi grafové databáze, ale ty principy se pomalu dostávají do SQL, což je IMO správná a užitečná cesta.

251

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

« kdy: 25. 04. 2019, 21:16:17 »

Deset minut smolím odpověď a mezitím mě zdejší geniální systém odhlásí a odpověď zahodí.

Je to normální selský rozum, jak pokud možno trochu efektivně uložit objekty s atributy a vazbami. Název mě až tak nepálí, s kolegy si to umím vysvětlit i bez teoretických pouček od akademiků.

* tabulka objektů - klíč obj_id. Objekty jsou různých typů - class_id

* tabulka druhů/názvů atributů - klíč attrib_id

* každý typ atributu má vlastní tabulku attrib_XXX, kde XXX je jeho attrib_id. Řádky jsou hodnoty pro objekty, tedy cizí klíč obj_id na objekt. Sloupec value je textový, číslo, datum, json atd., dle konkrétního typu atributu . Atributů/tabulek jsme zatím nadefinovali cca tisíc.

* tabulka vazeb s obj_from_id, obj_to_id a opět class_id - třída vazby. Vazby mají privátní číselnou položku, která určuje např. pořadí podtémat ve výpisu jedné úrovně stromu, snadno se podle toho stromy zpracovávají.

* další tabulky pro práva, fulltext nad stringovými atributy atd.

Samozřejmě to vyžaduje ORM vrstvu v javě, přes kterou se dělají všechny změny. Ta kešuje načtené objekty, atributy, vazby. Klidně úplně všechny, od toho paměť je. Změna nejdříve transakčně zapisuje do DB, když se podaří, změní i nakešovaná data, takže to samozřejmě drží synchronizované.

Jak říkám, je to selský rozum. Ale docela se to osvědčilo a zatím moc změn nevidím potřeba. Chybí atributy u vazeb, to bude potřeba pořešit. A samozřejmě to chce nativní fulltext, klasický problém spousty projektů.

252

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

« kdy: 25. 04. 2019, 17:48:09 »

Pokud to dobře chápu, máte tam Entity–attribute–value model (EAV)? Pokud ano, bylo by dobré zmínit, že to ledaskdo považuje za antipattern. Což samozřejmě neznamená, že to nemůže fungovat, otázkou je pracnost a vlastnosti.

Přiznám se, že teoretické antipatterny neřeším, zajímají mě praktické požadavky. Snadná rozšiřitelnost do všech stran, podpora spolehlivého dlouhodobého vývoje (žádná reflexe apod, vše typově hlídané) a v neposlední řadě rozumný výkon. Ale ten lze dnes nahonit HW, který je velice levný. Repas server DL580 s 512GB DDR3 12800, 40 jádry a spoustou PCI-e v.3 slotů pro NVMe disky jsme nedávno kupovali za 30k Kč s dopravou. Tichá pracovní stanice Precision T7600 2x octa e-5 xeon 128GB RAM + spoustu PCI-e v.3 vyjde na 21k Kč, s 256GB RAM něco přes 30k. Kolik je to proti měsíčním nákladům na jednoho vývojáře...

Narozdíl od nákladů na vývoj, které jen porostou. Požadavky na změny a nové funkce chodí od byznysu každý den, zatímco ruční zásah do struktury DB jsme nedělali už hodně let. Tabulky atributů si samozřejmě vyrábí ORM samo.

253

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

« kdy: 25. 04. 2019, 16:33:47 »

Používáme už skoro 20 let defakto ORM uložení do SQL - objekty a vazby mezi nimi.

Tabulka objektů se základními parametry objektů (ID objektu, ID typu objektu, název, datum vytvoření, přístupová práva atd.). ID typu objektu odpovídá příslušné třídě v javě - potomku InfoObject. Přímo třída objektu může nést už byznys kód, protože jsou vytvořené pro konkrétní účel (téma, dokument, uživatel, firma, skupina, obrázek, žádost, atd. atd.).

Pak je evidenční tabulka atributů, která obsahuje typ (string/int/date/JSON) a ID typu atributu. Stále častěji používáme typ JSONAttrib. Opět typu atributu odpovídají třídy v javě.

Každý atribut má vlastní tabulku attr_IDatributu se sloupcem value dle jeho typu a samozřejmě id_obj s navázáním na objekt.

Tabulka relations s ID typu vazby, id_obj_from, id_obj_to + pár dalších údajů. ID vazby odpovídá příslušné třídě v javě - potomku Relation. Přímo třída vazby může nést už byznys kód, protože je pro konkrétní účel a obvykle si i kontroluje, zda se ji snažíme vázat na správný typ objektu.

Je nad tím poměrně robustní vrstva v javě, která vše přes weak vazby kešuje v paměti. Paměť je dnes velice levná. DB slouží pro perzistenci a pro vyhledávání.

Tabulka 4 mil. objektů cca 100 typů,  1000 tabulek atributů, tabulka 20 mil. vazeb cca 150 typů. Vše provázané cizími klíči přes objID včetně fulltextových tabulek - při odstranění objektu se vyčistí všechny jemu odpovídající záznamy v DB. MariaDB + innodb zcela v pohodě. Hledání je svižné i při hodně komplikovaných query (spoustu podmínek na atributy a vazby, left joiny atd.). Je fakt, že má MariaDB na produkčních serverech nastavené celkem dost RAM (100GB) a vše samozřejmě na SSD (nové servery na PCIe NVMe).

Problém je fulltext. Máme interní indexátor nad atributy textového typu přímo v mysql, ale ten neumí spoustu fulltextových vychytávek, takže bokem defakto elastic search s asynchronní aktualizací z objektové vrstvy a to není úplně dobré. Jenže kvalitní fulltext (více jazyků, přibližná hledání) je opět elasticsearch...

Drží to dobře, asi bych to dneska dělal znovu podobně, noSQL DB zatím pořád nějak nevěřím, mongo mě pro tyto účely rozhodně nepřesvědčilo (máme pro statistiky přístupů, cca 100 mil. objektů). Jenom ten fulltext je problém, snad se nativní fulltext mariadb posune (podpora více jazyků apod...)

254

Vývoj / Re:výběr MCU ARM cortex M0/0+/4? konkrétně

« kdy: 23. 04. 2019, 17:27:34 »

Už to tu dřív zaznělo, ale doporučuji se podívat na ChibiOS. Vyvíjí to Ital, který dělá pro ST v Neapoli, velice dobře komunikuje. Pro Windows má plně nakonfigurované eclipse se všemi potřebnými závislostmi, stačí rozbalit, mírně pokonfigurovat dle konkrétní desky a rovnou nahrávat příklady. Zkoušel jsem to na blue pill z ebaye za 50Kč, i v linuxu to bylo bez problémů. K většímu otestování než připojení TFT LCD, rozchození napojení na ugfx a pár základním příkladům s texty a dotykem jsem se zatím bohužel nedostal, přišly jiné priority, ale chibiOS běží již roky a rozhodně bych se toho pro STM32 nebál.

255

Desktop / Re:Dotyková obrazovka má invertovaný dotek

« kdy: 19. 04. 2019, 14:11:41 »

Pokud stále platí, že při instalaci (liveUSB?) to bylo OK a po instalaci se to rozhodí, tak to musí být jen nějaká ptákovina. IMO by neměl být zásadní problém porovnáním zjistit, co je z live bootu jinak než z nainstalovaného.