Srovnání Mysql vs Firebird – PHP – Fórum – Programujte.com

Máte někdo zkušeností s databází Firebird a můžete říct jaký je rozdíl mezi Firebirdem a Mysql, tedy nějaké srovnání předností a kdy volit kterou databázi (nainstaloval jsem si Firebird 2.5 a jako správce jsem si stáhl program TurboBird). Mě by hlavně zajímalo jaká databáze se více hodí na ukládání obrázků (menších png a jpg). Četl jsem že Firebird při ukládání obrazů (typ BLOB) používá segmenty, takže si nastavíte velikost segmentu jako potřebujete aby vám stačil limit paměti/velikost odesílaného paketu, který máte nastavený u služeb server/klient. U mysql jsem nic takového nenašel, jen zmínku že se musíte vejít do limitu, který používá váš server/klient.

#1 oxidián
Obrázky do databáze raději nedávej. Souborový systém ve spolupráci s webovým serverem jim sluší mnohem lépe, protože tak mají podstatně nižší režii.

S PHP se mnohem častěji používají databáze MySQL, PostgreSQL, případně SQLite. Nemyslím si, že by Firebird mohl mít nějakou významnou výhodu proti nim.

Co myslíš tou nižší režii v jakém smyslu? Z hlediska místa na disku nebo rychlosti načítání/ukládání

#3 oxidián
Vytáhnout obrázek z databáze je dražší než z filesystému. Dražší ve smyslu systémových prostředků, a samozřejmě to i déle trvá.

#3 oxidián
Především v rychlosti a možnostech kešování. Do databáze se mi osvědčilo dávat pouze náhledy fotek, které inline vkládám přímo do HTML. Stránka s náhledy se pak natáhne jedním dotazem. Plné fotky se však mnohem lépe tahají z adresářů. Jako jejich název je dobré používat hash fotky - automaticky se tím udělá jejich deduplikace.

#4 z_moravec
A jseš si tím jistý. Co když bude ve složce 100.000 souborů? Já nevím jak to má dnešní Windows, ale pamatuju časy kde v souborovém systému FAT32 v dosu, když jsem najel do adresáře Windows/systém tak trvalo celou věčnost než se načetly soubory (nebo spíš smazání všech souborů toho Windowsu). Z DOSu to bylo strašně pomalé. To jisté má co dočinění spíš s OS a s faktem, že když máš hodně souborů a chceš je zobrazit v manageru tak to dlouho trvá. No a mě by zajímalo jestli něco podobného platí i když chceš načíst desítky souborů ze složky kde je 100.000 souborů. Vidím nevýhodu v tom, že takový počet souborů prostě bude zabírat v FS zbytečně spoustu dat navíc jako je časové razístko, velikost souboru, název souboru). V db je-li název číselný tak snad tě název stojí jen 4 byty max 8 bytů. No a v FS tě to bude stát desítky bytů. A o jak velkém zpoždění u db se tu bavíme? V rámci localhostu? Pokud je načtení v rámci 30-90ms je to stále v pohodě. Berme v úvahu obrázky do 200kB.

#5 Kit
Ale zkušenosti máš asi jen s Mysql nebo Postgre? Mě by zajímalo jestli je v tomto Firebird rychlejší. Tak neuvažuji jen o využití pro webové stránky, ale taky pro aplikaci C/C++ která bude upravovat obrázky, takže čas natažení z db může být zanedbatelný (protože se mohou načíst v době kdy se upravují jiné obrázky) a na to si myslím že by právě Mysql vhodné nebylo, ale Firebird ano alespoň jsem to četl na wiki, že ho programátoři používají aby mohli vytvořit aplikace využívající db.

#7 oxidián
S Firebirdem mám negativní zkušenosti, ale to tě asi nezajímá. Rychlost také nic moc. Proč myslíš, že Firefox uvnitř nepoužívá Firebird, ale SQLite?

Proč zrovna Firefox? Já nevím jakou technologii používají. A nevím že používají databázi. Na co taky? Fakt nevím jak funguje Firefox.

Jde o to, k jakému využití je ta aplikace. A myslím že zrovna pro web a pro soukromé využití bude něco jiného. Zatím jsem ale neslyšel žádné časy k porovnání. Snad zkusím něco pohledat na netu jestli najdu info

Te´d čtu toto: http://stackoverflow.com/questions/1635273/postgres-vs-firebird problém je právě v tom, že pokud bych vybral Firebird na moji aplikaci v C/C++ tak já nepotřebuji aby se tam přihlašovali jiní puživatelé a tudíž zkušenosti s webovou aplikací tady asi nebudou srovnatelné. Za druhé, když si někdo stěžuje že mu něco nejede nebo nefunguje nemusí to být nutně proto že by byla špatně napsaná aplikace, ale že ji uživatel nesprávně používá - to neumím posoudit protože nejsem ani začátečník natož odborník přes tento systém. Celkově lze říct že pokud si větší množství lidí stěžuje tak to asi nebude náhoda, ale zároveň je otázka jestli existují také nějací lidé co to umí používat správně a jsou spokojeni.... Jinak by snad ta služba nebyla používaná a byl by ukončen její vývoj.

Firebird na rozdíl od Mysql API pro C/C++ (ale teď nevím co to vlastně znamená protože jsem se dočetl že programátorský jazyk C/C++ a PHP podporují oba).

#10 oxidián
Jak to, že nepotřebuješ, aby se k databázi přihlašovaly další aplikace? Už ve svém popisu máš dvě. Vůbec ani nebereš v potaz, že by někdo tu aplikaci spustil dvakrát či čtyřikrát současně, aby například využil více jader procesoru.

#9 oxidián
V čem si Firefox podle tebe ukládá záložky, historii, konfiguraci, cookies, blokované stránky, pozici na stránce, ... ?

A na to potřebuješ mít více uživatelů? Já myslím - přihlašuje se jeden uživatel, dejme tomu SYSDBA.

#13 oxidián
Každý uživatel databáze by se k ní měl přece přihlásit, ne? Pokud ti k tomu stačí jeden účet, je to tvůj problém. Třeba zmíněný Firefox používá pro interní databázi jen jeden účet a dokonce si ho po přihlášení i zamyká, aby mu třetí strana neměnila data "pod rukama".

Tak jsem narazil na nápovědu tak už vím jak se přihlásit takže bych mohl někdy v příštích dnech zkusit nějaké testy se vkládáním obrázků ať zjistím jak rychle to jede.

Cokoliv čtu o Firebirdu ukazuje na poměrnou neoblibu toto databázového systému.

Srovnání výkonu s PostgreSQL, Firebird vede.

#15 oxidián
PostgreSQL je jiná liga, která ten výkon má úplně někde jinde, než kde měří benchmarky. To bych také mohl tvrdit, že DB4 je v testech 100× rychlejší než Firebird. Jen se hodí pro jinou oblast použití - třeba na ukládání fotek.

O DB4 slyším poprvé dej mi odkaz na oficiální stránku. Každopádně práce s MySQL by byla pro mě nejjednodušší (ve smyslu že jsem s ní už pracoval a že je oblíbenější tudíž se dají snáze na netu najít informace), ale nevím jestli se dá zkompilovat knihovna nebo jestli nabízí knihovny abych si mohl zkompilovat vlastní program, který bude využívat jejich systém. Ještě musím zopakovat že potřebuju systém který nebude fotky ukládat do jednotlivých souborů. Klidně ať má databázový soubor 4GB-400GB nebo víc ale ať nemusím přenášet 100.000 soborů z disku na disk. Pro web pak použiju sqlite a fotky na ty bych spíš odkazoval na jiná hostingový server, takže bych ukládal jen odkazy. Ale pro Céčkový program je to něco jiného.

#17 oxidián
Knihovna DB4 (resp. GDBM s podobnými vlastnostmi) je běžnou součástí PHP. Hledej ovladač DBA, který umí pracovat i s databázemi INIFILE a CDB. Databáze se dá generovat i konzolovými nástroji a přenést jako jeden soubor.

Za zmínku stojí i databáze Tokyo Cabinet, kterou jsem také zkoušel a také měla dobré výsledky. Podporuje více sloupců v tabulce.

Také Redis není špatný. Na zmíněné fotky se sice vůbec nehodí, ale má zajímavé objekty a kolekce pro přímou vazbu na OOP. Nepotřebuje ORM.

Jaká verze je aktuální stabilní? Našel jsem poslední verzi z Prosince 2004.

Chvíli to bude trvat než si pročtu manuál. Takže to je přímo pro C/C++?

Edit - jestli to správně chápu tak ta databáze nepoužívá žádné tabulky? Prostě tam vkládáš jen páry key=value? Může být key číselný index jako id řádku?

Mě se jedná spíš o to ukládat více druhů obrázků, takže bych to potřeboval rozdělit například na 32-64 tabulek. Jelikož v různých tabulkách mohou být různé druhy masek nemohu házet všechno do jednoho souboru. Snad bych mohl mít 64 různých databázových souborů místo toho to by nejspíš taky šlo. No fakt nevím jak to udělat. Nejde jen o obrázky. Jde o to asociovat k nim ještě další informace třeba co na obrázku je za objekt apod..

Pochopil jsem to tak, že data se tam posílají po jednom páru vždycky. A načítání snad taky. Takže nemohu poslat jeden obrázek, ale vše co chci zapsat. Veškeré popisující data, které k obrázku náleží. V programu bych měl strukturu

např:

- size_t img size

- img data (binární data)

- size_t header size

- header (binární data)

- size_t vectors size

- vectors ((binární data)

a toto bych odeslal jako pole char a int, a načítání to samé rovnou do struktury.

#19 oxidián
Je to databáze typu NoSQL. Vše zmíněné se v tom dá udělat v jednom i ve více souborech. Dá se v tom vytvořit hierarchie dle potřeby jednoduše tak, že hodnotou bude nějaký adresář zabalený např. do JSON.

#20 oxidián
To máš zafixováno asi z FAT, ale běžně se to takhle nedělá. Nemůžeš mít napříkad více názvů u jednoho obrázku, volitelné atributy a tak.

Když si však vezmeš inspiraci ze systémů NTFS nebo EXT2, kde jsou názvy a atributy odděleny od dat, dojdeš k mnohem pružnějšímu a kvalitnějšímu řešení. Položky s přídomkem "size" jsou zbytečné.

#22 Kit
Size_t by byl zbytečný pokud bych dal proměnlivou délku dat na konec a typy jako integer bych dal na začátek.

Právě že u toho typu struct je to úplně jedno. Je rychlejší a jednodušší např. otevřít jeden soubor, vyhledat jednu položku o délce např. 206104 byte a toto do té struktury načíst. Jediné co se musí v Céčku nejdříve udělat je klíčovým typům přidělit paměť. Struktura pak má například 32kB, jsou tam pointery na obrázky... Jinak bych musel otvírat například 8 souborů.

Řešení rozdělit to na tři soubory v tomto případě by nebylo špatné, ušetřilo by se tím místo. Ale co když tam chci mít 16 sloupců? Dát 16 souborů. 64 tabulek s 16 sloupci to máš už 64*16 souborů.

#23 oxidián
Jsi úplně mimo. Size_t si odvodíš z délky skutečně zapsaných dat. Nemusíš ten údaj vůbec ukládat.

Na struktury můžeš zapomenout. Takhle se s těmito databázemi nepracuje. Název sloupce se jednoduše integruje do klíče. 64 tabulek se 16 sloupci snadno umístíš do jednoho souboru. Záznam z více neklíčových sloupců můžeš uložit třeba jako jeden JSON.

Tak to není nic pro mě. Já bych chtěl vybrat najednou třeba 50 souborů a ty otevřít najednou a ne seriově otvírat každý soubor zvlášť (načítání po malých segmentech/blocích).

#25 oxidián
Máš snad 50jádrový procesor?

To ne ale chápeš že je rozdíl tahat data z disku po 200 kB a tahat je po deseti megabytech?

#27 oxidián
Chápeš, že v DB4 je to při správné konstrukci klíčů úplně jedno?

Já bych spíš šel do toho posgreSQL, zkusil bych něco nového. Kolik zabírá postgre v paměti jako server?

#29 oxidián
Zpravidla veškerou dostupnou. Záleží na konfiguraci.