Registrace nového uživatele     Návod     Kluby     Archív  Lopuchu     Lopuch.cz  

Diskuze na Lopuchu,
pohlazení na duchu

Lopuch.cz

Jméno:
Heslo:
Podpora LCD:
 
Archiv klubu Database (mysql,...) [ŽP: neomezená] (kategorie Programování) moderuje melkor_unlimited.
  Nastavení klubu     Nastavení práv     Homepage     Anketa     Přítomní     Oblíbené     Lopuch     Kategorie  
autor: 
text: 
vyplnit a 
Help
   
[ 414 ] <Novější  <<<Nejnovější  Nejstarší>>>  Starší>  
bredy 16.3.2006 14:47  337
tvxV zásadě se databázové systémy liší ve strategii cacheování mezivýsledků a stavění nějakých pomocných struktůr a v optimalizaci vyhledávacího dotazu.

Právě že u spojovaných tabulek se dá spoustu věci optimalizovat různě. MySQL tuším podporuje pouze jeden index na dotaz, to znamená, že pokud je potřeba hledat ve více kritériich, pak se vyhledá podle pole generující nejméně výsledků a na výsledky se aplikuje zbytek podmínky. Pokud se spojují tabulky, pak se začíná tabulkou, jejiž indeex generuje nejméně výsledků, pokud dotaz nepředepisuje pořadí (LEFT JOIN atd).

Hledání v rozsazích často představují jedno hledání a pak sekvenčí průchod do dosažení druhé hodnoty z rosahu. Je-li zadáno vícero rozsahů, pak se to tolikrát opakuje. Pokud se hledá pomocí IN, pak se hledání opakuje tolikrát, kolikrát je zadaných hodnot vpravo.

Samozřejmě doindexovávání záznamů je problém. V tomto směru bych viděl největší odlišnosti implementaci...

Chce to prostě zkusit. Zkus to, železo a databázi může podle mne kdykoliv vyměnit...

Kdokoliv: Vysoké N0 bych očekával spíš u Oracle, kde do hry bude vstupovat strategie cachování. U MySQL bych očekával N0 menší. Víc k tomu nemám co říct, tady se prostě neshodneme. I kdyby N0 bylo hodně vysoké, spíš to dává za pravdu mne, protože jakmile N bude vyšší než N0 nastoupí Log N a to v případě, že pod N0 je složitost horší naopak MySQL pomohlo. Zase nemůže být tak špatné, protože pro malé N je MySQL docela svižné.

Připomínáš mi jedince postiženého nemocí vyjádřenou filozofickou větou "Vím vše tudíž nevím nic" (Jára Cimrman - filozofie externismu)
kdokoliv Kdokoliv Nevidím důvod dělat cokoliv bezdůvodně. - http://kkl2401.wz.cz 16.3.2006 14:35  336
Bredy: Teorie slozitosti resi delku jedne instrukce. Typicky jedne instrukce Turingova stroje, protoze tam je dobre vyjadritelne, co to jedna instrukce je (a navic se da snadno predpokladat, ze vsechny instrukce trvaji stejne dlouho). Ja si pouze dovolil jiste zjednoduseni na jednu instrukci bezneho procesoru, protoze jsem predpokladal, ze by se Ti nechtelo zdrojaky MySQL prepisovat do jazyka Turingova stroje.
Uplne mimo jsi Ty, o tom svedci uz vety typu Vše je v jednotkách N.
Tys uvedl, ze je slozitost asymptoticky (nejhure) logaritmicka. To je i rada jinych funkci nez c+k*log N, to je treba taky c1 + c2*log N + c3*log log N a dalo by se najit rada dalsich.
Opetovne pouziti dle meho nazoru velmi velmi pofiderniho terminu teoreticke porovnani uz radsi ponecham stranou.
Co vime nebo nevime o MySQL je irelevantni, dulezite je, ze nevime, jak vysoke je N0, tudiz nevime, jestli tech Tvejch pul milionu je vetsi nez N0 a tudiz jestli celej Tvuj naznacenej vypocet dava jakejkoliv smysl, protoze pro hodnoty mensi nez N0 to vubec logaritmicke byt nemusi, muze to bejt klidne konstantni, linearni nebo taky exponencialni nebo vyjadreny faktorialem. O tom nam proste to asymptoticke vyjadreni nic nerika.

A uz radsi dost, tohle sem vubec nepatri, to by patrilo do nejakeho klubu o slozitosti a vycislitelnosti, ktery tu zaplatpanbu chybi.
tvx tvx Myslet si, že svět je JEN takový, jak - ho v daný čas můžeme pochopit je hloupé. 16.3.2006 14:32  335
OK, takze se popere, ja jen, ze se tu kdysi daaavno resilo, ze mysql proste od urciteho mnozstvi zaznamu uz ma problemy.
Teoretockej matematickej aparat jsem jaksi uz pozapomel nebo ani vsechen neznal, ale b-stromy mi jeste neco rikaj... :c]

Takze budu potrebovat hlavne asi dost pameti aby se toho co nejvice delo v ni a rychlej procesor, kloudne to vse natunit, mozna i o filesystemu pouvazovat nejakym rychlym a spolehlivym s nejakym i specifickym nastavenim.

Spojovat se spolu bude na strane bezneho uzivatele nejcasteji tabulka o cca 100tis. zaznamech s tabulkamam kolem 10-100 zaznamy, jedinou vyjimkou bude, kdyz se bude spojovat tabulka s 100tis.zaznamy s tou tabulkou o 1mil. zaznamu, ale tam bude predem filtrace ty milonovy tak na 100 zazamu, coz mysql asi udela prvne.

Problemy ocekavam pri nejakem hromadnem meneni dat, kdy ty vsechny indexy budou doindexovavat jako splaseny... kterezto me ceka temer denne a to v rozsahu aktualizace az vsech zaznamu v tom milionu, casto se tyka i nekterych indexovanych poli ktera se budou tim padem preindexovavat.

Pri aktualizaci se soucasne budou muset spojovat proti sobe bez filtrace cca 100tis zaznamu proti tomu milionu.
No a pak cekam problemy u cachovani nekterych dat, kdy se v cely ty milionovy tabulce budou pocitat pres indexovany polozky...

Pribyvat a ubyvat by zaznamy mely v pomeru k ostatnim problemum minimalne...

zajimalo by me, jaky HW naroky bych na to mel mit, pokud treba nekdo mate zkusenost s necim podobnym... ty aktualizace a podobne by bylo vhodny, kdyby zvladaly behat tak v radu minut, tedy aby clovek kliknul v browseru a dal si trochu kafe, podrbal se, podival na jinej web a bylo to...
bredy 16.3.2006 14:21  333
KdokolivPromin, ale tady jsi úplně mimo.

ze pokud DB stroj hleda 500000 zaznamu jednu sekundu, tak o hledani jakehokoliv jineho poctu zaznamu, muzeme rict tak akorat velky kulovy

To mluví za vše. Teorie složitosti neřeší délku jedné instrukce, ani jedné operace. Vše je v jednotkách N.

Pokud uvedu složitost, že O=c+k*log N, pak ze vztahu
k*log 500000 = 1-c
odvodím k jako cca (1-c)*0.076206
pokud je c<<1sec mohu ho zanedbat. Což zároveň uvažuje nejhorší variantu (s větším c vychází k menší).

Uvažuješ: N0 << N
jinak teoretické porovnání samozřejmě nemá smysl.

Je zajímavý, že jsi nenapadl samu vyjádřenou složitost. Oba totiž víme (bez znalosti implementace), že MySQL používá BTree pro indexaci a oba víme, že BTree má složitost log N.

kdokoliv Kdokoliv Nevidím důvod dělat cokoliv bezdůvodně. - http://kkl2401.wz.cz 16.3.2006 14:03  332
Bredy: No a ja Ti tvrdim, ze pokud DB stroj hleda 500000 zaznamu jednu sekundu, tak o hledani jakehokoliv jineho poctu zaznamu, muzeme rict tak akorat velky kulovy, kdyz jediny, co vime, je, ze asymptoticka slozitost toho problemu je logaritmicka. Protoze nezname ani konstantu pred logaritmem, ani zaklad logaritmu (i kdyz ten muzeme schovat do te konstanty) ani napriklad nejakou aditivni konstantu, ktera muze byt kuprikladu velmi vysoka, atd atd. Proto Te znovu vyzyvam, pokud jsi ovsem nezkoumal zdrojaky MySQL az do instrukci pro procesor, abys znal presne (nikoliv asymptoticke) vyjadreni te slozitosti, aby sis zopakoval definice asymptotickych slozitosti a vzpomnel si na takove pojmy jako limita a konkretne tu cast, ze existuje N0 takove, ze pro kazde N > N0 cosi plati (pricemz nikdo nevi, jak je N0 vysoke).
bredy 16.3.2006 13:57  331
KdokolivHmmm, tak na vyjasněnou. V reakci na tento dotaz:
kolik záznamů je ještě schopno rozumně obsloužit mysql v reálném čase pokud půjde převážně o zobrazování vyfiltrovaných oindexovaných dat?
půl milionu v jedný tabulce už je moc a měl bych uvažovat o jiným engine a nebo se s tím ještě popere?


Troufnu si tvrdit, že všechny tyto dotazy jsou liché. Pokud někdo hledá rychlejší železo pro databázi s pouhým milionem záznamů, nebude asi chyba v databázi, ale v jejím použití.

I kdyby na tom MySQL bylo tak špatně, že by k indexaci používalo pouhé vyvážené binární stromy, ta třinácka je pořád docela reálná.

Mluvil jsem ale o teoretickém porovnání ... Pokud ti ho někdo zatajil tak tě lituju. Umět teorii složitosti a nedokázat si představit co to znamená...

Pokud DB stroj hledá 500 000 záznamů jednu sekundu pak
500tis = 1s
1mil   = 1.05s
2mil   = 1.10s
10mil  = 1.22s
100mil = 1.40s
1000mil= 1.58s


To byl celý smysl mého příspěvku. Ukázat na nesmyslnost dotazu. Jistě se můžeme hádat, zda třeba Oracle bude pro ekvivalentní hledatcí dotaz o 10% rychlejší nebo MYSQL o 10% pomalejší, v zásadě se to na tak velkých číslech neprojeví.

Z dotazu tedy by mělo být jasno co třeba znamená "v reálném čase" a i to, jaké indexy se vlastně uplatní a také na množství spojení v jednom dotazu (které se násobí, takže spojení dvou tabulek má složitost log N * log M)

Jinak odpověď na dotaz: Zkuste to. Řekl bych, že je to spíš otázka peněz. A nebo jinak. Oktávkou taky dosáhnu cíle stejně jako s Audinou. A časově se moc lišit nebudu.
kdokoliv Kdokoliv Nevidím důvod dělat cokoliv bezdůvodně. - http://kkl2401.wz.cz 16.3.2006 13:39  330
Pojem teoreticke porovnani mi na fakulte utajili. Pokud jde o velka cisla, hovoril jsi o milionu a trinacti, to zas az tak velka cisla nejsou (obzvlast ta trinactka).
bredy 16.3.2006 13:36  329
Opakuji: Pokud jde jen o teoretické porovnání
A dodám: ... na velkých N.
kdokoliv Kdokoliv Nevidím důvod dělat cokoliv bezdůvodně. - http://kkl2401.wz.cz 16.3.2006 13:28  326
Bredy: Neumoznuje, nastuduj si znovu, co znamena, kdyz f = O(g) (pripadne o(g) pripadne dalsi obdobna pismenka jako omega a theta).
bredy 16.3.2006 13:23  325
KdokolivTeorie složitosti toto umožňuje. Pokud jde jen o teoretické porovnání. Rozdíl v konkrétní implementaci nebude nějak významně velký.
kdokoliv Kdokoliv Nevidím důvod dělat cokoliv bezdůvodně. - http://kkl2401.wz.cz 16.3.2006 09:32  324
Bredy: Hovorit o konkretnich cislech (jako ve druhe vete) vychazeje z asymptoticke slozitosti (prvni veta) je velmi odvazne, wtz.
pepak pepak - Pepak.net 16.3.2006 06:20  323
King: Za sebe muzu doporucit Firebird, je to dost pekna databaze a dost toho umi. Ma par veci, ktere se mi nelibi, ale vetsinou se bez nich da obejit (ve WHERE neumi pouzit pojmenovani poli ze SELECTu, musi se tam vzdycky natukat puvodni pole) nebo to je v betaverzi (temp. tabulky, separatni indexy pro pohledy).
king King Born to be king - ... 16.3.2006 01:43  322
jinak samozrejme souhlas, kdyz s tim clovek umi, view, procedury a funkce to podstatne zrychli...

problemem zustava, ze spousta lidi je odkojena MySQL a na takove veci neni zvykla, natoz aby to pouzivali, radsi vse udelaji rovnou v php (99% pripadu)... ;)
king King Born to be king - ... 16.3.2006 01:40  321
jj, uz nejaky cas se chystam na benchmark databazi... potrebuju pro jeden projekt zvolit free db, me se nejvic libi postgres, protoze toho umi nejvic, ale bude v tom dost dat, tak musim vyzkouset jak to bude s tim vykonem...
pepak pepak - Pepak.net 15.3.2006 20:03  320
Nejsem si uprimne receno az tak 100% jisty, jestli je opravdu MySQL nejvykonnejsi. Urcite ho nezdrzujou transakce a podobne veci, ale take mam z praxe vyzkouseno, ze vhodne uplatnena procedura nebo pohled mohou byt velmi podstatne rychlejsi nez obycejna prace s tabulkami.

[ 414 ] <Novější  <<<Nejnovější  Nejstarší>>>  Starší>  

(c) 2001-2011 Lopuch.cz   
Kontakt