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

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)

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.

@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?

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

Ne mogu da zamislim scenario u kome ti je potreban ovaj nivo kontrole. Ako ti ovo treba, sam pravi fajlove i smestaj gde sta hoces. Jedan od osnovnih zahteva za bazu podataka je da korisnik ne mora da brine o nacinu i mestu smestanja podataka.

Tekst sa adrese http://www.firebirdnews.org/docs/fb2min.html

Some people thinks that Firebird is a RDBMS to be used with just small databases and a few connections. They are wrong! Firebird is being used with many big databases and lots of connections. A good example was shown in Softool'06, where Avarda (russian ERP) was running with a Firebird 2.0 Classic server and an average of 100 simultaneous connections accessing a 120Gb Firebird database with 700 million records! Server was a SMP machine (2 CPUs - Dell PowerEdge 2950) and 6GB RAM.

Mislim da ti FB moze biti dobar izbor ako replikacija nije zahtev. Replikacija nije podrzana "out of the box", i za to ti su ti potrebni posebni programi.