RedisGraph was released in beta mode six months ago. On the 14th of November, RedisLabs announced the general availability of RedisGraph v1.0.
RedisGraph is a Redis module that adds a graph database functionality to Redis. RedisGraph delivers a fast and efficient way to store, manage and process graphs, around 6 to 600 times faster than existing graph databases. RedisGraph represents connected data as adjacency matrices and employs the power of GraphBLAS which is a highly optimized library for sparse matrix operations.
How does RedisGraph Work?
Redis is a single-threaded process by default. RedisGraph is bound to the single thread of Redis and supports all incoming queries while including a threadpool that takes a configurable number of threads at the module’s loading time to handle higher throughputs. The queries are calculated in one of the threads of the threadpool. This means reads can scale and handle large throughput easily. Each query only runs in one thread.
This is what separates RedisGraph from other graph database implementations—which typically execute each query on all available cores of the machine. This makes RedisGraph more suitable for real-time and real-world use cases where high throughput and low latency under concurrent operations are important.
In RedisGraph, a write query ( that modifies the graph in any way ) must be executed in complete isolation. RedisGraph also ensures write/readers separation by using a read/write (R/W) lock. This means that either multiple readers can acquire the lock or just a single writer can write a query. The lock ensures that as long as a writer is executing, no one can acquire the lock, and as long as there’s a reader executing, no writer can obtain the lock.
Benchmarking RedisGraph
The team conducted a benchmark test on RedisGraph that proved the latter’s speed was more than other graph databases. They used a simple benchmark released by TigerGraph that covered the following:
- Data loading time
- Storage size of loaded data
- Query response time for k-hop neighborhood count
- Query response time for weakly connected components and page rank
The TigerGraph benchmark compared all other graph databases and reported TigerGraph to be 2-8000 times faster than any other graph database. The Redis team compared RedisGraph using the exact same setup. The test focused mainly on the k-hop neighborhood count query.
To test the result of concurrent operations, parallel requests were added to the TigerGraph benchmark. RedisGraph utilized just a single core and other graph databases were using up to 32 cores. ReddisGraph was faster in response times than any other graph database (with the exception of TigerGraph in the single request k-hop queries tests on the Twitter dataset).
The single request benchmark test and parallel request benchmark test also returned positive results for RedisGraph. In all the tests conducted, RedisGraph never timed out or generated out of memory exceptions.
RedisGraph shows performance improvements under load of 6 to 60 times faster than existing graph solutions for a large dataset (twitter dataset) and 20 to 65 times faster on a normal data set (graph500 dataset).
The benchmark also proves that RedisGraph outperforms Neo4j, Neptune, JanusGraph and ArangoDB on a single request response time with improvements almost 36 to 15,000 times faster. There were 2X and 0.8X faster single request response times as compared to TigerGraph.
Future improvements as listed by the team include:
- Performance improvements for aggregations and large result sets
- A faster version of GraphBLAS
- More Cypher clauses/functionality to support even more diverse queries
- Integration for graph visualization software
- LDBC benchmarking tests
You can head over to RedisLabs official Blog to know more about the benchmarking tests conducted.
Read Next
Introducing Web High Level Shading Language (WHLSL): A graphics shading language for WebGPU
Facebook’s GraphQL moved to a new GraphQL Foundation, backed by The Linux Foundation
2018 is the year of graph databases. Here’s why.