{
  "id": "auto-tiering",
  "title": "Auto Tiering",
  "url": "https://redis.io/docs/latest/operate/rs/7.8/databases/auto-tiering/",
  "summary": "Auto Tiering enables your data to span both RAM and dedicated flash memory.",
  "content": "Redis Enterprise's auto tiering offers users the unique ability to use solid state drives (SSDs) to extend databases beyond DRAM capacity.\nDevelopers can build applications that require large datasets using the same Redis API.\nUsing SSDs can significantly reduce the infrastructure costs compared to only DRAM deployments. \n\nFrequently used data, called hot data, belongs in the fastest memory level to deliver a real-time user experience.\nData that is accessed less frequently, called warm data, can be kept in a slightly slower memory tier.\nRedis Enterprise’s Auto tiering maintains hot data in DRAM, keeps warm data in SSDs, and transfers data between tiers automatically.\n\nRedis Enterprise’s auto tiering is based on a high-performance storage engine (Speedb) that manages the complexity of using SSDs and DRAM as the total available memory for databases in a Redis Enterprise cluster. This implementation offers a performance boost of up to 10k operations per second per core of the database, doubling the performance of Redis on Flash.\n\nJust like all-RAM databases, databases with Auto Tiering enabled are compatible with existing Redis applications.\n\nAuto Tiering is also supported on [Redis Cloud]() and [Redis Enterprise Software for Kubernetes]().\n\n## Use cases\n\nThe benefits associated with Auto Tiering are dependent on the use case.\n\nAuto Tiering is ideal when your:\n\n- working set is significantly smaller than your dataset (high RAM hit rate)\n- average key size is smaller than average value size (all key names are stored in RAM)\n- most recent data is the most frequently used (high RAM hit rate)\n\nAuto Tiering is not recommended for:\n\n- Long key names (all key names are stored in RAM)\n- Broad access patterns (any value could be pulled into RAM)\n- Large working sets (working set is stored in RAM)\n- Frequently moved data (moving to and from RAM too often can impact performance)\n\nAuto Tiering is not intended to be used for persistent storage. Redis Enterprise Software database persistent and ephemeral storage should be on different disks, either local or attached.\n\n## Where is my data?\n\nWhen using Auto Tiering, RAM storage holds:\n- All keys (names)\n- Key indexes\n- Dictionaries\n- Hot data (working set)\n\nAll data is accessed through RAM. If a value in flash memory is accessed, it becomes part of the working set and is moved to RAM. These values are referred to as \"hot data\".\n\nInactive or infrequently accessed data is referred to as \"warm data\" and stored in flash memory. When more space is needed in RAM, warm data is moved from RAM to flash storage.\n\n When using Auto Tiering with RediSearch, it’s important to note that RediSearch indexes are also stored in RAM.\n\n## RAM to Flash ratio\n\nRedis Enterprise Software allows you to configure and tune the ratio of RAM-to-Flash for each database independently, optimizing performance for your specific use case.\nWhile this is an online operation requiring no downtime for your database, it is recommended to perform it during maintenance windows as data might move between tiers (RAM \u003c-\u003e Flash).\n\nThe RAM limit cannot be smaller than 10% of the total memory. We recommend you keep at least 20% of all values in RAM. Do not set the RAM limit to 100%.\n\n## Flash memory\n\nImplementing Auto Tiering requires pre planning around memory and sizing. Considerations and requirements for Auto Tiering include:\n\n- Flash memory must be locally attached. Using network-attached storage (NAS), storage area networks (SAN), or solutions such as AWS Elastic Block Storage (EBS) is not supported. \n- Flash memory must be dedicated to Auto Tiering and not shared with other parts of the database, such as durability, binaries, or persistence.\n- For the best performance, the SSDs should be NVMe based, but SATA can also be used.\n- The available flash space must be greater than or equal to the total database size (RAM+Flash). The extra space accounts for write buffers and [write amplification](https://en.wikipedia.org/wiki/Write_amplification).\n\n The Redis Enterprise Software database persistent and ephemeral storage should be on different disks, either local or attached. \n\nOnce these requirements are met, you can create and manage both databases with Auto Tiering enabled and\nall-RAM databases in the same cluster.\n\nWhen you begin planning the deployment of an Auto Tiering enabled database in production,\nwe recommend working closely with the Redis technical team for sizing and performance tuning.\n\n### Cloud environments\n\nWhen running in a cloud environment:\n\n- Flash memory is on the ephemeral SSDs of the cloud instance (for example the local NVMe of AWS i4i instances and Azure Lsv2 and Lsv3 series).\n- Persistent database storage needs to be network attached (for example, AWS EBS for AWS).\n\n\nWe specifically recommend \"[Storage Optimized I4i - High I/O Instances](https://aws.amazon.com/ec2/instance-types/#storage-optimized)\" because of the performance of NVMe for flash memory. \n\n### On-premises environments\n\nWhen you begin planning the deployment of Auto Tiering in production, we recommend working closely with the Redis technical team for sizing and performance tuning.\n\nOn-premises environments support more deployment options than other environments such as:\n\n- Using Redis Stack features:\n  - [Search and query]() \n  - [JSON]()\n  - [Time series]()\n  - [Probabilistic data structures]()\n\n Enabling Auto Tiering for Active-Active distributed databases requires validating and getting the Redis technical team's approval first . \n\n Auto Tiering is not supported running on network attached storage (NAS), storage area network (SAN), or with local HDD drives. \n\n## Next steps\n\n- [Auto Tiering metrics]()\n- [Auto Tiering quick start]()\n\n- [Ephemeral and persistent storage]()\n- [Hardware requirements]()\n",
  "tags": ["docs","operate","rs","rc"],
  "last_updated": "0001-01-01T00:00:00Z",
  "children": [{"id":"quickstart","summary":"Get started with Auto Tiering quickly, creating a cluster and database using flash storage.","title":"Auto Tiering quick start","url":"https://redis.io/docs/latest/operate/rs/7.8/databases/auto-tiering/quickstart/"},{"id":"storage-engine","summary":"Manage the storage engine used for your database with auto tiering enabled.","title":"Manage Auto Tiering storage engine","url":"https://redis.io/docs/latest/operate/rs/7.8/databases/auto-tiering/storage-engine/"}]
}