Administrace komentářů

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?