Lecture
All Redis data resides in the server's main memory, unlike
databases such as PostgreSQL, Cassandra, MongoDB and others,
which store most of their data on magnetic disks or SSD
drives. Compared to traditional disk-based databases,
which require a round-trip to disk for most
operations, in-memory data stores such as Redis are free of this
limitation. As a result, the number of operations performed
increases substantially and response time is reduced. This delivers
extremely high performance. Read or write operations
take less than a millisecond on average, and throughput
reaches millions of operations per second.
Unlike simplified key-value stores,
which support a limited set of data structures, Redis supports
a huge variety of data structures, allowing it to
meet the needs of various applications.
High speed is one of the key advantages of Redis, achieved by using main memory to store data. If data durability is not required, Redis can offer significantly better results compared to database management systems that persist every change to disk before completing a transaction. Redis can also efficiently perform read and write operations with no noticeable difference in speed. For example, during testing on a server with a Xeon X3320 2.5 GHz CPU, it was possible to achieve 110,000 write operations and 81,000 read operations per second. This makes Redis an excellent choice for tasks that require maximum performance and instant access to data, such as caching systems and other real-time scenarios. ➢
The data model in Redis is an associative array in which keys map to values. The main difference between Redis and other databases of this type is that dictionary values are not limited to string types. In addition to strings, the following abstract data types are supported: lists of strings, sets of strings (an unordered collection of non-repeating elements), sorted sets of strings (collections of non-repeating elements ordered by an associated floating-point value), and hashes, in which both keys and values are strings. The type of a value determines which operations can be performed on that value. Redis provides high-level atomic operations such as intersection, union and difference between sets and lists.
Powerful replication and distribution mechanisms establish Redis as an effective tool for scaling and ensuring reliability. Using the master-slave model for replication, Redis makes it possible to create duplicate copies of the data from any Redis server an arbitrary number of times. This approach is especially useful for scaling reads (but not writes) or for data redundancy. Redis 3.0 and later versions include Redis Cluster, which expands the system's capabilities for creating distributed data stores. It allows data to be automatically distributed across numerous nodes, facilitating the creation of fault-tolerant configurations where data is replicated across different nodes. This guarantees continuous availability even in the event of a single node failure, without bringing the system as a whole to a halt.
In addition, Redis is known for its ease of configuration, which makes it attractive to developers who value efficiency and minimal time spent on debugging.
A limitation to the amount of available memory is a significant drawback of Redis. This limitation leads to situations where Redis becomes less suitable for use cases in which storing all the information in main memory becomes costly and inefficient. This aspect may require careful planning and optimization of resource usage in order to achieve the best system performance.
Limited ability to execute complex queries. Oriented toward speed and simplicity of data operations, Redis may prove less effective when processing queries that require complex operations or analysis of data by intricate criteria. This limitation may pose a problem for projects where flexibility and advanced data-processing functionality are important. When choosing tools, developers should take this characteristic of Redis into account and select it for tasks where simplicity and speed are more important, or complement it with other solutions in cases where complex operations need to be performed. Even taking into account the presence of a replication mechanism that makes it possible to create copies of data on different servers, there is a risk of losing information if not all replicas have been successfully synchronized before the system is shut down. This can occur in the event of unforeseen errors or delays in the replication process. It is important to take this potential vulnerability into account when designing the system and developing backup strategies in order to prevent data loss in the event of emergencies or a forced system shutdown.
Limited security capabilities can lead to potential problems when exposing the server to public access. Redis does not always provide advanced means for data security, so it is important to be aware of this and take appropriate measures, such as using authentication to protect information. In large or critical projects, additional security measures and system configurations must be carefully considered in order to minimize possible risks . Consequently, Redis is a powerful database management system with a unique architecture and a number of advantages that determine its popularity among developers. High speed thanks to the use of main memory, a flexible data model, ease of configuration, as well as replication and distribution mechanisms make Redis an ideal choice for scenarios where performance and reliability are important. However, there are certain drawbacks, such as the limitation to the amount of memory, the execution of complex queries, and the risk
Finally, I suggest considering several database management systems that position themselves as more performant analogs of Redis: Dragonfly, KeyDB and Garnet. Moreover, these are not just analogs, but drop-in replacements — meaning that using them will not require any changes to the code or configuration. Let's figure out whether that is really the case!
DragonflyDB — one of the newest solutions on the market:
an in-memory database written in C++;
fully compatible with Redis, but not a fork of it;
a multithreaded architecture;
a full-fledged LRU rewritten from scratch based on the Dashtable algorithm — a 2Q implementation (Redis uses sampling).
On the vendor's website there are charts comparing Dragonfly and Redis, not in the latter's favor:
Judging by this data, Dragonfly outperforms Redis by an order of magnitude on both read and write operations. In reality, however, the team simply took a single-node Redis configuration and compared their system against it. But you and I know that such configurations are unsuitable for a production environment. For an objective comparison, you need to use a full-fledged fault-tolerant Redis cluster. In other words, this chart is not entirely accurate and was clearly created to promote the "dragonfly."
And what is it really like?
If we try to test the claimed drop-in replacement, we will discover that Dragonfly does not support keyspace notifications. And they are absolutely essential for solving many tasks.
Dragonfly still has no horizontal scaling. Its creators claim that this is an advantage: supposedly vertical scaling is more efficient. But all of our experience says the opposite: modern solutions should de facto scale horizontally.
The reaction of the Redis creators, in fact, did not take long to arrive: they conducted their own comparison, using a full-fledged Redis cluster for it and writing tests that made use of pipelining mechanics. And — lo and behold! — the results turned out to be completely different:
KeyDB has been under active development since 2019 and is essentially a multithreaded fork of Redis.
"under the hood" it is still the same multithreaded architecture;
the claimed performance gain is 5x (compared to a single-node Redis configuration);
compatible with Redis as a drop-in replacement;
its own replication implementation (Active Replica, Multi-master).
It looks great, but then why hasn't everyone run off to KeyDB and why do they keep using Redis? The thing is that both implementations of the fault-tolerant topology are, to put it mildly, not the most reliable.
If you look at other criteria, it becomes clear why KeyDB never became a full-fledged replacement for Redis:
Garnet. This Redis alternative from Microsoft was released quite recently, but is already generating interest:
it is an open-source cache store under the MIT license;
written in C#;
its own multithreaded engine, Tsavorite (a fork of Microsoft's FASTER storage);
storage is split into two: the main store (for strings) and the object store (for complex objects);
all data resides in the C# heap;
compatible with Redis as a drop-in replacement.
Microsoft also compared their product with its counterparts and produced a chart. Credit where it's due — for the analysis they applied pipelining. The results are impressive: Garnet really does outperform its competitors on many metrics and may in the future even replace Redis.
Redis simplifies code by allowing you to write fewer lines to store,
use data and organize access to data in applications.
For example, if an application contains data stored in a hash
table, and you need to save this data to a store, you can simply
use the Redis hash-table data structure. Solving
such a task using a data store that does not support the hash-table
structure would require writing a considerable amount of code
to convert the data from one format to another. Redis already
comes equipped with built-in data structures and provides numerous
ways to combine them and interact with the client's data.
Developers working with Redis have access to more than a hundred open-source
clients. Supported programming languages include Java, Python, PHP,
C, C++, C#, JavaScript, Node.js, Ruby, R, Go and many others.
Comments