[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-10450":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":9,"htmlUrl":10,"language":11,"languages":10,"totalLinesOfCode":10,"stars":12,"forks":13,"watchers":14,"openIssues":15,"contributorsCount":16,"subscribersCount":16,"size":16,"stars1d":16,"stars7d":17,"stars30d":18,"stars90d":16,"forks30d":16,"starsTrendScore":16,"compositeScore":19,"rankGlobal":10,"rankLanguage":10,"license":20,"archived":21,"fork":21,"defaultBranch":22,"hasWiki":23,"hasPages":21,"topics":24,"createdAt":10,"pushedAt":10,"updatedAt":33,"readmeContent":34,"aiSummary":35,"trendingCount":16,"starSnapshotCount":16,"syncStatus":36,"lastSyncTime":37,"discoverSource":38},10450,"rosedb","rosedblabs\u002Frosedb","rosedblabs","Lightweight, fast and reliable key\u002Fvalue storage engine based on Bitcask.","https:\u002F\u002Frosedblabs.github.io",null,"Go",4883,646,39,3,0,1,4,61.33,"Apache License 2.0",false,"main",true,[25,26,27,28,29,30,31,5,32],"data-structures","database","embedded","go","golang","key-value","kv-store","throughput","2026-06-12 04:00:50","\u003Cdiv align=\"center\">\n\u003Cstrong>\n\u003Csamp>\n\n[English](https:\u002F\u002Fgithub.com\u002Frosedblabs\u002Frosedb\u002Fblob\u002Fmain\u002FREADME.md) · [简体中文](https:\u002F\u002Fgithub.com\u002Frosedblabs\u002Frosedb\u002Fblob\u002Fmain\u002FREADME-CN.md)\n\n\u003C\u002Fsamp>\n\u003C\u002Fstrong>\n\u003C\u002Fdiv>\n\n## What is ROSEDB\n\nrosedb is a lightweight, fast and reliable key\u002Fvalue storage engine based on [Bitcask](https:\u002F\u002Friak.com\u002Fassets\u002Fbitcask-intro.pdf) storage model.\n\nThe design of Bitcask was inspired, in part, by log-structured filesystems and log file merging.\n\n## Status\nrosedb is well tested and ready for production use. There are serveral projects using rosedb in production as a storage engine.\n\n**Didn't find the feature you want? Feel free to open an issue or PR, we are in active development.**\n\n## Design overview\n\n![](https:\u002F\u002Fgithub.com\u002Frosedblabs\u002Frosedb\u002Fblob\u002Fmain\u002Fdocs\u002Fimgs\u002Fdesign-overview-rosedb.png)\n\nRoseDB log files are using the WAL(Write Ahead Log) as backend, which are append-only files with multiple blocks.\n\n> wal: https:\u002F\u002Fgithub.com\u002Frosedblabs\u002Fwal\n\n## Key features\n\n### Strengths\n\n\u003Cdetails>\n    \u003Csummary>\u003Cb>Low latency per item read or written\u003C\u002Fb>\u003C\u002Fsummary>\n    This is due to the write-once, append-only nature of Bitcask database files.\n\u003C\u002Fdetails>\n\n\u003Cdetails>\n    \u003Csummary>\u003Cb>High throughput, especially when writing an incoming stream of random items\u003C\u002Fb>\u003C\u002Fsummary>\n    Write operations to RoseDB generally saturate I\u002FO and disk bandwidth, which is a good thing from a performance perspective. This saturation occurs for two reasons: because (1) data that is written to RoseDB doesn't need to be ordered on disk, and (2) the log-structured design of Bitcask allows for minimal disk head movement during writes.\n\u003C\u002Fdetails>    \n\n\u003Cdetails>\n    \u003Csummary>\u003Cb>Ability to handle datasets larger than RAM without degradation\u003C\u002Fb>\u003C\u002Fsummary>\n    Access to data in RoseDB involves direct lookup from an in-memory index data structure. This makes finding data very efficient, even when datasets are very large.\n\u003C\u002Fdetails>\n\n\u003Cdetails>\n    \u003Csummary>\u003Cb>Single seek to retrieve any value\u003C\u002Fb>\u003C\u002Fsummary>\n    RoseDB's in-memory index data structure of keys points directly to locations on disk where the data lives. RoseDB never uses more than one disk seek to read a value and sometimes even that isn't necessary due to filesystem caching done by the operating system.\n\u003C\u002Fdetails>\n\n\u003Cdetails>\n    \u003Csummary>\u003Cb>Predictable lookup and insert performance\u003C\u002Fb>\u003C\u002Fsummary>\n    For the reasons listed above, read operations from RoseDB have fixed, predictable behavior. This is also true of writes to RoseDB because write operations require, at most, one seek to the end of the current open file followed by and append to that file.\n\u003C\u002Fdetails>\n\n\u003Cdetails>\n    \u003Csummary>\u003Cb>Fast, bounded crash recovery\u003C\u002Fb>\u003C\u002Fsummary>\n    Crash recovery is easy and fast with RoseDB because RoseDB files are append only and write once. The only items that may be lost are partially written records at the tail of the last file that was opened for writes. Recovery operations need to review the record and verify CRC data to ensure that the data is consistent.\n\u003C\u002Fdetails>\n\n\u003Cdetails>\n    \u003Csummary>\u003Cb>Easy Backup\u003C\u002Fb>\u003C\u002Fsummary>\n    In most systems, backup can be very complicated. RoseDB simplifies this process due to its append-only, write-once disk format. Any utility that archives or copies files in disk-block order will properly back up or copy a RoseDB database.\n\u003C\u002Fdetails>\n\n\u003Cdetails>\n    \u003Csummary>\u003Cb>Batch options which guarantee atomicity, consistency, and durability\u003C\u002Fb>\u003C\u002Fsummary>\n\tRoseDB supports batch operations which are atomic, consistent, and durable. The new writes in batch are cached in memory before committing. If the batch is committed successfully, all the writes in the batch will be persisted to disk. If the batch fails, all the writes in the batch will be discarded.\n\u003C\u002Fdetails>\n\n\u003Cdetails>\n    \u003Csummary>\u003Cb>Support iterator for forward and backward\u003C\u002Fb>\u003C\u002Fsummary>\n\tRoseDB supports iterator for forward and backward. The iterator is based on the in-memory index data structure of keys, which points directly to locations on disk where the data lives. The iterator is very efficient, even when datasets are very large.\n\u003C\u002Fdetails>\n\n\u003Cdetails>\n    \u003Csummary>\u003Cb>Support key watch\u003C\u002Fb>\u003C\u002Fsummary>\n\tRoseDB supports key watch, you can get the notification if keys changed in db.\n\u003C\u002Fdetails>\n\n\u003Cdetails>\n    \u003Csummary>\u003Cb>Support key expire\u003C\u002Fb>\u003C\u002Fsummary>\n\tRoseDB supports key expire, you can set the expire time for keys.\n\u003C\u002Fdetails>\n\n### Weaknesses\n\n\u003Cdetails>\n    \u003Csummary>\u003Cb>Keys must fit in memory\u003C\u002Fb>\u003C\u002Fsummary>\n    RoseDB keeps all keys in memory at all times, which means that your system must have enough memory to contain your entire keyspace, plus additional space for other operational components and operating- system-resident filesystem buffer space.\n\u003C\u002Fdetails>\n\n## Gettings Started\n\n### Basic operations\n\n```go\npackage main\n\nimport \"github.com\u002Frosedblabs\u002Frosedb\u002Fv2\"\n\nfunc main() {\n\t\u002F\u002F specify the options\n\toptions := rosedb.DefaultOptions\n\toptions.DirPath = \"\u002Ftmp\u002Frosedb_basic\"\n\n\t\u002F\u002F open a database\n\tdb, err := rosedb.Open(options)\n\tif err != nil {\n\t\tpanic(err)\n\t}\n\tdefer func() {\n\t\t_ = db.Close()\n\t}()\n\n\t\u002F\u002F set a key\n\terr = db.Put([]byte(\"name\"), []byte(\"rosedb\"))\n\tif err != nil {\n\t\tpanic(err)\n\t}\n\n\t\u002F\u002F get a key\n\tval, err := db.Get([]byte(\"name\"))\n\tif err != nil {\n\t\tpanic(err)\n\t}\n\tprintln(string(val))\n\n\t\u002F\u002F delete a key\n\terr = db.Delete([]byte(\"name\"))\n\tif err != nil {\n\t\tpanic(err)\n\t}\n}\n```\n\n### Batch operations\n\n```go\n\t\u002F\u002F create a batch\n\tbatch := db.NewBatch(rosedb.DefaultBatchOptions)\n\n\t\u002F\u002F set a key\n\t_ = batch.Put([]byte(\"name\"), []byte(\"rosedb\"))\n\n\t\u002F\u002F get a key\n\tval, _ := batch.Get([]byte(\"name\"))\n\tprintln(string(val))\n\n\t\u002F\u002F delete a key\n\t_ = batch.Delete([]byte(\"name\"))\n\n\t\u002F\u002F commit the batch\n\t_ = batch.Commit()\n```\n\nsee the [examples](https:\u002F\u002Fgithub.com\u002Frosedblabs\u002Frosedb\u002Ftree\u002Fmain\u002Fexamples) for more details.\n\n## Community\nWelcome to join the [Slack](https:\u002F\u002Fjoin.slack.com\u002Ft\u002Frosedblabs\u002Fshared_invite\u002Fzt-19oj8ecqb-V02ycMV0BH1~Tn6tfeTz6A) channel and [Discussions](https:\u002F\u002Fgithub.com\u002Forgs\u002Frosedblabs\u002Fdiscussions) to connect with RoseDB team developers and other users.\n\n## Contributors\n[![](https:\u002F\u002Fopencollective.com\u002Frosedb\u002Fcontributors.svg?width=890&button=false)](https:\u002F\u002Fgithub.com\u002Frosedblabs\u002Frosedb\u002Fgraphs\u002Fcontributors)\n","ROSEDB 是一个基于 Bitcask 存储模型的轻量级、快速且可靠的键值存储引擎。它采用写前日志（WAL）作为后端，支持高吞吐量的数据写入，尤其适用于大量随机数据流的写入场景，并且能够处理超出内存大小的数据集而不会导致性能下降。ROSEDB 的设计使得每次读写操作都具有低延迟和可预测的性能表现，单次磁盘寻道即可完成任意值的检索。此外，由于其文件是追加写入且仅写一次的特点，ROSEDB 还能提供快速且有界的崩溃恢复能力。该项目适合需要高性能键值存储的应用场景，如缓存系统、消息队列或实时数据分析平台等。",2,"2026-06-11 03:28:38","top_topic"]