Dotaz: PHP - Jak ukládat a načítat seznamy ?

[Orlando]

Ahoj. Jde nějak udělat to, že bych vygeneroval velký seznam a uložil jej do souboru a pak bych jen načítal ten soubor a ušetřil tak spoustu dotazů do mysql, paměti a času ? jak se to správně dělá? Děkuji

Odpovědi

[Kit]

Nejlépe asi tak, že ten seznam uložíš do MySQL a jedním dotazem si ten seznam načteš do paměti. Není důvod k tahání záznamů z DB po jednom.

[Lyco]

Jednoduchá odpověď by byla http://php.net/manual/en/function.serialize.php

Obecně ale záleží na tom co je cílem. Zápis na disk je vždycky pomalý, ať už ho děláš z PHP nebo ho dělá databáze - ta ale asi má chytřejší cachování v paměti než ad-hoc cache ve tvé aplikaci. Nebylo by lepší použít třeba materializované pohledy v databázi? Nebo jestli řešíš výkon, proč nepoužít nějakou paměťovou cache, jako je třeba Redis nebo Memcache?

[j]

Spousta dotazu do mysql bude asi tak o 3 rady rychlejsi, nez nejaky ukladani souboru na disk. Proc myslis, ze se databaze pouzivaji ...

[Kit]

Proč dělat spoustu dotazů do DB, když stačí jeden?

[Sten]

Rozhodně se nepoužívá soubor, databáze je o dost rychlejší. Pro další zrychlení aplikace lze použít Memcache. Anebo nenačítat obří seznamy, ale používat kurzory.

[AraxoN]

<?php

// Test 1 - DB:

// CREATE TABLE test (id SERIAL NOT NULL, name VARCHAR NOT NULL, PRIMARY KEY (id));
// INSERT INTO test (id, name) VALUES (1, 'somarina');

$repeat=10000;
$begin=microtime(true);

$con=pg_connect("host=localhost user=araxon dbname=araxon");
for ($i=0;$i<$repeat;$i++) {
	$res=pg_query($con,"SELECT name FROM test WHERE id=1");
	$row=pg_fetch_assoc($res);
	$val=$row["name"];
	pg_free_result($res);
}
pg_close($con);

$end=microtime(true);

echo sprintf("DB done in %.3f s<br />\n",$end-$begin);

// Test 2 - filesystem:

// echo "somarina" > test

$begin=microtime(true);
for ($i=0;$i<$repeat;$i++) {
	$val=file_get_contents("test");
}
$end=microtime(true);

echo sprintf("Filesystem done in %.3f s<br />\n",$end-$begin);

?>

Výsledky:

DB done in 8.246 s
Filesystem done in 0.426 s

A to je v tej databáze jeden jediný záznam a ešte sa vyberá triviálnym dotazom podľa indexu. Ani tak to nie je rýchlejšie, než prečítanie lokálneho súboru. Takže rozhodne by som netvrdil, že súbory sú pasé a má sa na všetko používať databáza.

Bežne robíme to, že zostavu tvorenú zložitejšími SELECT-ami generujeme cron-om do súboru a klientom sa to potom zobrazuje len prostým prečítaním.

[Kit]

Koukám, že jsi ten test schválně napsal tak, aby DB prohrála.

[AraxoN]

Ten test som napísal za 5 minút, najjednoduchšie ako som vedel. Ja mám SQL databázy rád a Postgres obzvlášť. Ale tvrdiť, že súbory sa nemajú používať, pretože databáza je rýchlejšia, to je IMO prejav nedostatočného všeobecného rozhľadu v IT.

Keby si napísal prečo tento test považuješ za zlý, možno Ti dám za pravdu. Napríklad keby bolo objektov desaťtisíce, tak je neúčelné každému z nich spraviť vlastný súbor, pretože filesystém to zabije. Agregovať viacej objektov do jedného súboru je tiež o držku. A pri požiadavke na časté zápisy sa to ďalej komplikuje - zamykanie, čiastočné zápisy, nekonzistencia atď..

Takže ja netvrdím, že súbory sú tým najlepším univerzálnym spôsobom ukladania dát. Najlepší univerzálny spôsob ukladania neexistuje. Databáza je vo väčšine prípadov dobrým kompromisom, ale existujú okrajové prípady, ktoré si vyžadujú iný prístup. Programátor, ktorý to odmieta, podľa mňa nie je dobrý programátor. A to nepíšem o Tebe, ale o tom nad Tebou, ktorý súbory pochoval ako akýsi prekonaný koncept.

[Kit]

Orlando chce velký seznam. Do toho velkého seznamu jsi dal jen jeden záznam. Kdybys dal do DB 1000 záznamů vs. 1000 souborů a měl je načíst všechny, vyhrála by DB, protože by ti stačil jeden SELECT.

[AraxoN]

Je otázka čo to je "veľký zoznam" a tiež čo s ním plánoval urobiť po jeho načítaní do PHP. Ak ho chcel len celý zobraziť, tak potom nemusí byť nakúskovaný do tisícov súborov, ale môže byť v jednom. Ten potom slúži ako cache pre túto jednu jedinú vec.

Inak sám tam spomína množstvo dotazov, takže to asi jedným SELECT-om vybaviť nevie. Tam je zase možné, že len nemá potrebné znalosti SQL.

[Kit]

Sám také soubory používám, např. INI, XML, šablony nebo křížence mezi souborem a databází - SQLite. Vše podle okolností. Orlando nám však nesdělil, k čemu to potřebuje. Proto se můžeme pouze dohadovat, které řešení je nejvhodnější. Možná nakonec zjistíme, že potřebuje Gettext...

[Sten]

Právě protože je tam jen jeden záznam, tak to trvá tak dlouho. Přečtěte si zadání OP a zkuste přijít na to, v čem mu váš příklad neodpovídá.

Takže rozhodne by som netvrdil, že súbory sú pasé a má sa na všetko používať databáza.

Nic takového jsem netvrdil, nevím, kde jste na to přišel.

Bežne robíme to, že zostavu tvorenú zložitejšími SELECT-ami generujeme cron-om do súboru a klientom sa to potom zobrazuje len prostým prečítaním.

Pokud nad těmi daty nepotřebujete pracovat, je to možnost. Opět ale naprosto mimo vzhledem k zadání.

[Josef Kufner]

Pokud je rychlost databáze dostačující, použij ji. Ta databáze ti ušetří kopec práce a mnohem spolehlivěji zajistí konzistenci dat.

Pokud je to pomalé, podívej se na indexy v databázi a vylepši to. Optimalizuj SQL dotazy, udělej lépe indexy.

Pokud to musí být opavdu hodně rychlé, kešuj data v paměti. Použij například APC, což je key-value úložiště ve sdílené paměti, takže to je opravdu hodně rychlé, o několik řádů oproti souboru i databázi. Oproti memcached odpadá síťová komunikace, která memcached zpomaluje na úroveň dobře udělané SQL databáze.

Pokud máš složité výpočty, které chceš jednou spočítat a pak mnohokrát zobrazit, je kešování do souboru celkem rozumná volba. Toto je například případ mnoha šablonovacích systémů, které si šablonu zkompilují do PHP a to pak spouští. Tím se i využije OPcache vestavěná v PHP, takže to je rychlejší než ruční přístup k souboru (je tam jen trochu více režie než v případě použití APC, které vzniklo právě jako OPcache).