i just discovered a new thing that is newer than dgraph.io badger key/value store
https://github.com/egotist0/SLM-DB
the wisckey paper made a design change to log structured merge-tree database designs (like rocksdb and leveldb and all their related forks) by separating the key and value data structures, the reason being that updating the keys all the time when only the values were changing creates a feedback effect called "write amplification" and by splitting the tables, the iterations become faster and the compaction of the value log becomes cheaper
the feature list is pretty self explanatory why it might be a better option (and badger really is a lot better, but i feel like with age it's got crufty):
- Maintains an in-memory B+ tree to store record file IDs and offsets, enabling fast queries and range queries.- Supports sequential and append writes similar to LevelDB to ensure high performance for bulk data writes.- Implements a write-ahead log to ensure data durability.- Uses a multi-level memtable based on Skiplist to guarantee O(log N) query performance.- Implements a single-level SSTable and uses selective compaction to manage garbage collection.
i'm quite used to using badger now, and i understand enough about how it works to see that this might be substantially better, being that it is another, recently updated and ongoing maintained project
i'm just gonna see if i like the API anyhows, before i decide i'm not a badger maxi anymore
mleku / mleku™️
npub1fj…mleku
2024-09-06 23:00:10
Author Public Key
npub1fjqqy4a93z5zsjwsfxqhc2764kvykfdyttvldkkkdera8dr78vhsmmlekuPublished at
2024-09-06 23:00:10Event JSON
{
"id": "4becaf9af7513c71d1e50c50e3278f0561f076deec4e8f9080b7e43758e356a4",
"pubkey": "4c800257a588a82849d049817c2bdaad984b25a45ad9f6dad66e47d3b47e3b2f",
"created_at": 1725656410,
"kind": 1,
"tags": [
[
"client",
"Coracle",
"31990:97c70a44366a6535c145b333f973ea86dfdc2d7a99da618c40c64705ad98e322:1685968093690"
]
],
"content": "i just discovered a new thing that is newer than dgraph.io badger key/value store\n\nhttps://github.com/egotist0/SLM-DB\n\nthe wisckey paper made a design change to log structured merge-tree database designs (like rocksdb and leveldb and all their related forks) by separating the key and value data structures, the reason being that updating the keys all the time when only the values were changing creates a feedback effect called \"write amplification\" and by splitting the tables, the iterations become faster and the compaction of the value log becomes cheaper\n\nthe feature list is pretty self explanatory why it might be a better option (and badger really is a lot better, but i feel like with age it's got crufty):\n\n - Maintains an in-memory B+ tree to store record file IDs and offsets, enabling fast queries and range queries.- Supports sequential and append writes similar to LevelDB to ensure high performance for bulk data writes.- Implements a write-ahead log to ensure data durability.- Uses a multi-level memtable based on Skiplist to guarantee O(log N) query performance.- Implements a single-level SSTable and uses selective compaction to manage garbage collection.\n\ni'm quite used to using badger now, and i understand enough about how it works to see that this might be substantially better, being that it is another, recently updated and ongoing maintained project\n\ni'm just gonna see if i like the API anyhows, before i decide i'm not a badger maxi anymore",
"sig": "874a59ebf609724665938c90171b8484f46bc5cc093d6cb3acad52b7ff0511db824090225f9aea4798bd4f1f55dc74fa9c01fc762ee077aa713a6fc49d49fd6a"
}