limit sql dotazu na ceskyhosting.cz

Hostuju web u tohohle renomovaného hostingu, narazil jsem na technický problém. Maximální délka dotazu na databázi je 1MB. Běžně ukládám soubory do BLOBů v databázi, tak mi omezení přišlo celkem tristní. Tech support mě odbyla s tím, že jde o defaultní nastavení MySQL, a že je to běžný. (na pipni, bananu, dokonce i na webzdadma maj limit 8MB a víc) Co víc, že jsem první člověk s podobným problémem. Nikdo prý tak velké inserty do db nepotřebuje.

To mě docela zaskočilo - máte někdo názor shodný s oním mužem z tech support? Databázi používám na ukládání souborů celkem běžně, rád bych znal názory / zkušenosti ostatních - třeba i s jinýma hostingama.

je to dle mýho názoru praktičtější, než je házet do filesystému (což předpokládam považuješ za lepší ty), důvody:
-pracuje se s nima líp, je-li jich větší množství
-eliminuje to riziko duplicitních názvů
-je to bezpečnější

ale to je trochu off-topic (i když kritiku uvítam)

šlo mi o to, jestli to skutečně nikomu nepřijde jako (zbytečně) svazující omezení..

doblethink:
Vidíš, a já jsem si myslel, že filesystem taky nepovoluje duplicitní názvy.
jj, přesně tak. zatimco do db je klidně nacpeš - v čemž spatřuju výhodu. uznávam že neni nijak podstatná

pracuje se s nima líp, je-li jich větší množství
Ale? fakt? Pokud v nich fulltextově nevyhledáváš, tak bych na to nesázel.
Databáze si umí mnohem snáz pohlídat integritu - je robustnější vůči chybám. Zmizí-li soubor z filesystému, nezjistíš to dokud ti nepíše rozzuřenej user že mu něco nejde stáhnout. Zmizí-li soubor z dobře udělaný db, ta okamžitě pozná že je něco špatně (přebývá jí nějakej foreign key) - a problém se může řešit hned.

je to bezpečnější
Nemyslím si. Ne při správném nastavení práv filesystemu.
nj. s nastavením filesystemu si na hostingu za 1000 ročně moc nepohraju. Hlídání přístupových práv v db mi přijde mnohem pohodlnější, zvlášť máš-li třeba nějaký user groups..

Mastodont, armin jde mi o archivaci souborů obecně (i když fulltext je bonusovej argument pro db), řekněme do velikosti 8MB.
2) je to mnohem pomalejsi (mysql je taky filesystem, tak proc pouzivat neco slozitejsiho nez ciste soubory?) databaze JE rychlejsi - predne diky fyzicky organizaci dat na disku, jejich indexaci..
1) zaloha db muze dosahovat abnormalni velikosti => nebude zalohovana a budou li soubory mimo databazi, budou mensi?



izsak: více méně souhlasím, uvažoval jsem o podobným řešení, nakonec mi vyšla jako lepší alternativa migrace za jiným hostingem.
webzdarma ty dotazy kupodivu skutečně zvládá :) ne na 100%, ale na freehosting to ujde. použil jsem to jen jako příklad, jak velkej deficit tu podle mě ceskyhosting bezdůvodně má.

souki : Napadlo tě někdy ukládat si informace o souborech do DB a na disk je ukládat třeba pod id? Pak máš všechny výhody
napadlo. nemám. čti výše. (bezpečnost, rychlost,fulltext,integrita)

djlj : Tak nejdřív vidíš výhodu v tom, že ti databáze umožňuje neumožnit vložit duplicitvní názvy, o den později zase vidíš výhodu v naprostém opaku…
ne, to jsem nikdy netvrdil (ale byl jsem tak pochopen). asi jsem se špatně vyjádřil. sorry.

Zmizí-li soubor z filesystému - Proč by měl mizet? Mně se teda ještě nikdy nestalo, že by soubor sám od sebe zmizel.
ne každej systém je dokonalej. neměl jsem na mysli ani tak "náhodný" mizení souborů, jako nějakou disfunkci systému která ho způsobí. jak při ladění, tak při ostrým provozu se takový věci stát můžou. Tvrdím pouze to, že databáze je vůči takovým událostem robustnější - díky snazším kontrolám integrity.


armin, djlj : ano databáze je rychlejší než klasickej filesystém, a to v případě že je potřeba k datům přistupovat nikoliv systematicky, ale chaoticky (což je náš případ - žádosti uživatelů na jednotlivé soubory jsou náhodný proces). Je tomu díky indexačním metodám a způsobu fyzické organizace dat na disku, kterou si každá rozumná databáze hlídá. Přístupový čas je rychlejší. Ne že bych soubory ukládal do db z tohoto důvodu, ale rozhodně nelze povzžovat nízkou rychlost za nevýhodu db. ba naopak.

jinak díky za názory. nejsem ten typ co musí mít vždycky pravdu a rád se hádá se všema ostatníma. nicméně o výhodách filesystému nad databází jste mě nepřesvědčili.

jedinou výhodou filesystemu vidim v tom že funguje na ceskyhosting :) má někdo tušení proč maj tak restriktivní omezení na databázi?

připomínám, že MySQL skutečně je mimo jiné určená k archivaci "velkých" dat. K čemu by jinak byly datové typy MEDIUM BLOB a LONG BLOB (velikosti tuším že 16 MB a 4 GB)?

ronnie:
-link se zdá být broken
-vim proč mi to technicky nefunguje. řešim jen, jaký je smysl toho omezení :)

Tak ještě jednou a naposled:

Výhoda ukládání metadat o souborech do db je neoddiskutovatelná a nejspíš se na ní shodnem - i kdyby mělo být jediným argumentem výše zmíněné třídění.

Když už si metadata ukládám do db, nevidím jediný důvod (V celým vlákně. Pominu-li fakt že mi Hofy rozbije držku, což je jistě pádný argument.) proč k nim nepřidat rovnou i binární data souboru.

Naopak je výhodné tak učinit ze dvou důvodů:

-Přístup k datům JE rychlejší, díky jejich "organizovanějšímu" uložení na disku. Index budovanej nad databází lze s trochou nadsázky přirovnat k vyhledávacímu indexu, který si můžou budovat WinXP. Onen krásně animovaný pejsek vám tuto možnost zajisté nabídl (omlouvám se příznivcům alternativnách OS, a všem kteří nemají slabost pro kancelářské sponky a čaroděje na koberci, díky nimž jsou WinXP ještě více user friendly). Proč to ten pejsek udělal? Protože i v Microsoftu je pár chytrých lidí, kteří ví, že index zajišťuje rychlejší vyhledávání než běžný filesystém. Navíc samotná DB hlídá fyzické uložení dat na disku - nepřipouští rozkouskování dat do cluterů disku, který jsou zrovna volný. Když už jsem u wokeních příkladů - pak je to proces analogický permanentně běžící defragmentaci, organizující navíc (u některých db) data fyzicky podle hashových signatur - což umožňuje nepřesný vyhledávání nad opravdu velkýma datama. Bohužel ani tak nádhernej systém jako XPčka nemá pro defragmentaci animovaného průvodce.
Netvrdim že zisk několika milisekund udělá rozdíl. Rozhodně ne na mým webu. Nicméně databáze v tomto případě zkrátka je lepší.

-Práce s řádkami="soubory" je snazší, než by tomu bylo s párem metadata-filesystém. Ať chcete s daty dělat téměř cokoliv, vždycky je to jeden krok (přístup do db) oproti dvěma (přístup do db k metadatům + do filesystému). Integrita metadata=data je navíc automaticky zajištěna, což je jistě u dokonalých aplikací také, ale my ostatní omylní programátoři uvítáme, odpadne-li nám tato jedna starost.

Howgh

djlj: asi budu muset omezit svoje přespříliš barvité vyjadřování. Takhle jsem to nemyslel. Zkus si to ještě jednou přečíst.

U statických souborů je lepší je normálně uložit na disk. Proč?

DoubleThink: ha, první rozumná kritika
U větších souborů budeš narážet na paměťové omezení PHP Ano budu. Vzhledem k tomu že provozuju server kde soubory vkládaj uživatelé přes klasický formulář, tak to omezení mam tak jako tak. Ale uznávam že obecně to problém je.

Míra fragmentace nikdy nebude zpomalovat získání souboru víc než komunikace s SQL serverem (často ještě na jiném stroji). Používáme-li výše zmíněná metadata, musí před přístupem na disk stejně ke komunikaci s SQL serverem dojít. Dotaz bude v obou případech stejně velký=rychlý. Řešíme tedy otázku, jestli trvá déle jeden přenos odpovědi na dotaz obsahující binární data, nebo přenos krátké odpovědi obsahující pouze metadata + přístupová doba k souborům.
Určitě netvrdím že i v tomto případě je moje varianta rychlejší, není ale ani nutně pomalejší. (rozdíl mezi přenosem krátký a dlouhý odpovědi na 1GB síti tak velkej nebude). Jinak je to v případě běhu obého na jednom stroji, kde bych náročnost "komunikace" jednoho jádra procesoru s druhým nepřeceňoval, a tudíž hádal že rychlejší bude DB - díky onomu přístupu na disk (resp. dvěma přístupům na disk v případě užití systému metadata + filesystém).

souki: nechápu moc kam tím míříš. To, že metadata potřebuju častěji neříká nic o tom, jakým způsobem bych měl mít uložený soubor. (Počet řádků v databázi je stejný se soubory i bez. Načítám-li pouze metadata, bude to stejně rychlé ať už jsou samotné soubory uložené jakkoliv. IMHO tedy přístupy pouze k metadatům nehrají v našem sporu roli..)

souki - velikost řádku IMHO nehraje pro rychlost zpracování dotazu roli, jde-li o rozumný dotaz. Tedy takový, který používá k třídění nebo restrikci indexovaný pole (např SELECT WHWRE ID=X, ORDER BY TIMESTAMP..). U jiných dotazů si tím nejsem úplně jistej, ale takových by nad dobře navrženou db být moc nemělo.

..to vše samozřejmě za podmínky, že očekávaná odpověď je stejná - tedy že chceme v obou porovnávaných případech (široká vs. úzká tabulka) vrátit JENOM metadata, čili stejný počet sloupců.

btw. není tu dodatečná změna postu považována za neetickou, že ne? (samozřejmě pokud na něj dosud nikdo nereagoval)

v tom předchozím jsem měl chybku, jen jsem ji odstranil.