in-memory hash table implementation with AOF persistence and versioning via point-in-time snapshotting supporting rollbacks and querying past states.
This is implementation of how transaction ensures atomicity and durability in databases via write ahead logging and by maintaining multiple versions of the database consistent state. Here, it uses hash table as it's data store, which stores key-value pairs in the memory. Before writing to hash table, it logs first the PUT/DELETE operations to append only file in JSON format. It uses mutex(mutual exclusion) lock to ensure our writes to log are atomic, ensuring sort of software implementation of write ahead log as stable storage. On commit, it creates binary snapshot out of key-value pairs buffered in the memory hash table and assign a version no. to it, and save it a binary file with {version}.snap naming scheme. On successful commit, we clear the log file by truncating it to size of 0.
If the program crashes or gets terminated intentionally or unintentionally and after some time if we restart the program, it will fetch the current version of database state from the snapshot file by deserializing and buffering the memory with key-value pairs, then we can replay the log file to fetch the uncommitted/new changes, after the last commit.
- In-memory storage using a Go map
- Thread safe operations via mutex locking.
- write ahead logging of put/delete operations to Append Only File(AOF).
- Binary serialization/deserialization of current snapshot state.
- Versioning to support rollbacks and querying past states.
- Replay writes in case of crash
- Start from latest state in case of restart
- Viper based configuration management
