Real-time database

Rabil bi hitro free bazo (ne rabi biti sql), lohka je tudi opensource.
Ker jih je ogromno na trgu, men se pa mudi, bi rad slisal vase izkusnje, da ne probam vsake posebej.
Ta baza bo zgolj temporary, vendar mora biti zanesljiva (poweroff) in hitra, nekaj kilo transakcij/s+, max 1 mio records. Navadno pisanje v fajl zarad specifike ne rabim. real-time timesten je sicer to kar rabim, vendar je $$$.
Trenutno sem si zacahnal H2, extremedb, mongodb, objectdb, berkeleydb.

Kdo uporablja ze kaj takega da pove izkusnje ?

Lokalno samo. Record oriented. Zgubit je ne smem :) Ostalo je opcija.
Na kratko, realtime async transakcije ki prihajajo notri, morajo biti temp zapisane, ostalo se bo naprej procesiralo sinhrono in slo v
pravo bazo, rabim tolk, da ce je poweroff lohk pri restartu nazaj precitam temp zapise. Bi naredu navaden rdbms, sam ob procesiranju
recorda ga mora oznacit done, so pa variable-length, zato se ne bi svoje strukture loteval ker mam dost drucga dela (se bojo drugi igral z deploymentom med tem cajtom :P)

Je kr kompliciran multithread model, tko da c++ pa java.

Prepocasn :)

Nobena baza ki se dotika diska direktno ne pride v postev. Razen ce bi mel ogromno raid diskovja z batterybackuped cachejem, pol se da priblizat
par jurjev transakcij/s.

Bom pogledu jype, thx

Jype, na prvi pogled je hitra (single thread), bom zdej se concurrency pa poweroff stestiru, ce bo ok, je to to :)

win64, ta je in-memory only, poweroff in vse zgubis.

Jype, teste je vse uspesno prestal, 50,000 recordov v 80ms. Zelo navdusen. Poweroff je tud do recorda natancno zapisal, tko da to je to.

Si mel drgac kake tezave z njim kadarkoli ?

Tale problem se prevede v "kateri persistant storage omogoča IO reda 1000 ali več"?
Dokler gre samo za OUT operacije (branje) še lahko shajaš z HDD, kjer se podatki pač hranijo v ramu, takoj ko pa so v igri IN operacije pa si omejen z prepustnostjo nekaj 10 ukazov na sekundo al pa žrtvuješ 100% "ne smem zgubit" za 99,9..9% verjetnost, da ne zgubiš.

Če res hočeš/nucaš to kar praviš, ti preostane le RAID polje SSD diskov. Piše že en sam dost hitro da dosegaš svojih nekaj kilo IOPSov, z redundanco se pa zaščitiš proti odpovedi HW.

Poweroff je tud do recorda natancno zapisal, tko da to je to.

To niti približno ni to.
Kritičen je čas med zadnjim prispelim podatkom in PowerOff dogodkom. Če je minila desetinka sekunde, problema ne boš videl več niti na HDDju.
Ko boš mel pa realtime okolje, bo pa stvar ckrnila ravno takrat, ko par zadev še ne bo prišlo do diska.

WarpedOne> si omejen z prepustnostjo nekaj 10 ukazov na sekundo al pa žrtvuješ 100% "ne smem zgubit" za 99,9..9% verjetnost, da ne zgubiš.

V resnici nikoli nimaš 100%, KyotoCabinet dela WAL in shadow paging, kar je dovolj dobro za tistih pet devetk na normalnem serverskem hardveru. Če potrebuješ še več konsistence reč postaviš na ZFS ali drug checksumming filesystem in je to to.

WarpedOne> Ko boš mel pa realtime okolje, bo pa stvar ckrnila ravno takrat, ko par zadev še ne bo prišlo do diska.

To drži vedno, ne glede na tehnologijo hranjenja.

Evo, se že spučajo zahteve.
Ko je treba plačat, so zahteve vedno nižje, kot dokler še ni bilo treba :)

Čakaj, ti v bistvu rabiš message queue?

Btw. MongoDB ni robusten pri scenarijih smrti procesa ker transakcije poola v memoriji.

Za message queue se je nam za precej robustno rešitev izkazal rabbitmq.

Performančno pravijo, da je ZeroMQ prava stvar.

Btw kunigunda ne da bi rinil vate, vendar če sem pravilno razumel tvoj usecase na vhodu dobivaš ogromen stream podatkov, katerega moraš obdržati pri življenju dokler ga ne sprocesiraš, potem ga pa lahko usmeriš v persistent storage?

Meni se zdi, da je to use case za message queue. Za KyotoTyrant si se pa odločil, ker rabiš "boljši" persistance?

Sprašujem pa zato, ker sam ravnokar implementiram MQ za obveščanje uporabnikov. Mail/SMS gre v queue, kjer počaka na svoj schedule, nakar ga dispatcher task odpošlje. Sicer sem tudi razmišljal o kaki NoSQL zadevi a sem se odločil, da probam z MQ.

Po drugi strani me pa zanima zakaj tebi ne ustreza MQ.

Sem jih ogromno sprobal Zaphod, skupno imajo to (Apache, Swift, Mantaray, Openjms, Sonic..) da prvih par dni delajo ok, potem se pa ze porajajo
problemi s timeouti (ne glede na pucanje queue-ja). Nisem pa testiral placljivih ker imam low-budget.

ZeroMQ mi je neki znano, se pa ne spomnim vec a je bil tud v igri takrat, sam zdej itak mam kar sem rabil :)

Oj, ja naceloma se po dva queuja uporabljata, dohodni in odhodni, ceprav lahko tudi preko enega delas (bodisi s flagi, ali celo preko topicov) Sam MQ je asinhron, sam proces ki ga jaz rabim pa ne, pri meni letijo notri requesti nakljucno, nobeden ne sme biti blocked, lahko se pa prvi se procesira, medtem ko sedmega celega pohendlam. Poleg tega mi ni ratalo resiti MQ z dual-node syncom. Detajlov sicer ne morem pisati, a je stvar se mnogo bolj kompleksna v samem procesu. ActiveMQ mi je pri single proces testih z nizko latenco odgovarjal, tja do 1000msg/s max. Je pa nekje po 30urah ze opazno upadla brzina zapisovanja v queue (test je bil tak da jih je nekje 500 vedno bilo v queueju istocasno).
SW ki ga delam je zlo obcutljiv in specificen, tko da moram vse vzeti v ozir (na trgu ni zastonj po 500k+ eur :P)

To maš trading platformo?