From 833914cb5829555b2d2c65124c554913d2e9fb07 Mon Sep 17 00:00:00 2001
From: Fanit Kolchina <kolchfa@amazon.com>
Date: Wed, 27 Nov 2024 10:33:42 -0500
Subject: [PATCH] Editorial comments

Signed-off-by: Fanit Kolchina <kolchfa@amazon.com>
---
 _posts/2024-11-26-opensearch-performance-2.17.md | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/_posts/2024-11-26-opensearch-performance-2.17.md b/_posts/2024-11-26-opensearch-performance-2.17.md
index a225f5fb7..92f9b8a72 100644
--- a/_posts/2024-11-26-opensearch-performance-2.17.md
+++ b/_posts/2024-11-26-opensearch-performance-2.17.md
@@ -15,7 +15,7 @@ categories:
 meta_keywords: OpenSearch performance progress 2.17, OpenSearch roadmap
 meta_description: Learn more about the strategic enhancements and performance features that OpenSearch has delivered up to version 2.17.
 has_science_table: true
-excerpt: Learn more about the strategic enhancements and performance features that OpenSearch has delivered through version 2.17.
+excerpt: Learn more about the strategic enhancements and performance features that OpenSearch has delivered up to version 2.17.
 featured_blog_post: false
 featured_image: false 
 ---
@@ -24,9 +24,9 @@ OpenSearch has always been committed to expanding functionality, scalability, an
 
 The wide range of applications that OpenSearch supports means that no one number can summarize the improvements you'll see in your applications. That's why we're reporting on a variety of performance metrics, some mostly relevant to analytics in general and log analytics in particular, others mostly relevant to lexical search, and still others relevant to semantic search using vector embeddings and k-NN. Under the rubric of performance, we're also including improvements in resource utilization, notably RAM and disk.
 
-Overall, OpenSearch 2.17 delivers a 6x performance improvement over OpenSearch 1.3, with gains across essential operations such as text queries, term aggregations, range queries, date histograms, and sorting. And that's not even counting improvements to semantic vector search, which is now highly configurable in order to let you choose the ideal balance of response time, accuracy, and cost for your applications. All these improvements reflect the contributions and collaboration of a dedicated community, whose insights and efforts drive OpenSearch forward.
+Overall, OpenSearch 2.17 delivers a 6x performance improvement over OpenSearch 1.3, with gains across essential operations such as text queries, terms aggregations, range queries, date histograms, and sorting. And that's not even counting improvements to semantic vector search, which is now highly configurable in order to let you choose the ideal balance of response time, accuracy, and cost for your applications. All these improvements reflect the contributions and collaboration of a dedicated community, whose insights and efforts drive OpenSearch forward.
 
-This post highlights the performance improvements in OpenSearch 2.17. The first section focuses on key query operations, including text queries, term aggregations, range queries, date histograms, and sorting. These improvements were evaluated using the [OpenSearch Big5 workload](https://github.com/opensearch-project/opensearch-benchmark-workloads/tree/main/big5), which represents common use cases in both search and analytics applications. The benchmarks provide a repeatable framework for measuring real-world performance enhancements. The next section reports on vector search improvements. Finally, we present our roadmap for 2025, where you'll see that we're making qualitative improvements in many areas, in addition to important incremental changes. We are improving query speed by processing data in real time. We are building a query planner that uses resources more efficiently. We are speeding up intra-cluster communications. And we're adding efficient join operations to query domain-specific language (DSL), Piped Processing Language (PPL), and SQL. To follow our work in more detail, and to contribute comments or code, please participate on the [OpenSearch forum](https://forum.opensearch.org/) as well as directly in our GitHub repos.
+This post highlights the performance improvements in OpenSearch 2.17. The first section focuses on key query operations, including text queries, terms aggregations, range queries, date histograms, and sorting. These improvements were evaluated using the [OpenSearch Big5 workload](https://github.com/opensearch-project/opensearch-benchmark-workloads/tree/main/big5), which represents common use cases in both search and analytics applications. The benchmarks provide a repeatable framework for measuring real-world performance enhancements. The next section reports on vector search improvements. Finally, we present our roadmap for 2025, where you'll see that we're making qualitative improvements in many areas, in addition to important incremental changes. We are improving query speed by processing data in real time. We are building a query planner that uses resources more efficiently. We are speeding up intra-cluster communications. And we're adding efficient join operations to query domain-specific language (DSL), Piped Processing Language (PPL), and SQL. To follow our work in more detail, and to contribute comments or code, please participate on the [OpenSearch forum](https://forum.opensearch.org/) as well as directly in our GitHub repos.
 
 <style>
 .green-clr {
@@ -113,11 +113,11 @@ Text queries are fundamental to effective text search, especially in application
 
 With OpenSearch 2.17, we further amplified these performance gains. Building on the foundation of the **match_only_text** field, OpenSearch 2.17 optimizes text queries, achieving **21% faster performance compared to 2.14** and **63% faster performance compared to 1.3**. These improvements stem from continued enhancements to query execution and index optimization. Applications relying on text search for analytics or high-recall use cases can now achieve faster results with reduced resource usage, making OpenSearch 2.17 an even more powerful choice for modern text search workloads.
 
-### Term and multi-term aggregations 
+### Terms and multi-terms aggregations 
 
-Term aggregations are crucial for slicing large datasets based on multiple criteria, making them important query operations for data analytics use cases. Building on prior advancements, OpenSearch 2.17 enhances the efficiency of global term aggregations, using term frequency optimizations to handle large immutable collections, such as log data, with unprecedented speed. 
+Terms aggregations are crucial for slicing large datasets based on multiple criteria, making them important query operations for data analytics use cases. Building on prior advancements, OpenSearch 2.17 enhances the efficiency of global terms aggregations, using term frequency optimizations to handle large immutable collections, such as log data, with unprecedented speed. 
 
-Performance benchmarks demonstrate a **61% performance improvement compared to OpenSearch 2.14** and an overall **81% reduction in query latency compared to OpenSearch 1.3**, while **multi-term aggregation queries demonstrate up to a 20% reduction in latency**. Additionally, memory efficiency is improved dramatically, with a **50--60% reduction in memory footprint for short-lived objects** because new byte array allocations for composite key storage are not needed. 
+Performance benchmarks demonstrate a **61% performance improvement compared to OpenSearch 2.14** and an overall **81% reduction in query latency compared to OpenSearch 1.3**, while **multi-terms aggregation queries demonstrate up to a 20% reduction in latency**. Additionally, memory efficiency is improved dramatically, with a **50--60% reduction in memory footprint for short-lived objects** because new byte array allocations for composite key storage are not needed. 
 
 OpenSearch 2.17 also introduced support for the **[wildcard field type](https://github.com/opensearch-project/OpenSearch/pull/13461)**, enabling highly efficient execution of wildcard, prefix, and regular expression queries. This new field type uses trigrams (or bigrams and individual characters) to match patterns before applying a post-filtering step to evaluate the original field, resulting in faster and more efficient query execution.
 
@@ -177,7 +177,7 @@ In 2025, we will continue to invest in the following key initiatives aimed at pe
 * **Index build acceleration with GPUs and SIMD:** k-NN performance can be enhanced by using libraries with GPU support. Because vector distance calculations are compute-heavy, GPUs can speed up computations and reduce index build and search query times.
 * **Autotuning k-NN indexes:** OpenSearch's vector database offers a toolkit of algorithms tailored for diverse workloads. In 2025, our goal is to enhance the out-of-the-box experience by autotuning hyperparameters and settings based on access patterns and hardware resources.
 * **Cold-warm tiering:** In version 2.18, we added support for enabling vector search on remote snapshots. We will continue focusing on decoupling index read/write operations to extend vector indexes to different storage systems in order to reduce storage and compute costs.
-* **Memory footprint reduction:** We will continue to aggressively reduce the memory footprint of vector indexes. One of our goals is to support the ability to partially load HNSW indexes into native engines. This complements our disk-based-optimized search and helps further reduce the operating costs of OpenSearch clusters.
+* **Memory footprint reduction:** We will continue to aggressively reduce the memory footprint of vector indexes. One of our goals is to support the ability to partially load HNSW indexes into native engines. This complements our disk-optimized search and helps further reduce the operating costs of OpenSearch clusters.
 * **Reduced disk storage with "derived source":** Currently, vector data is stored both in a doc-values-like format and in the stored `_source` field. The stored `_source` field can contribute more than 60% of the overall vector storage requirement. We plan to create a custom stored field format that will inject the vector fields into the source from the doc-values-like format. In addition to storage savings, this will have the secondary effects of improved indexing throughput, lighter shards, and even faster search.
 
 ### Neural search
@@ -200,7 +200,7 @@ These advancements aim to enhance query performance, streamline operations, and
 
 OpenSearch continues to evolve, not only by expanding functionality but also by significantly enhancing performance, efficiency, and scalability across diverse workloads. OpenSearch 2.17 exemplifies the community's commitment, delivering improvements in query speed, resource utilization, and memory efficiency across text queries, aggregations, range queries, and time-series analytics. These advancements underscore our dedication to optimizing OpenSearch for real-world use cases.
 
-Key innovations like disk-optimized vector search and enhancements to term and multi-term aggregations demonstrate our focus on staying at the forefront of vector search and analytics technology. Additionally, OpenSearch 2.17's improvements to hybrid and vector search, combined with roadmap plans for streaming architecture, gRPC APIs, and smarter query planning, highlight our forward-looking strategy for meeting the demands of modern workloads.
+Key innovations like disk-optimized vector search and enhancements to terms and multi-terms aggregations demonstrate our focus on staying at the forefront of vector search and analytics technology. Additionally, OpenSearch 2.17's improvements to hybrid and vector search, combined with roadmap plans for streaming architecture, gRPC APIs, and smarter query planning, highlight our forward-looking strategy for meeting the demands of modern workloads.
 
 These achievements are made possible through collaboration with the broader OpenSearch community, whose contributions to testing, feedback, and development have been invaluable. Together, we are building a robust and efficient search and analytics engine capable of addressing current and future challenges.