diff --git a/content/commands/command.md b/content/commands/command.md index 14267822c9..60f7487e41 100644 --- a/content/commands/command.md +++ b/content/commands/command.md @@ -101,7 +101,7 @@ Command flags are an array. It can contain the following simple strings (status * **no_auth:** executing the command doesn't require authentication. * **no_async_loading:** the command is denied during asynchronous loading (that is when a replica uses disk-less `SWAPDB SYNC`, and allows access to the old dataset). * **no_mandatory_keys:** the command may accept key name arguments, but these aren't mandatory. -* **no_multi:** the command isn't allowed inside the context of a [transaction]({{< relref "/develop/reference/transactions" >}}). +* **no_multi:** the command isn't allowed inside the context of a [transaction]({{< relref "develop/using-commands/transactions" >}}). * **noscript:** the command can't be called from [scripts]({{< relref "/develop/programmability/eval-intro" >}}) or [functions]({{< relref "/develop/programmability/functions-intro" >}}). * **pubsub:** the command is related to [Redis Pub/Sub]({{< relref "/develop/pubsub" >}}). * **random**: the command returns random results, which is a concern with verbatim script replication. diff --git a/content/commands/scan.md b/content/commands/scan.md index 2228bceffa..4387baaee2 100644 --- a/content/commands/scan.md +++ b/content/commands/scan.md @@ -286,7 +286,7 @@ Also note that this behavior is specific of [`SSCAN`]({{< relref "/commands/ssca ## Further reading -For more information about managing keys, please refer to the [The Redis Keyspace]({{< relref "/develop/keyspace" >}}) tutorial. +For more information about managing keys, please refer to the [The Redis Keyspace]({{< relref "/develop/using-commands/keyspace" >}}) tutorial. ## Additional examples diff --git a/content/develop/ai/search-and-query/best-practices/index-mgmt-best-practices.md b/content/develop/ai/search-and-query/best-practices/index-mgmt-best-practices.md index 4233dae684..68b84d51ad 100644 --- a/content/develop/ai/search-and-query/best-practices/index-mgmt-best-practices.md +++ b/content/develop/ai/search-and-query/best-practices/index-mgmt-best-practices.md @@ -150,7 +150,7 @@ Monitoring and troubleshooting aliases: ## Index maintenance - If schema changes are required, create a new index with the updated schema and reassign the alias once the index is ready. -- Use [Redis key expiration]({{< relref "/develop/keyspace#key-expiration" >}}) to automatically remove outdated records and keep indexes lean. +- Use [Redis key expiration]({{< relref "/develop/using-commands/keyspace#key-expiration" >}}) to automatically remove outdated records and keep indexes lean. ### FT.ALTER vs. aliasing diff --git a/content/develop/clients/dotnet/condexec.md b/content/develop/clients/dotnet/condexec.md index 2c53a84855..f601e06ce1 100644 --- a/content/develop/clients/dotnet/condexec.md +++ b/content/develop/clients/dotnet/condexec.md @@ -17,7 +17,7 @@ weight: 60 Most Redis client libraries use transactions with the [`WATCH`]({{< relref "/commands/watch" >}}) command as the main way to prevent -two clients writing to the same key at once (see [Transactions]({{< relref "/develop/reference/transactions" >}}) for more information). Unfortunately, this approach is +two clients writing to the same key at once (see [Transactions]({{< relref "develop/using-commands/transactions" >}}) for more information). Unfortunately, this approach is difficult to use explicitly in `NRedisStack`. Its [multiplexing]({{< relref "/develop/clients/pools-and-muxing" >}}) system is highly efficient and convenient but can also cause bad interactions diff --git a/content/develop/clients/dotnet/transpipe.md b/content/develop/clients/dotnet/transpipe.md index 4e4f1c2a16..65e2d5e875 100644 --- a/content/develop/clients/dotnet/transpipe.md +++ b/content/develop/clients/dotnet/transpipe.md @@ -21,11 +21,11 @@ There are two types of batch that you can use: - **Pipelines** avoid network and processing overhead by sending several commands to the server together in a single communication. The server then sends back a single communication with all the responses. See the - [Pipelining]({{< relref "/develop/reference/pipelining" >}}) page for more + [Pipelining]({{< relref "/develop/using-commands/pipelining" >}}) page for more information. - **Transactions** guarantee that all the included commands will execute to completion without being interrupted by commands from other clients. - See the [Transactions]({{< relref "/develop/reference/transactions" >}}) + See the [Transactions]({{< relref "develop/using-commands/transactions" >}}) page for more information. ## Execute a pipeline @@ -57,7 +57,7 @@ to different keys. The basic idea is to watch for changes to any keys that you use in a transaction while you are are processing the updates. If the watched keys do change, you must restart the updates with the latest data from the keys. See -[Transactions]({{< relref "/develop/reference/transactions" >}}) +[Transactions]({{< relref "develop/using-commands/transactions" >}}) for more information about optimistic locking. The approach to optimistic locking that other clients use diff --git a/content/develop/clients/go/transpipe.md b/content/develop/clients/go/transpipe.md index 73d45bb4bf..ee001456fa 100644 --- a/content/develop/clients/go/transpipe.md +++ b/content/develop/clients/go/transpipe.md @@ -21,11 +21,11 @@ There are two types of batch that you can use: - **Pipelines** avoid network and processing overhead by sending several commands to the server together in a single communication. The server then sends back a single communication with all the responses. See the - [Pipelining]({{< relref "/develop/reference/pipelining" >}}) page for more + [Pipelining]({{< relref "/develop/using-commands/pipelining" >}}) page for more information. - **Transactions** guarantee that all the included commands will execute to completion without being interrupted by commands from other clients. - See the [Transactions]({{< relref "/develop/reference/transactions" >}}) + See the [Transactions]({{< relref "develop/using-commands/transactions" >}}) page for more information. ## Execute a pipeline @@ -77,7 +77,7 @@ to different keys. The basic idea is to watch for changes to any keys that you use in a transaction while you are are processing the updates. If the watched keys do change, you must restart the updates with the latest data from the keys. See -[Transactions]({{< relref "/develop/reference/transactions" >}}) +[Transactions]({{< relref "develop/using-commands/transactions" >}}) for more information about optimistic locking. The code below reads a string diff --git a/content/develop/clients/hiredis/transpipe.md b/content/develop/clients/hiredis/transpipe.md index da15826faa..abd228dcc0 100644 --- a/content/develop/clients/hiredis/transpipe.md +++ b/content/develop/clients/hiredis/transpipe.md @@ -21,11 +21,11 @@ There are two types of batch that you can use: - **Pipelines** avoid network and processing overhead by sending several commands to the server together in a single communication. The server then sends back a single communication with all the responses. See the - [Pipelining]({{< relref "/develop/reference/pipelining" >}}) page for more + [Pipelining]({{< relref "/develop/using-commands/pipelining" >}}) page for more information. - **Transactions** guarantee that all the included commands will execute to completion without being interrupted by commands from other clients. - See the [Transactions]({{< relref "/develop/reference/transactions" >}}) + See the [Transactions]({{< relref "develop/using-commands/transactions" >}}) page for more information. ## Execute a pipeline @@ -109,5 +109,5 @@ when you have finished processing it, as in the example above. you can implement them yourself using the [`MULTI`]({{< relref "/commands/multi" >}}), [`EXEC`]({{< relref "/commands/exec" >}}), and [`WATCH`]({{< relref "/commands/watch" >}}) commands as you would from [`redis-cli`]({{< relref "/develop/tools/cli" >}}). -See [Transactions]({{< relref "/develop/reference/transactions" >}}) +See [Transactions]({{< relref "develop/using-commands/transactions" >}}) for more information. diff --git a/content/develop/clients/jedis/transpipe.md b/content/develop/clients/jedis/transpipe.md index 38bd481f37..4c40cc9582 100644 --- a/content/develop/clients/jedis/transpipe.md +++ b/content/develop/clients/jedis/transpipe.md @@ -21,11 +21,11 @@ There are two types of batch that you can use: - **Pipelines** avoid network and processing overhead by sending several commands to the server together in a single communication. The server then sends back a single communication with all the responses. See the - [Pipelining]({{< relref "/develop/reference/pipelining" >}}) page for more + [Pipelining]({{< relref "/develop/using-commands/pipelining" >}}) page for more information. - **Transactions** guarantee that all the included commands will execute to completion without being interrupted by commands from other clients. - See the [Transactions]({{< relref "/develop/reference/transactions" >}}) + See the [Transactions]({{< relref "develop/using-commands/transactions" >}}) page for more information. ## Execute a pipeline @@ -68,7 +68,7 @@ to different keys. The basic idea is to watch for changes to any keys that you use in a transaction while you are are processing the updates. If the watched keys do change, you must restart the updates with the latest data from the keys. See -[Transactions]({{< relref "/develop/reference/transactions" >}}) +[Transactions]({{< relref "develop/using-commands/transactions" >}}) for more information about optimistic locking. The code below reads a string diff --git a/content/develop/clients/nodejs/transpipe.md b/content/develop/clients/nodejs/transpipe.md index 43d8bcfdcf..584090cdf3 100644 --- a/content/develop/clients/nodejs/transpipe.md +++ b/content/develop/clients/nodejs/transpipe.md @@ -21,11 +21,11 @@ There are two types of batch that you can use: - **Pipelines** avoid network and processing overhead by sending several commands to the server together in a single communication. The server then sends back a single communication with all the responses. See the - [Pipelining]({{< relref "/develop/reference/pipelining" >}}) page for more + [Pipelining]({{< relref "/develop/using-commands/pipelining" >}}) page for more information. - **Transactions** guarantee that all the included commands will execute to completion without being interrupted by commands from other clients. - See the [Transactions]({{< relref "/develop/reference/transactions" >}}) + See the [Transactions]({{< relref "develop/using-commands/transactions" >}}) page for more information. ## Execute a pipeline @@ -112,7 +112,7 @@ to different keys. The basic idea is to watch for changes to any keys that you use in a transaction while you are are processing the updates. If the watched keys do change, you must restart the updates with the latest data from the keys. See -[Transactions]({{< relref "/develop/reference/transactions" >}}) +[Transactions]({{< relref "develop/using-commands/transactions" >}}) for more information about optimistic locking. The code below reads a string diff --git a/content/develop/clients/pools-and-muxing.md b/content/develop/clients/pools-and-muxing.md index a16435005e..821b76f3c4 100644 --- a/content/develop/clients/pools-and-muxing.md +++ b/content/develop/clients/pools-and-muxing.md @@ -71,7 +71,7 @@ used to identify where to send the response data from your commands. Note that it is not a problem if the multiplexer receives several commands close together in time. When this happens, the multiplexer can often combine the commands into a -[pipeline]({{< relref "/develop/reference/pipelining" >}}), which +[pipeline]({{< relref "/develop/using-commands/pipelining" >}}), which improves efficiency. Multiplexing offers high efficiency but works transparently without requiring diff --git a/content/develop/clients/redis-py/transpipe.md b/content/develop/clients/redis-py/transpipe.md index a03500c3d5..78093f86d1 100644 --- a/content/develop/clients/redis-py/transpipe.md +++ b/content/develop/clients/redis-py/transpipe.md @@ -21,11 +21,11 @@ There are two types of batch that you can use: - **Pipelines** avoid network and processing overhead by sending several commands to the server together in a single communication. The server then sends back a single communication with all the responses. See the - [Pipelining]({{< relref "/develop/reference/pipelining" >}}) page for more + [Pipelining]({{< relref "/develop/using-commands/pipelining" >}}) page for more information. - **Transactions** guarantee that all the included commands will execute to completion without being interrupted by commands from other clients. - See the [Transactions]({{< relref "/develop/reference/transactions" >}}) + See the [Transactions]({{< relref "develop/using-commands/transactions" >}}) page for more information. ## Execute a pipeline @@ -62,7 +62,7 @@ to different keys. The basic idea is to watch for changes to any keys that you use in a transaction while you are processing the updates. If the watched keys do change, you must restart the updates with the latest data from the keys. See -[Transactions]({{< relref "/develop/reference/transactions" >}}) +[Transactions]({{< relref "develop/using-commands/transactions" >}}) for more information about optimistic locking. The example below shows how to repeatedly attempt a transaction with a watched diff --git a/content/develop/data-types/hashes.md b/content/develop/data-types/hashes.md index ea6fec41e0..3f109ae6a6 100644 --- a/content/develop/data-types/hashes.md +++ b/content/develop/data-types/hashes.md @@ -101,7 +101,7 @@ See the [complete list of hash commands]({{< relref "/commands/" >}}?group=hash) ## Field expiration New in Redis Open Source 7.4 is the ability to specify an expiration time or a time-to-live (TTL) value for individual hash fields. -This capability is comparable to [key expiration]({{< relref "/develop/keyspace#key-expiration" >}}) and includes a number of similar commands. +This capability is comparable to [key expiration]({{< relref "/develop/using-commands/keyspace#key-expiration" >}}) and includes a number of similar commands. Use the following commands to set either an exact expiration time or a TTL value for specific fields: diff --git a/content/develop/get-started/data-store.md b/content/develop/get-started/data-store.md index 8505d9e876..a5b8096cb1 100644 --- a/content/develop/get-started/data-store.md +++ b/content/develop/get-started/data-store.md @@ -82,7 +82,7 @@ You can get a complete overview of available data types in this documentation si ## Scan the keyspace -Each item within Redis has a unique key. All items live within the Redis [keyspace]({{< relref "/develop/keyspace" >}}). You can scan the Redis keyspace via the [SCAN command]({{< relref "/commands/scan" >}}). Here is an example that scans for the first 100 keys that have the prefix `bike:`: +Each item within Redis has a unique key. All items live within the Redis [keyspace]({{< relref "/develop/using-commands/keyspace" >}}). You can scan the Redis keyspace via the [SCAN command]({{< relref "/commands/scan" >}}). Here is an example that scans for the first 100 keys that have the prefix `bike:`: ``` SCAN 0 MATCH "bike:*" COUNT 100 diff --git a/content/develop/get-started/vector-database.md b/content/develop/get-started/vector-database.md index ceecfbb3df..47842ac455 100644 --- a/content/develop/get-started/vector-database.md +++ b/content/develop/get-started/vector-database.md @@ -120,7 +120,7 @@ Inspect the structure of one of the bike JSON documents: {{< clients-example search_vss dump_data />}} ### 2. Store the demo data in Redis -Now iterate over the `bikes` array to store the data as [JSON]({{< relref "/develop/data-types/json/" >}}) documents in Redis by using the [JSON.SET]({{< relref "commands/json.set/" >}}) command. The below code uses a [pipeline]({{< relref "/develop/reference/pipelining" >}}) to minimize the network round-trip times: +Now iterate over the `bikes` array to store the data as [JSON]({{< relref "/develop/data-types/json/" >}}) documents in Redis by using the [JSON.SET]({{< relref "commands/json.set/" >}}) command. The below code uses a [pipeline]({{< relref "/develop/using-commands/pipelining" >}}) to minimize the network round-trip times: {{< clients-example search_vss load_data />}} diff --git a/content/develop/programmability/_index.md b/content/develop/programmability/_index.md index b8030c0922..b2c40510e4 100644 --- a/content/develop/programmability/_index.md +++ b/content/develop/programmability/_index.md @@ -61,7 +61,7 @@ Please refer to the following pages for more information: * [Redis Functions]({{< relref "/develop/programmability/functions-intro" >}}) When running a script or a function, Redis guarantees its atomic execution. -The script's execution blocks all server activities during its entire time, similarly to the semantics of [transactions]({{< relref "/develop/reference/transactions" >}}). +The script's execution blocks all server activities during its entire time, similarly to the semantics of [transactions]({{< relref "develop/using-commands/transactions" >}}). These semantics mean that all of the script's effects either have yet to happen or had already happened. The blocking semantics of an executed script apply to all connected clients at all times. diff --git a/content/develop/programmability/eval-intro.md b/content/develop/programmability/eval-intro.md index 4ca58a8ac6..138d5a5171 100644 --- a/content/develop/programmability/eval-intro.md +++ b/content/develop/programmability/eval-intro.md @@ -191,7 +191,7 @@ Please consult your client's documentation regarding the specific details. ### `EVALSHA` in the context of pipelining -Special care should be given executing [`EVALSHA`]({{< relref "/commands/evalsha" >}}) in the context of a [pipelined request]({{< relref "/develop/reference/pipelining" >}}). +Special care should be given executing [`EVALSHA`]({{< relref "/commands/evalsha" >}}) in the context of a [pipelined request]({{< relref "/develop/using-commands/pipelining" >}}). The commands in a pipelined request run in the order they are sent, but other clients' commands may be interleaved for execution between these. Because of that, the `NOSCRIPT` error can return from a pipelined request but can't be handled. @@ -229,7 +229,7 @@ These are: _1_ means the specific SHA1 is recognized as a script already present in the scripting cache. _0_'s meaning is that a script with this SHA1 wasn't loaded before (or at least never since the latest call to [`SCRIPT FLUSH`]({{< relref "/commands/script-flush" >}})). * `SCRIPT LOAD script`: this command registers the specified script in the Redis script cache. - It is a useful command in all the contexts where we want to ensure that [`EVALSHA`]({{< relref "/commands/evalsha" >}}) doesn't not fail (for instance, in a pipeline or when called from a [`MULTI`]({{< relref "/commands/multi" >}})/[`EXEC`]({{< relref "/commands/exec" >}}) [transaction]({{< relref "/develop/reference/transactions" >}}), without the need to execute the script. + It is a useful command in all the contexts where we want to ensure that [`EVALSHA`]({{< relref "/commands/evalsha" >}}) doesn't not fail (for instance, in a pipeline or when called from a [`MULTI`]({{< relref "/commands/multi" >}})/[`EXEC`]({{< relref "/commands/exec" >}}) [transaction]({{< relref "develop/using-commands/transactions" >}}), without the need to execute the script. * [`SCRIPT KILL`]({{< relref "/commands/script-kill" >}}): this command is the only way to interrupt a long-running script (a.k.a slow script), short of shutting down the server. A script is deemed as slow once its execution's duration exceeds the configured [maximum execution time]({{< relref "/develop/programmability/#maximum-execution-time" >}}) threshold. @@ -271,7 +271,7 @@ We call this **script effects replication**. starting with Redis 5.0, script effects replication is the default mode and does not need to be explicitly enabled. In this replication mode, while Lua scripts are executed, Redis collects all the commands executed by the Lua scripting engine that actually modify the dataset. -When the script execution finishes, the sequence of commands that the script generated are wrapped into a [`MULTI`]({{< relref "/commands/multi" >}})/[`EXEC`]({{< relref "/commands/exec" >}}) [transaction]({{< relref "/develop/reference/transactions" >}}) and are sent to the replicas and AOF. +When the script execution finishes, the sequence of commands that the script generated are wrapped into a [`MULTI`]({{< relref "/commands/multi" >}})/[`EXEC`]({{< relref "/commands/exec" >}}) [transaction]({{< relref "develop/using-commands/transactions" >}}) and are sent to the replicas and AOF. This is useful in several ways depending on the use case: diff --git a/content/develop/programmability/functions-intro.md b/content/develop/programmability/functions-intro.md index ae5112dc31..c19f64f442 100644 --- a/content/develop/programmability/functions-intro.md +++ b/content/develop/programmability/functions-intro.md @@ -37,7 +37,7 @@ The underlying assumption is that scripts are a part of the application and not This approach suits many light-weight scripting use cases, but introduces several difficulties once an application becomes complex and relies more heavily on scripting, namely: 1. All client application instances must maintain a copy of all scripts. That means having some mechanism that applies script updates to all of the application's instances. -1. Calling cached scripts within the context of a [transaction]({{< relref "/develop/reference/transactions" >}}) increases the probability of the transaction failing because of a missing script. Being more likely to fail makes using cached scripts as building blocks of workflows less attractive. +1. Calling cached scripts within the context of a [transaction]({{< relref "develop/using-commands/transactions" >}}) increases the probability of the transaction failing because of a missing script. Being more likely to fail makes using cached scripts as building blocks of workflows less attractive. 1. SHA1 digests are meaningless, making debugging the system extremely hard (e.g., in a [`MONITOR`]({{< relref "/commands/monitor" >}}) session). 1. When used naively, [`EVAL`]({{< relref "/commands/eval" >}}) promotes an anti-pattern in which scripts the client application renders verbatim scripts instead of responsibly using the [`KEYS` and `ARGV` Lua APIs]({{< relref "/develop/programmability/lua-api#runtime-globals" >}}). 1. Because they are ephemeral, a script can't call another script. This makes sharing and reusing code between scripts nearly impossible, short of client-side preprocessing (see the first point). @@ -82,7 +82,7 @@ Functions are also persisted to the AOF file and replicated from master to repli When Redis is used as an ephemeral cache, additional mechanisms (described below) are required to make functions more durable. Like all other operations in Redis, the execution of a function is atomic. -A function's execution blocks all server activities during its entire time, similarly to the semantics of [transactions]({{< relref "/develop/reference/transactions" >}}). +A function's execution blocks all server activities during its entire time, similarly to the semantics of [transactions]({{< relref "develop/using-commands/transactions" >}}). These semantics mean that all of the script's effects either have yet to happen or had already happened. The blocking semantics of an executed function apply to all connected clients at all times. Because running a function blocks the Redis server, functions are meant to finish executing quickly, so you should avoid using long-running functions. diff --git a/content/develop/reference/protocol-spec.md b/content/develop/reference/protocol-spec.md index 2441003b96..459494cd71 100644 --- a/content/develop/reference/protocol-spec.md +++ b/content/develop/reference/protocol-spec.md @@ -696,7 +696,7 @@ Pipelining is supported, so multiple commands can be sent with a single write op The client can skip reading replies and continue to send the commands one after the other. All the replies can be read at the end. -For more information, see [Pipelining]({{< relref "/develop/reference/pipelining" >}}). +For more information, see [Pipelining]({{< relref "/develop/using-commands/pipelining" >}}). ## Inline commands Sometimes you may need to send a command to the Redis server but only have `telnet` available. diff --git a/content/develop/using-commands/_index.md b/content/develop/using-commands/_index.md new file mode 100644 index 0000000000..dea086ad11 --- /dev/null +++ b/content/develop/using-commands/_index.md @@ -0,0 +1,71 @@ +--- +categories: +- docs +- develop +- stack +- oss +- rs +- rc +- oss +- kubernetes +- clients +description: Learn how to interact with Redis using commands. +linkTitle: Using commands +title: Using Redis commands +weight: 33 +--- + +Client applications and tools interact with Redis using commands. Most of the +commands implement [data types]({{< relref "/develop/data-types" >}}) to store and retrieve data, +but there are also commands that deal with server configuration, security, and more. + +The sections below give an overview of how Redis commands operate. See the +[Redis commands reference]({{< relref "/commands" >}}) for a complete list of commands. + +## Command structure + +Each command is identified by a unique name. Related groups of commands +tend to follow a consistent naming convention. For example, all commands that +deal with [hashes]({{< relref "/develop/data-types/hashes" >}}) start with the `H` prefix. +Most commands receive one or more arguments that specify the data to operate on. +For data type commands, the first argument is usually the [key]({{< relref "/develop/using-commands/keyspace" >}}) that identifies the target data object. + +After you issue a command, the server attempts to process it and then returns +a response. Commands that update data typically return a status message (such as `OK`) +or a number that indicates the number of items changed or updated. Commands that +retrieve data return the requested data. An unsuccessful command returns an +error message that describes the problem. + +Interacting with a Redis server involves a sequence of commands and responses. +The effect of a given command is the same regardless of whether you send it +from a [client library]({{< relref "/develop/clients" >}}), or from a client tool +such as [redis-cli]({{< relref "/develop/tools/cli" >}}) or +[Redis Insight]({{< relref "/develop/tools/insight" >}}). This is very useful +during development. You can use a high-level tool to experiment with a +command, set up test data, or prototype a data model, and then access the +prepared data from your application code. Most Redis code examples are +presented with an excerpt of a CLI session and the equivalent application code +for each client library. + +## Batching commands + +Although you can issue Redis commands one at a time, it's often more efficient +to batch a sequence of related commands together into a *pipeline*. A pipeline +sends several commands to the server as a single communication and receives +the responses in the same way. See +[Pipelining]({{< relref "/develop/using-commands/pipelining" >}}) for a full +description of the technique and see also the pipelining examples for the +[client libraries]({{< relref "/develop/clients" >}}). + +Another reason to batch commands is to treat them as an uninterrupted unit. +You should do this if you need to be sure that the commands are all +completed without the same data being modified by another client (which +could leave the data in an inconsistent state). Redis uses *transactions* +to implement this behavior. See +[Transactions]({{< relref "/develop/using-commands/transactions" >}}) for +more information and see also the transaction examples for the +[client libraries]({{< relref "/develop/clients" >}}). + +## More information + +The other pages in this section describe Redis command concepts in more detail: diff --git a/content/develop/keyspace.md b/content/develop/using-commands/keyspace.md similarity index 98% rename from content/develop/keyspace.md rename to content/develop/using-commands/keyspace.md index ee955bbce3..a06b8b03f8 100644 --- a/content/develop/keyspace.md +++ b/content/develop/using-commands/keyspace.md @@ -15,7 +15,7 @@ description: 'Managing keys in Redis: Key expiration, scanning, altering and que ' linkTitle: Keys and values title: Keys and values -weight: 33 +weight: 10 aliases: /develop/use/keyspace --- @@ -202,7 +202,7 @@ This command is intended for debugging and special operations, such as changing your keyspace layout. Don't use [`KEYS`]({{< relref "/commands/keys" >}}) in your regular application code. If you're looking for a way to find keys in a subset of your keyspace, consider -using [`SCAN`]({{< relref "/commands/scan" >}}) or [sets][{{< relref "/develop/data-types/sets" >}}]. +using [`SCAN`]({{< relref "/commands/scan" >}}) or [sets]({{< relref "/develop/data-types/sets" >}}). [tdts]: /develop/data-types#sets diff --git a/content/develop/reference/pipelining.md b/content/develop/using-commands/pipelining.md similarity index 99% rename from content/develop/reference/pipelining.md rename to content/develop/using-commands/pipelining.md index 509ced19ed..706a16c793 100644 --- a/content/develop/reference/pipelining.md +++ b/content/develop/using-commands/pipelining.md @@ -13,7 +13,7 @@ description: How to optimize round-trip times by batching Redis commands linkTitle: Pipelining title: Redis pipelining aliases: /develop/use/pipelining -weight: 2 +weight: 20 --- Redis pipelining is a technique for improving performance by issuing multiple commands at once without waiting for the response to each individual command. Pipelining is supported by most Redis clients. This document describes the problem that pipelining is designed to solve and how pipelining works in Redis. diff --git a/content/develop/reference/transactions.md b/content/develop/using-commands/transactions.md similarity index 100% rename from content/develop/reference/transactions.md rename to content/develop/using-commands/transactions.md diff --git a/content/embeds/r7.2-breaking-changes.md b/content/embeds/r7.2-breaking-changes.md index 223809f0bd..c4039685c7 100644 --- a/content/embeds/r7.2-breaking-changes.md +++ b/content/embeds/r7.2-breaking-changes.md @@ -19,7 +19,7 @@ Upgrading to Redis version 7.2 from version 7.0 introduces the following potenti - Time sampling is now frozen during command execution and scripts ([#10300](https://github.com/redis/redis/pull/10300)). While a command or script is running, the keys used by the command or script will not expire. This breaks any script that uses a loop to wait for a key to expire. -- Blocked commands in scripts now work the same way as when they are used in [transactions]({{< relref "/develop/reference/transactions" >}}) ([#11568](https://github.com/redis/redis/pull/11568)). +- Blocked commands in scripts now work the same way as when they are used in [transactions]({{< relref "develop/using-commands/transactions" >}}) ([#11568](https://github.com/redis/redis/pull/11568)). ##### Error handling diff --git a/content/embeds/r7.2-combined-breaking-changes.md b/content/embeds/r7.2-combined-breaking-changes.md index ff7f7d3bfe..8f835e232c 100644 --- a/content/embeds/r7.2-combined-breaking-changes.md +++ b/content/embeds/r7.2-combined-breaking-changes.md @@ -28,7 +28,7 @@ Upgrading to open source Redis version 7.2 from version 6.2 introduces the follo - Time sampling is now frozen during command execution and scripts ([#10300](https://github.com/redis/redis/pull/10300)). While a command or script is running, the keys used by the command or script will not expire. This breaks any script that uses a loop to wait for a key to expire. -- Blocked commands in scripts now work the same way as when they are used in [transactions]({{< relref "/develop/reference/transactions" >}}) ([#11568](https://github.com/redis/redis/pull/11568)). +- Blocked commands in scripts now work the same way as when they are used in [transactions]({{< relref "develop/using-commands/transactions" >}}) ([#11568](https://github.com/redis/redis/pull/11568)). ##### Error handling diff --git a/content/operate/rc/databases/configuration/sizing.md b/content/operate/rc/databases/configuration/sizing.md index 03df0ccb9f..4c2e8f31b8 100644 --- a/content/operate/rc/databases/configuration/sizing.md +++ b/content/operate/rc/databases/configuration/sizing.md @@ -55,7 +55,7 @@ Here are some things to keep in mind for optimizing throughput: - Test and monitor your app's performance and adjust the set ops/sec based on how if performs in real-world conditions. - If your average request size is larger than 3KB, consider setting your throughput higher than expected. - Track the slow logs using the [`SLOWLOG` command]({{< relref "/commands/slowlog" >}}) or the **Slowlog** tab on the [database screen]({{< relref "/operate/rc/databases/view-edit-database" >}}). -- Use [pipelining]({{< relref "/develop/reference/pipelining" >}}) and [concurrent connections]({{< relref "/develop/reference/clients" >}}) effectively to optimize throughput and latency. +- Use [pipelining]({{< relref "/develop/using-commands/pipelining" >}}) and [concurrent connections]({{< relref "/develop/reference/clients" >}}) effectively to optimize throughput and latency. - Search databases have their own throughput requirements. See [Search and query sizing]({{< relref "/operate/rc/databases/configuration/advanced-capabilities#search-and-query-sizing" >}}) for more info. ### Frequently asked questions