REDGUY: měl jsem tam blbých 10 000 záznamů a snažím se vydedukovat, co je tam naprogramované blbě. Což není snadné a velikost sloupců v tom velkou roli hrát nebude:

mysql> SELECT id FROM guestbook WHERE (UNIX_TIMESTAMP(datum) + 3600*24 < UNIX_TIMESTAMP(NOW()) AND hodnoceni >= 0) ORDER BY id DESC LIMIT 64;ERROR 1030 (HY000): Got error 134 from storage engine

XCHAOS: Podle mě se to otázky pre-kompilace SQL dotazů docela dotýká porad cekame az nam vysvetlis cemu presne ta kompilace prospeje a jak moc.

ISTEVE: no prostě vím o řadě firem, kde by tenhle problém řešili přikoupením RAMěti pro databázový server (reps. přikoupením paměťové kapacity v cloudu) :-) (citation je profesní tajemství, takže nebude)

XCHAOS: u MySQL evidentně hraje roli to, zda se celý obsah tabulky vejde do paměti - Chces rict, ze si myslis ze kdyz mam 10GB tabulku a 1GB pameti, tak s ni MySQL neumi pracovat? Opravdu se snazis rict hole?

REDGUY: ano, skutečně mi to překvapilo. Nicméně potom už neprošel ani ten s nulou, tak to asi byla nějaká zanedbatelná náhoda (šlo prostě o množství výsledků v dotazu, kterých je pro lépe a lépe hodnocené komentáře logicky méně a méně).

Pokud ale dělám jen SELECT id FROM... tak se ta data se kterými dotaz pracuje do paměti bohatě vejdou a dotaz je navíc velice svižný.

Podle mě se to otázky pre-kompilace SQL dotazů docela dotýká - i když jen letmo - protože jak je vidno, tak SQL není tak chytré, jak se snaží předstírat (aspoň MySQL ne)... prostě fakt rád bych zase dělal na kompilovaném projektu, kde některé věci jsou jasné předem a ne až za běhu.

DAVIDOWITCH: mno, viz předchozí: u MySQL evidentně hraje roli to, zda se celý obsah tabulky vejde do paměti i v případě, že WHERE formule s danými sloupci nepracuje. Velice trapné :-)

Jinak já nikoho omezovat nehodlám, ale taky mě nějak z principu nesednou centralizovaná clusterová/cloudová řešení - ne, že bych je chtěl zakazovat, ale prostě se mi je nechce implementovat. To, na co si stěžuješ je asi stejné, jako když ti u Apache nebo MySQL (viz předchozí) dojde paměť. To se děje dnes a denně a lidé používající na takové platformně dnešní CMS bastly jsou v takovém případě tak jako tak v koncích.

Opravdu nechápu, proč by měly statisíce až miliony lidí používat chybný neoptimalizovaný kód na např. dvojnásobném množství clusterovaných serverů, než by mělo být nezbytně potřeba :-)

XCHAOS: [citation needed]

REDGUY: pochopitelně. škoda, že je to tady offtopic :-)

Google chybu moc dobře zná, a je to moje oblíbená kategorie výsledků: "problém má i hodně jiných lidí"

řešení je ale prosté, milý Watsone:

select * from guestbook where id in (SELECT id FROM guestbook WHERE (UNIX_TIMESTAMP(datum) + 3600*24 < UNIX_TIMESTAMP(NOW()) AND hodnoceni >= 0) ORDER BY id DESC) limit 64;

prostě to bude o tom, že SQL předstírá, že je všemohoucí Bůh (resp. vševidoucí vědma) a že má na dotazy dostatek paměti. Ale pochopitelně nemá - a to už i u překvapivě krátkých tabulek, co do počtu záznamů - problém je prostě v tom, že celkový obsah tabulky se už nevejde do paměti, i když by to vadit nemělo, protože v té WHERE podmínce se s daným sloupcem vůbec nepracuje.

XCHAOS: Tak na externi database engine bych se klidne spolehl. Co to ma spolecnyho s MySQL ale nevim :-)

XCHAOS: Takze tvoje reseni je rict "sorry, mame plno"? To urcite potesi spoustu lidi. Bych zavedl i jinde. Treba ze v zadnem momente nesmi bejt nainstalovano vic nez 100k instalaci Debianu, aby to pohodlne zvladaly servery s packages.

XCHAOS: Aha, nezaregistroval sem. Distribuovany vypocty v heterogennim prostredi jsou celkem easy, akorat te to dost omezi v tom co muzes pocitat. Nejakej number crunching (mersene primes, SETI, protein folding), kde mas queue veci co je treba individualne zpracovat je easy. Treba i ta moje 3D grafika se na to da dobre napasovat (no, obcas).
Ale je spousta veci ktery naprosto neudelas, coz je vetsina velkejch fyzikalnich simulaci (nasobeni obrovskejch matic), protoze tam si potrebujou jednotlivy vypocetni nody vymenovat data a v momente kdy se naprosto nemuzes spolehnout nejen na vykon, bandwidth a latenci, ale ani na to ze ti tu masinu nekdo neodpojil, tak si to radsi spocitas lokalne.

XCHAOS: tak to bude záležitost provozovatele daného node, rozhodnout se jaké množství uživatelů jeho systém zvládá. 8)))

Jo, to zni skvele. Takze kdyz se budu chtit prihlasit do tvoji site, budu muset hledat provozovatele nodu, kterej je duveryhodnej, spolehlivej a ma zrovna volno? To zni skvele 8))

mě se na cloud computingu něco dost zásadním způsobem nelíbí - co konkretne?

svoje osobní data bych především chtěl mít uložené na vlastní hardware A SOUSČASNĚ je zpřístupnit - aha. A kolik desetin procenta zbytku lidstva chce totez? Kolik lidi se chce srat s provozovanim vlastniho serveru, zejmena kdyz alternative je proste napsat "plus.google.com" do browseru? Jak spolehliva by byla sit tvorena nodama provozovanejma nahodnejma joudama?

REDGUY: tak to bude záležitost provozovatele daného node, rozhodnout se jaké množství uživatelů jeho systém zvládá.

mě se na cloud computingu něco dost zásadním způsobem nelíbí - neříkám, že neexistují aplikace, kde něco podobného má smysl, ale nelíbí se mi to, pokud se bavíme o každodenním použití dat - např. sociální sítě, uložení osobních dat.

svoje osobní data bych především chtěl mít uložené na vlastní hardware A SOUČASNĚ je zpřístupnit. nebráním se cacheování někde jinde, zálohování je spíše žádoucí - ale současně třeba chci mít u sebe uloženou zpětnou vazbu od jiných uživatelů (komentáře, hodnocení).

REDGUY: tak to bude záležitost provozovatele daného node, rozhodnout se jaké množství uživatelů jeho systém zvládá.

mě se na cloud computingu něco dost zásadním způsobem nelíbí - neříkám, že neexistují aplikace, kde něco podobného má smysl, ale nelíbí se mi to, pokud se bavíme o každodenním použití dat - např. sociální sítě, uložení osobních dat.

svoje osobní data bych především chtěl mít uložené na vlastní hardware A SOUSČASNĚ je zpřístupnit. nebráním se cacheování někde jinde, zálohování je spíše žádoucí - ale současně třeba chci mít u sebe uloženou zpětnou vazbu od jiných uživatelů (komentáře, hodnocení).

wow, tak tedy debugování TÉHLE chyby bych chtěl vidět :-) aneb zdrojáky MySQL budou určitě bomba :-)

SELECT count(0) FROM guestbook WHERE hodnoceni>0 ORDER BY id DESC LIMIT 64;
... v pohodě.

SELECT count(0) FROM guestbook WHERE hodnoceni>-1 ORDER BY id DESC;
... v pohodě.

SELECT count(0) FROM guestbook WHERE hodnoceni>-1 ORDER BY id DESC LIMIT 64;
... SQL session úplně vytuhne, resp. pokud tam nedám kumulativní funkci count() ale třeba *, tak to hodí ERROR 1030 (HY000): Got error 134 from storage engine

.... no, je to tady úplně offtopic, jen se těším, až někdo překompiluje mysql s debug info a vrhne se na to s gdb :-) (data do tabulky případně dodám)

XCHAOS: programatoru jako je napriklad D. Knuth je fakt malo. malokdo dokaze napsat aplikaci tak, aby se nemusela za poslednich 25let vyrazne menit. ano mluvim o TeX a tam by se dalo hovorit o zivotnosti programu.
vetsina dnesnich programatoru vidi programovani jako teoreticke hledani nekonecne lehkeho letadla s nekonecnym vykonem a doletem.

XCHAOS: tohle třeba řeší i takové nastavení pravidel přijímání nových uživatelů do víceuživatelského systému (reps. jejich dat), aby se ten růst zpomalil dávno předtím, než by bylo nutné přidat HW : Chces rict, ze problem s mizernym vykonem budes resit tim, ze proste nedovolis vic uzivatelu/dat a proste budes lidi posilat do prdele? Opravdu, opravdu tohle myslis vazne?

DAVIDOWITCH: ve skutečnosti, spíš jsem začal úplně nové téma, než že bych někam odbočoval.

je pravda, že distribuované výpočty mě zajímají daleko více v heterogením prostředí - co se týká administrace nebo vlastnictví hardware - než v homogenním prostředí.

TENCOKACISTROMY: to je samozřejmě pravda - ale tohle třeba řeší i takové nastavení pravidel přijímání nových uživatelů do víceuživatelského systému (reps. jejich dat), aby se ten růst zpomalil dávno předtím, než by bylo nutné přidat HW.

Představ si to jako životnost nějakého předmětu osobní spotřeby z hlediska života člověka: rozdíl mezi životností výrobku 60 vs. 120 let může být zcela zásadní :-)

No, právě jsem se u MySQL dopracoval na "Got error 134 from storage engine" - a to má ta tabulka teprve trapných 11326 záznamů. Takže nevím, jestli je vždy taková výhra spoléhat na externí databázový engine :-)