Kronotop is a new open-source database designed as a Redis-compatible, transactional document store built on top of FoundationDB. It aims to offer the familiar interface and ease-of-use of Redis, combined with the strong consistency, scalability, and fault tolerance provided by FoundationDB. Kronotop supports a subset of Redis commands, including string, list, set, hash, and sorted set data structures, along with multi-key transactions ensuring atomicity and isolation. This makes it suitable for applications needing both the flexible data modeling of a document store and the robust guarantees of a distributed transactional database. The project emphasizes performance and is actively under development.
rqlite's testing strategy employs a multi-layered approach. Unit tests cover individual components and functions. Integration tests, leveraging Docker Compose, verify interactions between rqlite nodes in various cluster configurations. Property-based tests, using Hypothesis, automatically generate and run diverse test cases to uncover unexpected edge cases and ensure data integrity. Finally, end-to-end tests simulate real-world scenarios, including node failures and network partitions, focusing on cluster stability and recovery mechanisms. This comprehensive testing regime aims to guarantee rqlite's reliability and robustness across diverse operating environments.
HN commenters generally praised the rqlite testing approach for its simplicity and reliance on real-world SQLite. Several noted the clever use of Docker to orchestrate a realistic distributed environment for testing. Some questioned the level of test coverage, particularly around edge cases and failure scenarios, and suggested adding property-based testing. Others discussed the benefits and drawbacks of integration testing versus unit testing in this context, with some advocating for a more balanced approach. The author of rqlite also participated, responding to questions and clarifying details about the testing strategy and future plans. One commenter highlighted the educational value of the article, appreciating its clear explanation of the testing process.
Summary of Comments ( 1 )
https://news.ycombinator.com/item?id=42771403
HN commenters generally expressed interest in Kronotop, praising its use of FoundationDB for its robustness and the project's potential. Some questioned the need for another database when Redis already exists, suggesting the value proposition wasn't entirely clear. Others compared it favorably to Redis' JSON support, highlighting Kronotop's transactional nature and ACID compliance as significant advantages. Performance concerns were raised, with a desire for benchmarks to compare it to existing solutions. The project's early stage was acknowledged, leading to discussions about potential feature additions like secondary indexes and broader API compatibility. The choice of Rust was also lauded for its performance and safety characteristics.
The Hacker News post titled "Kronotop: Redis-compatible, transactional document store backed by FoundationDB" generated a moderate amount of discussion, with several commenters expressing interest and raising relevant questions.
Several commenters focused on the choice of FoundationDB as the backing store. One questioned why FoundationDB was chosen over something simpler like SQLite, prompting a response from the project author explaining that FoundationDB provides distributed consistency and scalability, crucial for the intended use cases of Kronotop. The author also clarified that while starting with a simpler backing store might seem easier, it would eventually become a limitation. This exchange highlighted the project's emphasis on robust scalability and fault tolerance.
Another commenter expressed curiosity about the compatibility layer with Redis and whether it was challenging to implement. The author responded, detailing that the Redis protocol's simplicity made the implementation relatively straightforward, though managing client connections efficiently was a key aspect of their work. They elaborated on their use of Tokio and the complexities of handling multiple simultaneous connections within that framework.
Further discussion centered on the specific features of Kronotop and their potential applications. The transactional nature of the database garnered attention, with users exploring use cases where data integrity is paramount. Questions about data modeling and querying capabilities were raised, with the author outlining their approach to document storage and retrieval. They clarified that Kronotop utilizes JSON for document representation and supports a subset of Redis commands.
Performance and benchmarking were also topics of interest, with one commenter suggesting a comparison with existing Redis implementations. While acknowledging the value of such benchmarks, the author stated that their current focus was on stability and feature completeness. They indicated that formal benchmarking would be a future priority.
The project's open-source nature and the invitation for community contributions were welcomed by several commenters. The overall tone of the discussion was positive, with a general sense of intrigue surrounding Kronotop's potential and the novel approach of combining Redis compatibility with the robustness of FoundationDB.