mysql: vynechání order by
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?
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?
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:
[code]
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');
[/code]
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í.
[code]
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');
[/code]
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í.
Ž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()
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()
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
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
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/en/innodb-index-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.....
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/en/innodb-index-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.....
[quote=Logout;305075]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/en/innodb-index-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.....[/quote]
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
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/en/innodb-index-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.....[/quote]
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
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.
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.
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á
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á
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/benchmarking-results-of-mysql-lucene.html
http://whatstheplot.com/blog/tag/lucene/
http://www.pdfdownload.org/pdf2html/pdf2html.php?url=http%3A%2F%2Fwww.mysqlfulltextsearch.com%2Ffull_text.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ů)?
http://jayant7k.blogspot.com/2006/06/benchmarking-results-of-mysql-lucene.html
http://whatstheplot.com/blog/tag/lucene/
http://www.pdfdownload.org/pdf2html/pdf2html.php?url=http%3A%2F%2Fwww.mysqlfulltextsearch.com%2Ffull_text.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ů)?
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
... 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
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).
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).
