OpenSearch 3.0 रिलीज़ - vector database performance और AI-आधारित search infrastructure में बड़ा सुधार

(opensearch.org)

12 पॉइंट द्वारा GN⁺ 2025-05-09 | 3 टिप्पणियां | WhatsApp पर शेयर करें

OpenSearch 3.0 आधिकारिक रूप से जारी हो गया है और OpenSearch 1.3 की तुलना में 9.5 गुना बेहतर performance प्रदान करता है
vector search के लिए GPU acceleration, AI agent integration, storage optimization सहित कई महत्वपूर्ण फीचर जोड़े गए हैं
gRPC, Kafka streaming, index auto-detection के ज़रिये data processing efficiency और flexibility को मजबूत किया गया है
search infrastructure के स्तर पर Lucene 10, Java 21, modular architecture को अपनाकर future scalability और maintainability में सुधार किया गया है
AI और RAG-आधारित search की बढ़ती मांग के जवाब में यह open source community-आधारित अगली पीढ़ी का search platform बनकर उभर रहा है

OpenSearch 3.0 आधिकारिक रिलीज़: AI युग के लिए vector search optimization

OpenSearch Software Foundation ने OpenSearch 3.0 का आधिकारिक संस्करण जारी करते हुए OpenSearch 1.3 की तुलना में 9.5 गुना performance improvement की घोषणा की
AI search, recommendation systems, RAG आदि में आवश्यक बड़े पैमाने के vector data processing performance में सुधार किया गया है

vector engine में नवाचार: performance और cost efficiency दोनों हासिल

GPU acceleration (NVIDIA cuVS आधारित): index build time को अधिकतम 9.3 गुना तक कम किया गया, जिससे high-performance workloads को संभालना आसान हुआ
Model Context Protocol (MCP) support: AI agents के साथ integration के ज़रिये flexible search solutions बनाए जा सकते हैं
Derived Source feature: duplicate vector data हटाकर storage usage को 1/3 तक कम किया गया

data management features: flexibility और scalability में सुधार

gRPC support: node-to-node और client-server data transfer को तेज़ बनाता है (experimental)
Pull-आधारित data ingestion: Kafka, Kinesis जैसे external streaming systems से OpenSearch सीधे data लाने वाली संरचना लागू
Reader-Writer separation: search और indexing को अलग करके दोनों कार्यों की stability और performance सुनिश्चित
Apache Calcite integration: SQL/PPL में intuitive query builder फीचर उपलब्ध
index type detection: log index को अपने आप पहचानकर उपयुक्त analysis options प्रदान करता है

search infrastructure और platform core में सुधार

Lucene 10 upgrade: parallel processing performance बेहतर हुई और search capabilities उन्नत हुईं
Java 21 minimum supported runtime: नवीनतम language features और performance improvements का उपयोग संभव
Java module system adoption: monolithic structure को library-आधारित संरचना में बदलकर maintainability सुधारी गई

open community-केंद्रित sustainable innovation

OpenSearch, Linux Foundation के अंतर्गत एक स्वतंत्र community पर आधारित open source search platform है
AWS, SAP, Uber जैसी प्रमुख कंपनियाँ और हज़ारों contributors इसमें भाग ले रहे हैं
vector DB युग के अनुरूप scalability और transparent governance पर ज़ोर देते हुए, ऐसे ecosystem की दिशा में बढ़ रहा है जिसमें कोई भी भाग ले सके
विस्तृत release जानकारी official blog और release notes में देखी जा सकती है

3 टिप्पणियां

kaydash 2025-05-12

Elasticsearch AGPL है, इसलिए उसे इस्तेमाल करना डरावना लगता है, और मैं लगातार on-premise में सिर्फ OpenSearch ही इस्तेमाल कर रहा हूँ।

GN⁺ 2025-05-09

Hacker News की राय

मुझे अभी-अभी OpenSearch के बारे में पता चला। यह Elasticsearch के लाइसेंस बदलने के बाद 2021 में fork किया गया प्रोजेक्ट है। मैं जानना चाहता हूँ कि क्या यह अब भी Elasticsearch का विकल्प बन सकता है, और performance व features की तुलना कैसी है।
- मैं Kotlin में Elasticsearch और OpenSearch दोनों के लिए client (kt-search) maintain करता हूँ।
  - ज़्यादातर commonly used features में API अभी भी compatible है।
  - vector search जैसी वे features जो fork के बाद जोड़ी गईं, अपवाद हैं।
  - search_after जैसी कुछ features दोनों में अलग तरह से काम करती हैं, और client इसमें मदद करता है।
  - दोनों products में SQL query feature है, लेकिन implementation अलग है।
  - feature के मामले में Elastic अब भी आगे है, खासकर Kibana की capabilities Amazon fork से ज़्यादा समृद्ध हैं।
  - aggregation features में भी Elastic ने पिछले कुछ सालों में काफी optimization और upgrades पर ध्यान दिया है।
  - performance use case पर निर्भर करती है; दोनों products Lucene (open source search library) पर आधारित हैं।
  - AWS पर OpenSearch की तुलना में Elastic Cloud थोड़ा बेहतर है।
  - अगर self-hosting और tuning खुद करें, तो दोनों products काफी समान हो जाते हैं।
  - Elastic 9.0 और OpenSearch 3.0 दोनों नए Lucene version का उपयोग करते हैं, और client दोनों को support करता है।
  - consulting clients में open source license और AWS support की वजह से OpenSearch को पसंद करने के मामले बढ़ रहे हैं।
  - legacy Elasticsearch से OpenSearch में जाने के लिए सारा data फिर से reindex करना पड़ता है, और libraries भी बदलनी पड़ सकती हैं। यह काफी झंझट है, इसलिए मैंने kt-search बनाया।
  - हमारे पास बहुत से पुराने Elasticsearch 2.3 databases थे, इसलिए हर database के लिए parallel में OpenSearch खड़ा किया और service startup पर data bulk copy किया। अब तक OpenSearch से कुल मिलाकर संतुष्ट हूँ।
  - विस्तृत explanation के लिए धन्यवाद, यह उपयोगी लगा।
- OpenSearch में हाल में जिस चीज़ की कमी खली, वह enrich processors feature है (document link दिया गया)।
  - अगर आप सिर्फ standard document ingestion और search features का उपयोग करते हैं, तो ज़्यादातर चीज़ें compatible हैं।
  - paid version में मिलने वाली advanced features अक्सर compatible नहीं होतीं या गायब रहती हैं।
- Elasticsearch version 9.0+ तक आगे बढ़ चुका है, और OpenSearch की तुलना में उसमें 27,000 commits ज़्यादा हैं।
  - अब इसे drop-in replacement कहना मुश्किल है।
  - इनमें से कितने core features हैं, यह नहीं पता, लेकिन इससे समझ आता है कि दोनों projects कितने अलग हो चुके हैं।
- सितंबर 2024 से Elasticsearch फिर से पूरी तरह open source license (AGPLv3) में लौट आया है।
  - इस पर किसी ने पुराने धोखे जैसा अनुभव याद किया।
  - Elastic Search अब भी open core है; enterprise features कभी open source version में शामिल नहीं होंगी, जबकि OpenSearch पर ऐसी पाबंदी नहीं है।
- OpenSearch पूर्ण विकल्प नहीं है, लेकिन लगभग compatible है; 1.x version Elasticsearch 7.10 के साथ compatible है।
- उसी hardware पर OpenSearch थोड़ा धीमा है। अगर आपको UI चाहिए, तो सावधान रहें; Kibana fork धीमा है और bugs भी ज़्यादा हैं।
  - असल स्थिति थोड़ी अधिक जटिल है; दोनों products के अपने-अपने workflows हैं जिनमें वे मजबूत हैं।
  - हमारी कंपनी ने दोनों का व्यापक benchmark किया है; अगर दिलचस्पी हो तो उस blog post को देख सकते हैं।
- OpenSearch नाम मूल रूप से Amazon की subsidiary A9 द्वारा बनाए गए personal search result aggregation service से आया था।
  - यह भी कहा गया कि एक ही नाम के कई अर्थ हो सकते हैं।
OpenSearch project को लेकर अफसोस जताया गया।
- यह Elasticsearch के license change के विरोध में AWS के साथ मिलकर बना एक प्रतिक्रियात्मक project था।
- community किसी निष्क्रिय multiplayer game जैसी लगती है, जिसमें open source projects के लिए ज़रूरी ऊर्जा की कमी है।
- मैंने किसी company या enterprise customer को इसे Elasticsearch replacement के रूप में अपनाते नहीं देखा; यह अभी पूरी तरह साबित नहीं हुआ और long-term commitment पर भरोसा भी कम है।
- अलग-अलग SIEM platforms अपने-अपने search platforms बना रहे हैं।
- Elastic ने भी SIEM platform (Elastic Security) लॉन्च किया है।
- Elastic ने खुद को फिर open source बताया है, लेकिन management किसी unproven fork पर migration cost खर्च नहीं करेगी; इससे project का उद्देश्य और भी अस्पष्ट हो जाता है।
  - मैं फिर से Elastic का उपयोग नहीं करना चाहता। Lucene–Solr–custom extension वाला क्रम मैं खुद इस्तेमाल कर चुका हूँ, और Elastic Search की ज़रूरत मुझे सिर्फ AWS उपयोग करते समय पड़ी थी। फिर भी OpenSearch migration के बाद इसका उपयोग ठीक-ठाक रहा है।
  - मुझे लगता है कि OpenSearch और AWS की वजह से Elastic को लंबे समय तक आर्थिक नुकसान हुआ।
क्या यहाँ कोई OpenSearch के knn और vector features का उपयोग कर रहा है? बड़े scale पर production में यह कैसा है, जानना चाहता हूँ।
- OpenSearch implementation के बारे में तो नहीं जानता, लेकिन Redis के लिए vector set को HNSW structure में खुद implement करने का अनुभव साझा कर सकता हूँ।
  - अगर HNSW अच्छी तरह implement हो, तो यह काफी बड़े scale पर भी अच्छा काम करता है।
  - एक single HNSW insertion speed प्रति सेकंड कुछ हज़ार तक होती है, और read उससे कहीं तेज़ होते हैं (multi-core environment में)।
  - शुरुआती bulk insert बहुत धीमा हो सकता है, लेकिन इसे parallelize किया जा सकता है।
  - HNSW की inefficiency memory usage में है; disk पर रखने से random seeking होती है।
  - 1024-dimensional जैसे high-dimensional vectors के लिए quantization ज़रूरी है।
- अगर vector embedding dimension बहुत ऊँचा हो, तो knn से ज़्यादा HNSW जैसी approximate nearest neighbor search method की सिफारिश है।
  - मैं खुद opensearch को text, multimodal embeddings और metadata-आधारित hybrid search में उपयोग कर रहा हूँ।
  - अभी यह पूरी तरह large-scale production नहीं है, लेकिन opensearch होने की वजह से scalability को लेकर आशावादी हूँ।
- मेरे अनुभव में तो इसका लगातार उपयोग होता है। performance embedding model पर निर्भर है, और index tuning बहुत महत्वपूर्ण है।
  - Lucene HNSW इस्तेमाल करने पर Java Heap RAM काफी consume होती है।
  - FAISS या nmslib plugin इस्तेमाल करें, तो JNI RAM पर भी ध्यान देना पड़ता है।
  - 10 करोड़ से ज़्यादा vectors वाले बड़े ANN को आसानी से scale करना सरल नहीं है; इसके लिए team का focused support चाहिए।
- एक स्वीकार किया हुआ caveat है: लाखों documents की search performance ठीक रहती है, लेकिन KNN search के लिए पूरे embedding graph को RAM में लाना पड़ता है, इसलिए RAM management ही मुख्य बात है।
  - result quality आखिरकार embedding quality पर ही निर्भर करती है।
मुझे ऐसा log ingesting tool चाहिए था जो simple syslog parsing कर सके और fields को graph/search कर सके, लेकिन Opensearch या ELK setup बहुत पेचीदा लगा।
- मुझे हैरानी हुई कि Elastic और Opensearch दोनों में ऐसी basic setup भी उम्मीद से ज़्यादा कठिन है।
  - सब कुछ configuration-driven है, इसलिए recipe खुद बनानी पड़ती है।
  - opentelemetry जैसे मददगार tools हैं, लेकिन फिर भी असुविधा बनी रहती है।
  - अगर दोनों tools की official guidelines ही मानें, तो इन्हें जल्दी इस्तेमाल किया जा सकता है; समस्या तब होती है जब custom logic चाहिए।
  - simple requirements हों तो logstash के बिना भी काम चल सकता है।
  - Elastic और opensearch app metrics के लिए उपयुक्त नहीं हैं; उस स्थिति में prometheus, grafana की सिफारिश है।
  - अगर Elastic ecosystem (beats, logstash आदि) में निवेश करें, तो कई index templates और pipeline configurations संभव हैं।
  - अब dynamic field mapping की वजह से Elasticsearch में data input/output काफी आसान हो गया है।
  - performance बनाए रखना उससे बड़ा concern है।
- क्या आपने Graylog आज़माया है? मेरी workplace में हम इसका काफी ठीक-ठाक उपयोग कर रहे हैं।

davidayo 2025-05-11

OpenSearch 2021 में Elasticsearch के license बदलने के बाद सामने आया, जिसका लक्ष्य एक compatible replacement बनना था। हालांकि यह काफी हद तक compatible है, खासकर version 1.x का Elasticsearch 7.10 के साथ, लेकिन यह पूरी तरह drop-in solution नहीं है। Elasticsearch आगे और विकसित हुआ है और इसमें ज़्यादा features व optimizations हैं, खासकर Kibana और aggregations में। Performance application पर निर्भर करती है, क्योंकि दोनों Lucene पर बने हैं। कुछ users को OpenSearch धीमा लगता है और इसके Kibana forks buggy लगते हैं। सितंबर 2024 में Elasticsearch के फिर से open source (AGPLv3) होने के बावजूद, कुछ लोग इसकी truly open-source nature और AWS support की वजह से OpenSearch को पसंद करते हैं। हालांकि vector search एक अहम differentiator है, बड़े पैमाने के implementations के लिए RAM management पर सावधानी से ध्यान देना पड़ता है। अंततः, चुनाव specific needs पर निर्भर करता है, और दोनों की अपनी strengths और weaknesses हैं। मैं Davidayo https://www.davidayo.com के साथ opensearch पर काम कर रहा हूँ, AI powerful tool "AskPromptAI" https://askpromptai.com.