Techno Blender
Digitally Yours.

Bolster OpenSearch performance with 5 simple steps | by Noam Schwartz

0 40


Learn how to improve the performance of your OpenSearch cluster to ultimately accelerate your workloads

Photo by John Cameron on Unsplash

OpenSearch aims to help everyone find what they need faster. But how fast is “fast enough”? To answer that question, Paul Buchheit, the creator of Gmail, introduced the “100ms rule of latency” for all digital interactions. He explains that 100ms is a threshold “where interactions feel instantaneous”. A study conducted by Amazon found that every additional 100ms of latency on their site cost them 1% in sales. Therefore, it’s crucial for business owners to optimize latency, accuracy and cost. By improving your OpenSearch cluster and search speed, you can enhance your customers’ user experience and, in turn, significantly increase your revenue. To help you do just that, I’ll walk you through some simple and advanced steps for improving OpenSearch performance. I’ll also discuss the benefits of a new search accelerator plugin that I helped develop at Searchium.ai.

Step 1: Choose the right refresh interval for your use case

Photo by Genessa Panainte on Unsplash

Indexed data in OpenSearch is not immediately accessible. For efficiency, documents initially pass through an in-memory buffer before being indexed into the segments. If there are numerous heavy indexing processes, it is more effective to first keep the tokens in an in-memory buffer, and later transfer them to the shard segments; a process called “refresh”. There are costs and benefits to increasing and decreasing the refresh interval. Decreasing the refresh period makes the in-memory buffer less effective as it can only hold a certain number of tokens before it is time to index them to the segment. In general, increasing the refresh interval will improve search performance. However, if you increase the refresh interval too much, the refresh process will take longer to complete because of the large amount of data in the buffer, which could hurt the performance of your search. Moreover, long intervals mean that your data is in the memory buffer for longer and therefore is not searchable until the buffer is refreshed. In most circumstances, the default refresh interval of one second works well. However, keep in mind that many resources are used during refreshes and the interval should be appropriate for your use case. For example, if you are working with data from previous days and don’t require near-real-time data, you could refresh just once a day.

You can change the refresh interval simply using the refresh API, as follows:

PUT /<index_name>/_settings{
“index”: {
“refresh_interval”: “30s”
}
}

There are multiple caches that can help you improve search performance, such as the filesystem cache, the request cache, and the query cache. For example, you can improve performance by increasing the size of the node-level query cache. OpenSearch uses the node-level query cache to store the results of queries so that they can be returned more quickly when the index is searched again. By default, the cache can store up to 10,000 queries and takes up 10% of the heap’s total space. OpenSearch keeps a query history to track occurrences and assess whether a query qualifies for caching. The cache uses the Least Recently Used (LRU) policy — as it fills up, it removes the queries that haven’t been accessed for a while.

Your OpenSearch performance may suffer if your node-level query cache size is too small, as some of your queries may not be cached. To change the size, you can change the global setting parameter- indices.queries.cache.size, which accepts either a percentage value, like 5%, or an exact value, like 512MB:

The caches mentioned above are maintained at the node level, which limits their usefulness in some situations. For example. if you run the same request twice in a row (and have one or more replicas and use the default round-robin algorithm) each of the requests will go to different shard copies, preventing node-level cache from helping.

Another approach is using the shard-level request cache to improve search speed. When a search query is executed against an index or several indices, each involved shard conducts the search locally and sends its local results to the coordinating node, which merges these shard-level results into a “global” result set. The shard-level request cache module caches the local results on each shard. This allows heavy and frequently used search requests to return results very quickly. Users of search applications frequently run similar requests one after another, therefore making maximum use of this cache can improve search speed significantly.

The request cache is set to 1% by default. This can be changed by editing the opensearch.yml file parameter: indices.requests.cache.size

Image by the author

Shards are one of the main drivers of OpenSearch’s high availability and fast performance. In OpenSearch, every query runs on a single thread per shard. Multiple shards can be executed in parallel. If you have multiple shards, you have multiple threads running simultaneously. Shards enable concurrent searches, enhancing the efficiency of your search. However, having too many shards has its own drawbacks. The query process includes merging shards — the more shards you have, the more time you spend merging them. In addition to this, each shard utilizes resources for mapping, storing cluster state, querying, etc. The greater the number of shards, the higher the resource utilization, thereby decreasing performance. There is no single number of shards that is suitable for all scenarios. One popular strategy is to start with one shard and keep adding more until you get the best results. Generally, the recommended shard size should range from 30 GB to 50 GB.

You can change the number of shards and replicas using the API:

PUT <index_name>/_settings{
“index”: {
“number_of_shards”: 3,
“number_of_replicas”: 1
}
}
Photo by Nathália Rosa on Unsplash

Construct OpenSearch data and indices that are right for your use case:

Break your data down into smaller indices — OpenSearch stores data in indices. To store data, you can use one or more indices. All your data need not be kept in a single index. You can, for example, choose an index to store data for a month, a day, or an hour depending on your use case.

Avoid nested fields — Proper document design can help speed the processing of requests. Queries take longer when there are nested fields and parent-child hierarchies. To speed up queries, make your documents as flat as possible.

Consider mapping identifiers as keywords

It is not necessary to map every numeric value as a numeric field data type. Integer and long fields are suitable for OpenSearch range queries. However, term-level queries work better with keyword fields.

To improve retrieval speed, consider mapping fields as keyword fields if you don’t plan to search them using range queries. For example, identifiers like an ISBN or a product ID can be handled as keyword fields without affecting validity.

Reindex your data occasionally

Data in OpenSearch is immutable. When updating a document in OpenSearch, a new document is created rather than updating the existing one. The new document is assigned a version number, which helps OpenSearch track the latest and most relevant documents. However, as a result of including both new and old documents, the index expands significantly. Reindexing addresses this issue. After reindexing, your indices will contain only the most recent information, saving memory and speeding up subsequent searched.

This can be done using the API, as follows:

POST _reindex{
“source”: {
“index”: “my-index”
},
“dest”: {
“index”: “my-new-index”
}
}
Photo by Nicolas Hoizey on Unsplash

You probably chose OpenSearch because you need quick access to a large amount of data and don’t want to use a traditional database. However, even with the best optimization and software modifications, performance will still be inadequate without sufficient computing capabilities. Sufficient cache, disk space, CPUs, and RAM (Random-Access Memory) are crucial for peak OpenSearch performance.

One good option is to use advanced computing machines that have extended RAM. Your search latency will be reduced the more RAM you have. RAM enable applications to store and access data on a short-term basis. It stores the information your computer is actively using so that it can be accessed quickly. An example of such a device are AWS’s m5 instances, which consist of an Intel Xeon Platinum 8000 series processor. The combination of such a CPU processor and large RAM space can significantly enhance your search performance.

Another good option may be to shift your workload from a CPU and RAM based solution to non-traditional hardware solutions. Upgrading your computing resources is expensive and may not reduce latency. Sometimes, a solution which involves more advanced resources is required to address latency problems and boost search performance. GSI Technology’s APU is such a computing resource.

Imagine being able to do computational operations directly in memory rather than in the CPU, avoiding memory-processor bottlenecks and enjoying incredibly fast search performance. In fact, there is an OpenSearch plugin, which implements powerful semantic vector search on the APU. Using Searchium’s OpenSearch k-NN plugin, which is easily accessible via a payed subscription to their SaaS platform, in addition to the OpenSearch improvement suggestions mentioned above, is one way to speed up searches even more while also improving result accuracy and reducing infrastructure costs. Installing the plugin is easy. The plugin allows for vector similarity searches to be run as simply as any standard OpenSearch query. The plugin provides similarity search results in the standard OpenSearch format. Check out a more detailed explanation of how to install and use Searchium’s OpenSearch KNN and Searchium’s website, where you can get full access to the accelerator plugin. There is even a free tier where you can test it out!

Do your research, understand the demands of your company and consider how much and how frequently you’ll need to manipulate, query, and store data. This will help you understand what computing resources you need for the best OpenSearch experience.

Conclusion:

Data is essential to every business, especially in today’s fast-paced environment. Fast, effective handling and processing of complex data has become even more important than before. OpenSearch is a fantastic search engine that makes it possible to search data and get almost instant results. Since OpenSearch’s exceptional performance is essential for meeting business needs, I genuinely hope that this article helped you remove some of the impediments that stand in the way of peak performance.


Learn how to improve the performance of your OpenSearch cluster to ultimately accelerate your workloads

Photo by John Cameron on Unsplash

OpenSearch aims to help everyone find what they need faster. But how fast is “fast enough”? To answer that question, Paul Buchheit, the creator of Gmail, introduced the “100ms rule of latency” for all digital interactions. He explains that 100ms is a threshold “where interactions feel instantaneous”. A study conducted by Amazon found that every additional 100ms of latency on their site cost them 1% in sales. Therefore, it’s crucial for business owners to optimize latency, accuracy and cost. By improving your OpenSearch cluster and search speed, you can enhance your customers’ user experience and, in turn, significantly increase your revenue. To help you do just that, I’ll walk you through some simple and advanced steps for improving OpenSearch performance. I’ll also discuss the benefits of a new search accelerator plugin that I helped develop at Searchium.ai.

Step 1: Choose the right refresh interval for your use case

Photo by Genessa Panainte on Unsplash

Indexed data in OpenSearch is not immediately accessible. For efficiency, documents initially pass through an in-memory buffer before being indexed into the segments. If there are numerous heavy indexing processes, it is more effective to first keep the tokens in an in-memory buffer, and later transfer them to the shard segments; a process called “refresh”. There are costs and benefits to increasing and decreasing the refresh interval. Decreasing the refresh period makes the in-memory buffer less effective as it can only hold a certain number of tokens before it is time to index them to the segment. In general, increasing the refresh interval will improve search performance. However, if you increase the refresh interval too much, the refresh process will take longer to complete because of the large amount of data in the buffer, which could hurt the performance of your search. Moreover, long intervals mean that your data is in the memory buffer for longer and therefore is not searchable until the buffer is refreshed. In most circumstances, the default refresh interval of one second works well. However, keep in mind that many resources are used during refreshes and the interval should be appropriate for your use case. For example, if you are working with data from previous days and don’t require near-real-time data, you could refresh just once a day.

You can change the refresh interval simply using the refresh API, as follows:

PUT /<index_name>/_settings{
“index”: {
“refresh_interval”: “30s”
}
}

There are multiple caches that can help you improve search performance, such as the filesystem cache, the request cache, and the query cache. For example, you can improve performance by increasing the size of the node-level query cache. OpenSearch uses the node-level query cache to store the results of queries so that they can be returned more quickly when the index is searched again. By default, the cache can store up to 10,000 queries and takes up 10% of the heap’s total space. OpenSearch keeps a query history to track occurrences and assess whether a query qualifies for caching. The cache uses the Least Recently Used (LRU) policy — as it fills up, it removes the queries that haven’t been accessed for a while.

Your OpenSearch performance may suffer if your node-level query cache size is too small, as some of your queries may not be cached. To change the size, you can change the global setting parameter- indices.queries.cache.size, which accepts either a percentage value, like 5%, or an exact value, like 512MB:

The caches mentioned above are maintained at the node level, which limits their usefulness in some situations. For example. if you run the same request twice in a row (and have one or more replicas and use the default round-robin algorithm) each of the requests will go to different shard copies, preventing node-level cache from helping.

Another approach is using the shard-level request cache to improve search speed. When a search query is executed against an index or several indices, each involved shard conducts the search locally and sends its local results to the coordinating node, which merges these shard-level results into a “global” result set. The shard-level request cache module caches the local results on each shard. This allows heavy and frequently used search requests to return results very quickly. Users of search applications frequently run similar requests one after another, therefore making maximum use of this cache can improve search speed significantly.

The request cache is set to 1% by default. This can be changed by editing the opensearch.yml file parameter: indices.requests.cache.size

Image by the author

Shards are one of the main drivers of OpenSearch’s high availability and fast performance. In OpenSearch, every query runs on a single thread per shard. Multiple shards can be executed in parallel. If you have multiple shards, you have multiple threads running simultaneously. Shards enable concurrent searches, enhancing the efficiency of your search. However, having too many shards has its own drawbacks. The query process includes merging shards — the more shards you have, the more time you spend merging them. In addition to this, each shard utilizes resources for mapping, storing cluster state, querying, etc. The greater the number of shards, the higher the resource utilization, thereby decreasing performance. There is no single number of shards that is suitable for all scenarios. One popular strategy is to start with one shard and keep adding more until you get the best results. Generally, the recommended shard size should range from 30 GB to 50 GB.

You can change the number of shards and replicas using the API:

PUT <index_name>/_settings{
“index”: {
“number_of_shards”: 3,
“number_of_replicas”: 1
}
}
Photo by Nathália Rosa on Unsplash

Construct OpenSearch data and indices that are right for your use case:

Break your data down into smaller indices — OpenSearch stores data in indices. To store data, you can use one or more indices. All your data need not be kept in a single index. You can, for example, choose an index to store data for a month, a day, or an hour depending on your use case.

Avoid nested fields — Proper document design can help speed the processing of requests. Queries take longer when there are nested fields and parent-child hierarchies. To speed up queries, make your documents as flat as possible.

Consider mapping identifiers as keywords

It is not necessary to map every numeric value as a numeric field data type. Integer and long fields are suitable for OpenSearch range queries. However, term-level queries work better with keyword fields.

To improve retrieval speed, consider mapping fields as keyword fields if you don’t plan to search them using range queries. For example, identifiers like an ISBN or a product ID can be handled as keyword fields without affecting validity.

Reindex your data occasionally

Data in OpenSearch is immutable. When updating a document in OpenSearch, a new document is created rather than updating the existing one. The new document is assigned a version number, which helps OpenSearch track the latest and most relevant documents. However, as a result of including both new and old documents, the index expands significantly. Reindexing addresses this issue. After reindexing, your indices will contain only the most recent information, saving memory and speeding up subsequent searched.

This can be done using the API, as follows:

POST _reindex{
“source”: {
“index”: “my-index”
},
“dest”: {
“index”: “my-new-index”
}
}
Photo by Nicolas Hoizey on Unsplash

You probably chose OpenSearch because you need quick access to a large amount of data and don’t want to use a traditional database. However, even with the best optimization and software modifications, performance will still be inadequate without sufficient computing capabilities. Sufficient cache, disk space, CPUs, and RAM (Random-Access Memory) are crucial for peak OpenSearch performance.

One good option is to use advanced computing machines that have extended RAM. Your search latency will be reduced the more RAM you have. RAM enable applications to store and access data on a short-term basis. It stores the information your computer is actively using so that it can be accessed quickly. An example of such a device are AWS’s m5 instances, which consist of an Intel Xeon Platinum 8000 series processor. The combination of such a CPU processor and large RAM space can significantly enhance your search performance.

Another good option may be to shift your workload from a CPU and RAM based solution to non-traditional hardware solutions. Upgrading your computing resources is expensive and may not reduce latency. Sometimes, a solution which involves more advanced resources is required to address latency problems and boost search performance. GSI Technology’s APU is such a computing resource.

Imagine being able to do computational operations directly in memory rather than in the CPU, avoiding memory-processor bottlenecks and enjoying incredibly fast search performance. In fact, there is an OpenSearch plugin, which implements powerful semantic vector search on the APU. Using Searchium’s OpenSearch k-NN plugin, which is easily accessible via a payed subscription to their SaaS platform, in addition to the OpenSearch improvement suggestions mentioned above, is one way to speed up searches even more while also improving result accuracy and reducing infrastructure costs. Installing the plugin is easy. The plugin allows for vector similarity searches to be run as simply as any standard OpenSearch query. The plugin provides similarity search results in the standard OpenSearch format. Check out a more detailed explanation of how to install and use Searchium’s OpenSearch KNN and Searchium’s website, where you can get full access to the accelerator plugin. There is even a free tier where you can test it out!

Do your research, understand the demands of your company and consider how much and how frequently you’ll need to manipulate, query, and store data. This will help you understand what computing resources you need for the best OpenSearch experience.

Conclusion:

Data is essential to every business, especially in today’s fast-paced environment. Fast, effective handling and processing of complex data has become even more important than before. OpenSearch is a fantastic search engine that makes it possible to search data and get almost instant results. Since OpenSearch’s exceptional performance is essential for meeting business needs, I genuinely hope that this article helped you remove some of the impediments that stand in the way of peak performance.

FOLLOW US ON GOOGLE NEWS

Read original article here

Denial of responsibility! Techno Blender is an automatic aggregator of the all world’s media. In each content, the hyperlink to the primary source is specified. All trademarks belong to their rightful owners, all materials to their authors. If you are the owner of the content and do not want us to publish your materials, please contact us by email – [email protected]. The content will be deleted within 24 hours.

Leave a comment