Hello everyone!
Welcome to review my Capstone project for RustCamp (GitHub - rust-lang-ua/rustcamp: Getting ready for prod).
ZeroCache is a fast cache server with full-text search capabilities that combines the simplicity of JSON key-value storage. Built for speed and ease of use.
1 Like
This appears to be a diffrent capstone than the well known disassembler GitHub - capstone-engine/capstone: Capstone disassembly/disassembler framework for ARM, ARM64 (ARMv8), Alpha, BPF, Ethereum VM, HPPA, LoongArch, M68K, M680X, Mips, MOS65XX, PPC, RISC-V(rv32G/rv64G), SH, Sparc, SystemZ, TMS320C64X, TriCore, Webassembly, XCore and X86. (with Rust bindings at GitHub - capstone-rust/capstone-rs: High-level Capstone system bindings for Rust)? I'm confused as to what you are talking about.
Yes, you're absolutely right - this is a completely different project!
The name "Capstone project" here refers to a final bootcamp project (GitHub - rust-lang-ua/rustcamp: Getting ready for prod), not the Capstone disassembly framework.
My ZeroCache is a cache server: GitHub - brenik/ZeroCache: In-memory JSON cache server with HTTP API and memory-mapped persistence
Sorry for the confusion with the naming! 
This feature comparison makes ZeroCache look amazing, but there's no such thing as a free lunch.
What tradeoffs did you make to support things like ACID transactions and full text search while still being as fast as Redis?
2 Likes
They probably mean a capstone project, like a senior project but more industry-oriented and less academia-oriented.
Seems so. I had never heard that term. But Wikipedia seems to indicate it is a US thing, so that is hardly surprising. Here it would be known as "final project" or (in academia) "thesis".
The entire code base is one humongous PR in three commits on a hello world project. This is a huge red flag for me.
4 Likes
This is the first working version without the hundreds of comments and bugs that I don’t want to make public in my own project.
I don’t consider my project a competitor to Redis. My project has slightly different goals.
But for me, such benchmark results are a victory.
It wasn’t easy, and it didn’t work on the first try.
The first attempts to implement this idea consumed 40–60 GB of RAM when inserting 100,000 items.
But I managed to find the golden balance between the required functionality and speed.
It’s simple here. Quickly return a value that lives in RAM, which is indexed, by removing all unnecessary obstacles.
The main use case is in JavaScript, for fast data retrieval for a web page.
@brenik
Sorry for my comment, I didn't see the pr...