4 ms·
>Keep it simple, stupid. No support for transactions, versioning or snapshots -- anything that can be done outside of the store should be done outside. Not sur
by aphextron 9y ago
>Keep it simple, stupid. No support for transactions, versioning or snapshots -- anything that can be done outside of the store should be done outside.
Not sure how I feel about that philosophy. Transaction support is extremely complex and should be left to a storage engine if ever possible.
What is the benefit of this over something like Berkeley DB?
- mrjn 9y agoThe reason we want to KISS is to ensure a solid, robust, and performant layer of storage, that other projects can use to build their transactional versions, etc. One can take Badger and build a transactional layer above it, and it would still be below the application layer.
- foodie_ 9y agoWhy would one want to though? (edit) as in why choose this and invest hundreds (thousands?) of development hours doing so. What ROI would support this?
- true_religion 9y agoBecause you were already committed to building a database yourself, so RockDB saves you time in building the base layer. Transaction support comes with a set of performance compromises, and different companies may want to make different compromises.
- maxpert 9y ago> The reason we want to KISS is to ensure a solid, robust, and performant layer of storage, that other projects can use to build their transactional versions, etc. Then comparing it to Rocks DB is unfair (infact title of this post is misleading). Stuff like transactions and MVCC is way complicated than it sounds.
- mrjn 9y agoIt's not. The comparison is using the same APIs as provided by LevelDB/RocksDB. Not the transactional ones mentioned below. TransactionDB* txn_db; Status s = TransactionDB::Open(options, path, &txn_db); Transaction* txn = txn_db->BeginTransaction(write_options, txn_options); s = txn->Put(“key”, “value”); s = txn->Delete(“key2”); s = txn->Merge(“key3”, “value”); s = txn->Commit(); delete txn;
- deleted 9y ago[deleted]