|
|
|
|
|
by AtlasBarfed
573 days ago
|
|
Lsms and sstables involve compaction in all data write patterns that involve updates or deletes. I don't know how Rockdb handles this, but this is a very very non-trivial problem in Cassandra. Let's say your update spans a row of data that is stored across multiple sstables (the row of data, that is a set of column values, was formed in multiple updates that spanned multiple flushes of the mentable to disk/sstables. So either as part of your update you will be compacting that is rewriting multiple SS tables of unknown size, possibly very large into a new SS table with the new updates, or you must employ some means of time stamping the individual values or in the case of deletes employing something like tombstones or delete markers or timestamps Then your reed engine needs to be able to read multiple SS tables and apply update ordering in order to find the most recent actual value. This results in Io stress and reduced performance in the read path. Lsms exist to scale writes to large indexes. Essentially what you were doing is you are queuing up the updates for a future process (compaction) to clean up. |
|