MySql vs. Firebird vs Postgresql

Mysql -> community verzija, dobra za obične podatke, ali ne i za dokumente.jednostavna sql sintaxa za procedure i funkcije.

Firebird -> besplatna baza, kvalitetna, instalacija ispod 20 MB.sviđa mi se što se jedna baza zapisuje u jedan file.

postgresql -> besplatna baza, ono što mi se ne sviđa jest to što kad se kreira nova baza, na disk se zapiše u 130 fileova.
svaka nova tablica ide u novi file, nova kolona u novi file, ispravite me ako griješim.podržava nekoliko raznih jezika.



pitanja:

mysql ->
dali se kod mysql-a može narihtat da jedna baza ide u jedan file?
dali bi enterprise baza izdržala do 5 000 000 dokumenata (između 100 KB i 20 MB su dokumenti) ?
ispalo bi do 100 GB + podaci do 40 GB.


Firebird ->
dali bi baza izdržala do 5 000 000 dokumenata (između 100 KB i 20 MB su dokumenti) ?
ispalo bi oko 100 GB + podaci do 40 GB.

Postgresql ->
dali bi baza izdržala do 5 000 000 dokumenata (između 100 KB i 20 MB su dokumenti) ?
ispalo bi oko 100 GB + podaci do 40 GB.
dali postoji mogučnost da jedna baza ide u jedan file?



moj cilj: odabrati bazu po mogučnosti od ove 3 koje zadovoljavaju kriterije: do 5 mil. dokumenata, možda i više, jedna baza u jedan file(mogučnost, ali ne mora biti), da kad se ubaci 5 ili 10 mil. dokumenata da se baza ne raspadne.Operativni sustav bi bio Linux Debian.
dali bi server sa 2 dvo jezgrena procesora, 8 ili 16 GB radne memorije po potrebi i do 48 GB izdržao ovakvu bazu?
moram reći da je broj radnih stanica između 100 i 200 komada.broj istovremenih konekcija na bazu 0-200.
server bi služio samo za bazu.

Mozes li objasniti zasto imas potrebu da to bude jedan fajl?

Potpis

:: Nemoj se svadjati sa budalom, ljudi cesto nece primjetiti razliku ::

kad imaš jedan bazu u jednom file-u, lakše je baratati sa bazama tj. fileovima.

ozbiljno? a zasto uopste trpati dokumenta/fajlove u bazu? nije li bolje resenje trpati putanje?
zatim, potrebno je resiti problem trajnosti podataka/dokumenata (rezervni hardovi, rezervni racunari, automatski bekapovi na posebnim racunarima da bi racunar na kom je baza bio sto je manje opterecen)

Potpis

Žena u krevetu i vino na stolu nikako ne smeju da čekaju. Jer, vino se greje a žena hladi.

-vinolog

a šta misliš zašto je MS napravio sharepoint i svi dokumenti idu u baze?

Probaj sa FB, nista te ne kosta da napunis jednu test bazu, i vidis kako se ponasa. Ja imam bazu koju punim skeniranim slikama (oko 1MB slika), i baza je trenutno oko 2GB i radi skroz normalno. Doduse tvoji su zahtevi veci, ali to je u principu isto.

Pogledaj i ovo: http://codicesoftware.blogspot...aster-than-filesystem-for.html

Sto se tice putanja do fajlova ili fajlovi u DB - mislim da imas mnogo bolju kontrolu nad podacima kada su u bazi, a i lakse je za implementaciju.

jel postoji nekakav besplatan data generator za blob polja?

Evo da i ja nešto kažem, pošto se ovih dana baš bavim sličnim problemom - naša baza je kad sam zadnji put proverio bila cca. 60GB, nedeljni rast je 2-3GB. Ovo govorim čisto kao uvod, da objasnim da znam šta pričam :). Elem, nevezano za bazu koju misliš na kraju uzeti, evo par stvari o kojima vredi razmišljati:
Pre svega, koliko god jak server da kupiš možeš upasti u problem. Šta ako baza postane tolika da je taj mega-giga server ipak ne može opslužiti? Dakle, unapred treba ozbiljno razmotriti rešenja za klastering / replikaciju - ako mene pitaš ne samo pročitati da "to ima", nego testirati, videti kako se ponaša, da li trpi tetet, da li je stabilno... Svi imaju ta rešenja, ali to je nešto za šta praktično ne postoji dokumentacija ili community support, a profesionalni setup/support se masno plaća.
Drugo veliko pitanje je sigurnosna kopija podataka - bekap tako velike baze se ne da baš brzo napraviti. Dakle, treba proveriti da li baza podržava neku vrstu hot-backup-a, kako sve to radi, koje je vreme potrebno za restore, postoji li point-in-time recovery, itd. Ponovo, community support je slab, jer takva stvar ne treba mnogim ljudima.
Na kraju, vredi i dobro proveriti kakvi alati su na raspolaganju za datu bazu. Za tako velike baze se sql mora pisati vrlo pažljivo, jer sitnice na kraju odlučuju o ogromnim utrošcima vremena za svaki upit. Potrebno je da na neki način može da se vidi (idealno i da se utiče na) execution plan, da je moguće podesiti parametre query-analyzer-a, da je moguće odrediti prioritet tipova join-a, i slične zezalice.
Za sve o čemu pričam, provera podrazumeva štopericu u ruci, a ne čitanje teorije šta sve baza podržava.

Nadam se da sam bar delimično pomogao,

pozdrav, ss

ps. Eh, da, meni postgresql trenutno radi posao.

pps. Ako uslovi i tehnologija dozvoljava, obavezno razmisli o ORM biblioteci, kasnije može da ti spasi život.

Potpis

When something is hard to do, then it's not worth doing.

@sasas
probao sam sa firebirdom na kučnom računalu, i koliko sam vidio baza od 4 GB radi dobro.filtriranje radi itd..
ali bojim se ako je napunim do 100 GB, da će mi se disk raspast.
a kako testirat?
jer nije isto doma kučno računalo, atlhon 3500 xp sa 1 GB rama i dva serverska procesora od 5000 xp i 16 ili 32 GB rama i bržiji disk.
jel netko zna, koliko dođe support za postgresql?

evo za firebird.

http://www.ibphoenix.com/main....nix&page=ibp_services#FREE

http://www.cleverworkarounds.c...storage-api-crushing-my-dream/

I jedno i drugo rešenje imaju prednosti i mane. Držanje fajlova na fajl sistemu ti, naprimer u tvom slučaju, dosta olakšava izbor baze, pošto bi svaka od ponuđenih mogla da se izbori sa putanjama do fajlova, nasuprot korišćenju blobova. Takođe bi mnogo lakše mogao da podeliš sadržaj na više diskova, radiš parcijalan backup itd.

WTF?! Do deset redova koda u svakom normalnom jeziku.

Glavni problem, koliko ja shvatam, je izabrati bazu koja ce podneti tu velicinu i rad sa velikim blobovima. Pretpostavljam da tu nece biti stotine tabela i slozenih RI, nego mozda par tabela i to je sve. Znaci, radice na svakoj od ovih baza. Ako bas hoce u jedan fajl - onda nema sta da se misli, samo je FB tako napravljen.

Posto nemam iskustva sa druge dve baze, ja opet o FB:
- FB moze da se podesi baza da bude i u vise fajlova, i da svaki od njih bude ako treba na posebnom disku. Znaci, ako zafali prostora mozes na server dodati novi disk, i restore baze u dva fajla.
- ima i nbackup alatka koja omogucava da se pravi incremental backup, sto znaci - svakog 1 u mesecu pravim full backup, pa onda svake nedelje samo desavanja od tog prvog do tada, onda svaki dan radis backup za desavanja za tu nedelju, i jos mozes i svaka 2 sata praviti dnevne backupe. Znaci, mozes imati vrlo ceste backupe, a da ne trose puno prostora. Naravno, to sve radi online, korisnici mogu da rade bez prekida.

Bitno u ovoj prici je da se klijent aplikacija pametno napravi i da uvek pristupas konkretnom slogu koji ti treba. Eventualno pretrazivanje sadrzaja blob polja bi se moralo napraviti na server strani.

Tek sad videh onih 200 istovremenih konekcija... pa, sta god izaberes, bice slabo :)))

Problem koji me mući može se uklopiti i ovdje:
Radim s Firebird 1.5 bazom (planira se prelazak na 2.0 čim bude vremena :) ), sve jo OK, preporučujem ju i za ovaj problem. Radi se o spremanju podataka u blob ili na disk, a putanje u bazu.

Program koji imam, koji radi, koji ima upisanih cca 100,000 dokumenta služi za arhiviranje. Upisuje se 5-6 podatka o svakom dokumenut, a između ostalog i PDF scan-iranog dokumenta. Do sada su se ti PDF-ovi čuvali na disku, a samo putanje u bazi, sada testiram varijantu s pospremanjem PDF-ova u bazu. Pokušavam staviti plus i minus svakoj varijanti. Testirao sam bazu sa cca 1,000 zapisa i radila je OK.

Pri upisu PDF-a u bazu, baza raste drastično što znači i teži backup, teže kopiranje itd. ali zato jednostavnija manipulacija s podacima.

Nisam radio sa FB, interesuje me par stvari:

Da li možeš nekako uticati na to šta će od podataka ići u koji fajl, i na kom nivou (sloga, tabele, kolone)?

Kad kažeš online, da li to podrazumeva da mogu i da pišu, ili samo da čitaju? Koliko traje takav backup baze od 100 giga?

Mislim da ne.


Mogu da rade sve - backup kod FB ne ometa rad na bazi. Kreira se snapshot transakcija nad celom bazom, i backup se radi za podatke vidljive u toj transakciji, tako da ga ne ometa ako je neko u medjuvremenu nesto upisao, jer je to u novijoj transakciji i ne vidi se iz ove starije.
Ne znam koliko backup traje kod tako velike baze. Evo sad sam merio full backup baze sa slikama od 2,4GB traje 1:45 minuta, doduse na isti disk gde mi je jos par baza na kojima se radi. Znaci bck na poseban disk bi trebalo da ide brze. Ako bi koristio incrementalni backup, onda bi se kopirali samo menjani podaci u toku dana, sto je mnogo, mnogo manje tj. brze.

Ne razumeh ovo najbolje, da li ovde misliš na minut i 45 sekundi ili sat i 45 minuta?

Potpis

When something is hard to do, then it's not worth doing.

1 minuta i 45 d.

jer meni je trebalo 2 minute i 20 sekundi za ubacivanje 2, 5 GB dokumenata u bazu.

To je sasvim ok vreme za backup.



Ovo je stvarno "good point". Btw, postgres ima stvar zvanu "table space", na nivou tabele. Za particionisanje na nivou sloga je ponuđeno stvarno majstorsko rešenje, totalno u duhu postgres-a - nisam ni znao do danas za to, a stvarno je lepo rešeno:

http://www.postgresql.org/docs...eractive/ddl-partitioning.html

Potpis

When something is hard to do, then it's not worth doing.