Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - František Ryšánek

Stran: 1 ... 67 68 [69] 70 71 ... 77
1021
Server / Re:Současný hardware pro 1PB storage
« kdy: 27. 06. 2018, 13:09:15 »
1TB 64x16GB DDR3 vyjde kolem 90 tis.

:-) 90 Kč / GB? Konečně chápu a souhlasím. Nové DDR4 stojí asi 350 Kč/GB.

Pokud ta věc bude bootovat z nějakého direct-attached mirroru (klidně interního) tak není ani potřeba, aby prašivý značkový BIOS "viděl" všechny HBA a disky. Možná naopak lepší kdyby neviděl :-D Ono by možná šlo zakázat v BIOSu startování přídavných option ROM ze zásuvných PCI karet.  Hlavně aby byly HBA dostupné na PCI sběrnici. Linux nebo BSD už si je přebere. Moderní HBA čipy IMO nepotřebujou, aby si na ně při startu sáhla BIOSová option ROMka.

1022
Server / Re:Současný hardware pro 1PB storage
« kdy: 26. 06. 2018, 15:17:19 »
Pozor na to řešení s HBA co mají velký počet SAS portů - typicky mají tyhle HBA stejně na čipu jen 4 SAS linky, takže velký počet portů je pak spíš pro pocit

Budu-li mluvit konkrétně:
Areca ARC-1320-8x (Marvell): 8 linek pro disky (2x x4 multilane)
Areca ARC-1320ix-16 (Marvell): onboard expandér
LSI SAS 9300-16e (2 ks LSI 3008 "Fury" + PCI-e bridge): PCI-e 3.0 x8, čistých 16 linek pro disky, <2 M IOps, full height, 27W
LSI SAS 9302-16e (2 ks LSI 3008 "Fury" + PCI-e bridge): PCI-e 3.0 x16, čistých 16 linek pro disky, 2.8 M IOps, full height, 29W
LSI SAS 9305-16e (1 ks LSI 3216 "Cutlass"): PCI-e 3.0 x8, čistých 16 linek pro disky, 1.5 M IOps, low profile, 13 W
LSI SAS 9400-16e (1 ks LSI 3416 "Crusader"): PCI-e 3.1 x8, čistých 16 linek pro disky, ? IOps ?, low profile?, 11W
LSI SAS 9405-16e (1 ks LSI 3616 "Mercator"): PCI-e 3.1 x16, čistých 16 linek pro disky, ? IOps ?, low profile?, 14W

Crusader a Mercator zatím zřejmě nejsou ve FreeBSD, ve vanilkovém upstream Linuxu už ano. Ve widlowsím driveru je vidět pár dalších (novějších) codenames.

1023
Server / Re:Současný hardware pro 1PB storage
« kdy: 26. 06. 2018, 14:09:07 »
Dekuji za smysluplnou reakci. Resim celkovou raw kapacitu 1PB, jak si to rozdelim pak je na me a mych pozadavcich ktere jsou mimo tuhle diskusi. Do racku by se AFAIK melo vejit 1PB bez problemu, treba backblaze ma ve 4U 60 disku, to co mam ted je takove na kolene poskladane reseni, ale kapacitne to nezabira vice nez 6U se 4tb disky, tudiz by to melo jit. Co se tyce ram a desek - mam nejakou predstavu, 1TB chci kvuli dedup a dalsim vecem, myslim ze 64gb moduly se daji sehnat, zalezi od konkretniho vyrobce. Pokud mate zkusenosti s konkretnimi deskami budu rad za info.

Popravdě v levném serverovém HW mám spíš dávné vzpomínky než nějaký aktuální přehled. Dustin vypadá, že je víc v obraze a má přehled o značkovém HW.

Obecně každému doporučuji, mít disky v šuplíkách jednotlivě přístupné zepředu (aby šly jednotlivě vyměňovat) a identifikovatelné, proto enclosure management. V momentě, kdy RAID vykopne disk, tak člověk brečí vděkem za failure LEDku - ale zákazníkům se to předem občas těžko vysvětluje :-) Na in-band SES se dá sáhnout pomocí sesutil (používá driver ses).

Z tohoto důvodu, a taky kvůli chlazení, váze a hloubce (klidně přes metr) se mi nelíbí kastle, kde se do 4U nacpe 60-100 disků nastojato.

Pokud to nebude někde v útulné "teplé a studené uličce" tak bacha ať má stojan po celé ploše děrovaná vrata vpředu i vzadu (a osobně bych se snažil omezit i falešný vzduch uvnitř stojanu zezadu dopředu). Pokud máte ten luxus vybrat si stojan, tak 80cm šířka dává prostor po stranách pro umístění distribuce napájení a tahání kabeláže (ale bacha na ten falešnej vzduch).

Obecně u nového hardwaru je volba spíš věcí osobního vkusu a subjektivní důvěry v konkrétní značku - protože u toho prostě nejsou zkušenosti s konkrétním modelem motherboardu, zdrojů apod. Statistika se vytvoří až po létech běhu, a tou dobou je na trhu HW zas o dvě generace novější.

Jak jsem psal, nemám zkušenosti s aktuálním HW tohoto kalibru, ale dlouhodobě dost věřím značce Areca, a třeba Supermicro vypadá, že nakonec taky docela funguje (poslední průser si vybavuju ještě v dobách končící Capacitor Plague).

Zjistil jsem, že dokonce Areca má v nabídce JBODy na 12 disků/2U nebo 24disků/4U. Uvnitř je expandér (nebo dva pro redundanci) a zezadu kouká jako uplink 12Gb SAS (x4 multilane). Tzn. není to direct attach, ale ten multilane SAS nebude úplně pomalý. Bude pomalejší než Dustinův nekompromisní "přímý propoj na každý jednotlivý disk". Případně by se dalo přemejšlet, jestli vzít šasi po 12 nebo 24 discích (šasi po 12 discích dá teoreticky větší průchodnost, ale vyjde dráž.)

Popravdě se mi Arečí "PS/2" zdroje s 80mm ventilátorem líbí víc, než Supermicrovic napájecí zdroje, hubené a dlouhé s 40mm větráky - ale je to jenom bezelstný pohled zvenčí, ono u zdrojů hodně záleží na obvodovém řešení, součástkách, detailech zapojení/chlazení, jmenovitém dimenzování atd.

Areca má taky nějaké "svoje" SAS HBA, tuším končí na 6 Gbps (opět - vcelku proč ne) ale určitě budou fungovat i HBA od LSI apod. Arečí vlastní ARC-1320 má čipy Marvell, expandéry jsou pravděpodobně od LSI.

Bejvaly doby, kdy SASové čipy vyrábělo AVAGO a LSI a navzájem si konkurovali. Dneska jsou zřejmě oba pod jednou střechou (LSI bylo sežráno Avagem a Avago se zanedlouho přejmenovalo na Broadcom). Zdá se, že aktuální 93xx/94xx jsou nadále "3rd-gen MPT SAS" (tzn. dědictví LSI Fusion MPT) ale skoro mám pocit, podle IDček z Windows driverů, že 94xx ještě možná nejsou komplet v Linuxové vanilce (driver mpt3sas) a prakticky shodná je koukám situace ve FreeBSD (driver mrsas). Čili situace je stejná jako před 15-20 lety: aktuálně prodávaný nejnovější HBA hardware ještě nemá drivery v distribucích :-) Opět má pravdu Dustin: držet se vyzkoušených modelů. (A to se snažím nevzpomínat na dávné quirky třeba u Adaptecu.)

Mě osobně se líbí šasi od Arecy. Jsou hluboká jenom asi 50 cm, všechno přístupné pro servis zvenčí, celá kisna se připojí k HBA jediným fousem. Do 16 U se vejde 96 disků, k serveru se to připojí 4 nebo 8 fousy. Na to teoreticky stačí 1-2 HBA karty (při dvojitě redundantním připojení 2-4).

Dustinova koncepce "direct attach" má teoreticky tu výhodu, že každý disk má svůj vlastní kanál na HBA, tzn. nevstupuje do toho expandér. (V dávných dobách se tradovalo, že za určitých okolností expandér jede proti HBA jediným lanem, ale už nevím, jestli to bylo v případě kdy se skrz expandér sahalo na SATA disk, nebo jediné vlákno, nebo v čem byl přesně problém.) Direct attach má maximální průchodnost. Kromě toho je expandér další potenciální "point of failure".
Odhadem může být problém, dosáhnout při "direct attach" na failure LEDky, protože jednotlivě připojené disky nemají in-band SES (expandér pravděpodobně ano). Leda by se z HBA do backplanu dalo dotáhnout ještě taky SGPIO. Matně si vybavuju, že TQ šáska SuperMicro SGPIO podporují. Ale nenašel jsem zmínky, že by SGPIO podporovaly mpt3sas HBA's a že by se na to dalo nějak sáhnout. Čili SGPIO asi leda v kombinaci s HW RAIDem :-(

Tady jsem našel debatu se zmínkou o ZFS nad multipath SASem proti diskům: Debatěj tam taky o zapřažení flash SSD a že to jde připojit na multipath pomocí "redukce do šuplíku". Konkrétně od Supermicra.

Pokud se týče boardů, koukal jsem na tyhle s DDR4: 1 2 3 4 . Plus spousta příbuzných. Koukám všechny berou DDR4 LR paměti. Uvedené desky jsou všecky s LGA2011, ale tamtéž jsou k vidění i sestřičky s LGA3647. Poslední PCI-e slot bývá jenom x4, ale není to železné pravidlo a i kdyby, tak PCIe 2.0 nebo 3.0 x4 má průchodnosti pořád relativně dost.

Pokud se týče RAM, namátkou jsem nahlédl zde: DDR4 ECC REG a DDR4 LR. (Nemám s tou firmou nic společného.) Bacha ECC REG a LR zřejmě nejsou v konkrétním boardu záměnné. Jasně jsou to koncovky, dál to komentovat nebudu. Pro přehled to myslím stačí velmi dobře. Pokud správně rozumím, "škáluje" u DDR4 cena lineárně mnohem dál než u DDR3. Nebo se u DDR3 bavíme o 8GB modulech z druhé ruky, které adminům "zbývají" při upgradech a proto jsou levné? Tolik k nápadu repasovat starší hardware a cpát do něj terabajt DDR3.

Pokud se týče disků: podle popisu připadají v úvahu např. Seagate Exos x12 (až 12 TB), Exos x10 (až 10 TB), Exos 7E8 (až 8 TB). x10 a x12 jsou héliové, 7e8 je zřejmě plněný vzduchem. Všechny tři rodiny obsahují SATA i SAS modely, na výběr je kupodivu dodnes velikost sektoru 512B nebo 4 kB. A všechny modely se SAS rozhraním mají dvojitý uplink - pokud by byl zájem o multipath zapojení disků.

Pokud byste se zajímal o Arecu/Supermicro, tak Starline, Abacus i Compos tenhle hardware staví/prodávají dlouhá léta (a snad se i trochu starají o zákazníky v DC), budou vědět co a jak, přitom jsou to pořád v zásadě "železářství" tzn. doufám žádní nafukovací hochštapleři.

1024
Server / Re:Současný hardware pro 1PB storage
« kdy: 25. 06. 2018, 20:23:13 »
A DDR4 ECC REG škáluje přímou úměrou až do 64 GB na DIMM modul, ten stojí něco přes 20kKč vč.DPH. Ať už se jedná o ECC REG nebo ECC LR. Tzn. s deskou co má 16 SODIMM slotů by se na ten 1 TB dalo dostat. Procesorově k tomu bude potřeba 2x Xeon E5.

1025
Server / Re:Současný hardware pro 1PB storage
« kdy: 25. 06. 2018, 20:01:49 »
Koukám že na velké šuple pro disky není třeba chodit daleko...

1026
Server / Re:Současný hardware pro 1PB storage
« kdy: 25. 06. 2018, 14:23:01 »
Zkusím se trochu zasnít:

Jestli správně počítám, 42 U = 14 šasi po 3U, do 3U se vejde standardně 16 disků normálně v šuplíku na čelní stěně. To je 224 disků. Takže pokud je požadavek na 1 PB, vycházelo by to na 4.5 PB na disk v RAIDu 0. Tzn. pokud by to byl RAID 10 nebo nějaká podobná míra redundance (+100%), vychází to na cca 9-10 TB disky. Případně jsou k vidění šasi pro 24x 3.5" disků v 4U. To by se do stojanu vešlo 240 disků + by zbyly 2U na nějaký ten server. Asi trochu nesmysl to takhle našlapat, ale takové jsou teoretické počty. A jsou i nějaká šasi, kde se disky zřejmě strkají *dovnitř* = nejsou jednotlivě dostupné pro hot-swap z čelní strany. Což pak podle mého znamená, že je třeba celé šasi odstavit kvůli výměně jednoho disku...

Od koho šasi? No pokud ne HP / IBM / EMC=DELL tak třeba Infortrend nebo tihle němci - vedle Infortrendu vedou i nějaké "svoje" značky s Arecou apod. uvnitř. Svého času tuším prodávali i Fujitsu nebo NEC, už nevím. Jsou na trhu už hrozně dlouho a výrobci přicházejí a odcházejí. Jo a abych nezapomněl, něco by se dalo vybrat taky u Supermicra (u nás Abacus / Compos).

Chápu správně, že to bude jediný veliký JBOD, nad kterým poběží ZFS?

Čím to připojit k serveru: no teoreticky asi přes SAS. Nakolik to bude provozně spolehlivé, bůh suď - celý ten strom JBODů bude samý single point of failure. Taky bacha jestli ty JBODy budou umět "větvit" / daisy-chainovat. Už si nepamatuju, jestli 240 disků nedojede na počet SCSI IDček na jedné sběrnici...

SAS dává teoreticky možnost, vydrátovat šasi "dvojmo" kvůli redundanci. A teoreticky jsou i nějaké disky, co mají dvojitý SAS uplink - jenom si nejsem jistej, nakolik je dvojitý SAS uplink na discích běžná věc. A jestli třeba takové ty "entry-level SAS Barracudy" nejsou naschvál single. A taky by to znamenalo, pořešit v serveru multipath. Další zajímavé téma je enclosure management a hot-swap jednotlivých disků. Matně si vybavuju z doby před 10-15 lety, že FreeBSD mělo už tehdy jakousi podporu pro enclosure manager šváby a normy...

Hrozně dlouho jsem neslyšel o discích s nativním FC, takže pokud by to mělo mít vnější interconnect přes FC, tak leda by to šasi obsahovalo bridge. Ještě mě napadá, jakpak je to s možností bridgovat SAS na InfiniBand.

A další možnost, jako alternativa ke kaskádě SAS expandérů nebo IB fabricu: vyvést ze serveru co nejtlustší PCI-e do externího expanzního šasi (nebo do dvou), do těch šasi naložit větší počet SAS HBA. A každý HBA kanál by pak měl na sobě třeba jediný expandér v jediném diskovém šasi. Tzn. žádný vícepatrový daisy-stromeček ze SAS expandérů. Ale zase by narostl potřebný prostor pro servery a expanzní PCI-e boxy. Hm popravdě kdyby ty JBODy měly každý jediný uplink, tak by se 5-7 SAS HBA (každý 2x multilane external) vešly teoreticky do jednoho 3U šasi. Které by navíc eventuelně mohlo mít svých 16 disků. Jde jenom o to najít serverový board se 7x PCI-e.

Asi netřeba zdůrazňovat, že celá tahle DAS pornografie je dost old-school. Větší kapacity se dneska běžně řeší spíš "cloudově a distribuovaně" nad Ethernetem nebo TCP/IP apod., tzn. samotné disky a HBA jsou nuda, zajímavé je SW uspořádání nad tím.

No a stojan naložený cca půl tunou šásek a disků, s běžnou spotřebou (topným výkonem) okolo 3 kW, při rozběhu klidně k 10 kW (ledaže staggered spin-up)... dneska už asi jsou hostingy, které tohle vezmou. :-) Předpokládám že nehrozí začátečnické chyby typu "stojan nedostatečně hluboký" nebo "teplo se o sebe postará samo" :-)

Jak už tady říkali ostatní, on to rád někdo dodá celé na klíč. A asi je i správně, aby si za to celé ručil. Ale taky je fakt, že není špatné, udělat si předem jasno, jestli třeba řadič externího RAIDu v rámci "fair balancingu" neomezí datový tok jednoho "vlákna" na 100 MBps zatímco Vy potřebujete na chroustání 4k videa 10x tolik apod :-) Nepříjemná nedorozumnění se občas stávají...

BTW terabajt RAMky? Jo aha, ono je to "vcelku normální"... dá se to nacpat do desky s pouhými 8 DIMM sloty, pokud seženete DIMMy o kapacitě 128 GB (v provedení DDR4 se údajně nějaké dělají). Nejnovější dvoupaticové desky s LGA2011 tohle umí vcelku běžně, našel jsem i nějaké jednopaticové... Nebo jestli jsou DIMMy 32GB pořád ještě citelně levnější, tak vzít desku se 16 DIMM sloty (2x Xeon E5) a spokojit se s 512 GB RAM.

1027
Server / Re:Vysvětlete mi indexování v databázi
« kdy: 16. 06. 2018, 15:24:26 »
Čili index jakožto struktura je uložena na disku. Jaká data jsou uložena v té RAM? To jsou ta data, ke kterým se odkazujeme přes ty indexy nebo přímo ty indexy?

Vy si nedáte pokoj, dokud se nepustíme pod kapotu, žejo? Zkusím to nakousnout. Sám znám jenom obrysy. Možná vytrollím pár dalších, kteří doplní chybějící kousky, únavné podrobnosti, vyvrátí nepravdy atd.

No z velmi vysokého nadhledu potřebujete data v RAMce, aby s nimi kód běžící na CPU mohl pracovat, a potřebujete je i ukládat na disk - kvůli perzistenci (aby se počítač směl někdy vypnout) a taky proto, že se Vám celá databáze do RAMky často ani náhodou nevejde. Takže potřebujete mít převodní mechanismy mezi formátem v RAMce a na disku, a potřebujete algoritmy které si dokážou dotahovat z disku do RAM jenom nezbytné minimum, které momentálně potřebují k práci (a případně využití dostupné RAM nějak optimalizovat). A konkrétně u databází to znamená, že jak indexy tak "užitečná data tabulek" potřebujete na disku i v RAMce. (Byl by k něčemu užitečný index, který by se musel vejít do RAMky, a konstruoval by se vždy při startu RDBMS procesu?) Což nevylučuje možnost, že v RAMce budou nějaké pracovní, efemérní indexy a další struktury "navíc", které se na disk neukládají (po restartu se vytvoří znova).

V širším úhlu pohledu se opět jedná o obecný programátorský problém :-) Jiné datové struktury jsou vhodné pro manipulaci s daty v RAM, jiné pro uložení dat na disku. RAMka používá jiné alokační strategie a organizaci dat než diskový prostor, a jiné způsoby odkazování/adresace. V RAMce je výhodné (rychlé) používat přímé pointery na strojové adresy v paměťovém prostoru CPU, kde je alokován nějaký struct nebo jeho member, [ i ]tá položka v poli apod.  Přímo nad těmito strukturami pracují algoritmy zkompilované do binárního strojového kódu, běžícího na CPU = přímo s nativními pointery pracují instrukce CPU. Samozřejmě by šlo i v RAMce letmo dohledávat nepřímé odkazy přes "lidské" identifikátory... možná to tak zrovna databáze dělají, nevím. (Teď bych sem nepletl interpretované jazyky a varianty jejich "vm" - v zásadě je tam tlustá vrstva abstrakce navíc.) Naproti tomu na disku je bloková vrstva adresace, nad ní oddíly, v nich souborový systém, a v rámci souboru ofsety po bajtech od začátku... a formát pro uložení v souboru může vypadat velmi různě. Každopádně "přímo na disku" nemůže nic běžet, protože v datech na disku se CPU přehrabuje hodně dlouhým klacíkem... Err... v dnes obvyklých architekturách :-)

Obecně čím víc má být formát na disku lidsky čitelný, tím víc bude tíhnout k využití lidsky čitelné znakové sady (ASCII, Unicode apod.), řádky a pole uvnitř řádků budou členěny "čitelnými" znaky (čárky, středníky, tabulátory, konce řádku apod.), formát může tolerovat volné místo, komentáře apod. Viz třeba CVS, YAML, XML apod. Zároveň "lidsky čitelné" formáty souborů vyžadují nejvíc zpracování při převodu mezi runtime podobou dat v RAMce a formátem souborů. Proto se často používají jako exportní/importní formáty.

Naopak "těžce binární" formáty umožňují přesouvat data mezi RAM a diskem s menší mírou letmého přežvykování. Binární formáty čísel a řetězců, odkazy na bajtové ofsety spíš než na "lidské" identifikátory / čísla řádek/záznamů, implicitní velikosti uložených "structů" apod. Dovedl bych si třeba představit, že v on-disk formátu s pevnou délkou "DB řádku" zůstanou volná místa pro machine-level pointery (pokud jsou potřeba) ale to si cucám z prstu. Binární formáty jsou obvyklejší jako "nativní pracovní formát" všelijakého softwaru.  (Radši nebudu odbočovat, co je to relokovatelný executable kód, dynamické linkování sdílených knihoven apod.)

Přiznám bez mučení, že netuším, jak vypadá on-disk formát dnešních reálných RDBMS. Našel jsem nějaká hesla na wikipedii 1 2 , ale přijde mi to čtení stále dost abstraktní. Mohu jenom doporučit zdrojáky nějaké open-source DB.

Traduje se, že RDBMS nefungují příliš rády skrz souborový systém. Raději fungují přímo na vyhrazený diskový oddíl. Odpadne tím magie souborového systému, která může zpomalovat, násobit počet seeků apod. Ze stejného důvodu se tradovalo, že velikost stránky virtuální paměti hostitelského CPU (na x86 tradičně 4 kB) je pro RDBMS optimální alokační jednotkou na disku (sektor tradičně 512B, u nových disků točivých i SSD převažuje 4 kB).  Ale celé to má další zádrhele, třeba huge pages apod. Chtěl jsem říct, že takovéto souznění velikosti stránek by nasvědčovalo přímočarému kopírování dat 1:1 mezi RAM a diskem, bez složitého přežvykování = on-disk formát velmi podobný pracovnímu formátu v RAM. Ale jestli je to tak doopravdy...

Jinak je asi vcelku známá věc, jak funguje swapování. RAMka je "overbooked". Virtuální paměťové prostory user-space procesů jsou v součtu větší než skutečná fyzická RAM. User-space proces alokuje paměť podle potřeby. Stránky přidělené user-space procesům v kernelu eviduje memory management subsystém a pomocí LRU a spol si mezi stránkami vybírá ty "nejuleželejsí" - které v případě nedostatku RAM odkládá do swapu na disk. V tom případě se ovšem může snadno stát, že konkrétní user-space proces později sáhne "do prázdna" = chce stránku, která není v RAMce, protože byla odložena na disk. Tím vyvolá na procesoru výjimku zvanou page fault - vlastně obsluhu IRQ a přepnutí kontextu do kernelu. Kernel si nějakou tu stránku v paměti uvolní (podle LRU), přimapuje ji procesu který zrovna způsobil page fault, loadne do ní příslušnou stránku ze swapu a proces může pokračovat v práci (je v plánovači vrácen mezi "běžící"). Proč to tady vytahuju? Hned to bude.

Se soubory se totiž dá pracovat dvěma způsoby:
  • Jednak známějším open()/seek()/read()/write()/close() = soubor v programu otevřete a nějak ho žužláte, třeba do něj po jednom sekvenčně zapisujete ASCII řádky nebo nějaké binární "záznamy". Tzn. data podáváte syscallům skrz nějaký buffer v user space, a data se následně kopírují do kernelu.
  • No a druhý způsob je, že se soubor dá namapovat do paměti. Tuhle fintu umí syscall mmap(). Přesněji řečeno, mmap() je třeba zavolat na otevřený file descriptor (tzn. napřed proběhne open()) a jsou tam nějaké nuance jaké flagy mmap()u předat. Tímto způsobem není potřeba data kopírovat mezi kernelem a user space - prostě se do user space namapuje pár stránek přímo z bufferu blokové vrstvy. A tento mechanismus funguje prakticky stejně jako paging podložený swapem (nuance/flagy stranou) tzn. dá se zařídit, aby se ze souboru dotahovaly stránky až když jsou potřeba (díky page faults). V těch heslech na wikipedii se dá dočíst, že page faultů je vlastně několik stupňů, a že se může stát, že bloková vrstva díky read-aheadu načte do bufferů pár stránek navíc, nepřimapují se všechny hned, ale příští page-fault třeba sáhne jenom po další stránce v bufferu (nemusí čekat na diskovou operaci).
 

Čili opravdu líný RDBMS engine (= user-space démon) by mohl třeba jenom namapovat z disku celý extent / table-space do svého adresního prostoru a těžkou práci s ládováním z disku do RAM (a naopak odkládáním na disk) nechat na memory-managementu hostitelského OS :-)  = na jeho LRU, page-faultech, blokové vrstvě, managementu disk IO bufferů a tak. Nicméně pokud jsem měl možnost pozorovat, RDBMS si naopak tyhle věci rády spravují samy... naalokují si ze systému co nejvíc RAMky a pak si s ní interně hospodaří po svém.

Tohle jsou opravdu jenom velmi hrubé obrysy. Na rootu bacha, "kdo se moc ptá, moc se dozví." Jestli se návnady chytí někdo od fochu, budu nakonec se svým tapetováním vypadat jako břídil.

1028
Odkladiště / Re:Výroba plošných spojů laserem a leptáním
« kdy: 15. 06. 2018, 13:24:29 »
- vlastní osvitka postavená z UV LED pásků (cca 60W, expozice 2 minuty)

Potkal jsem borce co si postavil osvitku ze starého A4 flatbed skeneru.
Jakási stará kráva tlustá asi 8 cm.
Vykuchal vnitřnosti a na dno položil plošák posázený UV LEDkami.
Výkon nevím. Je to už pár let, měl tam jednotlivé nohaté LEDky
v klasickém 5mm pouzdru.

1029
Server / Re:Vysvětlete mi indexování v databázi
« kdy: 15. 06. 2018, 13:13:22 »
Vy to ale pořád píšete opačně. Index primárně slouží pro vyhledávání (a tudíž není unikátní). A s pomocí toho indexu se dá nastavit omezení na sloupci, aby byl unikátní, pro což se pak používá zkratka „unikátní index“. Samozřejmě, že pro vyhledávání je lepší mít index než ho nemít. A různé typy indexů mohou být pro určitý typ dat lepší než jiné – a unikátní index může být o něco efektivnější, než neunikátní. Což je ale jedno, protože unikátní index se nastavuje především kvůli tomu omezení unikátnosti dat.

Myslím, že jsem konečně pochopil, o co Vám jde. Děkuji za vysvětlení, že kočár patří za koně :-)

1030
Odkladiště / Re:Vyroba plosnych spoju laser+leptani
« kdy: 15. 06. 2018, 11:08:30 »
V domácích podmínkách je problém právě v reprodukovatelnosti procesu. A vůbec mít na tu chemii prostor a čas.

Zkoušel jsem přenos nažehlováním a podle mých zkušeností závisí výsledek na použitém toneru. Jestli na mědi drží nebo nedrží. Pokud nedrží, tak Vám nepomůže ani svěcená - můžete odmašťovat desku jak dlouho chcet, nebrat výtisk do ruky, používat "samolepový" nepřilnavý papír nebo vodou namáčecí samolepící papír apod. S dobrým přilnavým tonerem to funguje i na kancelářský papír. Na nepřilnavý toner nepomůže nic. A bohužel jsem nezjistil způsob, jak předem zjistit, který toner bude držet a který nikoli. Potkal jsem lasery Canon a HP které "držely fest", ale po výměně tonerové patrony najednou nikoli. A nehrálo roli, jestli je nový toner originál nebo neoriginál. Vliv má taky teplota žehličky nebo laminovačky, pomocí které toner obtiskáváte na měď. Laminovačky mají většinou příliš nízkou teplotu a termostat co nejde hacknout. Na tiskárnách jde málokdy nastavit sytost výtisku atd.

Zkoušel jsem i fotocestu... včetně fint s natavením laserového výtisku acetonovými parami apod. Překrytí více výtisků je fajn, ale problém je, že výtisk laserem na fólii je vždycky trochu deformovaný, takže překryv není dokonalý. Takže překryv dvou výtisků jenom pro maličké motivy. Výtisk inkoustem na fólii není dostatečně sytý / neděravý. Vytisknout na pauzák a prolít ho "zprůhledňovacím lakem"... ach jo a tak dál. A nakonec se mi taky stalo, že jsem měl parádně kontrastní předlohu, a stejně se kus plošáku nevyleptal a jiný kus měl děravé plochy, co měly zůstat. Přímo na kalibračním obrazci, kde jsem si testoval dobu osvitu s postupným odkrýváním ve 4 krocích. Při manipulaci jsem si svítil 20W červenou žárovkou pro fotokomory a osvit horským sluncem, a ten proces jsem měl předtím už vyzkoušený.
Používal jsem materiál s již naneseným fotorezistem (prodáváno zabaleno v černé fólii). Asi to byl šmejd, ve zpětném pohledu mě to u dotyčného dodavatele nepřekvapuje. Pokud bych se o to snažil dneska, asi bych zkusil tisk na pauzák, nacucat vodou ředěným čirým akrylem, a fotorezist si na desku nastříkat sám. K tomu zas člověk musí být trochu šikovný jako lakýrník. Nebo někde sehnat tu "fotorezistivní samolepu" od DuPontu, jak tu někdo dával video...

A nakonec souhlas: jednovrstvý plošák se dá levně nechat vyrobit i tady, a maličké dvouvrstvé desky s prokovem bez speciálních požadavků dělají v AllPCB (a jinde v Číně) tuším 5 ks za 5 USD. Dodací lhůta cca do týdne. U Allpcb spočívá obchodní model (cenotvorba) zřejmě v tom, že maličkými jednoduchými plošáky "vycpou volná místa" na velké desce, kterou pak vcelku vyrobí. V podstatě si tím redukují odpad/odřezky. Jakmile chce člověk něco většího, nebo na tom nějaké speciality, tak cena rychle roste. Ale není problém říct si třeba o prokovené oválné díry, nebo frézované mezery s "mouse bites", od určitého minimálního rozměru V-grooves apod. - akorát to stojí peníze navrch. Nemá cenu např. naschvál "panelizovat" menší různé plošáky, pokud jich nepotřebujete fakt hodně - protože větší formát "panelu" stojí víc, než několik maličkých jednotlivých destiček (které si číňan rozhází do zbytků volného místa).

1031
Server / Re:Vysvětlete mi indexování v databázi
« kdy: 15. 06. 2018, 10:32:03 »
Pokud by bylo více Danů v tabulce, tak bude ukazovat na všechny Dany.
Tak. V tom případě se nejedná o index unikátní. I tak má příznivý vliv na rychlost selectů apod., které nad pojednaným sloupcem budete provádět.
Ono je to opačně – index se vytváří kvůli rychlému vyhledání určitého záznamu v tabulce, a když je potřeba zajistit unikátnost nějaké hodnoty, vytvoří se nad daným sloupcem index, protože vyhledávat danou hodnotu bude nutné při každém insertu a updatu.

Já bych řekl, že naše tvrzení nejsou ve sporu :-)

Index v SQL lze vytvořit i bez požadavku na unikátnost. Proto souhlasím s tazatelem, že pak záznam v takovém indexu (např. btree koncový list) odkazuje na množinu/kolekci záznamů v "hostitelské" tabulce. A příznivě se projeví na rychlosti selectů / joinů apod. nad takto indexovaným sloupcem = neunikátní index je lepší než žádný index. A že není unikátní, to vyplývá z reality = z dat, která ten sloupec uchovává.

Teď mluvím na abstraktní úrovni - jak to vidí "uživatel DBMS" = SQL programátor. Jak je to implementováno pod kapotou by určitě vydalo na zajímavou další debatu. Sám občas v c++ takové "hybridní grafy" vytvářím, a to se pohybuju obvykle jenom na heapu, o perzistenci se nesnažím.

1032
Software / Re:Tisk PDF vytiskne testovací stránku tiskárny
« kdy: 14. 06. 2018, 21:52:18 »
A není to spíš "košilka jobu" než testovací stránka? Anglicky banner.
A hele. Záložka "policies".

1033
Odkladiště / Re:Vyroba plosnych spoju laser+leptani
« kdy: 14. 06. 2018, 21:44:30 »
Já mám trochu strach, že to laser nevezme úplně dočista. Takže se na některých místech leptací roztok nedostane do kontaktu s mědí.

Taky jsem leptával. Dávno jsem přešel z FeCl3 na HCl+H2O2. Tam je zase potřeba trochu trefit koncentrace, jinak to celé zmodrá a šumí a neleptá... kyselina s peroxidem je taky dost exotermní, ale to vadí spíš při větších plochách leptané mědi. A není špatné při leptání lázní trochu "kejvat", aby se lázeň promíchávala, protože jinak vzniknou zóny s nižší koncentrací žíraviny a vyšší koncentrací produktů (asi hlavně CuCl2) a prostě kus je vyleptaný rychleji, kus pomaleji.

Nedávno mě šéf naučil na allpcb.com a asi už sám leptat nebudu. Už jsem asi starej na to dejchat chlorovodík a řešit likvidaci použitého roztoku. A ono to zabere i dost času, "mít kde" apod. Nechat si to vyrobit od číňanů je sice nesportovní a dopravné je nejspíš dotované jejich vládou, ale je to rychlé a výsledek proti domácím pokusům vypadá jak mimozemská technologie. V základní ceně pokovení cínem, prokovené díry, z obou stran nepájivá maska a košilka... Přijde mi užitečné spíš si pilovat designérské řemeslo, než si špinit ruce a životní prostředí domácím leptáním.

1034
Server / Re:Vysvětlete mi indexování v databázi
« kdy: 14. 06. 2018, 20:26:51 »
Takže třeba když budu hledat Dan - tak index Dan bude ukazovat na ten řádek (s id=3) v tabulce.
Ano. Terminologická poznámka: index je celý ten strom zkonstruovaný nad sloupcem "jméno". Položka "Dan" je jenom jeden záznam v indexu, koncový "list" stromu. A ano, záznam v indexu obsahuje nějaký low-level odkaz na záznam v "hostitelské" tabulce. (Tedy pokud se jedná o index unikátní. Jak jste sám správně poznamenal.)

Pokud by bylo více Danů v tabulce, tak bude ukazovat na všechny Dany.
Tak. V tom případě se nejedná o index unikátní. I tak má příznivý vliv na rychlost selectů apod., které nad pojednaným sloupcem budete provádět.

Mimochodem index se dá definovat i nad více sloupci - tzn. můžete si třeba oindexovat "složený klíč", třeba jméno+příjmení. Kombinací více sloupců dosáhnete unikátnosti záznamů v indexu (nebo téměř).

1035
Server / Re:Vysvětlete mi indexování v databázi
« kdy: 14. 06. 2018, 09:47:08 »
Když nemám index, tak pokud zadám dotaz, tak se musí projet všechna data po jednom, pokud mám index, tak systém ví, kam má přesně jít a nemusí procházet všechna data. Index je datová struktura uložená v paměti a používá B+ stromy.

Zaklínadlo je právě B-tree. SELECT potom nemusí procházet (porovnávat) N záznamů, ale stačí mu log2(N) porovnání. Což znamená rozdíl 1000 vs. 10 nebo 1 000 000 vs 20. Ona údržba toho indexu taky něco stojí, ale odehrává se při vkládání záznamů (a i tak vložení záznamu opět NEznamená projít celou tabulku). Takže index má smysl pro velký počet záznamů a zejména pro tabulky (sloupce?) kde se často hledá (čte) a málo vkládá (zapisuje). Nebo nad sloupci, na které se provádí join mezi tabulkami!

B-tree má jeden obecný vtipný aspekt, přítomný v různých implementacích - pokud zkusíte používat nějaké B-tree knihovny v jazyce nízké úrovně, třeba v Cčku: samotná stromová struktura nijak těsně nezávisí na datovém typu, který stromem třídíte. Tzn. kostra stromu je prakticky stejná, ať se jedná o integer, nebo třeba o řetězec znaků o proměnlivé délce. (Nebo o Váš vlastní bizardní objekt se svéráznou sémantikou porovnávání.) Finta je v tom, že B-tree knihovně při vytvoření stromu předáte odkaz na "porovnávací funkci". V zásadě se jedná o funkci "je větší než", která bere dva argumenty "konkrétního cílového" datového typu. A pak už do stromu jenom sypete položky (resp. v našem případě odkazy na záznamy v DB) a on si porovnávací funkci úkoluje po svém. Vám při vyhledávání vypadnou hotové výsledky. Zdejší věrozvěsti funkcionálního programování zajisté pobaveně kroutí hlavou jak přednáším o vynálezu kola.

Nicméně... Jak je ten index uložený v paměti? Nedovedu si to prostě představit... to se vytvoří nová tabulka? Jak ta tabulka bude vypadat? Jak probíhá to "propojení"? Jak si zvolím ty hodnoty indexové? Když budu mít index na id nějakých zaměstnanců, tak z těch id se vytvoří ten b+ strom? Když budu chtít index na příjmení zaměstnanců a třeba budu hledat "Novák" - tak jak to bude konkrétně vypadat? To se projede ten index a index odkazuje na ty data přímo a projde se mnohem méně těch datových položek?

Jak je index uložený v paměti. Jak je binární strom uložený v paměti. Zkoušel jste programovat v Cčku, Pascalu, Perlu, nebo nějakém jiném jazyku, kde lze dynamicky alokovat "kompozitní" datové typy jako struct/record a odkazovat se na ně pointery/referencemi apod.? Většinou je tahle látka vyučována cca v pořadí pointer, struct, linked list, strom. Plus na to navazuje téma o "alokátorech" paměti = jak se z té "společné hromady" parcelují kousky RAMky pro jednotlivé structy = uzly stromu, tzn. co se skrývá za funkcemi jako malloc()/free(). To se pořád bavíme o RAMce / heapu. On se ale index nemusí do RAMky celý vejít, nebo není potřeba aby místo v RAMce trvale zabíral. A rozhodně potřebuje mít zajištěnu "perzistenci". Takže ano, ukládá se i na disk. Vlastně se dá i přímo na disku procházet, aniž by se celý do RAMky natáhl. Opět platí výše zmíněné "poměry akcelerace" - jenom už se nebavíme o porovnávacích operacích co operují čistě v RAMce, ale latence každého kroku bude určena latencí seeku na disk. (Nebo něco mezi, protože několik uzlů B-stromu bude na disku pohromadě v jedné alokační jednotce.) Navazuje problematika alokace místa na discích - a nebudu odkazovat striktně na souborové systémy, protože mnohé databáze rády fungují přímo na diskový oddíl (blokové zařízení) a spravují si alokaci "po svém". To je myslím už poměrně dost buzzwordů do googlu, co říkáte :-) Samozřejmě je index s tabulkou provázaný odkazy, jak v RAMce, tak na disku. Skutečné interní algoritmy indexování, alokování souvisejících datových struktur v RAMce a na disku, to je "sladké tajemství" každého DB enginu. U komerčních DB se jedná o obchodní tajemství / klíčové intelektuální vlastnictví, u open-source DBMS Vám nic nebrání ponořit se do zdrojáků a číst. V souvislosti s indexováním se zkuste mrknout vedle b-trees také na "hash" algoritmy, které k problému přistupují trochu jinak a mohou urychlit prohledávání indexu jiným způsobem.

Pro Vás jako uživatele RDBMS  = programátora aplikace a SQL dotazů je důležité, že tohle všechno se děje "pod kapotou", kam v zájmu svého duševního zdraví nechcete moc nahlížet. Od toho Vám pánbůh seslal DB engine, aby se postaral o Vaše pohodlí. Takže na úrovni SQL není index sám o sobě moc vidět. Vy ho vytvoříte příkazem cca CREATE INDEX ON TABLE, čili vznikne tam jakýsi objekt ve "jmenném prostoru věcí co jste si v databázi vytvořil", ale je pevně přivázaný ke konkrétní tabulce, a při SELECT/INSERT/UPDATE/DELETE se každopádně bavíte pomocí SQL příkazů explicitně s _tabulkou_, nikoli s indexem. Čili Index je v tomto smyslu občanem nižší kategorie než třeba "view". Nebo jinak, Index je za provozu spíš jenom takový "astrální duch v pozadí", který na Vaši tabulku potichu dohlíží. Existuje také explicitní "DROP INDEX", v různých dialektech SQL buď samostatný, nebo v rámci "ALTER TABLE".

A ještě jedna poznámka: snad všechny DBMS vytvoří impliticní index, pokud zmíníte klauzulku PRIMARY KEY v rámci SQL příkazu CREATE TABLE. Prostě primární klíč bývá implicitně indexovaný, aniž byste si o index musel ještě nějak extra říct pomocí CREATE INDEX. Stačí že si řeknete o PRIMARY KEY.

Stran: 1 ... 67 68 [69] 70 71 ... 77