Která databáze je nejrychlejší?

Zdravím, používám jeden nejmenovaný pokladní sofware, a ten má možnost pracovat nad databází. A z daných tabulkem udělat eshopNa výběr jsou následující APACHE DERBY Client/Server,HSQLDB, MySQL, Oracle 11g EXPRESS, PostgreSQLMusím poznamenat, že do databáze se ukládají i obrázky pomocí datového typu BLOBTakže má otázka zní, která z uvedených databází je nejrychlejší?

Nelze žádnou označit za nejrychlejší. Mnohem víc záleží na databázovém modelu, indexech a dotazech.Z pohledu otevřenosti a ekosystému bych si vybral PostgreSQL nebo MySQL.

Z pohledu rychlosti nasazení, snadnosti správy a případné optimalizace a podpory vyhraje MySQL (MariaDB) následována PostgreSQL.Největší "moloch" bude v tomto případě Oracle, kde bez specialisty toho moc v případě problémů neuděláte---------- Příspěvek doplněn 30.12.2013 v 10:24 ----------A ještě bych doporučil porovnat limity z hlediska počtu CPU, RAM, velikostí databáze, ...

No neviem, mali sme cez 800 instalacii Oracle Express -ov, ale ze by zme potrebovali nejakych specialistov na udrzbu tych databazy, to sa neda povedat. Ma to svoje defaultne webowske prostredie, nieco ako phpMyAdmin. Pri tom exprese pozor na obmedzenia. 10g expres mala nastavene obmedznei na maximalne 1GB RAM a cely server moze mat maximalne 10GB dat.

@kyborg: ještě než se do čehokoliv pustíte, vězte, že největším problémem jsou ty obrázky v DB, které jsou největší ultranesmysl pro eshop. Věřím, že pro ekonomický systém to může být dobré, ale pro eshop je to impossible. U vytíženého eshopu bojujete s časem v řádu ms. Pokud načítáte obrázek z DB, berete jedno vlákno než se přenese obrázek ke klientovi. To však může trvat více než 5-8 sekund (záleží na vaší šířce pásma a na přípojení zákazníka). Tím však vyčerpáváte prostředky pro zpracování dalších dotazů, takže na relativně jednoduchý shop s nízkou návštěvností byste potřeboval velmi výkonný stroj.K DB. Nejrychlejší a nejlépe škálovatelný je MySQL při jednoduchých dotazech, ale při složitějších dotazech se daleko rychleji zadýchá, než PostgreSQL. Takže bude záležet, jak budete mít vymyšlenou celou logiku. Počítejte s tím, že pokud to pojede na jednom serveru, který bude mít alespoň 64GB RAM a quad CPU s frekvencí kolem 3GHz, tak PostgreSQL se bude zpočátku při testech jevit jako líný, ale když jej pořádně zatížíte, tak zjistíte, že to vypadá jako by chytil druhý dech a s rostoucí počtem konkurenčních dotazů se moc nemění výstup. U MySQL při konkurenčních dotazech dochází rychle dech. Když to budete testovat, tak můžete u MySQL dospět k mylnému závěru, že je výrazně rychlejší než pgSQL, protože většina testů dělá ten stejný dotaz do DB a MySQL má cache, která si pamatuje předchozí dotaz. Takový provoz na eshopu, ale nikdy nenastane, protože lidé chodí z různých zdrojů a různých adres a zde MySQL začne velmi rychle ztrácet. Jeho jedinou výhodou je, že můžete velmi rychle rozšiřovat cluster s DB servery a prakticky bez limitace. PostgreSQL má limitaci v 2000 slave serverech.Takže odpověď je: záleží jaký provoz budete očekávat a jaké ambice s projektem máte do budoucna

Napsal Bedříšek;1038041

@kyborg: ještě než se do čehokoliv pustíte, vězte, že největším problémem jsou ty obrázky v DB, které jsou největší ultranesmysl pro eshop. Věřím, že pro ekonomický systém to může být dobré, ale pro eshop je to impossible. U vytíženého eshopu bojujete s časem v řádu ms. Pokud načítáte obrázek z DB, berete jedno vlákno než se přenese obrázek ke klientovi. To však může trvat více než 5-8 sekund (záleží na vaší šířce pásma a na přípojení zákazníka). Tím však vyčerpáváte prostředky pro zpracování dalších dotazů, takže na relativně jednoduchý shop s nízkou návštěvností byste potřeboval velmi výkonný stroj.

K DB. Nejrychlejší a nejlépe škálovatelný je MySQL při jednoduchých dotazech, ale při složitějších dotazech se daleko rychleji zadýchá, než PostgreSQL. Takže bude záležet, jak budete mít vymyšlenou celou logiku.

Počítejte s tím, že pokud to pojede na jednom serveru, který bude mít alespoň 64GB RAM a quad CPU s frekvencí kolem 3GHz, tak PostgreSQL se bude zpočátku při testech jevit jako líný, ale když jej pořádně zatížíte, tak zjistíte, že to vypadá jako by chytil druhý dech a s rostoucí počtem konkurenčních dotazů se moc nemění výstup. U MySQL při konkurenčních dotazech dochází rychle dech. Když to budete testovat, tak můžete u MySQL dospět k mylnému závěru, že je výrazně rychlejší než pgSQL, protože většina testů dělá ten stejný dotaz do DB a MySQL má cache, která si pamatuje předchozí dotaz. Takový provoz na eshopu, ale nikdy nenastane, protože lidé chodí z různých zdrojů a různých adres a zde MySQL začne velmi rychle ztrácet. Jeho jedinou výhodou je, že můžete velmi rychle rozšiřovat cluster s DB servery a prakticky bez limitace. PostgreSQL má limitaci v 2000 slave serverech.

Takže odpověď je: záleží jaký provoz budete očekávat a jaké ambice s projektem máte do budoucna

Tak jelikož se bude jednat o docela malou místní drogérii, tak nejspíše použiji MySQL.. Přemýšlel jsem, zda by bylo možné, např. CRONEM, dělat cache data obrázků do zvláštní složky, a když by obrázek neexistoval, tak by se vytvořil, v opačném případě by se načetl ze složky.. Je to vůec možné?? Moc zkušeností, co se týče datového typu BLOB, nemám...

Napsal kyborg;1038089

Tak jelikož se bude jednat o docela malou místní drogérii, tak nejspíše použiji MySQL..

Přemýšlel jsem, zda by bylo možné, např. CRONEM, dělat cache data obrázků do zvláštní složky, a když by obrázek neexistoval, tak by se vytvořil, v opačném případě by se načetl ze složky.. Je to vůec možné?? Moc zkušeností, co se týče datového typu BLOB, nemám...

Určitě bych řešil obrázky cronem do složky jednou denně celé a průběžně cronem změněné v průběhu dne. Dále bych určitě oddělil DB účetnictví od DB shopu. Pokud myslíte, že máte v účetnictví všechno, co potřebujete mít na eshopu (takový ekonomický systém jsem, kromě Varia s nástavbovými moduly, neviděl), tak bych klidně synchronizaci řešil MySQL replikací master-master. Ovšem dle mého názoru budou vaše náklady vyšší než vzít hotové řešení a napojit účetnictví na tento shop. Obecně se propojení pohybuje v řádu tisícikorun u XML porpojení a cca mezi 30-60tis. Kč u automatizovaného propojení mezi jakýmikoliv dvěma SQL databázemi (shop-účetnictví). Záleží na míře informací, které se přenášejí a kterým směrem (produkty, parametry, kategorie, přílohy, související produkty, alternativní produkty, objednávky, stavy objednávek, a to vše oboustranně|jednostranně).Takže pokud pomýšlíte jen na malý shop, tak začít s levnějším XML a jak se objednávky zvednou, tak dodělat automatizované propojení. Pokud pomýšlíte, že by jste mohli mít desítky objednávek denně a více, řešil bych rovnou automatizovanou variantu.

Napsal Bedříšek;1038099

Určitě bych řešil obrázky cronem do složky jednou denně celé a průběžně cronem změněné v průběhu dne. Dále bych určitě oddělil DB účetnictví od DB shopu. Pokud myslíte, že máte v účetnictví všechno, co potřebujete mít na eshopu (takový ekonomický systém jsem, kromě Varia s nástavbovými moduly, neviděl), tak bych klidně synchronizaci řešil MySQL replikací master-master.

Ovšem dle mého názoru budou vaše náklady vyšší než vzít hotové řešení a napojit účetnictví na tento shop. Obecně se propojení pohybuje v řádu tisícikorun u XML porpojení a cca mezi 30-60tis. Kč u automatizovaného propojení mezi jakýmikoliv dvěma SQL databázemi (shop-účetnictví). Záleží na míře informací, které se přenášejí a kterým směrem (produkty, parametry, kategorie, přílohy, související produkty, alternativní produkty, objednávky, stavy objednávek, a to vše oboustranně|jednostranně).

Takže pokud pomýšlíte jen na malý shop, tak začít s levnějším XML a jak se objednávky zvednou, tak dodělat automatizované propojení. Pokud pomýšlíte, že by jste mohli mít desítky objednávek denně a více, řešil bych rovnou automatizovanou variantu.

Jak jsem řekl, jedná se o pokladní systém Unicenta OPOS, který je opensource, a nabízí tuto možnost, tak jsem si řekl, že databázi využiji přímo pro daný eshop. Náklady by byly vlastně jen na VPS / webhosting. Ten systém, si kompletně vše ukládá do databáze. Zkusím ještě zjistit tu synchronizaci master-master, zda by se na daný typ operace hodila... Popřípadně několikrát denně zkopírovat tabulky zboží a kategorií do druhé databáze? Jak by bylo výhodné toto popisované řešení??

Napsal kyborg;1038443

Jak jsem řekl, jedná se o pokladní systém Unicenta OPOS, který je opensource, a nabízí tuto možnost, tak jsem si řekl, že databázi využiji přímo pro daný eshop. Náklady by byly vlastně jen na VPS / webhosting. Ten systém, si kompletně vše ukládá do databáze.

Zkusím ještě zjistit tu synchronizaci master-master, zda by se na daný typ operace hodila... Popřípadně několikrát denně zkopírovat tabulky zboží a kategorií do druhé databáze? Jak by bylo výhodné toto popisované řešení??

ad. náklady vps - no někdo ten shop k tomu musí doprogramovat. pokud jste to někdy dělal od začátku, tak to nemusí být problém. pokud jste to nikdy nedělal, tak po prvních týdnech vývoje budete postupně odhalovat různé nástrahy (bezpečnost, rychlost, stabilita, nekonzistence db....). To není pouhý dotaz do db a zobrazení. V praktickém provozu zjistíte, že tam je mnoho situací, které musíte ošetřit. ad. master-master - replikace je jedno z možných řešeníad. několikrát denně kopírovat tabulky - ano, i takto se to dělá. opět je to otázka stability a bezpečnosti. aplikaci, která tento proces bude zajišťovat může být jak na straně shopu, tak na straně účetnictví. nebo klidně i kombinace. máme vyzkoušeny všechny tři varianty a nelze říct, že některá by byla lepší nebo horší. vždy záleží na tom, jak je postaven celý business.