Dakle, 50 merenja u sekundi to mu izađe 50*60*60*24 = 4,320,000 slogova za 24 časa. Jedan slog bi bio, otprilike 40 bajtova, pa mu to izađe 172,800,000 bajtova u roku od 24 časa.
Limit Express verzije je 10GB podataka, pa mu to izađe da će skalamerija da radi 58 dana dok se ne dostigne limit.

Sa druge strane, onako kako si opisao situaciju, to ne bi bio problem ni za jednu bazu podataka, samo da nije ograničenja količine podataka.
Bolje da ideš na MySQL ili neku drugu "besplatnu" bazu.

Hvala na odgovoru. Eto nisam znao za limit od 10GB, znaci express ispada iz igre. Minimalna kolicina podataka treba da bude bar za 1 godinu, sto onda ispada nekih 60GB?
Malo me brine i to sto je os XP 32 bita, znaci 3gb rama maksimalno. Ne znam da li je to dovoljno, ili cu morati da nabavim 64-bitnu verziju.

Ja sam lupio odokativno potreban prostor, ne znam kakvi su ti zaista podaci, ali treba da računaš i da ćeš želeti da imaš indekse nad podacima, što mu dođe još 30%-100% overheda na podatke.

Sada, kada ti je otpala MS SQL Express varijanta, ne moraš uopšte ni da ideš na Win varijantu servera. Ako je neki niskobudžetni projekat, lepo staviš 64-bitni Linux, pa onda stavi memorije koliko hoćeš. Ne znam koliko je matora mašina, kada još uvek gura XP na sebi, ali za max 400 EUR kupiš bombonicu od mašina sa 8GB RAM-a, pa sve ima da leti (evo, baš gledam neki i3 sa 8GB za 39,990)...

Nazalost, mora XP, jer se merenja kupe preko softvera koji radi samo pod Windows-ima.

PostgreSQL?
http://www.postgresql.org/about/

Najbolje da probas na svojoj konfiguraciji.

Posto mene zanimaju mogucnosti PosgreSQL pustila sam ovo na svom par godina starom laptopu. Tablespace je na eksternom usb disku.

create table test as
select
trunc(random()*300+1) id
,current_timestamp ct
,substr(md5(random()::text),1,25) vl
,round(random()) bt
from generate_series(1,1500000000);

Ovo je odradio za neka 2.5 sata. Kreiranje indexa nad (id,ct) je radio satima i nije uspeo da zavrsi. Zauzece diska u podacima je 117GB.

Ovo bi trebalo da simulira godinu dana rada (na id treba dodati do sestocifrene vrednosti).

PostgreSQL nije podesavan default instalacija je u pitanju.

Predlazem ti da kada upunis bazu napravis neki programcic koji ce da simulira punjenje baze da vidis da li mozes da postignes brzinu od 50/s.

Nisam imao bas puno vremena ali evo sta sam postigao:

Krenuo sam od MS SQL Express 2008R2 . Napravio sam bazu sa 1 tabelom , 52 kolone gde je prva vreme kao string, zatim 50 real merenja i index. Kroz VB sam simulirao "punjenje" baze od godinu dana, sa 50 velicina na svake 2 sekunde i baza ispadne velicine nekih 8Gb, znaci ispod 10 tako da MS SQL Express teoretski moze da zavrsi posao. Medjutim, update na tolikoj bazi (365*24*60*30 zapisa) je EKSTREMNO SPOR, nesto tipa minut-dva za jedan record a meni je poptrebno da se odradi u delicu sekunde. Citajuci malo o bazama naisao sam da se rad usporava ako baza ne moze da stane u RAM, a posto MS server uzme otpr. duplu kolicinu rama u odnosu na bazu, ispalo je da najveca velicina baze koju mogu brzo da apdejtujem jeste oko 1GB (radim na XP-u a tu je max. RAM ogranicen na 3GB).
Zato sam odlucio da napravim bazu na mesecnom nivou a da onda mesecno pravim arhivu (kroz bekap) pa da potom bazu popunjavam ponovo, tj apdejtujem zapise za odredjeni vremenski trenutak. Da ubrzam rad, pretvorio sam vreme u integer (po formuli sekunde + minuti*60 + sati*3600 +dani*86400), i sad update traje stvarno vrlo kratko.

Ostaje mi da resim pristup arhiviranim podacima. Ideja mi je da na serveru pored trenutne baze imam i neku temp bazu u koju bih po potrebi mogao da vratim bekapovane podatke za odredjeni mesec, te ih obradim po potrebi. E, sad imam problem posto ne znam kako to da izvedem. Pokusao sam da uradim restore:

Dim conect As New ADODB.Connection
With connect
.ConnectionString = "Provider=SQLNCLI10;Server=SERVER\SQLEXPRESS;Database=baza;Trusted_Connection=yes"
.Open
.Execute "RESTORE DATABASE bazatemp FROM DISK = 'C:\Backup\baza.bak' WITH REPLACE;"
.Close
End With

ali ovo ne radi, tj umesto u bazatemp pokusava da uradi restore u originalnu bazu a to server ne dozvoli jer je baza otvorena. Verujem da je resenje jednostavno ali jos ga nisam nasao pa ako neko zna, neka pomogne.

Nije ti serevr kriv za sporost, nego najverovatnije baza.

Ono 52 kolone najverovatnije moze da se svede na 52 rekorda. Kazao si ovo:


Tvoja tabela treba da izgleda ovako:
Merenja { ID LongInt, Vreme datetime, Vrednost varchar(25) } PRIMARY KEY (ID,Vreme) Pretpostavio sam da ID na neki nacin predstavlja 'sta se meri' pa se istih 52 ID ponavljaju svake sekunde sa razlicitim vrednostima.

Ovakav dizajn tabele ce mnogo brze da ti radi nego 52 kolone (zlo i naopako, daleko bilo...)

Nije mi jasan ovaj tvoj predlog za organizaciju baze. Ne znam da li sam i sam najbolje opisao zadatak ali da probam jos jednom:

Svake sekunde treba "upamtiti" vrednosti 50 razlicitih velicina. Vrednosti (value1,...value50) su ili integer ili real brojevi. Iz baze treba da se po potrebi "izvuce" kretanje bilo koje velicine od tih 50 izmedju dva proizvoljna vremenska trenutka. Nekako mi je logicno bilo da svaki row bude nova sekunda, ali mozda ima bolji pristup?

Nije svaki row jedna sekunda. 50 rows bi bila jedna sekunda. Svako od 50 merenje u svakoj sekundi ide u zaseban row. Ima mnogo redova, godisnje 52*60*24*365 ali ce ti kveriji biti mnogo brzi, unos I sve ostalo.

Ovako nekakao, ako je moguce. Pretpostavka je da za svaki od 50 izmerenih podataka znas sta je to (napon, amperaza, proticaj, nivo, brzina, nekakav staus I slicno).

Sta je ta zadnja kolona koja je index? Mozda si hteo da indeksiras po vremenu da bi brze nasao slog

CREATE INDEX idxVreme ON MyTable (Vreme);

Ali tu si na knap sa 10 GB, nije bas sa tim se kockati.

Jeste,

Znam sta je svaka velicina, poznat je i format. Mislim da razumem predlog, formiracu test bazu da vidim kako radi. Samo da te ispravim, imace 50*60*60*24*365 redova, tj 1.5 milijardi na godisnjem nivou sto mi deluje zastrasujuce. Potrebne su 3-4 kolone, timestamp, Id, value, eventualno index ako uopste treba. Posto baza ima mnogo vise upisa nego prva varijanta (u prvoj 52 velicine u sekundi, u drugoj 150-200), i verovatno ce biti mnogo veca, moram da vidim sta moze da stane u 10GB (kao sto sam pomenuo, imam mogucnost da merim na 2 sekunde umesto na jednu kao i da baza bude na mesecnom nivou sa automatskim bekapom). Iskren da budem MS SQL Expres mi je "legao" pa ne bih da prelazim na nesto drugo ako ne moram.


Malo mi je nezgodno sto ce upis i citanje biti u komplikovanijem obliku nego sada. trenutno kad hocu da "izvucem" neku velicinu koristim:



a za tvoj predlog baze ce valjda ici nesto tipa

Meni se laicki cini da ce ovaj upit da se radi sporije, ima vise uslova. Takodje, kod apdejtovanja umesto da se apdejtuje 1 row sa 50-tak kolona apdejtuje se 50 row-a sa 3 kolone. Da li organizacija tabele da ima malo kolona a puno redova zaista toliko ubrzava rad sa bazom?




Upravo to, nisam istestirao ali je to bila ideja.


_{[Ovu poruku je menjao indicator1 dana 13.03.2014. u 10:46 GMT+1]}

Možda bi bilo dobro da nam detaljinije opišeš realni sistem koji pokušavaš da prevedeš u informacioni. Koji je to konkretni realni sistem?
Recimo da bi jedna od ideja smanjenja količine upisa bila, da se upisuje zapis samo ukoliko se bar u jednom merenju razlikuje od prethodnog. To bi smanjilo zahteve za kapacitetom, jer se zapis nebi upisivao na svaki sekund.
Kada su merenja u pitanju, sigurno je da postoje standardne veličine (dozvoljene granice).
Razmisli o tome da beležiš samo one koje su van opsega.

Da kazemo da je u pitanju vise strimova podataka koji stizu potpuno asinhrono, ali vrlo cesto. Da bude lakse, recimo meri se 50 temperatura a za merenje se koriste razliciti meraci. Windows PC pod XP-om (ima razloga zasto je bas XP) skuplja podatke sa vise tipova meraca, sa kojima se komunikacija ostvaruje ili preko LAN mreze ili serijskim portom ili konvertorskom karticom ugradjenom u sam racunar. To znaci da moja aplikacija kupi raznorazne podatke (merenja), na razlicite nacine (DCOM objekti, UDP strim, serijska komunikacija, windows drajver kojem se pristupa na razne nacine. ...) Strimovi su razlicite brzine neki dostavljaju podatke i po 100 puta u sekundi, neki redje. Zadatak je prikupiti sve te podatke od razlicitih uredjaja(strimova) i skupiti ih na jedno mesto za naknadnu analizu.
Svaka merene velicina ima svoj dozvoljeni opseg, ali to nije od interesa u ovoj prici. Ono sto jeste je da je za naknadnu analizu potrebno podatke pamtiti u vremenskom sledu od 1, eventualno 2 sekunde NAJREDJE . Brze podatke obradim (usrednjim, filtriram, sta vec) tako da ih svedem na tu vremensku bazu. Korisnik aplikacije treba bude u mogucnosti da analizira vrednosti bilo koje od 50 velicina za bilo koje vreme u poslednjih godinu dana. Do sada sam to radio direktnim upisom u binarne fajlove, pa ih kroz svoju aplikaciju vratim nazad i prikazem graficki, kroz excel tabelu ili vec kako ko hoce, sada moram da uposlim SQL bazu (da bi podaci bili dostupni i na neki drugi nacin a ne smo kroz moju aplikaciju).

Znaci ukratko, ja vec odbacujem suvisne podatke koje treba pamtiti, ovih 50 u 2 sekunde je MINIMUM MINIMUMA. Velicine su promenljive u vremenu, realnoj je ocekivati da se menjaju iz sekunde u sekundu tako da asinhroni nacin pracenja (belezenje samo trenutaka i velicine promene) nema smisla.

Video sam da se za ovakve stvari koriste neke ne-sql baze, ali ovde je bas zahtev za SQL (ima i smisla, taj koji bude analizirao podatke moze putem svojih sql upita da izdvoji bas ono sto mu treba iz GOMILE podataka).

Kad se ima (puno) para, za ovo se koriste historian baze, ali ovo treba da bude za dzabe.

_{[Ovu poruku je menjao indicator1 dana 13.03.2014. u 13:56 GMT+1]}

Firebird baza je besplatna ali nemam iskustva sa tolikom količinom podataka, možda da i nju pogledaš?

Nemam iskustva sa bilježenjem mjerenja, ali ako se ne varam, "SQL baze ilitiga relacijske baze" nisu najsretnije rješenje za tvoj problem. Dakle, po meni bi tebi trebala neka noSQL baza tipa Cassandra, SimpleDB, MongoDB. Ponavljam, nemam iskustva u tom području ali savjetujem ti da si malo googlaš, možda nađeš efikasnije rješenje.

Cassandra

Taman sam ti u zadnjem postu o ovome pisao. Zašto misliš da se u noSQL bazama ne može izdvojiti točno određeni podatak? Postoje i za njih "jezici" kojima se izvlače podatci, inače te baze ne bi imale smisla.
Mislim da si previše ograničen (pogotovo sa besplatnim verzijama) sa relacijskim bazama podataka. A o mjesečnom dijeljenu baza ne bi niti pomišljao jer me i strah pomisliti šta bi se dogodilo da moraš tražiti podatke u rangu 1.1.-31.12.

Zato sto korisnik trazi SQL bazu (iako malte ne nema relacija) jer zna SQL upite posto ima i druge SQL baze, a nece da uci kako se operise ne-sql bazama Ja ne znam nista o bazama pa mi je svejedno, ali ne mogu da biram. Vec sam potrosio par dana na upoznavanje sa SQL-om pa ne bih da menjam "u pola posla". Pomenuo sam da sam to sve ranije radio i bez baze, pa sam se borio sa tolikom kolicinom podataka. Neki sledeci put cu sigurno pogledati neke od ovih "specijalizovanih" baza, sad mora da bude besplatno i po mene jednostavno.

Pa ako nije neophodno u relnom vremenu pristupati bazi već samo kasnije u trenutku analize podataka

Relativno brzo možeš da doradiš tvoj program koji je pravio binarne fajlove sa podacima da pravi txt fajlove u formaty SQL upita za ubacivanje u bazu, a onda iz nekog alata ili čak command promta batcha ručno ili iz task shedulara aktiviraš update baze

Jbt, potrošio si par dana na upoznavanje sa tematikom koja je inače STRAŠNO komplikovana i obimna, plus što ti imaš prilično velike zahteve, pa nećeš više da se cimaš... Pa nije to izbor košulje za izlazak u grad pa kao MS SQL express ti je legao pa nećeš da gledaš dalje... Svašta.

Za to što hoćeš da radiš ima dosta različitih rešenja, masa njih je i open-source, ali od tvojih zahteva zavisi koja kombinacija je optimalna. Da li ti 20-og u mesecu treba svaka sekunda iz 5-og tog meseca? A iz 5-og prethodnog meseca? Da li imaš izmenu podataka ili samo upisivanje i čitanje? Da li agregiraš podatke nekako? Da li se čita mnogo ili malo? Sa uvek istim ili različitim upitima? Itd itd.

Ne znam koja je tvoja osnovna struka (elektronika?), ali ako i njoj pristupaš na isti način kao i bazama podataka, teško mušterijama...

Indeksi isto zauzimaju mesto i racunaju se u tih 10GB, pa povedi racuna o tome. Kreiranje indeksa nad tabelom koja zauzima 8GB lako moze da predje 2GB.
To sa smestanjem merenja u kolone je ok pod jednim uslovom - da ce uvek biti tih istih 50 inace ces se zapetljati u 'ALTER TABLE... ADD COLUMN...'
Ne radim sa SQL serverom ali koliko vidim restore bekapa u neki drugi database name ide otprilike ovako:

RESTORE DATABASE nova_baza FROM DISK = 'C:\Backup\baza.bak'
WITH
MOVE 'bazatemp' TO 'C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\DATA\nova_baza .mdf',
MOVE 'bazatemp_log' TO 'C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\DATA\nova_baza _log.ldf'

tako nekako
Ti to mozes ra resis aplikativno da kupis podatke iz restore bekapa, ali sta ce tvoj korisnik koji hoce da pise upite, da li on zna da izvede ovako nesto?

Pa ne mora čak ni da pravi SQL fajlove - može da napravi skripticu koja će te binarne fajlove da parsira i upumpava u bazu, bilo to SQL ili noSQL baza.

Slažem se sa svime napisanim. Imam osjećaš da želiš nešto na brzinu rješiti a to nikako ne može dobro završiti. U svakom slučaju ovo ograničenje od 10GB koje spominješ če te sigurno dovući u ogromne probleme. Pogledaj Firebird kao šta sam spomenuo, open-source je i mislim da može zadovoljiti tvoje potrebe, ako veće ne želiš ozbilnije pristupiti problemu.

Hvala na korisnim sugestijama. Ostajem mi da neku od ideja realizujem pa da vidim kako ce se ponasati u realnom radu. Ako u medjuvremenu nesto pametno saznam ili zakljucim, napisacu.