AWS AmazonElastiCache documentation change
Summary
Replaced 'vector workload' with 'search workload', clarified memory consumption applies to vector fields, changed 'Vector search' references to 'Search', and updated section headings
Security assessment
Changes are terminology updates and clarifications about workload types and memory management. No security vulnerabilities, configurations, or features are mentioned. Changes appear to be editorial/documentation refinements without security implications.
Diff
diff --git a/AmazonElastiCache/latest/dg/choosing-configuration.md b/AmazonElastiCache/latest/dg/choosing-configuration.md index 25f1a28ad..8b0e80984 100644 --- a//AmazonElastiCache/latest/dg/choosing-configuration.md +++ b//AmazonElastiCache/latest/dg/choosing-configuration.md @@ -11 +11 @@ Memory consumptionScaling your workload -Within the console experience, ElastiCache offers an easy way to choose the right instance type based on the memory and cpu requirements of your vector workload. +Within the console experience, ElastiCache offers an easy way to choose the right instance type based on the memory and cpu requirements of your search workload. @@ -15 +15 @@ Within the console experience, ElastiCache offers an easy way to choose the righ -Memory consumption is based on the number of vectors, the number of dimensions, the M-value, and the amount of non-vector data, such as metadata associated to the vector or other data stored within the instance. The total memory required is a combination of the space needed for the actual vector data, and the space required for the vector indices. The space required for Vector data is calculated by measuring the actual capacity required for storing vectors within `HASH` or `JSON` data structures and the overhead to the nearest memory slabs, for optimal memory allocations. Each of the vector indexes uses references to the vector data stored in these data structures as well as an additional copy of the vector in the index. It is advised to plan for this additional space consumption by the index. +Memory consumption for Vector fields is based on the number of vectors, the number of dimensions, the M-value, and the amount of non-vector data, such as metadata associated to the vector or other data stored within the instance. The total memory required is a combination of the space needed for the actual vector data, and the space required for the vector indices. The space required for Vector data is calculated by measuring the actual capacity required for storing vectors within `HASH` or `JSON` data structures and the overhead to the nearest memory slabs, for optimal memory allocations. Each of the vector indexes uses references to the vector data stored in these data structures as well as an additional copy of the vector in the index. It is advised to plan for this additional space consumption by the index. @@ -21 +21 @@ The number of vectors depend on how you decide to represent your data as vectors -Vector search supports all three methods of scaling: horizontal, vertical and replicas. When scaling for capacity, vector search behaves just like regular Valkey, i.e., increasing the memory of individual nodes (vertical scaling) or increasing the number of nodes (horizontal scaling) will increase the overall capacity. In cluster mode, the `FT.CREATE` command can be sent to any primary node of the cluster and the system will automatically distribute the new index definition to all cluster members. +Search supports all three methods of scaling: horizontal, vertical and replicas. When scaling for capacity, vector search behaves just like regular Valkey, i.e., increasing the memory of individual nodes (vertical scaling) or increasing the number of nodes (horizontal scaling) will increase the overall capacity. In cluster mode, the `FT.CREATE` command can be sent to any primary node of the cluster and the system will automatically distribute the new index definition to all cluster members. @@ -23 +23 @@ Vector search supports all three methods of scaling: horizontal, vertical and re -However, from a performance perspective, vector search behaves very differently from regular Valkey. The multi-threaded implementation of vector search means that additional CPUs yield up to linear increases in both query and ingestion throughput. Horizontal scaling yields linear increases in ingestion throughput but may reduce query throughput. If additional query throughput is required, scaling through replicas or additional CPUs is required. +However, from a performance perspective, search behaves very differently from regular Valkey. The multi-threaded implementation of search means that additional CPUs yield up to linear increases in both query and ingestion throughput. Horizontal scaling yields linear increases in ingestion throughput but may reduce query throughput. If additional query throughput is required, scaling through replicas or additional CPUs is required. @@ -31 +31 @@ To use the Amazon Web Services Documentation, Javascript must be enabled. Please -Vector search features and limits +Search features and limits @@ -33 +33 @@ Vector search features and limits -Vector Search Commands +Getting started with data aggregations