Názory k článku
Databáze Firebird 3.0: lepší podpora více jader a IPv6
-
Mohl by mi, prosím, někdo v rychlosti osvětlit zásadní výhody a nevýhody oproti jiným db? Koukal jsem na net, vždy první bod je, že je oproti mysql uplně free (což už dneska asi neni tak podstatný, když máme mariadb, záleží spíš co nabídí oproti mariadb) a pak nějaký drobnosti, kterým jsem ne vždy uplně rozuměl. Jediné dvě výhody (a možná to první nemusí bejt uplně výhoda), které jsem vlastně pochopil, jsou:- celá db se ukládá do jednoho souboru .fdb, prej po vzoru oracle -> tedy jednodušší záloha (z mého lajk pohledu vyvstává otázka, jestli to nemůže mít vliv na výkon?)
- neni třeba mít spuštěnej server, pokud chci k db přistupovat jen lokálně.
K tomu poslednímu bodu, jestli chápu dobře, tak tady může konkurovat třeba (třeba, ač mě nenapadá jiná podobná db) SQLite?
Díky
-
To, že se to ukládá do jednoho souboru se zálohou nesouvisí, to není jak sqlite, nezálohuje se to kopií (i když to asi jde), co se výkonu týče, tak je to asi taky jedno.
Výhody:
Fakt nevím, možná jen, že celý SŘBD je docela jednoduchý a člověk na něm dost pochopí.Nevýhody:
Katastrofální přístup k zápisu. Nepoužívá to WAL logy, ale při každé změně to volá fsync, čímž to rotační disky totálně zahltí a SSD asi dřív zničí. Konzistence je OK, ale výkon ne.
Cache je jen pro čtecí operace.
To zrychlení SMT znamená, že dokonce vlákna jsou schopna sdílet cache (což u 2- nešlo (clasic), nebo běželo jen jedno vlákno, které se staralo o všechna spojení (superserver))Jako s 3 jsem si moc nehrál, ale 2 řada mi připadla hrozně morálně zastaralá. Navíc 3 už tu dávno měla být dle roadmaps. Prostě IMHO nestíhají.
-
Skopalik (neregistrovaný)
ad fsync) Samozrejme se nevola po kazde zmene, ale pred dokoncenim prikazu COMMIT. Jde to vypnout, ale pak postara relacni DB smysl. FB pouziva tzv. MGA architekturu. Neco na zpusob WAL logu pak pouziva behem nbackup zalohovani. Vice treba zde:
https://en.wikipedia.org/wiki/Firebird_%28database_server%29#The_MultiGenerational_Architecture_.28MGA.29ad SMP) U verze 2.5 se to resilo nastavenim super classic. Nicmene to rozumne fungovalo do max 200-300 klientu. Pro vetsi mnozstvi je vhodnejsi superserver. Tam jsou IO a UDF operace pararelni, signle thread se vykonava "pouze" SQL jadro.
Jestli nekde vidim problemy, tak:
1. Neefektivni kodovani dat na disku, viz treba muj pokus zde http://elektlabs.cz/fbrle/
2. Nejsou podporovany casove zony
3. Pomaly restore. Ten by sel urychlit o cca 30% drobnym zasahem v gbaku -
j (neregistrovaný)
Ad soubory ... normalni databaze fungujou tak, ze v zakladu maji soubory dva - data + log. Vse se zapisuje do linearniho logu (= ziska se i vykon, protoze netreba seekovat ...) a teprve pak se to promita do dat. Bezne se ty dva soubory davaji na ruzny uloziste. Jednak kvuli vykonu a pak kvuli zalohovani - protoze se zalohuje tak, ze pozastavis zapis do dat, pockas, az ti databaze rekne, ze dobehly vsechny transakce, a odzalohujes data. Pritom je databaze stale RW, ale zapisuje se jen do logu. Muzes pripadne zalohovat i ten log - tam uz je to easy, protoze ho proste nekde ustrihnes. Pokud mas data i log, muzes se hypoteticky vratit do libovolnyho okamziku.
Spousta databazi pak umoznuje to jeste dal rozdelit do vice dalsich souboru, ktery muzes rozhodit na vice ruznych ulozist, cimz pochopitelne ziskas dalsi power (a treba muzes urcit, ze nektery tabulky budou na rychlejsim ulozisti ...).
Nektery databaze pak jeste umoznej i jednu tabulku roztrhat do vicero souboru a vicero ulozistich.
Pokud vim, MySQL zalohovat neumi, a to tak ze vubec ne. mysqldump ani polonefunckni replikaci neberu jako zalohovani.
-
j (neregistrovaný)
Kupodivu, normalni uzivatele databazi od databaze ocekavaji, ze jednou z jejich naprosto nejzasadnejsich funcionalit je garantovane konzistentni backup ... a ne ze nekdo sesmoli nejakej script a doufa, ze to vyjde (a ze treba nekdo nekde nezmenil chovani neceho, na co se spoleha, ze se bude chovat nejak).
A replikace? lol .. . ty miliony dotazu na tema "rozpadlo se mi to, nevim co stim" sou tusim dost vypovidajici.
BTW: Bezny postup zalohovani dneska vypada tak, ze sdelis databazi ze des zalohovat, ona ti rekne krles, zavolas snap, a reknes ji ze hotovo. Tim padem mas behem okamziku konzistentni fullbackup, a muzes si ho pekne na pozadi v poklidu prestrkat kam potrebujes, pripadne si vemes jen zmeny (a tudiz velikost 1/2 rocnich zaloh klidne muze byt +- dvojnasobek celkovy velikosti databaze nebo i podstatne min).
-
dustin (neregistrovaný)
O budoucnost toho nástroje se nebojím, vzhledem k tomu, že pochází od firmy, pro kterou je mysql klíčový byznys. A funguje velice dobře, i při zatížené db (druhý běh na pár sekund pozastavuje zápisy, když vytahuje data z logu - velice podobně jako tebou popsaný postup)
Zálohy děláme na jedné ze slave db přes mysqldump -tab -single-transaction, tudíž i tomto případě konzistentně. Rovnou se při dumpu bzipují. Tabulkové soubory se archivují deduplikovaně pomocí backuppc. DB má na disku cca 90GB, bzipované dumpy cca 3GB. Dumpuje se několikrát denně. Máme jednoduchý skript na nalití dumpů v případě potřeby, trvá na slušnějším SSD do hodiny, docela často se to využívá při ladění chyb softu nalezených se zpožděním (bohužel :-) )
V případě výpadku hlavní DB by se provoz přehodil na některý ze slaves v replikačním setu, nedochází ke zpoždění master-slave nad 1 sekundu (samozřejmě to monitorujeme). Samozřejmě by se nečekalo na nalití ze záloh, ty slouží hlavně pro uložení historie.
Záměrně neprovozujeme master-master, ssd v pohodě stíhají zápisy na jednom masteru. Chceme časem rozhodit čtení přes slaves, ale zatím byly jiné priority
Jasně, existují samozřejmě daleko "dospělejší" db, ale mysql (nyní mariadb) nám dobře slouží již cca 15 let (v té době byla např. postgresql výrazně pomalejší. zde zmiňovaný firebird nesrovnatelně pomalejší - tehdy jsme to dost důkladně testovali). A pořád se posouvá dopředu, takže nemám žádné obavy o její využitelnost do budoucna.
Předpokládám, že tebe tohle nezajímá, ale třeba to bude užitečné pro někoho jiného, kdo potřebuje řešit reálné problémy a nemá za sebou rozpočet velké firmy.
-
j (neregistrovaný)
"Zálohy děláme na jedné ze slave db"
mno ... prave ... a to sme u toho, ze potrebujes tu replikaci i jen proto, abys to odzalohoval, cimz kombinujes dva nespolehlivy systemy.
Ja netvrdim ze se mysql neda pouzivat, ale rozhodne bych tomu nesveroval veci, o ktery si nemuzu dovolit prijit. Pripadne veci, od kterych potrebuju, aby bezely 24/7.
-
dustin (neregistrovaný)
Mohli bychom klidně dumpovat z masteru, ale nevidím k tomu důvod zatěžovat hlavní stroj a linky. Replikaci potřebujeme z celé řady důvodů - vedle HA na další stroje přímo na páteři (to neřeší nespolehlivost MySQL, ale potenciální výpadky/smrt HW, ke kterým jednou za čas dojde bez ohledu na DB) se replikuje i do vnitřní firemní sítě, kde se db vedle dumpování pro zálohování historie používá i pro každonoční přípravu čerstvých db pro vývojáře (samozřejmě po obfuskaci hesel, emailů atd.). Kdykoliv se vývojář rozhodne, do 20 minut mu na jeho stanici či devel serveru běží čerstvá db s daty 20 minut starými. Zrovna tohle se využívá velice často, nejčastěji když se potřebuje vrátit k originálním (obfuskovaným) datům, protože si svoje nevratně při práci rozvrtal.
Dělal bych to stejně nebo podobně i s jinou db.
Mohl bych pro ostrá data použít přímo cluster, ale záměrně jsem nechtěl na masteru čekat na potvrzení transakce z ostatních členů clusteru. Je to vždycky o kompromisu a kdybychom náhodou přišli o transakci, tak to je přece normální stav db, že se transakce nepovedla a nastal rollback, s tím musí aplikace počítat. Ale možná na cluster jednou dojde...
Jak říkám, používáme mysql 15 let a zatím nám sloužila dobře a nikdy nás nevypekla (ťuk ťuk :-) ). Kolem 1000 tabulek, 80GB na disku, files per table. Největší tabulka (v jiné db, kam odkládáme celou historii změn objektů) má koukám 510 mil. řádků a 60GB na disku data + indexy.
Vyprávěj, jak a s jakými náklady tyhle běžné věci řešíš ty.
-
Jenda (neregistrovaný)
> celá db se ukládá do jednoho souboru .fdb, prej po vzoru oracle -> tedy jednodušší záloha
To, že je to jeden soubor, ještě neznamená, že bude po zkopírování za běhu vnitřně konzistentní (spíš nebude). Takže to stejně potřebuješ nějak ošetřit, a pak už ti typicky je jedno, jestli je to 1 nebo 100 souborů.
-
Phokz (neregistrovaný)
Důvod pro použití firebirdu jakožto potomka interbase je podpora/používání v projektech postavených nad delphi/kylix.
Verze 3 přináší mimo jiné nový síťový protokol, protože ten starý byl velmi neefektivní na linkách s vyšší latencí.
Takže jednoduchá odpověď na otázku "Kdy použávat firebird?" je IMO:
pokud už jej používáte a máte pro něj velké množství kódu.Pokud firebird nepoužíváte, tak pro nové projekty je nejlépe zvážit dle povahy projektu nějakou běžnější DB.
ČLÁNKY DO MAILU