We have recently introduced EloqKV, our distributed database product built on a cutting-edge architecture known as Data Substrate. Over the past several years, the EloqData team has worked tirelessly to develop this software, ensuring it meets the highest standards of performance and scalability. One key detail we’d like to share is that the majority of EloqKV’s codebase was written in C++.
In the previous blog, we discussed the durable feature of EloqKV and benchmarked the write performance of EloqKV with the Write-Ahead-Log enabled. In this blog, we will continue to explore the transaction capabilities of EloqKV and benchmark the performance of distributed atomic operations using the Redis MULTI EXEC commands.
In our previous blogs, we benchmarked EloqKV in memory cache mode, discussing both single node and cluster performances. In this post, we we benchmark EloqKV with durability enabled.
In our previous blog, we benchmarked EloqKV to evaluate it as an in-memory cache, focusing on single-node performance. In this blog, we shift our attention to Eloq clustering and discuss why it provides a fundmentally better solution.
In this blog, we evaluate EloqKV as an in-memory cache, focusing on its single-node performance. We compare EloqKV with Redis, a widely used in-memory data store, and DragonflyDB, a newer option boasting high performance due to its multi-threaded architecture and optimized implementation leveraging modern innovations.
We’re thrilled to introduce EloqKV, a high performance Redis API-compatible, ACID transactional, scalable, distributed key-value database. You might be thinking, “Really? Another key-value database?” In this post, we’ll explain what makes EloqKV stand out and the unique values EloqKV offers.
In this blog post, we introduce our transformative concept Data Substrate. Data Substrate abstracts core functionality in online transactional databases (OLTP) and provides a unified layer for CRUD operations of any data models. A database built on this unified layer is modular: a database module is optional, can be replaced and can scale up/out independently of other modules.