Rilis OpenSearch 3.0 - Performa basis data vektor dan infrastruktur pencarian berbasis AI ditingkatkan besar-besaran

 (opensearch.org)
12 poin oleh GN⁺ 2025-05-09 | 3 komentar | Bagikan ke WhatsApp
  • OpenSearch 3.0 resmi dirilis dan menghadirkan performa 9,5 kali lebih tinggi dibanding OpenSearch 1.3
  • Menambahkan banyak fitur inovatif untuk pencarian vektor seperti akselerasi GPU, integrasi agen AI, dan optimasi penyimpanan
  • Meningkatkan efisiensi dan fleksibilitas pemrosesan data dengan gRPC, streaming Kafka, dan identifikasi indeks otomatis
  • Dari sisi infrastruktur pencarian, Lucene 10, Java 21, dan arsitektur modular diterapkan untuk meningkatkan skalabilitas masa depan dan kemudahan pemeliharaan
  • Memantapkan posisinya sebagai platform pencarian generasi berikutnya berbasis komunitas open source yang menjawab meningkatnya kebutuhan pencarian berbasis AI dan RAG

OpenSearch 3.0 Resmi Dirilis: Optimasi pencarian vektor untuk era AI

  • OpenSearch Software Foundation merilis versi resmi OpenSearch 3.0 dan mengumumkan peningkatan performa 9,5 kali dibanding OpenSearch 1.3
  • Meningkatkan performa pemrosesan data vektor berskala besar yang dibutuhkan untuk pencarian AI, sistem rekomendasi, RAG, dan lainnya

Inovasi mesin vektor: performa dan efisiensi biaya sekaligus

  • Akselerasi GPU (berbasis NVIDIA cuVS): waktu pembuatan indeks dipersingkat hingga 9,3 kali, mendukung beban kerja berperforma tinggi
  • Dukungan Model Context Protocol (MCP): memungkinkan pembangunan solusi pencarian yang fleksibel melalui integrasi dengan agen AI
  • Fitur Derived Source: menghapus duplikasi data vektor sehingga penggunaan penyimpanan berkurang hingga 1/3

Fitur manajemen data: fleksibilitas dan skalabilitas diperkuat

  • Dukungan gRPC: mempercepat transfer data antar node dan antara klien-server (eksperimental)
  • Pengumpulan data berbasis pull: menerapkan struktur di mana OpenSearch mengambil data secara langsung dari sistem streaming eksternal seperti Kafka dan Kinesis
  • Pemisahan Reader-Writer: memisahkan pencarian dan pengindeksan untuk menjamin stabilitas dan performa masing-masing tugas
  • Integrasi Apache Calcite: menyediakan fitur pembangun kueri yang intuitif di SQL/PPL
  • Deteksi jenis indeks: secara otomatis mengidentifikasi indeks log dan menyediakan opsi analisis yang sesuai

Peningkatan infrastruktur pencarian dan inti platform

  • Upgrade ke Lucene 10: meningkatkan performa pekerjaan paralel dan memajukan kemampuan pencarian
  • Runtime minimum Java 21: memungkinkan pemanfaatan fitur bahasa dan performa terbaru
  • Penerapan sistem modul Java: mengubah struktur monolitik menjadi berbasis library untuk meningkatkan kemudahan pemeliharaan

Inovasi berkelanjutan berpusat pada komunitas terbuka

  • OpenSearch adalah platform pencarian open source berbasis komunitas independen di bawah Linux Foundation
  • Diikuti oleh perusahaan besar seperti AWS, SAP, Uber, serta ribuan kontributor
  • Menekankan skalabilitas yang sesuai untuk era basis data vektor dan tata kelola yang transparan, sambil mengarah pada ekosistem yang dapat diikuti siapa saja
  • Informasi rilis lebih lanjut dapat dilihat di blog resmi dan catatan rilis

Bacaan terkait

3 komentar

 
kaydash 2025-05-12

Karena Elasticsearch berlisensi AGPL, saya jadi khawatir menggunakannya, jadi saya terus memakai hanya OpenSearch secara on-premise.
 
GN⁺ 2025-05-09
Opini Hacker News

  • Baru tahu tentang OpenSearch; ini adalah proyek hasil fork pada 2021 setelah perubahan lisensi Elasticsearch. Muncul rasa ingin tahu apakah masih bisa dipakai sebagai pengganti Elasticsearch, serta bagaimana perbandingan performa dan fiturnya.

    • Saya memelihara klien Kotlin untuk Elasticsearch dan OpenSearch sekaligus (kt-search).

      • Untuk sebagian besar fitur yang sering dipakai, API-nya masih kompatibel.

      • Pengecualian utamanya adalah fitur yang ditambahkan setelah fork, seperti pencarian vektor.

      • Beberapa fitur seperti search_after berperilaku berbeda, dan klien kami menutup perbedaan itu.

      • Keduanya sama-sama punya fitur kueri SQL, tetapi implementasinya berbeda.

      • Dari sisi fitur, Elastic masih unggul, terutama karena kemampuan Kibana lebih kaya daripada fork buatan Amazon.

      • Untuk agregasi juga, Elastic dalam beberapa tahun terakhir banyak berfokus pada optimisasi dan peningkatan.

      • Performa bergantung pada tujuan penggunaan; keduanya sama-sama berbasis Lucene, pustaka pencarian open source.

      • Elastic Cloud sedikit lebih baik daripada OpenSearch di AWS.

      • Jika self-hosting dan tuning dilakukan sendiri, keduanya jadi sangat mirip.

      • Elastic 9.0 dan OpenSearch 3.0 sama-sama memakai versi Lucene baru, dan klien saya mendukung keduanya.

      • Di antara klien konsultasi saya, makin banyak yang memilih OpenSearch karena lisensi open source dan dukungan AWS.

      • Jika ingin pindah dari Elasticsearch lama ke OpenSearch, semua data harus diindeks ulang dan mungkin juga perlu mengganti library; cukup merepotkan, itulah alasan saya membuat kt-search.

      • Saya punya banyak database Elasticsearch 2.3 lama, jadi saya menjalankan OpenSearch secara paralel untuk tiap database dan menyalin data secara batch saat layanan mulai. Sejauh ini saya cukup puas dengan OpenSearch.

      • Terima kasih atas penjelasannya; sangat berguna.

    • Hal yang belakangan saya rasakan kurang di OpenSearch adalah tidak adanya fitur enrich processors (tautan dokumentasi disertakan).

      • Jika hanya memakai fungsi standar untuk ingest dan pencarian dokumen, sebagian besar tetap kompatibel.
      • Fitur lanjutan yang dulu tersedia di versi berbayar sering kali tidak kompatibel atau memang tidak ada.

    • Elasticsearch sudah berkembang sampai versi 9.0 ke atas, dan punya 27.000 commit lebih banyak daripada OpenSearch.

      • Sulit lagi menyebutnya sebagai drop-in replacement.
      • Tidak tahu berapa banyak di antaranya yang benar-benar fitur inti, tetapi itu menunjukkan seberapa jauh kedua proyek ini sudah berbeda.

    • Sejak September 2024, Elasticsearch kembali memakai lisensi open source penuh (AGPLv3).

      • Ada komentar yang mengingat pengalaman pernah tertipu soal hal seperti ini.

      • Elastic Search tetap open core; fitur "enterprise" tidak akan pernah masuk ke versi open source, sedangkan OpenSearch tidak punya batasan seperti itu.

    • OpenSearch bukan pengganti yang "sepenuhnya" sama, tetapi nyaris kompatibel; versi 1.x kompatibel dengan Elasticsearch 7.10.

    • Pada hardware yang sama, OpenSearch agak lebih lambat. Jika butuh UI, perlu berhati-hati; fork Kibana berjalan lambat dan banyak bug.

      • Kenyataannya sedikit lebih rumit; keduanya punya workflow yang menjadi keunggulan masing-masing.
      • Perusahaan kami melakukan benchmark menyeluruh terhadap keduanya; kalau penasaran dengan hasilnya, silakan lihat posting blog tersebut.

    • Nama OpenSearch awalnya berasal dari layanan agregasi hasil pencarian pribadi yang dikembangkan oleh A9, anak perusahaan Amazon.

      • Disebutkan juga bahwa nama yang sama bisa punya beberapa makna.

  • Ada ungkapan penyesalan terhadap proyek OpenSearch.

    • Ini dianggap sebagai proyek reaktif yang dibuat bersama AWS sebagai respons terhadap perubahan lisensi Elasticsearch.

    • Komunitasnya terasa seperti game multipemain yang sudah tidak aktif, kurang vitalitas yang penting bagi proyek open source.

    • Belum pernah mendengar ada perusahaan atau pelanggan enterprise yang benar-benar menggantikan Elastic Search dengannya; masih terasa belum terbukti dan kurang meyakinkan untuk komitmen jangka panjang.

    • Berbagai platform SIEM sekarang malah membangun platform pencarian mereka sendiri-sendiri.

    • Elastic juga merilis platform SIEM, yaitu Elastic Security.

    • Walaupun Elastic kini kembali menyatakan dirinya open source, manajemen tidak akan mau menanggung biaya migrasi ke fork yang belum terbukti, sehingga tujuan proyeknya jadi tidak jelas.

      • Saya pribadi tidak ingin kembali memakai Elastic. Saya pernah langsung memakai Lucene–Solr–versi ekstensi kustom, dan Elastic Search hanya terasa perlu saat menggunakan AWS. Meski begitu, setelah pindah ke OpenSearch, sejauh ini penggunaannya cukup baik.

      • Saya rasa Elastic sudah cukup lama terkena dampak ekonomi dari OpenSearch dan AWS.

  • Ada yang ingin tahu apakah orang benar-benar memakai fitur knn dan vektor di OpenSearch, serta bagaimana perilakunya dalam operasi skala besar yang nyata.

    • Saya tidak tahu implementasi OpenSearch-nya, tetapi pernah mengimplementasikan sendiri vector set untuk Redis dengan struktur HNSW.

      • Jika HNSW diimplementasikan dengan baik, ini bekerja cukup baik bahkan pada skala yang besar.
      • Kecepatan insert pada satu HNSW ada di kisaran ribuan per detik, sementara read jauh lebih cepat, terutama di lingkungan multicore.
      • Bulk insert awal bisa sangat lambat, tetapi bisa diparalelkan.
      • Kekurangan HNSW adalah penggunaan memorinya besar, dan jika disimpan di disk akan menimbulkan random seek.
      • Untuk vektor berdimensi tinggi seperti 1024 dimensi, quantization itu wajib.

    • Jika dimensi embedding vektor tinggi, saya lebih menyarankan approximate nearest neighbor seperti HNSW daripada knn murni.

      • Saya sendiri memakai OpenSearch untuk pencarian hybrid berbasis teks, embedding multimodal, dan metadata.
      • Belum sepenuhnya pada skala besar, tetapi karena ini OpenSearch, saya cukup optimistis soal skalabilitasnya.

    • Dalam pengalaman saya, fitur ini selalu dipakai; performanya bergantung pada model embedding, dan tuning indeks itu penting.

      • Saat memakai Lucene HNSW, Java Heap RAM akan banyak terpakai.
      • Jika memakai plugin FAISS atau nmslib, RAM JNI juga harus diperhatikan.
      • Tidak mudah menskalakan ANN berskala sangat besar, misalnya di atas 100 juta vektor, tanpa dukungan fokus dari tim.

    • Ada caveat yang sudah umum diterima: performa pencarian pada jutaan dokumen cukup baik, tetapi untuk pencarian KNN seluruh graf embedding harus dimuat ke RAM, jadi manajemen RAM menjadi kunci.

      • Kualitas hasil pada akhirnya ditentukan oleh kualitas embedding.

  • Saya ingin alat ingest log sederhana yang bisa mem-parsing syslog serta membuat grafik bidang dan pencarian, tetapi konfigurasi OpenSearch atau ELK terasa terlalu rumit.

    • Saya terkejut bahwa bahkan penyiapan dasar seperti ini ternyata sulit, baik di Elastic maupun OpenSearch.

      • Semuanya sangat berbasis konfigurasi, jadi kita harus menyusun resepnya sendiri.

      • Ada alat bantu seperti OpenTelemetry, tetapi tetap saja kurang nyaman.

      • Jika hanya mengikuti panduan resmi, keduanya sebenarnya bisa dipakai dengan cepat; masalah muncul saat butuh logika kustom.

      • Untuk kebutuhan sederhana, ini bisa dilakukan tanpa logstash.

      • Elastic dan OpenSearch kurang cocok untuk app metrics; untuk itu lebih disarankan prometheus dan grafana.

      • Jika berinvestasi di ekosistem Elastic seperti beats dan logstash, kita bisa menyusun berbagai template indeks dan pipeline.

      • Sekarang, berkat dynamic field mapping, input dan output data ke Elasticsearch jadi sangat mudah.

      • Tantangan yang lebih besar justru menjaga performanya.

    • Sudah coba Graylog? Di tempat kerja saya, kami memakainya dengan cukup baik.
 
davidayo 2025-05-11

OpenSearch muncul pada 2021 setelah perubahan lisensi Elasticsearch, dengan tujuan menjadi pengganti yang kompatibel. Meski sebagian besar kompatibel, terutama versi 1.x dengan Elasticsearch 7.10, ini bukan solusi drop-in yang sepenuhnya lengkap. Elasticsearch telah berkembang lebih jauh, dengan lebih banyak fitur dan optimasi, terutama pada Kibana dan agregasi. Performa bergantung pada aplikasi, dengan keduanya dibangun di atas Lucene. Sebagian pengguna merasa OpenSearch lebih lambat dan fork Kibana-nya memiliki bug. Meski Elasticsearch kembali menjadi open source (AGPLv3) pada September 2024, sebagian orang tetap memilih OpenSearch karena sifatnya yang benar-benar open source dan dukungan AWS. Walau pencarian vektor adalah pembeda utama, implementasi skala besar memerlukan pengelolaan RAM yang cermat. Pada akhirnya, pilihan bergantung pada kebutuhan spesifik, karena keduanya sama-sama memiliki kelebihan dan kekurangan. Saya sedang mengerjakan OpenSearch bersama Davidayo https://www.davidayo.com alat AI yang kuat "AskPromptAI" https://askpromptai.com.