abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
eParkomat, startup z ČR, postoupil mezi finalisty evropského akcelerátoru ChallengeUp!
Robot na pivo mu otevřel dveře k opravdovému byznysu
Internet věcí: Propojený svět? Už se to blíží...
včera 16:24 | Nová verze

Byla vydána Mageia 5.1. Jedná se o první opravné vydání verze 5, jež vyšla v červnu loňského roku (zprávička). Uživatelům verze 5 nepřináší opravné vydání nic nového, samozřejmě pokud pravidelně aktualizují. Vydání obsahuje všechny aktualizace za posledního téměř půldruhého roku. Mageia 5.1 obsahuje LibreOffice 4.4.7, Linux 4.4.32, KDE4 4.14.5 nebo GNOME 3.14.3.

Ladislav Hagara | Komentářů: 0
včera 13:42 | Pozvánky

V Praze probíhá konference Internet a Technologie 16.2, volné pokračování jarní konference sdružení CZ.NIC. Konferenci lze sledovat online na YouTube. K dispozici je také archiv předchozích konferencí.

Ladislav Hagara | Komentářů: 0
2.12. 22:44 | Komunita

Joinup informuje, že Mnichov používá open source groupware Kolab. V srpnu byl dokončen dvouletý přechod na toto řešení. V provozu je asi 60 000 poštovních schránek. Nejenom Kolabu se věnoval Georg Greve ve své přednášce Open Source: the future for the European institutions (SlideShare) na konferenci DIGITEC 2016, jež proběhla v úterý 29. listopadu v Bruselu. Videozáznam přednášek z hlavního sálu je ke zhlédnutí na Livestreamu.

Ladislav Hagara | Komentářů: 16
2.12. 15:30 | Zajímavý projekt

Společnost Jolla oznámila v příspěvku Case study: Sailfish Watch na svém blogu, že naportovala Sailfish OS na chytré hodinky. Využila a inspirovala se otevřeným operačním systémem pro chytré hodinky AsteroidOS. Použita je knihovna libhybris. Ukázka ovládání hodinek na YouTube.

Ladislav Hagara | Komentářů: 8
2.12. 14:15 | Nová verze

Byla vydána verze 7.1.0 skriptovacího jazyka PHP používaného zejména k vývoji dynamických webových stránek. Jedná se o první stabilní verzi nejnovější větvě 7.1. Přehled novinek v dokumentaci. Podrobnosti v ChangeLogu. K dispozici je také příručka pro přechod z PHP 7.0.x na PHP 7.1.x.

Ladislav Hagara | Komentářů: 2
2.12. 12:55 | Nová verze

Google Chrome 55 byl prohlášen za stabilní. Nejnovější stabilní verze 55.0.2883.75 tohoto webového prohlížeče přináší řadu oprav a vylepšení (YouTube). Opraveno bylo také 36 bezpečnostních chyb. Mariusz Mlynski si například vydělal 22 500 dolarů za 3 nahlášené chyby (Universal XSS in Blink).

Ladislav Hagara | Komentářů: 4
2.12. 11:55 | Pozvánky

Máte rádi svobodný software a hardware nebo se o nich chcete něco dozvědět? Přijďte na 135. sraz spolku OpenAlt, který se bude konat ve čtvrtek 8. prosince od 18:00 v Radegastovně Perón (Stroupežnického 20, Praha 5). Sraz bude tentokrát tématický. Bude retro! K vidění budou přístroje jako Psion 5mx nebo Palm Z22. Ze svobodného hardwaru pak Openmoko nebo čtečka WikiReader. Přijďte se i vy pochlubit svými legendami, nebo alespoň na pivo. Moderní hardware má vstup samozřejmě také povolen.

xkucf03 | Komentářů: 0
2.12. 00:10 | Nová verze

Byla vydána verze 3.2 svobodného systému pro detekci a prevenci průniků a monitorování bezpečnosti počítačových sítí Suricata. Z novinek lze zmínit například podporu protokolů DNP3 a CIP/ENIP, vylepšenou podporu TLS a samozřejmě také aktualizovanou dokumentaci.

Ladislav Hagara | Komentářů: 0
1.12. 21:00 | Nová verze

Byla vydána beta verze Linux Mintu 18.1 s kódovým jménem Serena. Na blogu Linux Mintu jsou hned dvě oznámení. První o vydání Linux Mintu s prostředím MATE a druhé o vydání Linux Mintu s prostředím Cinnamon. Stejným způsobem jsou rozděleny také poznámky k vydání (MATE, Cinnamon) a přehled novinek s náhledy (MATE, Cinnamon). Linux Mint 18.1 bude podporován až do roku 2021.

Ladislav Hagara | Komentářů: 0
1.12. 16:42 | Nová verze

Byl vydán Devuan Jessie 1.0 Beta 2. Jedná se o druhou beta verzi forku Debianu bez systemd představeného v listopadu 2014 (zprávička). První beta verze byla vydána v dubnu letošního roku (zprávička). Jedna z posledních přednášek věnovaných Devuanu proběhla v listopadu na konferenci FSCONS 2016 (YouTube, pdf).

Ladislav Hagara | Komentářů: 0
Kolik máte dat ve svém domovském adresáři na svém primárním osobním počítači?
 (32%)
 (24%)
 (29%)
 (7%)
 (5%)
 (3%)
Celkem 767 hlasů
 Komentářů: 50, poslední 29.11. 15:50
Rozcestník
Reklama

Dotaz: PHP je lepší select z db pre všetky idečka alebo postupne načitavanie viacerymi selectmi?

27.11.2011 10:42 adrinko | skóre: 22
PHP je lepší select z db pre všetky idečka alebo postupne načitavanie viacerymi selectmi?
Přečteno: 662×
Ahojte, mám takú dilemu. Mám tabuľku užívateľov, ktorých je 3000. V crone spúšťam php skript, ktorý každý deň, načíta každého užívateľa a niečo vykoná. Moja otázka: Je lepšie pri spustení tohto php skriptu hneď načítať mysql selectom všetky polia všetkých užívateľov do premennej (poľa) a tie v cykle (napr. for) spracovať, alebo v cykle for radšej spraviť sólo select pre každé jedno ID užívateľa (t.j. vykonalo by sa cca 3000 selectov)?

Zaujíma ma, čo je lepšie, keďže každý užívateľ má v tabuľke cca 10 stĺpcov, s ktorými chcem ďalej pracovať (aby to náhodou nezahltilo systémové prostriedky pridelené phpčku). Vďaka!

Řešení dotazu:


Odpovědi

David Watzke avatar 27.11.2011 11:30 David Watzke | skóre: 74 | blog: Blog... | Praha
Rozbalit Rozbalit vše Re: PHP je lepší select z db pre všetky idečka alebo postupne načitavanie viacerymi selectmi?
Pokud to půjde, určitě počet selectů minimalizuj. Když si to spočítáš, tak to nezabere zas tak moc paměti, pokud ty sloupce nejsou nějaký mamutí bloby.
“Being honest may not get you a lot of friends but it’ll always get you the right ones” ―John Lennon
bazil avatar 27.11.2011 11:53 bazil | skóre: 33 | blog: sluje | Miroslav
Rozbalit Rozbalit vše Re: PHP je lepší select z db pre všetky idečka alebo postupne načitavanie viacerymi selectmi?

Trošku teorie:
Většinou je lepší použít méně selektů než více. Pokud například pracuješ s velkými objemy dat a použiješ z nej jen pár záznamů, potom je ale lepší použít více selektů.

V tvém případě procházíš stejně všechny data a všechny je budeš zpracovávat, proto použij jeden selekt a pouze projekce (vybre jen ty sloupce, které potřebuješ).

Dále použij mysql_* pro procházení dat:

$res = mysql_query('select ...')
while(($row = mysql_fetch_array($res))
{

}
Tady je hezký příklad: http://www.php.net/manual/en/function.mysql-fetch-array.php

27.11.2011 12:00 Kit
Rozbalit Rozbalit vše Re: PHP je lepší select z db pre všetky idečka alebo postupne načitavanie viacerymi selectmi?
Určitě bude lepší provést jeden SELECT. Už proto, že kdyby během zpracování každého z těch 3000 mohlo docházet k modifikacím seznamu uživatelů, mohl by v datech vzniknout zmatek. Také by se mohlo případně stát, že by se to "niečo" provedlo jen pro některé uživatele a pro jiné ne.

Uvědom si, že každý SELECT se kompiluje do pseudokódu a teprve ten se provádí. Pokud se dá příkaz napsat jako jeden SELECT, je to k databázi mnohem šetrnější a výkonnější. Navíc celá akce proběhne atomicky.

Systémové prostředky by to zahltit nemělo, protože PHP si data z databáze odebírá postupně jak potřebuje. Obvykle bývá nastaven limit paměti pro proměnné v PHP na 32 MB, ale dá se zpracovat i select se stovkami MB.

Spíš bych se ale zamyslel nad tím: Co vlastně s těmi daty potom děláš? Neukládáš je po modifikaci opět do databáze? To bych v cyklu rozhodně nedělal, ale nechal bych to udělat přímo tu databázi.
27.11.2011 12:48 adrinko | skóre: 22
Rozbalit Rozbalit vše Re: PHP je lepší select z db pre všetky idečka alebo postupne načitavanie viacerymi selectmi?
ďakujem Vám za objasnenie. Moje čítané dáta sú väčšinou len krátke textové veci, mená, emaily, čísla,dátumy,... Spravím to teda jedným selectom a jeho dáta postupne spracujem v php.
28.11.2011 14:54 Sten
Rozbalit Rozbalit vše Re: PHP je lepší select z db pre všetky idečka alebo postupne načitavanie viacerymi selectmi?
Asi nejlepší je provést méně selectů s předpřipraveným dotazem (Prepared Statement), kam se jenom doplňuje offset, ale při třech tisících řádků by bylo lepší, aby to nebyl jeden, ale aby to bylo třeba po stovce záznamů (pomocí limit a offset). Záleží také na použitém enginu, tohle platí pro InnoDB, kde jsou záznamy řazené podle ID, takže ten limit a offset jsou velmi rychlé, u MyISAM může být lepší udělat select jeden.
28.11.2011 15:03 l0gik | skóre: 22
Rozbalit Rozbalit vše Re: PHP je lepší select z db pre všetky idečka alebo postupne načitavanie viacerymi selectmi?
A v čem je výhoda oproti jednomu dotazu?
28.11.2011 15:13 Šangala | skóre: 56 | blog: Dutá Vrba - Wally
Rozbalit Rozbalit vše Re: PHP je lepší select z db pre všetky idečka alebo postupne načitavanie viacerymi selectmi?
Ve spotřebě paměti?
To, že trpíš stihomamem, ještě neznamená, že po tobě nejdou. ⰞⰏⰉⰓⰀⰜⰉ ⰗⰞⰅⰜⰘ ⰈⰅⰏⰉ ⰒⰑⰎⰉⰁⰕⰅ ⰏⰉ ⰒⰓⰄⰅⰎ ·:⁖⁘⁙†
David Watzke avatar 28.11.2011 17:00 David Watzke | skóre: 74 | blog: Blog... | Praha
Rozbalit Rozbalit vše Re: PHP je lepší select z db pre všetky idečka alebo postupne načitavanie viacerymi selectmi?
U 3 tisíc uživatelů nelze mluvit o spotřebě paměti...
“Being honest may not get you a lot of friends but it’ll always get you the right ones” ―John Lennon
28.11.2011 17:08 l0gik | skóre: 22
Rozbalit Rozbalit vše Re: PHP je lepší select z db pre všetky idečka alebo postupne načitavanie viacerymi selectmi?
Kdo říká, že musím celej výsledek načítat najednou? Budu ho normálně zpracovávat řádku po řádce. A pokud myslíš podmínku do databáze, tak ono php stejně při budování jednotlivejch subpodmínek s největší pravděpodobností ty starý řetěze jen tak neuvolní, takže taky bude spotřeba paměti podobná. V každym případě, kolik by jich muselo bejt, aby to bylo alespoň trochu strovnatelný s overheadem samotnýho PHP v řádech desítek mega? Tvejch 3 tisíce řádků je dotaz na nějakejch 15kB a výsledek ne o moc víc...
28.11.2011 18:22 Šangala | skóre: 56 | blog: Dutá Vrba - Wally
Rozbalit Rozbalit vše Re: PHP je lepší select z db pre všetky idečka alebo postupne načitavanie viacerymi selectmi?
Nejsou to moje řádky a ptal jsi se na rozdíl. Na 3000 řádků mně to přijde v tomto případě zbytečné, pokud to neběží na nějaké „maličkém“ systému (30k už to tak nemusí být).
dotaz na nějakejch 15kB a výsledek ne o moc víc... + len krátke textové veci, mená, emaily, čísla, dátumy
Může ve výsledku znamenat i více než 0.3 MiB.
Budu ho normálně zpracovávat řádku po řádce
Jestli myslíš fetch_xxx, tak to na věci nic nemění, že data jsou v result setu načtena všechna.

PHP-ko jej uvolní, jakmile je potřeba a k uvolnění externích zdrojů (result setu) slouží například mysqli_result::free či třeba mysqli_stmt::free_result
PS: Výše uvedeným způsobem jsem pomocí PHP s limitem 64MiB napravoval propojení dvou rozdílných databází na dvou rozdílných strojích, protože „Enterprise“ Java aplikace (díky chybnému návrhu) to nezvládla s přidělenými 3GiB.
A taky pokud máte limit 8-16MiB a potřebujete na základě selectu upravovat obrázky, tak je vhodné dobře počítat a uvolňovat paměť…, ale může to být cokoliv…
To, že trpíš stihomamem, ještě neznamená, že po tobě nejdou. ⰞⰏⰉⰓⰀⰜⰉ ⰗⰞⰅⰜⰘ ⰈⰅⰏⰉ ⰒⰑⰎⰉⰁⰕⰅ ⰏⰉ ⰒⰓⰄⰅⰎ ·:⁖⁘⁙†
28.11.2011 22:21 l0gik | skóre: 22
Rozbalit Rozbalit vše Re: PHP je lepší select z db pre všetky idečka alebo postupne načitavanie viacerymi selectmi?
Na to se dá odpovědět nejlépe odkazem: http://www.mysqlperformanceblog.com/2006/06/26/handling-of-big-parts-of-data/ aneb v mysql(i) se nemusí straně klienta cachovat celej dotaz, když nechceš, normálně to zpracuješ proudově.

Jinak PHP má jakejs takejs GC od verze 5.3 a ani tam nechodí moc dobře, takže na nějakou GC bych nespoléhal.
28.11.2011 23:47 Šangala | skóre: 56 | blog: Dutá Vrba - Wally
Rozbalit Rozbalit vše Re: PHP je lepší select z db pre všetky idečka alebo postupne načitavanie viacerymi selectmi?
Odkazovaný článek je sice hezký, ale například fce mysql_unbuffered_query() nedělá to, že by neukládala výsledek na straně klienta, ona ho jen nepřipravuje pro použití v PHP (nedělá z něj typy PHP) a umožňuje zpracování, hned jakmile už nějaká data dojdou. To znamená, že můžete získat rychlost, díky paralelnímu zpracování a ušetřit nějakou paměť díky „nepřekládání dat“, pokud budete dostatečně rychle zpracovávat (což ale v PHP asi těžko půjde předběhnout takový typ dotazu.), ale ty data na straně klienta uložena jsou, jen je hned odebíráte a nejsou tak velká (zvláště pokud je tam spousta smallint, tinyint apod.).

Na GC se spoléhat nemusíte, i když jsem s tím neměl nikdy žádné problémy a vždycky při nedostatku paměti, když jsem to měl dobře spočítané a případně jsem dobře unset-nul proměnné jsem byl schopen využívat ji celou opakovaně.
Jo když budete blbě používat(respektive pak již nepoužívat) nějaké grosse-big multi-array a více a vzájemně je budete provazovat, třeba odkazem, tak určite GC zamotáte hlavu.

A také je si třeba uvědomit, že fce jako mysqli_result::free(), mysqli_stmt::free_result() nebo i třeba imagedestroy() uvolňují prostě paměť ihned, řekněme mimo vyhledávací loop GC.
To, že trpíš stihomamem, ještě neznamená, že po tobě nejdou. ⰞⰏⰉⰓⰀⰜⰉ ⰗⰞⰅⰜⰘ ⰈⰅⰏⰉ ⰒⰑⰎⰉⰁⰕⰅ ⰏⰉ ⰒⰓⰄⰅⰎ ·:⁖⁘⁙†
29.11.2011 12:52 l0gik | skóre: 22
Rozbalit Rozbalit vše Re: PHP je lepší select z db pre všetky idečka alebo postupne načitavanie viacerymi selectmi?
IMHO prostě nemáš pravdu. Dokládá to jednoduchej test: tabulka invoices (18k řádků, 4,7MB dat). Jednoduchej program

//pripojení k db
echo memory_get_usage(),"\n";
//$q=mysql_query("SELECT * FROM invoices");
$q=mysql_unbuffered_query("SELECT * FROM invoices"); \\ LIMIT 4000");
sleep(2);
echo memory_get_usage(),"\n";
$s=0;
while($r=mysql_fetch_row($q))
    {
    $s=$s+$r[0];
    //echo memory_get_usage(),", ";
    }
echo memory_get_usage(),"\n";
echo memory_get_peak_usage(),"\n";
exit();
Výsledky s normálním dotazem:
685984
4825840
4825840
44789896
44796976
s buffered s limitem 4000
686000
1688464
1688464
11289208
11296256
výsledky s unbuffered query
685800
695904
695904
696632
716056
unbuffered s limitem 4000
686008
689696
689696
690256
715968
unbuffered s limitem 20
685816
695920
695920
696648
715216
Myslím, že tato data Tvoje tvrzení prostě vyvrací: spotřeba paměti je při unbuffered query defakto identická při 20 i 18000 záznamech.

Navíc, kdyby to bylo tak, jak tvrdíš, tak by se data během sleepu načetly a spotřebovali paměť, tam ale k žádnému nárůstu paměti nedochází, k tomu dochází až u buffered query během cyklu. Proto je evidentní, že ani buffered query netahá všechna data hned, pouze je na straně klienta cachuje v okamžiku, kdy jsou poprve přečtena, aby umožnil pohyb zpět po resultsetu (samozřejmě tahá data po "paketech", proto je spotřeba paměti během cyklu vždy pár kroku stejná a pak skočí).
29.11.2011 23:15 Šangala | skóre: 56 | blog: Dutá Vrba - Wally
Rozbalit Rozbalit vše Re: PHP je lepší select z db pre všetky idečka alebo postupne načitavanie viacerymi selectmi?
A zas podle mého názoru nemám pravdu.
Navíc když se zobrazí paměťová náročnost scriptu a db jsou rozdíly patrnější než s fce memory_get_usage() a nebo se použije v PHP něco jako:
$pid = getmypid();
exec("ps -eorss,pid | grep $pid", $output);
echo IntVal(trim($output[0])) * 1024,"\n";
Takže je blbost co jsem psal v 1. odstavci a o čem jsem byl přesvědčen (nevím proč) a musel jsem se podívat i do zdrojáků PHP-ka a to i do starších verzí (4.x), ale nenašel jsem nic co by odpovídalo tomu co jsem psal, PHP funkce mysql_unbuffered_query() prostě a jednoduše odpovídá C API mysql_use_result().

Takže dík za námahu s vyvrácením 1. odstavce (třetí odstavec se mimoděk podobným testem potvrdil :-) ).
Zdrojový kód je zbytečný, hodnota je absolutní využití paměti přes funkci podobnou výše uvedené.
Conected and selected DB
  Exec ps:  6680576 
Start mysql_query()
Selected
  Exec ps: 41750528
Selected after sleep(2)
  Exec ps: 41750528
Fetched all rows, php sum(id): 16200090000
  Exec ps: 41750528
After mysql_free_result
  Exec ps:  6680576 
After mysql_close
  Exec ps:  6680576 
U mysql_buffered_query() to nabýšení na 40MiB nebylo.
Sledováním přes top se sice projevilo drobné navýšení na straně mysql, ale v zásadě nepodstatné.
To, že trpíš stihomamem, ještě neznamená, že po tobě nejdou. ⰞⰏⰉⰓⰀⰜⰉ ⰗⰞⰅⰜⰘ ⰈⰅⰏⰉ ⰒⰑⰎⰉⰁⰕⰅ ⰏⰉ ⰒⰓⰄⰅⰎ ·:⁖⁘⁙†
28.11.2011 17:49 Sten
Rozbalit Rozbalit vše Re: PHP je lepší select z db pre všetky idečka alebo postupne načitavanie viacerymi selectmi?
Ve spotřebě paměti (i na straně MySQL) a v tom, že takový dotaz běží velmi dlouho a blokuje systémové prostředky. A navíc může vytimeoutovat.
28.11.2011 22:53 Kit
Rozbalit Rozbalit vše Re: PHP je lepší select z db pre všetky idečka alebo postupne načitavanie viacerymi selectmi?
Spotřeba paměti? Velmi dlouho? Blokování systémových prostředků? Jaký timeout? Na 3000 záznamech o celkové velikosti 15 KB? O jakém systému se bavíme? Na čem to běží? Na 8088? I na tom by to běželo svižně.

Myslím si, že select záznamů po skupinách je v daném případě docela overkill. Jeden select bude bohatě vyhovovat pro většinu běžných aplikací.

Bohužel jsme se nedozvěděli, co s tím získaným seznamem chce tazatel dělat. Pokud jenom chce vygenerovat tabulku v HTML, tak nemusí výstup ani zpracovávat cyklem, ale celou tabulku mu databáze může vypsat jako jediný řetězec, který PHP jen pošle na výstup.

To ale nevíme a místo toho diskutujeme o variantách, o kterých má obvykle význam uvažovat až při práci s tabulkami o miliónech záznamů. Prostě overkill.
29.11.2011 12:55 l0gik | skóre: 22
Rozbalit Rozbalit vše Re: PHP je lepší select z db pre všetky idečka alebo postupne načitavanie viacerymi selectmi?
No generovat tabulku v databázi bych fakt nedooporučoval. Logika v databázi, to ano, ale view? To se bude tak obtížně spravovat, že fuj.

Ale jinak souhlas, v takovém množství je to overkill, smysl to má uvažovat pouze v případě, kdy by velikost dotazu narostla do nepatřičných mezí. Pak ale je zas na čase přesmýšlet, jestli není chyba v návrhu, málokdy je opravdu potřeba najednou upravovat statisíce záznamů.
29.11.2011 18:21 Kit
Rozbalit Rozbalit vše Re: PHP je lepší select z db pre všetky idečka alebo postupne načitavanie viacerymi selectmi?
No generovat tabulku v databázi bych fakt nedooporučoval. Logika v databázi, to ano, ale view? To se bude tak obtížně spravovat, že fuj.
Zrovna jsem to otestoval v SQLite na 300 000 záznamech. Vygenerování celé tabulky jedním selectem do jednoho řetězce bylo asi 3x rychlejší, než klasické procházení výsledků selectu cyklem.

Možná se to obtížněji spravuje, ale databáze udělá view rychleji než PHP.
29.11.2011 18:35 l4m4
Rozbalit Rozbalit vše Re: PHP je lepší select z db pre všetky idečka alebo postupne načitavanie viacerymi selectmi?
s/databáze/cokoli/

s/view/cokoli/
29.11.2011 18:49 Kit
Rozbalit Rozbalit vše Re: PHP je lepší select z db pre všetky idečka alebo postupne načitavanie viacerymi selectmi?
Že je PHP líné, to všichni víme. Proto vždycky hledám jakoukoli možnost, jak se v něm vyhnout cyklům.

Pro šťouraly: Cykly uvnitř vestavěných funkcí jsou zpravidla dobře optimalizovány, proto mě netrápí.
29.11.2011 19:47 l0gik | skóre: 22
Rozbalit Rozbalit vše Re: PHP je lepší select z db pre všetky idečka alebo postupne načitavanie viacerymi selectmi?
- železo je daleko levnější než programátor. Takže pokud nejde o mission critical aplikaci, tak nějaký 3x rychlejší opravdu nehraje roli. A pokud je to mission critical, tak to nebudu psát v php.

- Jak často potřebuješ plivat tabulku s 300000 záznamy?

- Přiznám se, že ty výsledky dost podezírám: v php můžu řetězce postupně načítat a plivat, zatímco když to čteš z databáze, tak musíš najednou v paměti držet celej ten řetězec. Jak má mysql udělanou práci s řetězci se přiznam, že nevim, ale např. v postgresu je skládání řetězců zrovna výkonnostně nicmoc. A naopak - pokud už budu mít v PHP celé pole, tak zas můžu použít např. implode nebo jinou rychlou interní funkci. Dej sem schválně kód, kteryms to dělal (jak v databázi tak v php), schválně, jestli to dokážu napsat rychlejc...
29.11.2011 20:55 Kit
Rozbalit Rozbalit vše Re: PHP je lepší select z db pre všetky idečka alebo postupne načitavanie viacerymi selectmi?
- ten SQL dotaz je zvětšený jen o jednu funkci. Programátorovi by mělo být jedno, jestli agregační funkci napíše v SQL nebo PHP. Většinou použije to, co umí lépe nebo to co se mu jeví lepší.

- 300000 záznamů jsem zvolil proto, abych získal nějak měřitelná data. Pro 3000 záznamů bych toho moc nenaměřil. Ještě bych mohl zkusit 3000 záznamů stovkou paralelních procesů, což by mohlo být blíž realitě (webové stránky).

- zkusil jsem i postupné načítání a výstup. Výsledky byly ještě horší, protože příkaz echo je líný. Mnohem rychlejší bylo výsledky naskládat do pole a pomocí funkce implode() je spojit a teprve takto vzniklý řetězec poslat na výstup. Agregace v SQLite však byla 3x rychlejší. Připadalo mi férové použít v obou případech echo jednoho řetězce, jinak by cyklus dopadl ještě hůř.

Klasika (14 sekund):
foreach($dbh->query("SELECT value as val FROM pokus;") as $row) {
  echo 'trtd'.$row['val'].'/td/tr'."\n";
}
Skládání řádek v SQL (12 sekund):
foreach($dbh->query("SELECT 'trtd'||value||'/td/tr\n' as val FROM pokus;") as $row) {
  echo $row['val'];
}
Použití pole (9 sekund):
$out=array();
foreach($dbh->query("SELECT value as val FROM pokus;") as $row) {
  $out[]='trtd'.$row['val'].'/td/tr';
}
echo implode("\n",$out);
Použití řetězce (9 sekund):
$out='';
foreach($dbh->query("SELECT value as val FROM pokus;") as $row) {
  $out.='trtd'.$row['val'].'/td/tr'."\n";
}
echo $out;
Skládání řádek, kombinace s polem (9 sekund):
$out=array();
foreach($dbh->query("SELECT 'trtd'||value||'/td/tr' as val FROM pokus;") as $row) {
  $out[]=$row['val'];
}
echo implode("\n",$out);
Agregace v SQL (5 sekund):
foreach($dbh->query("SELECT group_concat('trtd'||value||'/td/tr','\n') as val FROM pokus;") as $row) {
  echo $row['val']."\n";
}
Agregace v SQL bez výstupu echo (2 sekundy):
foreach($dbh->query("SELECT group_concat('trtd'||value||'/td/tr','\n') as val FROM pokus;") as $row) {
  $line=$row['val']."\n";
}
To poslední měření jsem uvedl proto, aby bylo vidět, jak je echo líné.

Znaky tr a td znamenají <tr> a <td>, ale nechtělo se mi to nahrazovat entitami v celém příspěvku. Kdo chce, domyslí si.
30.11.2011 13:25 l0gik | skóre: 22
Rozbalit Rozbalit vše Re: PHP je lepší select z db pre všetky idečka alebo postupne načitavanie viacerymi selectmi?
Skládání s polem máš naprosto zbytečně v cyklu, do implode můžeš hodit už ten query. Ale to je jedno, máš pravdu, opravdu je PHP tak zoufalý, že to je pomalejší.

Zapoměl jsi teda na podle mě nejrychlejší variantu: klasický echo se zapnutym output buffering - ale to tolik nezrychlí. Ale jinak máš pravdu.

Jen mi ten rozdíl v rychlosti nepřipadá tak velkej, by to bylo třeba řešit na úkor údržby kódu. Ale hodí se to vědět.
30.11.2011 16:12 Kit
Rozbalit Rozbalit vše Re: PHP je lepší select z db pre všetky idečka alebo postupne načitavanie viacerymi selectmi?
Skládání s polem máš naprosto zbytečně v cyklu, do implode můžeš hodit už ten query.
Asi mi něco uniká. Myslíš něco takového?
$result=$dbh->query("SELECT 'trtd'||value||'/td/tr' as val FROM pokus;",PDO::FETCH_COLUMN));
echo implode("\n",$result->fetchAll());
Zkusím to odladit, až budu na původním počítači. V této podobě by to mohlo být i rychlé.

Ohledně údržby kódu: Někteří vývojáři tvrdí, že SQL umí všechno. Dá i nedá se s tím souhlasit, někdy je to za cenu velkých obstrukcí. Souhlasím, že je dobré dělat aplikace jako vícevrstvé, kód se tím často zpřehlední.

V uvedeném případě mi však připadá přidání jedné funkce do SQL a ubrání z PHP jako jednoduchá úprava. Vychází mi však efektivnější. Můžu ještě zkusit porovnat i paměťové nároky jednotlivých řešení.
30.11.2011 19:22 l0gik | skóre: 22
Rozbalit Rozbalit vše Re: PHP je lepší select z db pre všetky idečka alebo postupne načitavanie viacerymi selectmi?
No, já jsem myslel toto: implode($dbh->query("SELECT 'trtd'||value||'/td/tr' as val FROM pokus;",PDO::FETCH_COLUMN, "\n") ale to se omlouvám, zas jsem zapoměl na "debilitu" phpka, kde sice něco se tváří jako pole/iterátor, ale to ještě neznamená, že se to dá jako pole nebo iterátor používat, takže todle máš pravdu, to nejde. Zkusit to s FetchAll je zajímavý, jestli je to fetchAll tedy napsané v něčem rozumějším než PHP, jinak to bude stejné.

V tý udržovatelnosti IMHO nejde až tak o to, že se to udělá jednou, ale o to, že např. za tejden přijde šéf, že chce, aby si mohl člověk tu tabulky "skinovat". V tu chvíli začne db řešení dělat problémy, protože tam se takový věci implantujou daleko hůř.
30.11.2011 21:41 Kit
Rozbalit Rozbalit vše Re: PHP je lepší select z db pre všetky idečka alebo postupne načitavanie viacerymi selectmi?
Tak po drobných úpravách to funguje v této podobě (7 sekund):
$result=$dbh->query("SELECT 'trtd'||value||'/td/tr' as val FROM pokus;",PDO::FETCH_COLUMN,0);
echo implode("\n",$result->fetchAll());
Je to asi nejrychlejší řešení z těch, které dělají výstupní agregaci mimo SQL. Zároveň nevypadá příliš složitě, mělo by být obecně použitelné.

Předpokládám, že metoda fetchAll() je napsána v C nebo něčem podobném. Raději použiji takovou funkci než abych iteroval ve skriptu. Beru to od tebe jako dobrý nápad na rozumný kompromis. A že to má 2 řádky místo zamýšlené jedné? To mě vůbec netrápí.

Zpracování skriptu v polovičním čase pro mne znamená zpracování dvojnásobného počtu požadavků klientů nebo pronajaté jedno procesorové jádro místo dvou. V případě některých aplikací to může být docela důležité. Jak už bylo řečeno, cokoliv je rychlejší než PHP. Tím cokoliv můžou být nejen databáze, ale i vestavěné funkce PHP, které obvykle v PHP napsány nejsou.
Josef Kufner avatar 30.11.2011 22:35 Josef Kufner | skóre: 66
Rozbalit Rozbalit vše Re: PHP je lepší select z db pre všetky idečka alebo postupne načitavanie viacerymi selectmi?
Chybí ti tam escapování HTML znaků. Tedy pokud to nejsou jen čísla.
Hello world ! Segmentation fault (core dumped)
30.11.2011 22:44 l0gik | skóre: 22
Rozbalit Rozbalit vše Re: PHP je lepší select z db pre všetky idečka alebo postupne načitavanie viacerymi selectmi?
Jo, jo, to jsou přesně ty detaily, které nakonec to řešení v databází zabíjejí :-) I když samozřejmě v rozumný databázi jde nadefinovat UDF funkce

Jinak já v podstatě souhlasím. PHP je pomalá mrcha a samozřejmě užívat vestvavěné fce je veskrze doporučeníhodné. Jen ale, že to má i druhou stránku a že je poměrně tenká hranice mezi neoptimalizovaným a přeoptimalizovaným kódem...
30.11.2011 23:02 Šangala | skóre: 56 | blog: Dutá Vrba - Wally
Rozbalit Rozbalit vše Re: PHP je lepší select z db pre všetky idečka alebo postupne načitavanie viacerymi selectmi?
Jo, lze to udělat na úrovni SQL tak, že to vyplivne až celou tabulku nebo dokonce HTML stránku, ale otázka je: „¿Která vrstva má být k čemu kompetentní, kolik lidí to dělá a kolik lidí bude udržovat kód a s jakou zodpovědností?“
A když začnete honit milisekundy stejně to celé přepíšete do c(++)-éčka, ehm ano - někdo do Javy. :-)
To, že trpíš stihomamem, ještě neznamená, že po tobě nejdou. ⰞⰏⰉⰓⰀⰜⰉ ⰗⰞⰅⰜⰘ ⰈⰅⰏⰉ ⰒⰑⰎⰉⰁⰕⰅ ⰏⰉ ⰒⰓⰄⰅⰎ ·:⁖⁘⁙†
30.11.2011 22:50 Kit
Rozbalit Rozbalit vše Re: PHP je lepší select z db pre všetky idečka alebo postupne načitavanie viacerymi selectmi?
Správně. Vím o tom, už jsem to kdysi řešil. Nechtěl jsem ty příklady zbytečně komplikovat, ale jde to. V některých případech je však vhodné ukládat data do DB už escapovaná, při generování výstupu je pak menší režie.
Josef Kufner avatar 1.12.2011 00:15 Josef Kufner | skóre: 66
Rozbalit Rozbalit vše Re: PHP je lepší select z db pre všetky idečka alebo postupne načitavanie viacerymi selectmi?
Btw, echo bere libovolný počet parametrů. Takže není třeba spojovat stringy tečkou, což žere celkem dost (měřitelně) výkonu.
Hello world ! Segmentation fault (core dumped)

Založit nové vláknoNahoru

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.