Vlákno názorů k článku PHP okénko: Získání počtu řádek od Jakub Hegenbart - "Druhý způsob je naproti tomu velice rychlý, protože...
-
"Druhý způsob je naproti tomu velice rychlý, protože MySQL jenom vezme počet řádků tabulky, který si vede jako statistický údaj, a vrátí ho."
Brutálně MySQL-specifická optimalizace. Jinde nepoužitelná.
Totéž druhá polovice článku. Nemělo by se to jmenovat spíš MySQL okénko???
Mimochodem, jak je ten "statistický údaj" imunní vůči transakčnímu zpracování? -
No mozna, ze MySQL to ma optimalizovano lepe nez tvoje oblibena databaze (protoze MySQL je optimalizovane kvalitne), ale bez ohledu na databazi bude druha moznost rychlejsi. PHP totiz implicitne pri mysql_query (narozdil od mysql_unbuffered_query) poctive precte celou odpoved SQL serveru a obavam se, ze stejne se chovaji i ostatni databazova rozhranni.
BTW, SQL server muze byt umisten i na jinem stroji nez apache - takze tahani vysledku muze zatizit i sit. -
anonymníNikdy jsem netvrdil, že bude rychlejší první možnost! Nebude, zcela samozřejmě. Ale tvrzení, že „to bude rychle, protože MySQL si to ukládá bokem průběžně“ je jednak MySQL-specific (což v „PHP okénku“ zamrzí), jednak stále ještě netuším, jak je to s concurrency a transakcemi. Jakmile mám snapshot transakce, můžu mít tolik různých počtů řádek, kolik mám transakcí, že...
Tohle absolutně nemá co dělat s optimalizací databáze, spíš s jejím „přihýbáním“ některým typizovaným použitím. Zde hrozí riziko, že budu uvažovat jinak než autoři a „optimalizace“ mne naopak postihne v podobě zfušované jiné části kódu, které se autoři tolik nevěnovali. Toho se mírně obávám... -
Ano, s tim pochopitelne souhlasim - vysvetleni, ktere jsem uvedl ja (nebo lepsi :-)) melo byt jiz v clanku. Jeste klika, ze tu jsou diskuse, ve kterych je mozne clanek doplnit ...
Take netusim, jak presne to funguje s transakcemi, nicmene nemyslim ze by v tom byl nejaky problem - pocet radek, ktery dostanete, nemusi byt za chvilku spravny ani bez transakci, stejne je nutne brat ho jen jako odhad (pokud tedy nemate tabulku zamcenou).
V pripade Javy se tomu rika "hotspot optimalizace". Ve skutecnosti se ale tento prvek vyskytuje prakticky v kazde optimalizaci - snazite se dosahnout nejlepsiho vykonu pro nejcastejsi pouziti a nutne tim snizujete vykon jindy. Dokonce i algoritmy pro loseless kompresi dat lze popsat podobne. A prekvapko - vetsinou to funguje. -
S transakcemi problém je, protože count(*) nemá co být odhadem, ale počtem řádků viditelných pro transakci. „pocet radek, ktery dostanete, nemusi byt za chvilku spravny ani bez transakci“ - tak tomu už neriozumím vůbec...
Vidím v poznámce ohledně zamykání tabulek náznak, že uvažujete poněkud omezeně – neberte to prosím jako urážku – já například ještě neměl tu čest pracovat s databází, která by tabulky musela zamykat (a i když to mnou používané servery na požádání dokáží, opravdu jsem to nikdy nepotřeboval), takže nemám _co_ zamykat :)
Hotspot? Dobře, ale hotspot optimalizuje metody, které používám a ostatní nechá být. Když budu MySQL používat určitým způsobem, předesignuje se sama tak, aby byla pro mou aplikaci rychlejší? :))) -
Copak podpora češtiny, ta ještě jde, ale co teprve logické myšlení čtenářů, kteří si myslí, že výkřik v názorech je spolehlivější než e-mail o problému na adresu provozovatele.
Díky za podnět, předal jsem kolegům. Mimochodem, zkuste si uvozovky či dlouhou pomlčku při zadání názoru s formátováním XHTML - je to lepší? -
Michal Kubeček (neregistrovaný)
já například ještě neměl tu čest pracovat s databází, která by tabulky musela zamykat
Já dokonce nejčastěji pracuji s databází, která když nedávno (po dvaceti letech své existence) explicitní zamykání tabulek umožnila, považovali vývojáři za nutné vysvětlit v release notes uživatelům, k čemu by to vlastně mohlo být dobré…
-
Krucifix ... nepsat reakce tesne pred spanim ...
Jak napsal Michal Kubeček, zalezi na nastaveni úrovne izolace transakci. Podrobnejsi vysvetleni radsi necham na nem, protoze jak jste spravne odhadl moje zkusenosti s transakcemi jsou omezene, presneji omezene jen na teoreticke znalosti. V praxi je pro me mnohem pochopitelnejsi princip zamykani tabulek a atomickych operaci. Mimochodem, ve vetsine webovych aplikaci se skutecne muzete obejit bez explicitniho zamknuti tabulek, protoze si vystacite s atomickymi operacemi (a pomuckami typu last_insert_id).
Ano, hotspot je optimalizace velmi dynamicka. Presneji receno, Java byla optimalizovana tak, ze se vzdala rychlejsi metody optimalizace natvrdo ve prospech adaptibilnejsi metody schopne optimalizovat primo pri behu. Asi to nebyl nejvhodnejsi priklad, nicmene na principu to nic nemeni - "přihýbání některým typizovaným použitím" je pomerne presne vysvetleni pojmu optimalizace, nikoliv jeho protiklad.
A sice by se mi taky libilo, kdyby nektere optimalizace byly dynamictejsi, ale v pripade ukladani poctu radek (ktere navic MySQL muze potrebovat pro interni ucely, napriklad pro odhad optimalnejsiho smeru joinovani tabulek) by jakykoliv pokus o dynamizaci skoncil narocnejsi. -
Satano (neregistrovaný)Podľa mňa COUNT(*) nie je nikdy odhadom, ale práve počtom riadkov viditeľných pre transakciu. A koľko riadkov transakcia vidí, záleží na jej úrovni izolácie (môžete, ale aj nemusíte vidieť nové riadky od iných transakcií). Akurát, že ten vrátený počet riadkov je presný práve iba v dobe (lepšie je asi v stave DB), kedy to tá transakcia ráta. S tým súvisí aj to, že vrátený počet riadkov nemusí byť správny ani bez transakcie. COUNT(*) si to všetko zráta, ale kým sa to spracuje (napr. PHPčkom) a odošle naspäť k vám (narp. vo forme www stránky), moholi byť do DB vložené ďalšie riadky, alebo niektoré vymazané, takže to číslo, čo vidíte v skutočnosti správne nie je. Ale nie je to ani odhad. Proste bolo správne v čase a stave, keď ho DB rátala.
Trošku off-topic, ale k tomu zamykaniu tabuliek. Tiež som veľmi dlhú dobu nemusel tabuľky v DB zamykať. Nebol nejaký vážny dôvod pre to a okrem toho asi všetky projekty bez ohľadu na to, ako intenzívne využívali DB, ju využívali hlavne na čítanie a ak na zápis, tak tie zápisy sa medzi sebou 'nebili' (napr. užívatelia portálu si väčšinou modifikujú každý svoje dáta a pod.). Avšak pri poslednom projekte došlo aj na zamykanie tabuliek. Ako DB server je použitý PostgreSQL (a transakčné spracovanie samozrejme - kôli tomu bol vybraný namiesto MySQL). Ale problém bol, že užívatelia systému sa snažia pristupovať a meniť rovnaké dáta a bez zamykania tabuliek mi tam vznikali deadlocky. Tie zmizli, keď som začal tabuľky zamykať a okrem toho to malo pozitívny vplyv aj na výkon - citeľne klesol load na servri (asi vďaka odstráneniiu deadlockov). -
Satano (neregistrovaný)Transakcie robia zmeny, v 2-4 tabuľkách, pričom zmeny sa môžu týkať viacerých riadkov naraz a je určitá podmnožiona riadkov, ktoré sa snažia meniť viaceré transakcie súčasne. V manuáli PostgreSQL je popísaný jedna možnosť, kedy môže dôjsť k deadlocku a aj jeho odstránenie. To spočíva v tom, že všetky zmeny, ktoré transakcie v tabuľkách robia, musia byť vykonávané v rovnakom poradí. Toto sa mi však nepodarilo dosiahnúť a tak som skúsil to explicitné zamykanie tabuliek, ktoré pomohlo.
Nepovažujem sa za špecialistu databáz, ale ani za nejakého amatéra. Zase si ani nemyslím, že tento model je zle navrhnutý. Vždy je čo vylepšovať, dokonca aj v tomto prípade viem, čo by sa ešte dalo vylepšiť, aj keď v tejto fáze to už možné nie je. Ale to by neodstránilo ten problém, ktorý tam vznikal (podľa mňa). -
> bez zamykania tabuliek mi tam vznikali deadlocky.
Myslim si, ze ide o chybu v navrhu aplikacie ( dlhe zotrvavanie v tranzakcii, update velkeho mnozstva riadkov ).
Ja by som skor ocakaval, ze k deadlockom bude dochadzat pri zamykani celych tabuliek ( zmeny do viacerych tabuliek v jednej tranzakcii ).
BTW. Jediny ( mne znamy ) dovod preco zamykat cele tabulky je aby sa odhlahcilo DB-serveru pri masivnom update/delete velkeho poctu riadkov. Pri takychto operaciach by musel DB-server vytvorit vela zamkov, pricom zamknutim celej tabulky tuto reziu nepotrebuje. Toto je specialny pripad, iny dovod ma nemapada. Vie niekto o inom dovode, preco je potrebne zamykanie tabuliek ? -
Druhy duvod proc zamykat cele tabulky: kdyz je databazocy server napsany spatne :-).
Pri zamykani tabulek nemuze dojit k deadlocku, protoze SQL implementuje metodu predchazeni deadlocku metodou napadnuti podminky drz a cekej. Proces, ktery drzi zamcene tabulky, nemuze zamknout zadne dalsi.
Pochopitelne, nelze vyloucit deadlock pres interni zamky db serveru, ale to uz by znamenalo ze je v nem bug. -
Program 1.)
begin work;
lock table A;
lock table B;
...
Program 2.)
begin work;
lock table B;
lock table A;
...
Je len na slusnosti programatora, ci urobi vsetky zamknutia hned na zaciatku tranzakcie ( velmi casto nie :-( ). Tiez sa moze stat, ze zbytocne zamknem tabulku, ktoru som ( v niektorej vetve algoritmu ) zamykat nemusel.
Navyse zamknutim tabulky zakazem pocas trvania tranzakcie spracovanie vsetkych selectov, a teda znizim priepustnost aplikacie ako celku. -
Tak vy sice tvrdíte, že to je "Brutálně MySQL-specifická optimalizace. Jinde nepoužitelná.", ale v zápětí dodáváte: "Nikdy jsem netvrdil, že bude rychlejší první možnost!".
SELECT COUNT(*) je obecně rychlejší než SELECT * a důvod, proč tomu tak je, je v článku popsán. V některých databázích (tuším ve starších Oracle) může být ještě rychlejší SELECT COUNT(id), ale na principu věci to nic nemění.
Nechci rozebírat, jak to funguje spolu s transakcemi v jednotlivých databázích, ale obecně se dá myslím říci, že to bude v souladu se selským rozumem - INSERT nebo DELETE dosud neviditelný pro venek transakce změní čítač počtu řádek pouze v rámci transakce. -
Satano (neregistrovaný)IMO ten štatistický údaj je voči transakciám imúnny úplne. Pretože MySQL transakcie nepodporuje na natívnych tabuľkách (MyISAM), ale na iných (InnoDB) a tam sa už počet riadkov (pokiaľ moje informácie siahajú) neuchováva ako štatistický údaj, ale počíta sa, ako pri iných databázach.
ČLÁNKY DO MAILU