Není všechno zlato, aneb k čemu je v MySQL GROUP_CONCAT ?

18.8.2011 21:12 | Přečteno: 1829× | Linux | poslední úprava: 18.8.2011 21:10

V tomto zápisku se prvně přiznám, že s direktivou Apache HostnameLookups jste měli nakonec pravdu nakonec vy. Původní příčina byla zapnutém firewallu ve Fedoře 15, u něhož se mi nepodařilo jeho zakázání obvyklým příkazem chkconfig, díky novém systemd. Za druhé se chci ale zamyslet na výše uvedeným příkazem v MySQL.

Na první pohled se totiž jedná o velice užitečný příkaz, který zřetězí pomocí zadaného oddělovače záznamy zesumarizované pomocí GROUP BY. Hodit se může např. v případě, že GROUPujeme např. podle uživatelského jména a chceme zjistit jestli v DB není jméno duplikované, takže si pomocí GROUP CONCAT(user_id) AS uid vypíšeme např.:

user1 | 14,21,35
filbar | 22,675
.
.
.
atd.

Jenomže to má jeden dooooost podstatný háček, velikost vráceného řetězce je ve výchozím stavu omezena na POUHÝCH 1024 znaků (přenastavit se dá v konfigu). Nechápu k čemu vůbec toto omezení existuje :-O. To má sloužit jako nějaká optimalizace, nebo proč? V každém případě nechápu proč vývojaři MySQL takto užitečnou funkci tak zbytečně pokazili.

BTW. Než jsem to dneska odpoledne odhalil, tak jsem ztratil dobré 2 hodiny času.        

Komentáře

[Michal Kubeček]

Hodit se může např. v případě, že GROUPujeme např. podle uživatelského jména a chceme zjistit jestli v DB není jméno duplikované

To můžete zjistit snáz třeba pomocí

  select NAME,count(ID) as CNT from TT group by NAME having COUNT(ID)>1

nebo (lépe) rovnou ten sloupec deklarovat jako unique.

Jenomže to má jeden dooooost podstatný háček, velikost vráceného řetězce je ve výchozím stavu omezena na POUHÝCH 1024 znaků (přenastavit se dá v konfigu). Nechápu k čemu vůbec toto omezení existuje :-O. To má sloužit jako nějaká optimalizace, nebo proč?

Zřejmě to bude souviset s implementací té agregační funkce a její návratové hodnoty. Na druhou stranu, pokud vám taková délka nestačí, je více než pravděpodobné, že to, o co se snažíte, bude vhodnější dělat úplně jinak. Tahle agregační funkce slouží k usnadnění práce při generování jednoduchých výpisů, ne k tomu, abyste pomocí ní lámal něco, co pravděpodobně půjde daleko lépe vyřešit nějakým joinem.

[Epik]

Já velikost GROUP_CONCAT upravuji sql dotazem SET SESSION group_concat_max_len = xx;

[Käyttäjä 11133]

odit se může např. v případě, že GROUPujeme např. podle uživatelského jména a chceme zjistit jestli v DB není jméno duplikované, takže si pomocí GROUP CONCAT(user_id) AS uid vypíšeme např.:

No nevím, nějaký index, nebo něco podobného by asi bylo mnohem rozumnější, než to řešit na aplikační úrovni...

[CEST]

Rekl bych, ze tvuj problem bude podobneho razeni jako problem s Apachem. Nakonec zjistis, ze to delas spatne a da se to delat naprosto jinak. Tvuj priklad se zjistovanim duplicit to primo potvrzuje.

Jinak, cti manualy, ne nejaky lammersky priklady, co najdes pres google - predpokladam, ze jsi nasel nejakej priklad, kde mel manik tabulku s 10 zaznamama a max. 3 mel duplictni a tys to same pouzil na nejakou tvoji tabulku s milionem zaznamu a tisicovkama duplicit.

V manualu je primo napsane

You can set a maximum allowed length with the group_concat_max_len system variable. (The default value is 1024.)

Osobne bych duplicity taky radsi hledal spis pomoci having.

[gabakuk]

Hodit se může např. v případě, že GROUPujeme např. podle uživatelského jména a chceme zjistit jestli v DB není jméno duplikované

Pane kolego, prestante vymyslet picoviny a radeji se venujte studium sql, indexu, klicu a normalovych forem.

[filbar]

Tu aplikaci jsem nenavrhoval já.

[Nemo7]

>> prestante vymyslet picoviny

1) Nejsem autor dotazu. 2) Pokud takto jednáte v životě, tak se divím, že s vámi ještě někdo komunikuje. 3) Při návrhu DB znám pouze NORMÁLNÍ formy, ne normálové. Poučte neznalého, rád se něco dozvím.

http://interval.cz/clanky/databaze-a-jazyk-sql/

[nyan]

Co se tyce MySQL, muj osobni pocit je ze blysti se tam toho hodne, ale zlata je tam asi jak v Ankh-Morporskem tolaru :)

Za posledni 1/2 rok sem stravil neuveritelne mnozstvi casu prochazenim manualu MySQL ve snaze vyresit ruzne veci. Vetsina featur MySQL se nese v tomto duchu: "MySQL ve verzi X ma novou skvelou featuru Y. .... nasleduje popis featury .... prosim prectete si omezeni tedle featury tady ..." a link na trikrat delsi popis omezeni featury.

Priklad co sem resil: mam tabulku a protoze bude mit moc radku (v radech milionu) chci udelat partitioning. Tabulka "t", primarni klic "id" auto increment, cizi klic "y_id", foreign key constraint nad y_id, par dalsich sloupcu.

Ja: create table... partition by list(y_id)
MySQL: partition tabulka nemuze mit foreign key constraint
Ja: ok, cert vem integritu, znovu bez foreign key
MySQL: kazdy sloupec z partition key musi byt soucast primary key.
Ja: WTF ? co je todle za .... ? no nic tak udelam slozeny primary key (y_id, id)
MySQL: Nemuzete mit auto_increment nad jednim sloupcem slozeneho primary key
Ja: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

... Kdyz nechcete prijit o nervy, vyhnete se MySQL obloukem.

[Josef Kufner]

MySQL je jednoduchá a hloupučká databáze a podle toho se s ní musí jednat. Kdybys v druhém kroku vyhodil místo foreign key onu partition část, tak bys měl po problému. A nebo jsi to prostě jen dělal blbě

[Miloslav Ponkrác]

Základní problém MySQL je v Linuxu. Linuxové distribuce běžně obsahuje MySQL několika let staré verze.

Holt než to projde linuxovým kolečkem ód objevení se nové verze poté, než to distribuce zabalí, otestují, než se otestuje celá distribuce a stane se stable, tak je v MySQL i roky zastaralá verze.

Oracle na MySQL zapracoval a vůbec ne špatně. A možná v příštím tisíciletí se dostanou tyto verze do Linuxu.

Schválně připiště na jeké verzi MySQL pracujete a bude jasno.

[okbob]

No jestli to není tím, že v MySQL se zasekli na 5.1 a 5.5 je teprve letošní záležitost? Nic produkčního mezitím nevyšlo, když nepočítám 5.4, která se vydávala narychlo ještě v Sunu (a spíš ze strachu, jak dopadne MySQL v Oraclu).

[nyan]

Kdybys v druhém kroku vyhodil místo foreign key onu partition část, tak bys měl po problému.

Podstata cviceni byla zavest partitioning. Zkouseli ste nekdy vymazat 5M radku z tabulky co jich ma 25M ? Kdyz je mate v partitionech, dropnuti jedne partition je prakticky okamzite.

A nebo jsi to prostě jen dělal blbě

Nemyslim. AFAIK vsechno na co sem narazil jsou dokumentovane omezeni, neboli gotcha

[Miloslav Ponkrác]

1) čtením manuálu bysis ušetřil 2 hodiny času, stejně tak jak dělání hlupáka ze sebe na tomto blogu.

SET [GLOBAL | SESSION] group_concat_max_len = nový_limit_pro_group_concat;

Stačí použít jednou po navázání spojení a je po problému.

Stačí se naučit číst, slabikář určitě někde od učitelky první základní třídy seženeš jako první kroky k tomu naučit se číst manuály. Pokud nakoukneš do manuálu, problém je vyřešen do minuty.

[filbar]

Manuál jsem tak detailně nezkoumal, protože jsem nečekal, že by databáze měla co ořezávat výsledky a o tom tento zápisek je, že databáze má data vracet tak jak jsou v ní uložena a ne dělat na nich nějaké nepochopitelné ořezávání.

[Miloslav Ponkrác]

A nějaká bezpečnost a snaha nepřetížit databázi Vám nic neříká?

Zkuste si příště přečíst ten manuál a nehrát si ředitele zeměkoule co by jiné věci měly dělat. Bude to rozhodně užitečnější.

[filbar]

Databázi můžu přetížit i obyčejným SELECTem, když ho napíšu špatně.

[Michal Kubeček]

Když jste přesvědčen, že je to tak jednoduché, tak proč to neimplementujete? Pokud to bude fungovat, vývojáři budou IMHO jedině rádi…

[Ladicek]

Boha, kdysi jsem narazil na jedné (raději nejmenované) databázi na "problém", že IN (1, 2, 3, atd.) klauzule mohla obsahovat nanejvýš 1024 prvků. To bys taky odsoudil?