Canonical vydal (email, blog, YouTube) Ubuntu 24.04 LTS Noble Numbat. Přehled novinek v poznámkách k vydání a také příspěvcích na blogu: novinky v desktopu a novinky v bezpečnosti. Vydány byly také oficiální deriváty Edubuntu, Kubuntu, Lubuntu, Ubuntu Budgie, Ubuntu Cinnamon, Ubuntu Kylin, Ubuntu MATE, Ubuntu Studio, Ubuntu Unity a Xubuntu. Jedná se o 10. LTS verzi.
Na YouTube je k dispozici videozáznam z včerejšího Czech Open Source Policy Forum 2024.
Fossil (Wikipedie) byl vydán ve verzi 2.24. Jedná se o distribuovaný systém správy verzí propojený se správou chyb, wiki stránek a blogů s integrovaným webovým rozhraním. Vše běží z jednoho jediného spustitelného souboru a uloženo je v SQLite databázi.
Byla vydána nová stabilní verze 6.7 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 124. Přehled novinek i s náhledy v příspěvku na blogu. Vypíchnout lze Spořič paměti (Memory Saver) automaticky hibernující karty, které nebyly nějakou dobu používány nebo vylepšené Odběry (Feed Reader).
OpenJS Foundation, oficiální projekt konsorcia Linux Foundation, oznámila vydání verze 22 otevřeného multiplatformního prostředí pro vývoj a běh síťových aplikací napsaných v JavaScriptu Node.js (Wikipedie). V říjnu se verze 22 stane novou aktivní LTS verzí. Podpora je plánována do dubna 2027.
Byla vydána verze 8.2 open source virtualizační platformy Proxmox VE (Proxmox Virtual Environment, Wikipedie) založené na Debianu. Přehled novinek v poznámkách k vydání a v informačním videu. Zdůrazněn je průvodce migrací hostů z VMware ESXi do Proxmoxu.
R (Wikipedie), programovací jazyk a prostředí určené pro statistickou analýzu dat a jejich grafické zobrazení, bylo vydáno ve verzi 4.4.0. Její kódové jméno je Puppy Cup.
IBM kupuje společnost HashiCorp (Terraform, Packer, Vault, Boundary, Consul, Nomad, Waypoint, Vagrant, …) za 6,4 miliardy dolarů, tj. 35 dolarů za akcii.
Byl vydán TrueNAS SCALE 24.04 “Dragonfish”. Přehled novinek této open source storage platformy postavené na Debianu v poznámkách k vydání.
Oznámeny byly nové Raspberry Pi Compute Module 4S. Vedle původní 1 GB varianty jsou nově k dispozici také varianty s 2 GB, 4 GB a 8 GB paměti. Compute Modules 4S mají na rozdíl od Compute Module 4 tvar a velikost Compute Module 3+ a předchozích. Lze tak provést snadný upgrade.
Nevim, zda tento dotaz patri vic sem, nebo do HW poradny - dotyka se obou oblasti.
V ramci jednoho meho projektu planuji vyuziti databaze PostgreSQL. Vzhledem k tomu, ze me domaci PC jiz dosluhuje, rohodl jsem se jej nahradit necim novym strojem co bude po nekolik mesicu hrat ulohu DB serveru a po skonceni projektu nasledne nahradi me stare zelezo. Jelikoz ale financni prinos z tohoto projektu je velmi nejisty a vse pujde z me kapsy, tak nechci investovat prilis mnoho. Muzete mi poradit na co se zamerit, nebo i pripadne konkretni komponenty?
Velikost databaze odhaduji na ~50 GiB s tim, ze po naplneni bude probihat temer vyhradne cteni. Planuji pouze dva soucasne pripojene lokalni klienty. Nebude tedy zapotrebi zadne velke network I/O, ale rychle disky a zrejme take spousta pameti pro cache...
Cenovy strop jsem si zatim stanovil na 30 - 35 kKc. Predpokladam minimalne dvoujadrovy procesor, ctyri SATA disky spojene do RAID 0 a asi 8 GB RAM. Po projiti nabidky na http://alza.cz bych to videl tak na nasledujici:
Jako systemovy disk zrejme pouziji PATA Seagate 160GB ze stareho pocitace. Jako operacni system pak Linux - s nejvetsi pravdepodobnosti posledni verzi openSuSE. Souborovy system pro datovy oddil s databazovymi daty (RAID 0 - striping) by asi byl ext2 pripojeny s volbou 'noatime'. Systemovemu disku je to asi jedno, takze tam muze zustat ext3.
Jsou me uvahy spravne? Jak na tom bude vykonove integrovany RAID na desce? Nebylo by lepsi se radeji poohlednout po samostatnem radici - napr. Adaptec AAR-1430SA nebo spise vyuzit maximalni moznosti desky a jeste zdvojnasobit pamet na 16 GB? Nebo byste pripadne zvolili jinou kombinaci velikosti a znacek disku?
Jak v tomto pripade nastavit PostgreSQL pro nejlepsi vykon? Zatim nemam z PostgreSQL temer zadne zkusenosti, takze predem dekuji za jakekoliv rady.
Jak jsem se tak dival, tak zminovany radic od Adaptecu je "HostRAID", takze stejne asi vetsinu prace tohoto "radice" odedre primo CPU... 
Ahoj.
50GB uz neni zas tak malo. Zalezi na povaze dat, ale z vlastni zkusenosti mohu doporucit RAID 10. 30-35kKc neni take zas tak uplne maly peniz, taakze by ses mohl poohlednout i po znackovem zeleze s HW raid controllerem. I kdyz USD leti vzhuru, furt se to da. Pokud stavim DB stroj, ktery ma byt zaroven i storage, tak pouzivam IBM 3650 s 2.5" 15krmp diskama (jde jich tam nastrkat az 8, ale jeden stoji bratru 4-10kKc). Rychle disky jsou zaklad. Pokud ti nevyjdou prasule na takovyto stroj, tak bych doporucil koupit mraky malych, treba 80GB SATA disku a dat je do R10. Jsou desky co zvladnou i 8 SATA nebo koupis radic od Adatecu. Ja osobne jsem si v posledni dobe oblibil GIGABYTE MA78G-DS3H (maji na alzaci) s Phenomem X4. RAM do toho nacpi co muzes, ta se hodi vzdycky. A co se tyka CASE, tak si dovolim doporucit Chieftech (jsou dobre stavene a dobre se chladi).
Dulezitym faktorem ke zvyseni vykonu jsou partitions. V PSQL si je musis "vytvorit" sam, ale je to vcelku snadne www.postgresql.org/docs/8.1/interactive/ddl-partitioning.html
Co se tyka nastaveni PSQL, tak vyzkousej treba tento postup:
shared_buffers = 1/4 TOTAL RAM
effective_cache_size = 1/2 TOTAL RAM
work_mem = 1/8 TOTAL RAM
maintenance_work_mem = 1/8 TOTAL RAM -- podle potreby
Snad ti to helpne 
Tem partitions moc nerozumim. K cemu to je dobre? Slysim o nich poprve...
Struktura zaznamu v tabulce bude
serial, bit(256), integer, integer, integer, integer
Nad jednotlivymi numerickymi sloupci vytvorim zrejme index, nebot se podle nich bude vyhledavat a sekvencne prochazet vse by asi nebylo to prave orechove. Co jsem tak zkousel vygenerovat data pro jednu tabulku, tak to delalo ~40 mil zaznamu a ~3 GB mista na disku. Jak v tomto pripade mohou partitions pomoci?
V kostce: Partitisny ti rozdely tabulku na x podcasti. Zmensi se ti tim mnozina prohledavanych dat. V praxi to znamena, ze tbl s 1 000 0000 zaznamu si treba rozdelis do 4 dilu, v tvem pripade treba podle serial (serial between 0 and 249000); (serial between 250000 and 499999) ... no a kdyz das SELECT xyz FROM TBL WHERE serial = 152, tak to prohledava pouze index 1. tabulky a na zbytek to prdi => usetris hromadu casu s prohledavanim velkych indexu. Zaroven se tim i zmensuje velikost indexu.
Hlavni vyhody partitions poznas pri update, delete, kde se ti prepocitavji indexy. Opet operujes s daleko mensi mnozinou indexu, nez pri jedne velike tbl. dalsi prinos to muze mit treba v tom, ze jednotlivym partitions priradis ruzne tablespaces, takze si muzes ridit vykonost systemu i podle vykonosti storage. U casovych dat, treba umistis nejaktualnejsi data na rychly SASy, kdezto data kam se divas jednou za mesic das na polede ze SATA.
Jak moc, jaka data a kam si PostgreSQL uklada v prubehu zpracovani dotazu? Tak mne ted napadlo zda by bylo mozne pouzit Solid State Disky - vykonostne pro cteni na tom budou lepe nez klasicke i 10k otackove, ale pri castem zapisu by to asi nebylo to prave... Cenove v prepoctu na kapacitu je to zhruba srovnatelne.
4.3.2009 19:09
frEon | skóre: 40
| Praha
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
deb http://ftp.cz.debian.org/debian jessie main contrib non-free
2.3.2009 21:03
AraxoN | skóre: 47
| blog: slon_v_porcelane
| Košice
jj, tým by som začal, že ten PATA disk úplne odstránim z úvah o serveri za 35k CZK.
Druhú vec, ktorú by som vystrelil preč je ten "RAID". Ak na tom po skončení projektu chceš prevádzkovať Windows, tak dajme tomu, že OK, ale v Linuxe by som išiel cestou SWRAID z linuxového jadra.
No, nevim, zda na svem domacim stroji jeste nekdy budu potrebovat MS Windows abych je musel pustit primo na HW. Reseni s VMware se mi celkem osvecilo. Navic pokud se nemylim ve verzi XP Professional stejne neumi vyuzit vice jak 4GB pameti a kupovat neco novejsiho, pro to zatim nevidim jediny rozumny duvod.
Jak jsem jiz na zacatku uvadel ten stroj bude spise lepsi workstation ktera bude docasne fungovat jako databazovy server. Nechapu proc by mel PATA disk pro system vadit. Taktez proc bych mel vymenit alespon castecnou HW podporu RAIDu za SW RAID. Predpokladal jsem, ze je kazda cast prace kterou mohu ze systemoveho CPU presunout nekam jinam je prinosem pro celkovy vykon sestavy.
3.3.2009 10:12
AraxoN | skóre: 47
| blog: slon_v_porcelane
| Košice
Ten "čiastočný" HW RAID nie je ani len čiastočný HW RAID. Všetko oddrie procesor, tak isto ako pri tom RAIDe z jadra. RAID z jadra ale má ustálené rozhranie, je rokmi preverený a bude fungovať aj keď matičná doska odíde do večných lovísk a vymení sa za inú, s iným radičom diskov. Naproti tomu tie "HW RAIDy" majú každý jeden iné rozhranie a spôsob ukladania metadát, firmware vyrábajú nejakí ťamťungovia za dolár na deň, a keď sa ten fras pokazí, tak buď zoženieš presne taký istý, alebo si pravdepodobne práve prišiel o všetky dáta. Tento druh "RAIDu" sme zo začiatku dávali na naše servery v dobrej viere, že to je niečo viac. Bohužiaľ sa nám to pekne vypomstilo a od istej doby používame buď RAID z jadra, alebo nejaký naozajstný HW RAID (3ware, HP, ...). RAID na doske je dobrý len na to, aby si sa naštval a unavil, zabiješ s ním toľko času, že by si za neho kľudne naštudoval mdadm, a keď sa pokazí, tak to ani nechceš vedieť čo sa bude diať.
No a teraz k tomu, prečo tam nepridávať starý PATA disk: nepríklad preto, že v bedni zvýši produkované teplo a čím viac diskov, tým musia byť bližšie pri sebe (fyzické rozmery bedne nepustia). Keď to nie je správne chladené, tak si disky navzájom ohrievajú elektroniku (typicky ten dole ohrieva elektroniku toho nad ním, preto je veľmi žiaduce pri montáži nerobiť taký ten hamburger z diskov, ale nechávať medzi nimi voľný slot), výsledkom je znížená životnosť a chybovosť za prevádzky (v messages sa potom objavujú roztodivné errorové hlášky). Urobiť správne chladenie v domácich podmienkach je dosť náročné, a nie každý chce mať doma taký počítač, kde hučí osem ventilátorov. Starý disk je okrem toho miestom pravdepodobného výskytu chyby v budúcnosti a úzkym hrdlom pre výkonnosť (ak tam budeš mať napríklad /tmp, swap, či /var).
S tim swapem a /tmp mas asi pravdu, ikdyz u meho soucasneho stroje s 1 GB pameti jsem si snad jeste nevsimnul, ze by nekdy vubec swap pouzil... Mozna proto jsem o umisteni swapu nepremyslel.
Kde lze najit informace o tom jak se jednotlive disky hreji?
DB stroj by nikdy nemel swapovat. Jestlize swapuje, tak je spatne nakonfigurovany pro pouzivani RAM.
Jaky maji disky ztratovy vykon najdes u vyrobce.
Uvazoval bych takto (razeno dle dulezitosti)...
Datove disky - WD VELOCIRAPTOR 74GB, SATA/300, 10000RPM, NCQ,16MB v konfiguraci 3x v RAID5, nebo (idealne) 4x v RAID10. Na RAID0 (striiping) zapomen, mas-li sva data rad. ~ 4000,-/kus
RAID radic - zadny HW RAID radic!, vytvorit v linuxu softwarovy RAID (mdadm). Tzn. nevyuzit ani funkce toho na zakladni desce integrovaneho s vlastnim BIOSem.
Zakladni deska - s chipsetem s dostatecne rychlym/propustnym pripojenim na jizni mustek, bez integrovane graficke karty! napr AMD 790FX + SB600/750 od provereneho vyrobce (ASUS, Gigabyte, ...) ~ 3500,-
Zdroj - kvalitni (Enermax, Fortron, ...) 600W, s aktivnim PFC a vysokou ucinnosti (predpokladam, ze se jedna o 24/7 server) ~ 3000,-
Zalozni zdroj - offline s USB feedbackem, filtrujici napeti a poskytujici alespon minimalni cas na korektni vypnuti pocitace v pripade vypadku, napr. APC 700VA CyberFort II nebo Trust PW-4080T 800VA. ~ 2500,-
CPU - s velkou cache, s nizkou spotrebou , s rychlou systemovou sbernici, nemusi byt nutne ctyrjadro - dva klienti jej nevyuziji -AMD Phenom™ II X3 710, 2.6GHz, 6MB L3, TDP 95W, ~ 3500,-
Pameti - 4GB neECC moduly nesezenes, bohate bude stacit 4x 2GB DDR2 800MHz (pripadne pro Phenoma II 1066Mhz), ~3500,- (low value RAM ~2500,-)
Systemove disky - idealne dva rychle v RAID1 (mirroring), ale muzou byt i obycejnejsi (7200RPM, <160GB). Pokud chces vyuzit stavajici PATA budiz, ale minimalne bych k nemu poridil do paru (RAID1) dvojce. ~2000,-
Sitova karta - PCIe GLAN idealne diskretni, v tomto konkretnim pripade (nizke I/O) muze byt i onboard
Skrin - dle vlastniho uvazeni, prostornou, dobre odvetravanou, muze byt i miditower, napr. Cooler Master Elite, .... ~ 1500,-
Graficka karta - aktualni pasivne chlazeny energeticky nenarocny low low end (treba i stara PCI S3 Trio co se vali v supliku). ~ < 1000,-
DVD mechanika - snad ani nebude mimo instalaci potreba, ale pro jistotu ... napr. DVD-ROM Nec 16x/48x DDU1675A. ~ 500,-.
Uvedene ceny jsou orientacni, preferovane znacky si zamen za sve oblibene/proverene ...
Diky za pripomenuti. Na UPS jsem uplne zapomel. Ta tam bude muset byt urcite.
Co se tyka pameti, tak v nabidce Alzy jsou 4GB DDR2 pametove chipy na 800 MHz. Co by mel byt za problem? Zakladni desky co jsem u nich videl maji navic i pri podpore 16 GB RAM pouze 4 sloty pro osazeni...
Ty pameti jsou fajn, jedine v cem je problem je dvojnasobna cena (oproti stejnemu mnozstvi pameti ve 2GB modulech), coz pri tvem rozpoctu na pocitac IMHO hraje roli.
To by me interesovalo, co lidi porad maji s tim PFC. Vedi vubec co to je? A proc navrhuli 600W zdroj pro servrik, ktery bude mit spotrebu 70W v iddle a do 200W v zatezi? Vedi vubec, ze zpinane zdroje maji nejvyssi ucinnost pri cca 80% zatizeni a pri zatizeni pod 20% jde ucinnost vyrazne dolu?
2x 4GB DDR2 800MHz kity jsou k dostani, leckde jsou i skladem na prodejne, treba tady http://www.alfacomp.cz/php/index.php?eid=15L1K30820TW1SR
Pozor na zalozni zdroje Trust, ujisti se, ze ho muzes vratit v pripade potreby. Nerozumi si s mnoha zdroji. Mam Enermax Liberty a pri vypadku napajeni se pocitac restartnul i kdyz nebyl zatizeny. Papirove slabsi APC funguje bez problemu.
Vime 
A na tu "pilu" co leze z lowend UPS se bude hodit.
Souhlasim, ze i 600W zdroj je naddimenzovany (v puvodnim navrhu chtel 900W), ale bude se hodit po skonceni projektu, kdy tu sestavu "degraduje" na workstejsnu a dokoupi si do ni ATI HD4870 nebo nejakou podobnou obludu ...
Po letitých bojích s neserverovým železem bych na provoz pod zátěží 24/7 šel jen se značkovým serverem. Máme výborné zkušenosti s nejnižšími modely HP ML, např. ML115. Stojí jako trošku dražší desktop (dříve v základu cca 11k, dnes trochu výš), ale za spolehlivost a provedení se nám to bohatě vyplatilo. Narozdíl od vyšších modelů s Xeony nepotřebují drahé ECC paměti, stačí třeba značkový Kingston. SATA řadič integrovaný v čipsetu Nvidia nám dává na swraidu10 se 4 x Samsung 750GB čtení i synchronizaci pole okolo 180MB/s. Nejsem žádný dealer HP, ale tato řada serverů mě fakt potěšila.
3.3.2009 18:15
AraxoN | skóre: 47
| blog: slon_v_porcelane
| Košice
jj, značkové servery sú v dnešnej dobe veľmi lacné a kvalitné, a nemusí ísť len o HP. Zákazník bral Fujitsu Siemens, ten najnižší model v toweri, a po nás chcel inštaláciu. Bol som veľmi prekvapený, že server za 15k SKK šľape rýchlo a bez problémov - už od leta beží nonstop v miestnosti bez klimatizácie a zatiaľ spokojnosť. To sa bohužiaľ nedá povedať o niektorých našich poskladancoch, ktoré by už boli uvarené nebyť klimatizácie v serverhousingu.
Zpočátku (2003?) jsme také pořizovali slepence z rádoby serverových dílů pro klimatizovaný serverhousing. Do roka odcházely zdroje, dokonce i deska. Zjistili jsme, že nemáme šanci posoudit kvalitu kupovaných dílů, i když byly docela drahé (Tyan apod.). Ty ML115ka jedou v neklimatizované místnosti již skoro dva roky. Na serverhousing jsme samozřejmě koupili výkonnější modely, kde je ale cena úplně jinde.
Také jsme ocenili, že tyto servery lze rozšiřovat o standardní HDD. Např. nejnižší IBM x206 (po roce provozu odpadl chladič čipsetu :) ) vyžadoval (2006?) na HDD speciální hotplugový rámeček, běžně nedostupný. Samozřejmě vyšší modely HP s hotplugem jej mají také, ale pro základní server hotplug nepotřebujeme, spíše možnost levně rozšířit pole.
Ok. Tak ta zatabaze bude vlastne uloziste dat - vzoru, ktere se z ni budou tahat a vzajemne porovnavat. To bude castecne prace pro perlovy skript, ale i pro databazi. Nechci znovu objevovat kolo vytvarenim vlastniho enginu, kdyz uz existuje reseni, ktere je navic proverene a velmi efektivni. Nulova redundance dat neni zase az takovy problem, nebot ty lze v pripade havarie znovu vygenerovat (ikdyz vytvoreni kompletniho setu je pro PERLovy skript prace tak na tyden a pul na Pentium M 1,6 GHz). Hlavni vyuziti databaze budou SELECTy => cteni dat z disku a jejich porovnavani. Takze bych to na tu 386 rozhodne nevidel. Tedy pokud chci ziskavat odpovedi v historicky kratke dobe
Data jsou rozdeleny do deseti tabulek. Prvni dve mely po naplneni na starem stroji kolem 44 a 48 milionu zaznamu a z disku to ukrojilo pres 3 GB na tabulku. Dalsi tabulky budou predpokladam vetsi, nebot tam neni tolik omezujicich podminek. Jak jsem zde jiz uvadel jeden zaznam bude mit celkem sest polozek nasledujicich typu
serial, bit(256), integer, integer, integer, integer
ikdyz ten sloupec typu serial (jednoznacne id) by tam mozna byt ani nemusel. Ale asi jo, protoze pak by unikatni index musel byt postaven pres vsechny sloupce... Indexy budou nad jednotlivymi sloupci typu integer, nebot podle nich se bude vybirat. Ukolem bude vybrat z kazde tabulky zaznam tak aby splnovaly urcite podminky - shodovaly se prislusne udaje v tech numerickych sloupcich. Budou se tedy vybirat desetiprvkove sety vyhovujici zadanym kriteriim z minimalne 500 milionu zaznamu. Jak rychle ci spise pomale to muze v realu byt to netusim. Vystup pak bude dale zpracovavan skriptem.
Co se tyka zdroje, tak tady se nebojim si priznat, ze tomu nerozumim ani za mak. Nemam predstavu a nevim jak si spocitat realnou spickovou spotrebu vsech komponent. Rikal jsem si, ze silnejsim zdrojem nic nepokazim. Vybiral jsem spise aby mek dostatek prislusnych konektoru. Ani mi tehdy nedoslo, ze existuji rozbocky a redukce...
Ohledne pameti jsem puvodne uvazoval 4GB moduly hlavne kvuli pripadne moznosti rozsireni na maximum co umi vybrana deska, tj. 16 GB. Pocital jsem ze vetsinu sezerou ruzne cache (hlavne diskova).
Jak rychle ci spise pomale to muze v realu byt to netusimTo je docela fatální nedostatek, protože první věcí při řešení optimalizace je změření stávajícího výkonu. Nešlo by třeba ten projekt nasimulovat na Vašem starém železe a udělat si o tom rámcovou představu? Pokud opravdu nevíte jak to bude, tak si kupte nějakou vyváženou sestavu, ale slabší, a ušetřete si peníze na případné dokoupení co bude potřeba - zřejmě minimálně tu graf. kartu až z toho uděláte pracovní stanici.
Nulova redundance dat neni zase az takovy problem, nebot ty lze v pripade havarie znovu vygenerovatZde je rozhodujícím faktorem vůle čekat na generování nových dat, aneb potřeba vysoké dostupnosti služby.
Nemam predstavu a nevim jak si spocitat realnou spickovou spotrebu vsech komponent.Vaše sestava se IMHO vejde do 200W - TDP u procesoru máte dané (dejme tomu 100W), disk sežere jeden tak 20 a základovka možná taky tolik. Na distribuci napájení Vám samozřejmě postačí prodlužky. Doporučuji koupit zdroj s certifikací 80+, a pokud Vám nevadí změť kabelů tísnící se na dně skříně, tak nepotřebujete vyhazovat peníze za modulární konektory. Nicméně kvalitní zdroj je základ všeho, takže nekupujte žádné šunty za 600 korun. (Viz tipy v minulém příspěvku.) Budete-li dokupovat grafiku, počítejte taky tak +100-200, čili 500W zdroj bude úplně v klidu. 900W je pro lidi, co mají 4 grafárny.
Mno, pořád jste neřekl to nejdůležitější a to je očekáváný load (dotazy za sekundu a horní limit na časovou odezvu). Pokud to bude přechroustávat nějaký skript na pozadí, tak ten nebude řešit, zda to trvá minutu nebo hodinu, ale uživatel to samozřejmě řešit bude.
Jak uz jsem zminoval jinde, jedna se o soucast reseni jednoho hlavolamu - najit spravne usporadani hracich kamenu v prostoru. Zpracovat standardne cely problem naraz je temer nerealne (spise otazka velikeho stesti pri vyberu pocatecniho usporadani kamenu), proto jej chci rozdelit na nekolik dilcich soucasti. Pri pouziti klasickeho zapisu algoritmu do programu tento nebyl schopen diky rozsahlosti datove zakladny dojit k cili za nekolik dnu...
To je docela fatální nedostatek, protože první věcí při řešení optimalizace je změření stávajícího výkonu. Nešlo by třeba ten projekt nasimulovat na Vašem starém železe a udělat si o tom rámcovou představu?
Na soucasnem stroji jsem po nejake te minute dostal na SELECT DISTINCT edge_right FROM block1x1; dostal odpoved, ze ma nedostatek mista. Nevim ale kde. Na oddilu s daty bylo volnych 1,2 GB a v /tmp zustavalo okolo 800 MB. Na to abych tam dostal vsechny data nemam ani prostor nebot prvni dve tabulky si ukrojily kazda minimalne 3,5 GB. Pritom kolik mista nestacilo na ten SELECT DISTINCT v ramci jedne tabulky bych asi nedelal SELECT pres vice tabulek.
Jinak to vypadá že budete mít hodně malých dat, takže bych v první instanci při dobrém indexování vyloučil disk jako místo optimalizace.
Jak tedy postavit spravne index kdyz jednotlive zaznamy predstavuji kameny umistovane do mrizky? Jednotlive sloupce typu integer udavaji typ hrany pres ktery se to pak sklada dohromady (WHERE block1x1.edge_right = block2x1.edge_left AND block2x1.edge_right = block3x1.edge_left). Bylo by tedy asi lepsi dat index pres protejsi strany kamenu, ze?
Jak uz jsem zminoval jinde, jedna se o soucast reseni jednoho hlavolamu - najit spravne usporadani hracich kamenu v prostoru.Takže je to čistě dávková úloha? V tom případě nacpěte peníze do procesoru a optimalizujte algoritmus tak, aby se neflákal.
Nevim ale kde. Na oddilu s daty bylo volnych 1,2 GB a v /tmp zustavalo okolo 800 MB.Zkuste to znova s tím externím USB diskem a uvidíte.
WHERE block1x1.edge_right = block2x1.edge_left AND block2x1.edge_right = block3x1.edge_leftPokud nekladete dotazy na uspořádání (menší, větší), ale jen na rovnost, je na místě použít hash tabulky. Index číslo jedna by pak jel přes (block1x1.edge_right, block2x1.edge_right) a číslo dva přes (block2x1.edge_left, block3x1.edge_left), respektive přes VIEWy které by tyto tabulky kombinovaly. V každém případě se koukněte na EXPLAIN SELECT... a měřte, profilujte, optimalizujte.
Pokud nekladete dotazy na uspořádání (menší, větší), ale jen na rovnost, je na místě použít hash tabulky. Index číslo jedna by pak jel přes (block1x1.edge_right, block2x1.edge_right) a číslo dva přes (block2x1.edge_left, block3x1.edge_left), respektive přes VIEWy které by tyto tabulky kombinovaly. V každém případě se koukněte na EXPLAIN SELECT... a měřte, profilujte, optimalizujte.
Z vasi reakce jsem ziskal dojem, ze jemozne udelat index pres ruzne tabulky, ale v dokumentaci jsem na to nenarazil. Pochopil jsem spatne vas pispevek, nebo jen spatne hledal? Mimochodem ve verzi 8.3 je v dokumentaci nasledujici zminka
Note: Testing has shown PostgreSQL's hash indexes to perform no better than B-tree indexes, and the index size and build time for hash indexes is much worse. Furthermore, hash index operations are not presently WAL-logged, so hash indexes might need to be rebuilt with REINDEX after a database crash. For these reasons, hash index use is presently discouraged.
Z vasi reakce jsem ziskal dojem, ze jemozne udelat index pres ruzne tabulky, ale v dokumentaci jsem na to nenarazil.Udělat to jde, když si nadefinujete správný VIEW přes víc tabulek. Můžete udělat viewy tupě přes (block1x1.edge_right, block2x1.edge_right) a (block2x1.edge_left, block3x1.edge_left) a oba je oindexovat. Ano, velikost indexu bude kvadratická. Záleží, zda všechny kombinace ve svém algoritmu k něčemu využijete. Druhou variantou je udělat VIEW přes příslušný JOIN na první podmínku a indexovat výsledek, pomocí něj pak vyhledávat druhou podmínku.
Mimochodem ve verzi 8.3 je v dokumentaci nasledujici zminkaTo je možné, já postgres tak dopodrobna neznám. Mluvil jsem o InnoDB v MySQL, o čemž povědomí mám.
Takze bych hadal nejake lamani sifer :)
Temer, jen tomu rikame hlavolam
5.3.2009 12:51
AraxoN | skóre: 47
| blog: slon_v_porcelane
| Košice
Na ukladanie stavov a prechodov pri riešení rôznych hlavolamov som kedysi používal mysql a musím povedať, že SQL databáza nie je na takýto druh úlohy to najlepšie. Nakoniec som ukladanie začal robiť do B+ stromu uloženého na disku a rýchlosť sa zvýšila oproti SQL rádovo. To čo predtým trvalo niekoľko hodín, sa zrazu stihlo za desať minút. Plnohodotný SQL server má príliš vysokú réžiu. Ak ovšem potrebuješ vyberať stavy podľa viacerých podmienok, tak ten SQL prístup je rozhodne jednoduchší a ak máš trpezlivosť čakať na výsledok mesiac, tak v pohode.
Databaze ma poslouzit jako druhy stupen zpracovani pro jiz nalezene dilci casti celeho reseni, jenz je zapotrebi vzajemne porovnat a skombinovat. Nasledne se skript bude snazit dopocitat zbytek. Pri tom mnozstvi dat mi to prijde jednodussi, nez vymyslet vlastni engine jenz bude operovat nad takto rozsahlym souborem dat.
Taktez pri hledani reseni tohoto problemu jsem prosel nekolika stadii ohledne vyberu jazyka a algoritmu. Pro testovaci mensi zjednodusene zadani
Pri aplikovani na uplne zadani bych se ale i tak vysledku nedockal v realnem case - exponencialni narocnost. Proto jsem to rozdelil na nekolik fazi ktere snad povedou k vysledku v historicky kratke dobe. Jednim z kroku je zpracovani vygenerovanych metadat pomoci SQL databaze.
To zminovane reseni ukladani pomoci B+ stromu by mne zajimalo. Kde najdu najake rozumne info ci priklady?
"Jelikoz ale financni prinos z tohoto projektu je velmi nejisty"
Nejedna se nahodou o tu skladacku, kde resitel dostane milion?(nevim presne, nemuzu to vygooglit)
Ano, jedna se o Eternity II. Odmena je vypsana, ale pravdepodobnost jejiho ziskani je dost mala. Za rok a pul to jeste nikdo nevyresil. Na odmenu ma narok prvni uspesny resitel, jenz svoje reseni zasle postou. Nesmi je ale sam zverejnit do vyhodnoceni zadavatelem jenz je jednou rocne. Vzhledem k tomu, ze uz se objevily zvesti o tom, ze uz se to letos nekomu konecne podarilo rozlousknout (pry nejaci studenti z jedne univerzity v madarsku) tak to beru spise jako vyzvu. I tak ale nalezeni uplneho reseni bude spise otazkem nahody pri moznem poctu kombinaci. Tedy alespon klasickym backtracking postupem bez jakychkoliv optimalizaci a heuristiky.
Tak v tomto pripade mi pouziti databazi prijde jako startovat v zavode dragsteru s bagrem ... a se spustenou radlici.
IMHO, pokud to chcete resit hrubou silou, zapomente na databaze. Na internetu se da najit nekolik aplikaci napsanych v C++ ci Jave, ktere se snazi tuto ulohu resit. Tohle je ciste vypocetni zalezitost. Napiste si program v C s co nejusporneji definovanymi hranami (v bitovych polich) a s co nejmene vypocetne narocnymi operacemi (bitovy posun), to vse pokud mozno vicevlaknove a jeste lepe distribuovane. V opacnem pripade vam vypocet na soucasnych domacich PC bude trvat tydny (spise mesice).
Ano, pres bitove masky a pole jsem to resil, jenze v PERLu (v C/C++ jsem naposledy delal neco vetsiho pred vice jak osmi lety a uz si na to netroufam; javu neznam vubec). I tak je to ale pri pouziti klasickeho backtrackingu jako celek hrubou silou neresitelne. Zato mi ale pripada celkem schudne vygenerovat nejake vetsi subbloky, udelat z nich vyber a tyto mezivisledky pak opetovne zpracovavat.
5.3.2009 19:51
AraxoN | skóre: 47
| blog: slon_v_porcelane
| Košice
B+ stromy vo všeobecnosti sú dobre popísané na internete a existujú aj knižnice, ktoré špinavú robotu urobia za Teba. Ja som použil svoje semestrálne zadanie ešte zo školy, keď sme mali programovať jednoduchý DB engine. Môžem To sprístupniť, ale je to čisté C-éčko, naprogramované bez toho aby sa myslelo na rozšíriteľnosť, znovupoužiteľnosť, či dobrú dokumentáciu. Tie stromy som tam používal na indexovanie stĺpcov, a keďže som nedoprogramoval v strome vymazávanie, tak nie je možné z tabuliek mazať záznamy, ani meniť také stĺpce, ktoré sú obsiahnuté v nejakom indexe. Na prehľadávanie stavového priestoru mi to ale stačilo, keďže som to indexoval podľa stavu - poľa bajtov konštantnej dĺžky.
Tiskni
Sdílej:
