Upgrade komentářů (diskuse)

[Leoš Literák]

Jedná se o již v blogu zmiňovanou změnu ukládání komentářu, každý komentář bude tvořit samostatný řádek v tabulce. Teď jsem začal testovat data po převodu a nejlepší diskuse na otestování je pověstný flame Proč je Linux pomalejší než Windows 95. První načtení je na nové verzi asi 2x rychlejší, druhé a další načtení je na nové verzi 20x rychlejší! (nefér srovnání abíčka vs. můj desktop).

[Jindřich 'GoldenShit' Plešinger]

   Pořád se tu remcá, že blogy znehodnocují ABCLinuxu. Byl bych pro ponechat pouze odkaz (v horním řádku odkazů) na blog a odkazovat ho na www.abclinuxu.cz/blog/souhrn, nebo pouze na seznam názvů blogů zobrazovaných ve dvou sloupcích a bez levého (zprávičky) a pravého sloupce. Zobrazovaný seznam by byl delší, nikdo by snad nemohl remcat, že obsah blogů by mohl někomu poškodit rozvíjející se názor na Linux a hlavně, byl by klid.

[Jindřich 'GoldenShit' Plešinger]

   Možná by se na novou úvodní stránku www.abclinuxu.cz/blog/ hodil místo zpráviček sloupek se seznamem blogerů seřazených podle počtu napsaných blogů, podle počtu návštěv blogů, nejlépe hodnocené blogy, ... . Prostě stránka jen o blogách a na hlavní stránce mít pouze odkaz.

[Leoš Literák]

O necem podobnem jsem jiz uvazoval, nicmene k veci: tvuj komentar je totalne offtopic Ted uz jen muzu cekat, az do diskuse o Firefoxu zacnes rozebirat jednotlive CAD

[Jindřich 'GoldenShit' Plešinger]

   Myslel jsem to tak, že jestliže budeš předělávat databázi ABCLinuxu, možná by si to mohl spojit s blogem. To jsi doufám pochopil. Neboj, o CADech budu psát pouze do blogu, nebo chtěl by si nějaký článek či recenzi?

[Leoš Literák]

Az budes v praci delat nejaky CAD vykres, mohl bys spojit s natrenim plotu

[Jindřich 'GoldenShit' Plešinger]

   Tomuhle nerozumím "s natřením plotu". Měl jsem na mysli třeba představení CFD modeláře Gambit, který je i pro Linux. Popis jak se v něm pracuje, co umí, jaké má závislosti, ... . Mám to chápat, jako že nemáš zájem?

[Leoš Literák]

Natreni plotu == Myslel jsem to tak, že jestliže budeš předělávat databázi ABCLinuxu, možná by si to mohl spojit s blogem.

Clanek - klidne napis, bude-li zajimavy a kvalitni, radi jej vydame.

[David Watzke]

To je super! Zrychlí to i výpis seznamu mnou napsaných příspěvků a tak? Občas si u toho trhám vlasy...

[Leoš Literák]

Teoreticky vyrazne, prakticky zatim na lokale vysledky spatne. Nedokazu pochopit, jak to ze join pres jednu dalsi tabulku, ve ktere se vyhledava INT v sloupecku s indexem, je pomalejsi nez hledani cisla uvnitr blobu. Takze ted si hraju a hledam zpusob, jak to optimalizovat. Pomoc zkusenejsich je vitana

[cronin]

Dovolim si rypnut: co tak pouzit nejaku databazu namiesto MySQL?

[Leoš Literák]

Vedet dopredu, jak bude prechod narocny, sel bych do toho. Ale kristalovou kouli nemam, takze volim vrabce v hrsti.

[madA]

Přechod na postgres by byl náročný pouze časově a na hw prostředky - na ty opravdu hodně (kolega to už několikrát musel provádět u poměrně náročných projetků, i když zřejmě ne tak rozsáhlých jako je Abíčko).

Napadá mě otázka jestli by bylo možné vyměnit práci za převední na postgre (pokud by Vám vyhovoval) např. za reklamní prostor. Prostě nějak tu práci ohodnotit v naturáliích .

[Leoš Literák]

Dohodnout by to urcite slo. Moc slozity by prevod asi take nebyl, vsechna SQL jsou na trech mistech, dialekty se lisi jen na par mistech. Asi "nejvetsi" zasah by byla zamena autoincrement sloupcu mysql za sekvence v postgresu.

Problem je tu spise psychologicky - od mysql vim, co ocekavat, znam ji. Od postgresu nevim, zda by se zmena vyplatila a zda by neprisly nove problemy.

[Dan Ohnesorg]

Zkusit explain, jestli se ten index opravdu pouzije.

O mysql mi dneska nemluv, cekali jsme pet hodin na vygenerovani primarniho indexu nad tabulkou s 3 mio radky a nakonec jsme to museli vratit z mysql5 na mysql4, ktera to zvlada v radu jednotek minut.

[Leoš Literák]

Prave ze pouzije, takze to nechapu. Ted se kvuli optimalizaci snazim naplnit jeden sloupecek, diky nemuz bych si mohl odpustit minimalne jeden join. Bohuzel nevim, jak to udelat v SQL, pridal jsem to tedy do java konverzni rutiny a ta ted trva skoro hodinu! To je prilis dlouhu vypadek, takze jdu zase experimentovat

[Dan Ohnesorg]

No vsak oni lidi radi prijdou znova, kdyz zrovba abicko nepobezi, takze ty reklamy se nakonec zobrazi

[Leoš Literák]

Radsi jsem zkusil napsat to hledani nadrazene relace a nastaveni hodnoty rucne, optimalneji. Snad to stahnu pod dvacet minut. A tim, jak se to protahuje, se posunul cas a vypadek zasahne mene lidi

[Miloslav Ponkrác]

Člověk, který použije nestabilní verzi mysql5, která není ještě určena k ostrému nasazení a ještě se diví? Vůbec mě děsí trend mnoha lidí spočívající v nasazování nehotových a k produkčnímu nasazení nedoporučených verzí. O to víc se divím, že se tím ještě někdo veřejně chlubí. Ale to jen tak na okraj, jako bych nic neřekl.

[Dan Ohnesorg]

Mysql 5 uz davno neni ve stadiu nestabilni verze a nektere projekty proste jednou dospeji do stadia, kdy mohou pokracovat prechodem na jinou databazi a nebo prechodem na vyssi verzi stavajici, byt to jeste neni verze overena dvema roky nasazeni na milionech instalaci.

Na dalsi akci FFII muzete rict Florianovi, ze mysql5 je nestabilni, budu to se zajmem sledovat

[Miloslav Ponkrác]

Naprosto netuším, co to je FFII, ani kdo to je Florian, ale myslím, že to není podstatné.

Já musím nasazovat věci, na které se mohu spolehnout. MySQL používám řadu let a vím, že i leckteré verze MySQL (mezi námi skoro každá verze) lze shodit vhodným SQL dotazem bez ohledu na její bezpečnostní nastavení. MySQL 5 byla prohlášena za produkční někdy na podzim minulého roku. Ale už i v této chvíli byly použity nekompatibility, které měnily chování oproti předchozím verzím MySQL 5, tudíž se tam zavedly nové neodladěné věci. Dodnes v poslední verzi (která vyšla 4. března 2006) sama firma MySQL AB píše, že pro MySQL 5 nejsou mnohé features testovány a nemůže zaručit jejich funkčnost.

Já umím bohužel vyhmátnout věci, které přestanou fungovat, jakmile na databázi sáhnu. Asi bych byl dobrý tester, protože na jakýkoli produtk sáhnu, velmi rychle zjistím, kde to hapruje.

Nějaké testování MySQL 5 a ověřování na miliónech instalací je Vám naprosto k ničemu, protože na 99% instalací nebude používáno stejně nic jiného, než pár jednoduchých selectů nad tabulkami o pár stovek řádcích, což Vám nic neřekne.

Já osobně v tuto chvíli budu ještě mysql 5 určitě ignorovat, protože bez ohledu na oficiální stav potřebuje ještě dozrát a určitě jí nebudu nějaký čas nasazovat. Zatím zůstanu u verze 4.1.

Nemám potřebu přesvědčovat Vás, ani pana Floriana, já jsem placen za to, že věci chodí, a to je pro mě skutečná odměna.

[Pavel Stehule]

Pro par adminu nebude dostatecne odladena databaze ani za 5 let. . Nestabilni jsou hlavne features jako jsou ulozene procedury, partitioning. Ostatni by melo byt v pohode. Kdyz budete cekat na stabilni verze, tak se nedockate. Chce to odvahu. Otestovat si funkcnost zas neda az tolik prace, a prejit na 5 ku se vyplati, uz kvuli vylepsene optimalizaci, a bohatsimu SQL. Uz to dokaze, skoro to co PostgreSQL , jsem si jenom rypnul.

Portace na PostgreSQL se nemusi pokazdy vyplatit, nema cenu ji delat na slepo. Odmonitorujte si nejpomalejsi a nejcastejsi dotazy, dumpnete databazi, a vyzkousejte je v Postgresu.

[cronin]

FYI: vyhladanie vsetkych prispevkov na abicku pre nejakeho pouzivatela tiez vacsinou skonci timeoutom.

[Leoš Literák]

To je ten duvod, proc jsem to vsechno prepsal. Ted by tato funkce mela byt o nekolik radu rychlejsi a prestat pretezovat databazi.

[Věroš]

Že jsem tak smělý, pokud je vyhledávání v diskusích jediným problémovým místem, mohla by to zvládnout i Lucene, ne? (Pořádně ji ale nepoužívám, takže jsem mohl přehlédnout nějaký zakopaný háček...).

[Leoš Literák]

hotovo. Fujjjjjj, to byl nářez. Nesnaším mysql, Dan Ohnesorg mě zachranil, dík moc.

[kavol]

no, bylo to trošku dýl než čtvrthodinka, ale ... gratuluju

[Cubic]

mam takovej pocit ze se to bez problemu neobeslo, viz moje potize

[Leoš Literák]

Bohuzel jsem mel na lokale nastaven velmi dlouhou dobu platnosti pripojeni na databazi, na serveru velmi kratkou. Takze doma mi to krasne jelo a na abicko to po minute spadlo. Rozhodl jsem se tedy vratit se k zaloze, zvetsit timeout a spustit proces nanovo. Jenze data nesla naimportovat! Zase hratky s collation v mysql, zdenek a zdeněk pro nej byli stejni uzivatele.

Dan mi tedy poradil, ze mam ten collate pridat za deklaraci tabulky do dumpu. Jenze editovat 200 MB soubor neni zadny med. Vi zklamalo, ty radky dlouhe tisice znaku jej udelaly neschopnym provozu. Takze jsem to zabalil a za deset minut mel na lokale. Oprava v neditu (s vypnutym zvyrznovanim syntaxe) byla hracka - skvely software. Jenze upload je vyrazne pomalejsi nez download.

Zacal jsem to tedy nahravat na server pres scp (zabzipovane). Po 80 minutach, kdyz chybelo poslednich 5 minut, mi Dan rekl, at pouziju rsync. A fakt - opatchovani toho 200 MB souboru trvalo nekolik desitek sekund!

rsync  -e "ssh -p port" -z zalohadb2.sql abclinuxu.cz:zalohadb2.sql

Pak jsem tedy nahral puvodni databazi, coz uz slo lehce. Provedl zmeny schematu a nanovo spustil konverzi dat. Za 11 minut hotovo - na lokale mi stejna konverze trvala 55 minut. Na abicku je 768 MB RAM a Intel Pentium 4 CPU 1.60GHz, na lokale 512 MB RAM a AMD Sempron(tm) 2600+. Jeste je tu rozdil v nastaveni mysql, na lokale je minimalisticka konfigurace.