Favicon Svetmobilne.cz  Svět mobilně Favicon Svetaudia.cz  Svět audia Favicon TVFreak.cz  TV Freak   Fórum Favicon Digimanie.cz  Digimanie   Fórum   Galerie Společnost oXy Online s.r.o.
Zobrazené výsledky: 1 až 11 z 11

Téma: mysql: vynechání order by

  1. #1
    Obyvatel SHW
    Registrace
    Jan 2009
    Příspěvků
    322

    jedním z pravidel databáze je, že nemám přímý způsob přístupu k datům a nemůžu se spolehnout na výsledek pořadí řádků selectu pokud nepoužiji order by

    a protože order by je největší žrout času

    ... už dávno jsem si všimnul, že mysql mi v snad vždy vrací řádky v tom pořadí co byly vloženy do tabulky

    takže pokud bych ty řádky potřeboval v tom pořadí v jakém je vkládám nemusím nikdy použít order by

    v tabulce uvažuje jen o použití funcí INSERT INTO table, DELETE FROM table a samozřejmě SELECT FROM table

    jediné co nevím, jestli delete by mohl mít nějaký vliv na to, že by mi zpřeházel moje záznamy?

    máte s tím někdo zkušenosti?
    Odpovídat lze po přihlášení

  2. #2
    Starousedlík SHW Avatar uživatele Dojigiri
    Registrace
    Jun 2008
    Příspěvků
    1,636

    U Mysql jsem to teď zkoušel a funguje to, tj. záznamy se vracejí v pořadí přidání. U jiných databází to tak ale být nemusí, záleží na tom, jak je to konkrétně implementovaný, např. by to mohlo být udělaný tak, že při vymazání určitýho záznamu se nevymaže "fyzicky", pouze se místo označí jako volný a při novým vložení se na to místo vloží novej záznam, a pokud by databáze neudržovala pořadí vkládání bude pak ten nově vloženej záznam mimo pořadí ... tj. příklad:

    Kód:
    insert into testtable values ('Record 1');
    insert into testtable values ('Record 2');
    insert into testtable values ('Record 3');
    insert into testtable values ('Record 4');
    
    delete from testtable where name='Record 2';
    
    insert into testtable values ('Record 5');
    by při "select * from testtable;" v takovým případě mohl vypsat:
    Record 1
    Record 5
    Record 3
    Record 4

    Ale MySQL jak jsem teď vyzkoušel, pořadí vkládání nějakým způsobem udržuje, tj. vypíše
    Record 1
    Record 3
    Record 4
    Record 5

    takže by to fungovat mělo. Ale je to už trochu "hack" spoléhat na něco takovýho, co není zaručený (ani není zaručený, že to funguje a bude fungovat v každý verzi mysql a v každým typu tabulky - mysql má myslím 2 různý typy tabulek ...).

    IMHO by možná stálo za to spíš zkusit zkrátit čas potřebný pro ORDER BY (pokud se používá často na stejnej sloupec) indexováním sloupce podle kterýho se řadí.
    Odpovídat lze po přihlášení



  3. #3
    Starousedlík SHW
    Registrace
    May 2006
    Příspěvků
    4,042

    Že jsou záznamy nějak seřazený když se vkládaj po sobě je čistě náhoda. Neni to zaručený a neni tomu tak vždycky - pokud uděláš delete, tak do daný díry se ti záznam klidně vloží.

    Pokud chceš řadit, použij order by na indexovaný pole, v Tvym případě Ti poslouží autoincrement (stejně bys tam měl mít rozumnej primární klíč) nebo timestamp default value = now()
    Odpovídat lze po přihlášení

  4. #4
    Obyvatel SHW
    Registrace
    Jan 2009
    Příspěvků
    322

    ad1) vše stojí za pokus jak se zbavit order by... protože ten výkonový rozdíl a možnosti v přístupu k datům za to stojí

    ad2) přesně jak píše dojigiri to funguje i mě a to dlouhou dobu na několika fyzických serverech

    ad3) toho že mi něco uloží do volné díry se fakt nebojím ... protože ono to funguje i tak... př.

    insert skupina1, 1 ...
    insert skupina1, 2...
    insert skupina1, 3...
    insert skupina1, 4...
    insert skupina1, 5...
    insert skupina1, 6...

    delete skupina1 2,3,4


    insert skupina2, 1 ...
    insert skupina2, 2...
    insert skupina2, 3...
    insert skupina2, 4...
    insert skupina2, 5...
    insert skupina2, 6...

    co je ve finále potom, že pokud nepoužiju filtr databy byly např takto

    skupina1, 1 ...
    skupina2, 1...
    skupina2, 2...
    skupina2, 3...
    skupina1, 5...
    skupina1, 6...
    skupina2, 4...
    skupina2, 5...
    skupina2, 6...

    protože když se zeptám na skupinu1 vše bude ok
    když se zeptám na skupinu2 taky vše ok
    Odpovídat lze po přihlášení

  5. #5
    Starousedlík SHW
    Registrace
    May 2006
    Příspěvků
    4,042

    1) Výkonový rozdíl? Kde?? Pokud budeš se ptát na skupinu 2, máš dvě možnosti. Buď db pojede sekvenčně - pak to bude zoufale pomalý. Nebo databáze pojede po indexu a nějaký fyzický řazení na disku je Ti úplně šumák.

    2) A co když Ti někdo smaže řádku uprostřed multiple insertu? Skončíš u toho, že při každý operaci budeš zamykat celou tabulku.

    3) Spolíhat na takovýdle nedokumentovaný "fíčury" je blbost. Co ty víš, jak mysql v další verzi změní či nezmění chování mysql? Najednou Ti aplikace přestane chodit - nebo ještě lépe Ti začne dávat blbý výsledky a půl roku si toho nikdo nevšimne. A hledej chybu....

    Co kdybys ses radši naučil využívat dokumentace?
    http://dev.mysql.com/doc/refman/5.0/...dex-types.html

    4) Kolik těch řádek v tabulce bude, že to vůbec řešíš???

    S prominutím, než začneš vymejšlet originální postupy, zkus se prosím o databázích něco naučit.

    dojigri: Jinak mysql má (reálně použitelný na dlouhodobější uložení dat, nepočítam různý heap a merge typy) tři typy tabulek a chystá se čtvrtej.....
    Odpovídat lze po přihlášení

  6. #6
    Obyvatel SHW
    Registrace
    Jan 2009
    Příspěvků
    322

    Citace Původně odesláno od Logout Zobrazit příspěvek
    1) Výkonový rozdíl? Kde?? Pokud budeš se ptát na skupinu 2, máš dvě možnosti. Buď db pojede sekvenčně - pak to bude zoufale pomalý. Nebo databáze pojede po indexu a nějaký fyzický řazení na disku je Ti úplně šumák.

    2) A co když Ti někdo smaže řádku uprostřed multiple insertu? Skončíš u toho, že při každý operaci budeš zamykat celou tabulku.

    3) Spolíhat na takovýdle nedokumentovaný "fíčury" je blbost. Co ty víš, jak mysql v další verzi změní či nezmění chování mysql? Najednou Ti aplikace přestane chodit - nebo ještě lépe Ti začne dávat blbý výsledky a půl roku si toho nikdo nevšimne. A hledej chybu....

    Co kdybys ses radši naučil využívat dokumentace?
    http://dev.mysql.com/doc/refman/5.0/...dex-types.html

    4) Kolik těch řádek v tabulce bude, že to vůbec řešíš???

    S prominutím, než začneš vymejšlet originální postupy, zkus se prosím o databázích něco naučit.

    dojigri: Jinak mysql má (reálně použitelný na dlouhodobější uložení dat, nepočítam různý heap a merge typy) tři typy tabulek a chystá se čtvrtej.....
    bohužel pro tebe řeším... protože až se pořádně naučíš mysql... tak zjistíš že při praktickém a často složitém využití je to nutnost

    takže to neber osobně... A navrhni lepší způsob jak neopakovat složité příkazy s where a order by... limit funknosti zdrojová tabule 100.000-1.000.000 řádků výsledný result omezený přes limit na prvních 250
    Odpovídat lze po přihlášení

  7. #7
    Starousedlík SHW
    Registrace
    May 2006
    Příspěvků
    4,042

    Při dobrym návrhu aplikace to nutnost neni. Tady jaksi stačí udělat index - pokud bys chtěl bejt jó rychlej tak clustered index - a rychlost operace bude v podstatě nezávislá na počtu řádek v tabulce.

    Jinak praktické a často složité užití tabulky - 10^6 řádků? To je jako hodně?
    Jinak v 99% případů se ukazuje, že pomalost aplikace není způsobena velikostí dat, ale chybou v návrhu aplikace.

    A co se týče lepšího způsobu - právě že databáze jsou na where a order by dělaný a pokud dodržuješ určitý pravidla, tak to uměj dělat opravdu rychle. Takže Ti opravdu doporučuju nevymejšlet speciální postupy, který prostě z principu nemusej fungovat a místo toho se naučit, jak se zachází s databázema. To neni jízlivost, to opravdu myslim jako dobrou radu.

    PS: Pokud chceš bejt jó rychlej, tak si udělej druhou tabulku a pověs nad první trigger, kterej bude v tý druhý tabulce udržovat prvních 250 záznamů. Ale jak píšu s dobře udělanym indexem je to opravdu naprosto zbytečný, pokud teda na těch prvních 250 záznamů neběžej stovky dotazů za sekundu. Teda asi i tak, protože mysl má query cache.
    Odpovídat lze po přihlášení



  8. #8
    Obyvatel SHW
    Registrace
    Jan 2009
    Příspěvků
    322

    není to o špatném návrhu databáze... ale o typu dat a s těma bohužel nikdo nic neudělá

    když na každém řádku musíš hledat fultextem like asi v 6. sloupcích a následně to řadit podle relevance, která je odlišná od prostého výskytu v textu, tak to fakt neurychlíš jiným návrhem, protože jako fultext tak order by si prostě ten čas vezmou

    a odstřihnout uživatele od jediného možného přístupu k datům tj. vyhledávání je šílenost

    ... navíc pokud jde opravdu o počet záznamů kolem milionu a co záznam to v podstatě celá stránka textu...

    PS: nebojte index používám , stejně jako fulltext atd... jenže ještě to chce něco pro zrychlení mezi stránkováním a opakováním a sql cache je sice pěkná ale bohužel taky omezená
    Odpovídat lze po přihlášení

  9. #9
    Starousedlík SHW
    Registrace
    May 2006
    Příspěvků
    4,042

    Fultextem like? Mezi like a fulltextem je dost velkej rozdíl. Jestli opravdu vyhledáváte v datech pomocí like, tak zkuste fulltext. Pokud je i fulltet pomalej, zkuste upgradovat na 5.1. Pokud i tak pomalej, zkuste buď fulltext v boolean mode, nebo externí fulltexty.

    http://jayant7k.blogspot.com/2006/06...ql-lucene.html
    http://whatstheplot.com/blog/tag/lucene/
    http://www.pdfdownload.org/pdf2html/...pdf&images=yes

    Ale nějak nechápu, jak todle souvisí s původním tématem.

    Další možnost je vybudovat tabulku slov v článcích a vyhledávat v tý tabulce - přijdete sice o relevance, blízkost slov atd..., ale vyhledávání by s indexem mělo bejt relativně rychlý (to jsem ale nezkoušel, takže za to neručim). Uvažoval bych nad tim, pokud se v databázi slova hodně opakujou.

    Jako další možnost bych viděl zkusit postgres.

    A pokud jsou často stejný dotazy, ale sql cache to nezvládá, co brání si napsat vlastní cacheování (každej výsledek vyhledávání si někam vypsat a tabulku třeba jednou za hodinu cronem promazat od přestárlejch výsledků)?
    Odpovídat lze po přihlášení

  10. #10
    Obyvatel SHW
    Registrace
    Jan 2009
    Příspěvků
    322

    citace: "Další možnost je vybudovat tabulku slov v článcích a vyhledávat v tý tabulce - přijdete sice o relevance, blízkost slov atd..., ale vyhledávání by s indexem mělo bejt relativně rychlý (to jsem ale nezkoušel, takže za to neručim). Uvažoval bych nad tim, pokud se v databázi slova hodně opakujou."

    ... jo, jo jo to jako myslíš stejně jako phpBB, který je díky tomuto známé jako database killer... jinými slovy volba dobrá, jenže do pekel
    Odpovídat lze po přihlášení

  11. #11
    Starousedlík SHW
    Registrace
    May 2006
    Příspěvků
    4,042

    Hmmm, phpBB neznam, takže nevim jak a jak dobře je to tam udělaný. Nicméně
    jsem ve spojení phpBB fulltext database killer našel jen tendle thread. A co se týče
    zpomalení zápisama do datbáze, tak jsem našel třeba todle:
    http://area51.phpbb.com/phpBB/viewtopic.php?f=4&t=27028

    Máš někde odkaz, jak je to hledání v phpBB dělaný?

    Ona to taky neni vhodná metoda na všechno - je to vhodný v okamžiku, kdy jsou jednotlivý prohledávaný texty
    podobný - v tu chvíli klasický fulltexty založený na vektorovym modelu začnou bejt můžou bejt neúnosně pomalý,
    zatimco tadle metoda furt "drží". Ale musí se udělat dobře. Spíš je její nevýhoda malá relevance (těžko se implementujou některý věci).
    Naposledy upraveno uživatelem Logout: 26-10-2009 v 10:07
    Odpovídat lze po přihlášení

Podobná témata

  1. Ukládání do databáze mysql
    Od typek.cz v sekci Programování
    Reakcí: 1
    Poslední příspěvek: 05-04-2012, 15:25
  2. MySQL LOCK TABLES
    Od petr.svec v sekci Programování
    Reakcí: 2
    Poslední příspěvek: 02-09-2010, 09:39
  3. mysql set @variable
    Od petr.svec v sekci Programování
    Reakcí: 5
    Poslední příspěvek: 04-12-2009, 11:07
  4. MySQL a JOIN
    Od petr.svec v sekci Programování
    Reakcí: 3
    Poslední příspěvek: 10-02-2009, 15:52