Conversation
🛡️ Jit Security Scan Results
✅ No security findings were detected in this PR
Security scan by Jit
|
|
@rrelledge the screenshot for the "create a database" step is really large. You could scale it down to half that size I think |
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 3 potential issues.
Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.
| - Reduce infrastructure costs by combining high-speed RAM with cost-efficient flash storage | ||
|
|
||
| {{<note>}} | ||
| Flex does not replace long-term data persistence. For workloads that require durability and recovery across restarts or failures, use Redis persistence features like [AOF (Append-Only File)]({{< relref "/operate/oss_and_stack/management/persistence#append-only-file" >}}), [RDB snapshots]({{< relref "/operate/oss_and_stack/management/persistence#snapshotting" >}}), or both. For more information, see [Database persistence]({{< relref "/operate/rs/databases/configure/database-persistence" >}}). |
There was a problem hiding this comment.
I suggest adding a dedicated "What Flex isn't" section with the wording similar to the doc: https://docs.google.com/document/d/1PuFejCooJpy_gs0MoM5Pf9MLS46x6gcNUmzYfPjIHik/edit?disco=AAABz_t08H0&tab=t.0
There was a problem hiding this comment.
This info is already included in a note in https://redis.io/docs/staging/DOC-6284/operate/rs/flex/#when-to-use-flex:
Note:
Flex does not replace long-term data persistence. For workloads that require durability and recovery across restarts or failures, use Redis persistence features like AOF (Append-Only File), RDB snapshots, or both. For more information, see Database persistence.
|
|
||
| ### Differences between Flex and Auto Tiering | ||
|
|
||
| - Key and value offloading |
There was a problem hiding this comment.
Add a short explanation on why it matters:
"frees RAM for hot data, higher RAM hit‑rate, bigger datasets per node”
| --- | ||
|
|
||
| Flex extends your database capacity by combining RAM and flash (SSD) storage. This tiered architecture keeps frequently accessed (hot) data in RAM for sub-millisecond latency while storing less active (warm) data on flash to reduce costs and increase capacity. | ||
|
|
There was a problem hiding this comment.
"Flex frees RAM for hot data, higher RAM hit‑rate, bigger datasets per node”
|
Thank you this is looking great |
| linkTitle: Get started | ||
| weight: 20 | ||
| --- | ||
| This page guides you through a quick setup of [Flex]({{< relref "/operate/rs/flex" >}}) with a single node for testing and demo purposes. |
There was a problem hiding this comment.
consider labeling it as a non-production quick start and refer to the planning page for production grade deployments.
There was a problem hiding this comment.
This sentence and the following sentence "For production environments" already indicate that this quick start is for testing and not intended for production, but I went ahead and linked to the planning doc too.
| This page guides you through a quick setup of [Flex]({{< relref "/operate/rs/flex" >}}) with a single node for testing and demo purposes. | ||
|
|
||
| For production environments, you can find more detailed installation instructions in the [install and setup]({{< relref "/operate/rs/installing-upgrading" >}}) section. | ||
|
|
There was a problem hiding this comment.
Consider adding before you begin clause with version requirements.
There was a problem hiding this comment.
I added a version requirements section to the quick start.
content/operate/rs/flex/plan.md
Outdated
|
|
||
| ### CPU allocation | ||
|
|
||
| Throughput capacity scales with both CPU cores. At minimum, allocate 1 vCPU per 50 GB shard. |
There was a problem hiding this comment.
"... with both CPU cores and the RAM-to-flash ration".
| --- | ||
|
|
||
| Review the following hardware requirements, sizing guidelines, best practices, and known limitations before you deploy a Redis Software cluster for Flex databases. | ||
|
|
There was a problem hiding this comment.
Consider adding a short checkbox:
`Before you deploy Flex, verify:
- locally attached NVMe or SSD dedicated to Flex data and keys.
- Flash capacity is greater than the total provisioned database size.
- Working set much smaller than total dataset - fits high-RAM hit-rate pattern.
`
|
|
||
| 1. Increase the database limit and [decrease the RAM-to-flash ratio](#decrease-ram-to-flash-ratio). | ||
|
|
||
| ### Add shards {#scale-volume-add-shards} |
There was a problem hiding this comment.
swap the order of ###Add shards and ###Decrease RAM-to-flash ratio to fit the list.
There was a problem hiding this comment.
Can you clarify what you mean by "swap to fit the list"?
Is this the list you were referring to?
1. Increase the database limit and [add shards](#scale-volume-add-shards).
2. Increase the database limit and [decrease the RAM-to-flash ratio](#decrease-ram-to-flash-ratio).
Or were you referring to the "Choose a scaling strategy" table at the top?
I thought it made more sense for the order to be similar under Scale volume and Scale throughput.
- Scale volume
- Add shards
- Decrease RAM-to-flash ratio
- Scale throughput
- Add shards or nodes
- Increase RAM-to-flash ratio
I'm fine with switching the order, but I think if we switch the order under Scale volume, maybe we should also switch the order of Scale throughput? Or maybe just change the order of rows in the "Choose a scaling strategy" table?
| 1. Decrease the **RAM limit**. | ||
|
|
||
| 1. Click **Save**. | ||
|
|
There was a problem hiding this comment.
Consider adding an example:
if you lower the RAM-to-flash ratio from 30% to 20% on a 1 TB database:
Memory limit might increase from 1 TB to 1.5 TB (more total capacity).
RAM limit stays at 300 GB, which becomes 20% of the new total capacity.
|
|
||
| You can add more shards to expand dataset capacity while maintaining the existing RAM-to-flash ratio. Throughput capacity also typically increases as a result of additional shards and infrastructure. This strategy is recommended when the dataset size and traffic are expected to grow together. | ||
|
|
||
| Before you increase the dataset capacity and add shards, you need to add more RAM and vCPUs to handle the increased number of shards. |
There was a problem hiding this comment.
Let's make it more explicit:
This increases capacity without adding CPU or RAM but may reduce RAM hit-rate and increase p99 latency; monitor metrics before and after the change.
There was a problem hiding this comment.
This suggestion contradicts the statement: "you need to add more RAM and vCPUs to handle the increased number of shards."
| ### Decrease RAM-to-flash ratio | ||
|
|
||
| You can allocate more data to the flash tier to increase the database capacity while keeping the same amount of RAM, shards, and vCPU. This strategy is recommended when scaling for volume only and SSD resources are underutilized. | ||
|
|
There was a problem hiding this comment.
Let's add implications:
This increases capacity without adding CPU or RAM but may reduce RAM hit-rate and increase p99 latency; monitor metrics before and after the change.
4 participants
Still a work in progress
Note
Low Risk
Low risk documentation-only change; primary risk is broken/incorrect internal links or navigation due to the new
flexsection and renamed page titles.Overview
Adds a new dedicated
Flex databasesdocumentation section (content/operate/rs/flex) with pages to explain Flex, how to get started, deployment planning, and scaling guidance.Updates the existing flash/Auto Tiering docs (
databases/flash/*) to consistently use Flex terminology, add banner callouts that route readers to the new Flex section, and refresh “Next steps” links to point to the new Flex pages while keeping Auto Tiering quickstart and storage-engine info in place.Written by Cursor Bugbot for commit efa2146. This will update automatically on new commits. Configure here.