Search Enhancement Features for Elasticsearch Clusters

Compared with open-source Elasticsearch, Elasticsearch clusters in CSS have many enhanced features. Table 1 lists these enhanced features and the corresponding cluster versions.

**Table 1** Search enhancement features for CSS Elasticsearch clusters
Enhanced Feature	Description	Cluster Version	Details
Vector search	Unstructured data, such as images, videos, and language corpora, is converted into vectors, which are searched based on similarity using either an exact or approximate nearest neighbors algorithm.	Elasticsearch 7.6.2, Elasticsearch 7.10.2	Configuring Vector Search for Elasticsearch Clusters
Storage-compute decoupling	CSS stores new data as hot data on SSDs to ensure optimal query performance, and historical data as cold data in OBS to cut storage costs. Compared with cold/hot storage switchover, storage-compute decoupling is a better option for use cases that are not particularly demanding in terms of search performance, as cold data is stored in OBS, which cuts storage costs.	Elasticsearch 7.6.2, Elasticsearch 7.10.2	Configuring Storage-Compute Decoupling for an Elasticsearch Cluster
Flow Control 2.0	Flow Control 2.0 controls traffic at the node level. You can configure blacklists and whitelists per node, the maximum concurrent HTTP connections allowed, and the maximum HTTP connections allowed. You can also configure node heap memory-based flow control that uses a backpressure mechanism, or one-click traffic blocking. CSS can also collect statistics on node access IP addresses and URLs. When backpressure is enabled, large requests will be rejected by nodes when their heap memory usage is high. This mechanism prevents nodes from breaking down and reduces the risk of node unavailability. NOTE: Elasticsearch 7.6.2 and Elasticsearch 7.10.2 clusters created after January 2023 support Flow Control 2.0 only, whereas those created before that support Flow Control 1.0 only.	Elasticsearch 7.6.2, Elasticsearch 7.10.2	Configuring Flow Control 2.0 for an Elasticsearch Cluster
Flow Control 1.0	Flow Control 1.0 controls traffic at the node level. You can configure blacklists and whitelists per node, the maximum concurrent HTTP connections allowed, the maximum HTTP connections allowed, the maximum heap memory used by specific request paths, and the maximum CPU usage. You can block access in one click, and collect statistics on IP addresses and URLs accessing the nodes. If flow control is enabled, requests will be blocked at the entry, which alleviates the cluster pressure in high-concurrency scenarios and reduces the likelihood of unavailability issues. NOTE: Elasticsearch 7.6.2 and Elasticsearch 7.10.2 clusters created after January 2023 support Flow Control 2.0 only, whereas those created before that support Flow Control 1.0 only.	Elasticsearch 7.6.2, Elasticsearch 7.10.2	Configuring Flow Control 1.0 for an Elasticsearch Cluster
Large query isolation	You can isolate query requests that consume a large amount of memory or take a long period of time. This way, you ensure service availability for other requests. If the heap memory usage of a node is too high, an interrupt control program will be triggered to terminate a large query based on the policies you configured. You can also configure a global query timeout duration. Long queries will be intercepted.	Elasticsearch 7.6.2, Elasticsearch 7.10.2	Configuring Large Query Isolation for an Elasticsearch Cluster
Enhanced aggregation	In the case of data clustering, enhanced aggregation uses the vectorization technology to process data in batches, improving aggregation performance and facilitating aggregated analysis for faster time to insight.	Elasticsearch 7.10.2	Configuring Enhanced Aggregation for an Elasticsearch Cluster
Read/write splitting	Data written to the primary cluster (Leader) is automatically synchronized to the secondary cluster (Follower). This allows data to be queried from the secondary cluster, improving query performance while alleviating the pressure of the primary cluster. If the primary cluster is unable to provide services, a primary/secondary switchover can be performed to use the secondary cluster to handle write and query requests, ensuring service continuity.	Elasticsearch 7.6.2, Elasticsearch 7.10.2	Configuring Read/Write Splitting Between Two Elasticsearch Clusters
Switchover between hot and cold storage	You can keep hot data on high-performance servers to ensure fast query response times (in seconds). For historical data that requires a query response time of minutes, you can keep it on large-capacity, low-specs servers as cold data. This allows you to cut storage costs and improve search efficiency. Compared with storage-compute decoupling, cold/hot storage switchover is a better option for use cases that are demanding in terms of search performance. Cold data is stored on local cold data nodes in the cluster. The storage capacity available depends on the number of cold data nodes and their disk capacity. The storage cost is higher than that of OBS.	This feature is supported as long as the cluster has cold data nodes.	Switching Between Hot and Cold Storage for an Elasticsearch Cluster
Index recycle bin	Similar to any other type of recycle bin, the index recycle bin temporarily stores deleted indexes so that users can restore them before they are finally removed from the recycle bin. This helps to prevent misdeletion of data and improve cluster data reliability.	Elasticsearch 7.10.2	Configuring an Index Recycle Bin for an Elasticsearch Cluster