5 ms·
Well, the data never leave JVM, that is why it is so "fast" - it never fsyncs. What if JVM instance crash under load? Data lose, but, see, it is not our fault
by dschiptsov 14y ago
Well, the data never leave JVM, that is why it is so "fast" - it never fsyncs.
What if JVM instance crash under load? Data lose, but, see, it is not our fault - our code is OK.
- ajross 14y agoThe idea behind RAM-based databases is that the data is inherently redundant. If it crashes under load the rest of the cluster still has the data. I don't know HBase well at all, but clearly no one sane would argue for a "database" which held data in DRAM on a single host.
- deleted 14y ago[deleted]
- deleted 14y ago[deleted]
- crypto5 14y agoNot exactly. Cassandra writes commit log, and if JVM will crash, cassandra will repair data from that log.
- dschiptsov 14y agohow often it fsyncs that log?
- crypto5 14y agoIt can be configured: http://wiki.apache.org/cassandra/Durability http://wiki.apache.org/cassandra/Durability One option is to fsync changes before telling client that operation is succeeded.
- dschiptsov 14y agoAnd get what benchmarks?)
- crypto5 14y agoBenchmark will be not so good, but do you have better choice?