RedisGears Glossary ¶
Redis is an ...
... open source (BSD licensed), in-memory data structure store, used as a database, cache and message broker. It supports data structures such as strings, hashes, lists, sets, sorted sets with range queries, bitmaps, hyperloglogs, geospatial indexes with radius queries, and streams. Redis has built-in replication, Lua scripting, LRU eviction, transactions, and different levels of on-disk persistence, and provides high availability via Redis Sentinel and automatic partitioning with Redis Cluster.
Redis is also...
An acronym for RE mote DI ctionary S erver that's pronounced "red" like the colour, then "iss".
A Redis module is a shared library that can be loaded by the Redis server during runtime. Redis modules extend Redis with new data types and commands.
You can learn more about Redis modules at:
A Redis client is a piece of software you use to interact with Redis. All Redis clients speak the Redis Protocol .
For a complete list of clients, refer to:
An instruction sent to the Redis server by a client. Both Redis and Redis modules implement commands.
Refer to these pages for more information about:
Zeros and ones that make up for everything. Usually stored in Redis, but can also be obtained from other sources.
Data Flow ¶
A logical operation that processes input data in some form and may consist of several steps.
Data Type ¶
Redis stores data in structures that implement different types and the API to manipulate their contents. Types can be added by modules, and the core Redis server provides support for Strings, Hashes, Lists, Sets, Sorted Sets and Streams.
Refer to these pages for more information about Redis' core types:
An event is a signal that the RedisGears engine can intercept and react to by triggering the execution of an event-driven processing function.
A RedisGears component in charge of the execution of functions. The engine executes locally on each of the cluster's shards.
A RedisGears component that handles cluster communication and data shuffling.
A cluster is a deployment option for Redis in which the database is partitioned across multiple shards in a shared-nothing fashion. Partitioning is done by hashing key names to slots.
More about the Redis cluster:
A node is a physical (or virtualized) server in a cluster. Each node can be used for hosting one or more shards.
A shard is a Redis server process that runs on one of the cluster's nodes and manages an exclusive subset of slots in the Redis keyspace. Every slot is managed by a single master shard. Master shards accepts writes and can optionally be configured with replicas for scaling read throughput and increasing availability.
RedisGears functions can be programmed via applicative interfaces. RedisGears provides a public Python API. RedisGears also provides a C API, which can be used internally by other Redis modules.
A RedisGears function is a an implementation of the processing steps in a data flow.
A function always:
- Starts with a reader
- Operates on zero or more records
- Consists of zero or more operations (steps)
- Ends with an action
- Returns zero or more results
Refer to the Functions page for a complete reference about functions.
A RedisGears reader is the mandatory first step of any function. Every function has exactly one reader. A reader reads data and generates input records from it. The input records are consumed by the function.
Refer to the Readers page for a complete reference about the various reader types and their operation.
A RedisGears record is the basic abstraction that represents data in the function's flow. Input data records are passed from one step to the next and are finally returned as the result.
An operation is the building block of RedisGears functions. Different operation types can be used to achieve a variety of results to meet various data processing needs.
Refer to the Operations page for a complete reference about the different operation types and their purpose.
A RedisGears function flow step is a term that's almost always interchangeable with "operation".
An action is special type of operation that is always the function's final step. There are two types of actions:
- Run : runs the function immediately in batch
- Register : registers the function's execution to be triggered by an event
Actions are described at the Functions page .
The result of a function is the set of output records it produces after executing.
Results are described at the Functions page .
An execution is a single run of a RedisGears function. Every execution is uniquely identified by an ID, and every execution consists of the results, errors, and other information generated while executing.
Executions are described at the Functions page .
A RedisGears registration is a stored function that is triggered by events.
Registrations are described at the Functions page .
A RedisGears session is an entity that is shared between all the executions and registrations created on the same RG.PYEXECUTE command. A session maintains everything that it created and dropped when all the registrations and execution that belongs to has dropped. It is possible to see information about sessions using RG.PYDUMPSESSIONS command.
In the context of a clustered environment, the initiator is the shard's engine in which a function is originally executed.
In the context of a clustered environment, a worker is any shard that isn't the initiator.
Batch Processing ¶
A RedisGears function is executed as a batch when it is run immediately on existing data.
Batch execution is always asynchronous. By default, the client executing the function is blocked until execution is finished. Once finished, RedisGears unblocks the client and returns any results or errors.
Event Processing ¶
A RedisGears function is executed as an event when it is registered to be triggered by events.
A framework for performing distributed data processing.
A RedisGears recipe is a collection of functions and their dependencies. A recipe typically implements a complex procedure, such as write-behind. You can think of a recipe as a "project".