WeeklyOSM CZ 257 na Talk-cz - OpenStreetMap.cz

Tom Ka tomas.kasparek na gmail.com #mbf2187 7. 7. 2015 14:33

Ahoj, je dostupné vydání 257 týdeníku weeklyOSM: http://www.weeklyosm.eu/cz/archives/4335 Téma čísla: Sbírka předčila očekávání * Oživení komunikace s KČT? * Mapillary pro Firefox OS nebo v JOSM * úmyslné ničení OSM kvůli výzkumu * Vizualizace rychlosti růstu OSM * Kdo získá Nokia HERE? Pěkné počtení...

jzvc jzvc na tpfree.net #m3062d4 7. 7. 2015 17:17

Ahoj, je dostupné vydání 257 týdeníku weeklyOSM: http://www.weeklyosm.eu/cz/archives/4335 Téma čísla: Sbírka předčila očekávání

Muj nazor na ty nakupy je takovej, ze je to technicky spatne. Data maj bejt na poli a servery maj mit jen CPU a RAM, bez disku. Pak se to lip spravuje, a daleko snaz taky rozsiruje. Kdyz potrebuju do pole dalsi kapacitu, prikoupim polici a disky. Kdyz potrebuju vic vykonu, koupim 1U s hromadou jader. Oni k tomu dojdou casem taky, ale v tyhle fazi mi to prijde jako pomerne vyhozeny penize. Trebas za tech 800k ... se da koupit pole s SSD cache (samo vcetne 20+ sas disku) (cca 400k) + 2x 2CPU 1U + 128GB. Tedy dokupy podstatne vykonejsi sestava nez co je odkazovany. A taky o dost bezpecnejsi - pole ma veskerej HW zdablovanej, takze pokud jedna pulka chcipne, jede to bez omezeni na ty druhy, a vymenit se to da za chodu.

Marián Kyral mkyral na email.cz #m9b8651 7. 7. 2015 18:11

Ahoj, je dostupné vydání 257 týdeníku weeklyOSM: http://www.weeklyosm.eu/cz/archives/4335 Téma čísla: Sbírka předčila očekávání
Muj nazor na ty nakupy je takovej, ze je to technicky spatne. Data maj bejt na poli a servery maj mit jen CPU a RAM, bez disku. Pak se to lip spravuje, a daleko snaz taky rozsiruje. Kdyz potrebuju do pole dalsi kapacitu, prikoupim polici a disky. Kdyz potrebuju vic vykonu, koupim 1U s hromadou jader. Oni k tomu dojdou casem taky, ale v tyhle fazi mi to prijde jako pomerne vyhozeny penize. Trebas za tech 800k ... se da koupit pole s SSD cache (samo vcetne 20+ sas disku) (cca 400k) + 2x 2CPU 1U + 128GB. Tedy dokupy podstatne vykonejsi sestava nez co je odkazovany. A taky o dost bezpecnejsi - pole ma veskerej HW zdablovanej, takze pokud jedna pulka chcipne, jede to bez omezeni na ty druhy, a vymenit se to da za chodu.

Zdar, myslím, že tady to asi těžko vyřešíme. Možná bys mohl OWG (http://wiki.osmfoundation.org/wiki/Operations_Working_Group) nabídnout pomoc. Marián

Petr Vejsada osm na propsychology.cz #mcd16e5 7. 7. 2015 18:59

začal bych třeba několika člověko-dny práce a lehce upravil totálně plýtvající DB schema. Vysvětlím na jedné tabulce, na tabulce s uzly. Máme tabulku nodes, obsahuje nody (id,version,lat,lon, changeset, visible, timestamp). V té tabulce jsou všechny, i smazané nody a všechny jejich verze za celou historii. Pak máme tabulku current_nodes, která je prakticky úplně stejná jako nodes a obsahuje "jen" aktuálně platné nody. Ano, úplně ty samé, jako jsou v tabulce nodes. Toto platí pro všechny tabulky (relations:current_relations, ways:current_ways, way_nodes:current_way_nodes, node_tags:current_node_tags, ...), takže celá aktuální planeta je v DB 2x plus celá historie. Úloha vyloženě dělaná pro Postgresql partitioning. Navíc mě nenapadá žádný důvod, proč by měla být celá historie v hlavní DB V Nominatimu jsou pro změnu geometrie 2x, některé až 4x; tam ale náprava není tak relativně jednoduchá. Tedy pokusil jsem se o částečné snížení redundance pro svoje účely, ale myslím, že mám reverzní geokodování rozbité :(

Marián Kyral mkyral na email.cz #m06fb9e 8. 7. 2015 7:51

Ahoj, zajímavý postřeh. Historii OSM databáze neznám a nepovedlo se mi ji teď dohledat. Možná pro to mají nějaký důvod. Nechceš to nadhodit tady? https://lists.openstreetmap.org/listinfo/dev Marián