OpenSearch 3.0 yayımlandı - vektör veritabanı performansı ve yapay zeka tabanlı arama altyapısı büyük ölçüde güçlendirildi

 (opensearch.org)
12 puan yazan GN⁺ 2025-05-09 | 3 yorum | WhatsApp'ta paylaş
  • OpenSearch 3.0 resmen yayımlandı ve OpenSearch 1.3'e kıyasla 9,5 kat daha yüksek performans sunuyor
  • GPU hızlandırma, AI agent entegrasyonu, depolama optimizasyonu gibi vektör arama için çok sayıda yenilikçi özellik eklendi
  • gRPC, Kafka streaming, otomatik indeks tanımlama ile veri işleme verimliliği ve esnekliği güçlendirildi
  • Arama altyapısı tarafında Lucene 10, Java 21, modüler mimari uygulanarak gelecekteki genişleyebilirlik ve bakım kolaylığı iyileştirildi
  • Yapay zeka ve RAG tabanlı aramaya yönelik artan talebe yanıt veren, açık kaynak topluluğu temelli yeni nesil bir arama platformu olarak konumlanıyor

OpenSearch 3.0 resmen yayımlandı: yapay zeka çağı için optimize edilmiş vektör arama

  • OpenSearch Software Foundation, OpenSearch 3.0'ın resmi sürümünü duyurdu ve OpenSearch 1.3'e kıyasla 9,5 kat performans artışı açıkladı
  • AI search, öneri sistemleri ve RAG gibi kullanım alanlarında gereken büyük ölçekli vektör veri işleme performansı iyileştirildi

Vektör motorunda yenilik: performans ve maliyet verimliliği birlikte

  • GPU hızlandırma (NVIDIA cuVS tabanlı): indeks oluşturma süresi en fazla 9,3 kat kısaldı, yüksek performanslı iş yükleri destekleniyor
  • Model Context Protocol (MCP) desteği: AI agent'larla entegrasyon sayesinde esnek arama çözümleri kurulabiliyor
  • Derived Source özelliği: yinelenen vektör verilerinin kaldırılmasıyla depolama kullanımı 1/3 oranında azaltıldı

Veri yönetimi özellikleri: esneklik ve ölçeklenebilirlik güçlendirildi

  • gRPC desteği: düğümler arası ve istemci-sunucu arası veri aktarımı hızlandırıldı (deneysel)
  • Pull tabanlı veri toplama: Kafka, Kinesis gibi harici streaming sistemlerinden veriyi doğrudan OpenSearch'ün çektiği yapı uygulandı
  • Reader-Writer ayrımı: arama ve indeksleme ayrılarak her iki işin de kararlılığı ve performansı güvence altına alındı
  • Apache Calcite entegrasyonu: SQL/PPL içinde sezgisel query builder özelliği sunuluyor
  • İndeks türü algılama: log indekslerini otomatik tanımlayarak uygun analiz seçenekleri sağlanıyor

Arama altyapısı ve platform çekirdeğinde iyileştirmeler

  • Lucene 10 yükseltmesi: paralel iş performansı artırıldı ve arama yetenekleri geliştirildi
  • Asgari desteklenen çalışma zamanı olarak Java 21: modern dil özellikleri ve performans avantajlarından yararlanılabiliyor
  • Java modül sistemi kullanımı: monolitik yapı kütüphane tabanlı yapıya dönüştürülerek bakım kolaylığı artırıldı

Açık topluluk merkezli sürdürülebilir inovasyon

  • OpenSearch, Linux Foundation bünyesindeki bağımsız topluluk temelli bir açık kaynak arama platformu
  • AWS, SAP, Uber gibi büyük şirketler ve binlerce katkıcı projeye katılıyor
  • Vektör DB çağına uygun ölçeklenebilirlik ve şeffaf yönetişimi vurgulayarak, herkesin katılabildiği bir ekosistemi hedefliyor
  • Ayrıntılı sürüm bilgileri resmi blogda ve sürüm notlarında görülebilir

İlgili okumalar

3 yorum

 
kaydash 2025-05-12

Elasticsearch AGPL olduğu için kullanmaya çekiniyorum; bu yüzden on-premise tarafta sürekli sadece OpenSearch kullanıyorum.
 
GN⁺ 2025-05-09
Hacker News görüşleri

  • OpenSearch’i daha yeni öğrendim; Elasticsearch lisans değişikliğinden sonra 2021’de fork edilmiş bir proje. Hâlâ Elasticsearch’e alternatif olarak kullanılıp kullanılamayacağını ve performans ile özellik karşılaştırmasını merak ediyorum.

    • Kotlin ile hem Elasticsearch hem de OpenSearch için bir istemci (kt-search) bakımını yapıyorum.

      • Sık kullanılan özelliklerin çoğunda API hâlâ uyumlu.

      • Vektör arama gibi, fork sonrasında eklenen özellikler istisna.

      • search_after gibi bazı özellikler farklı çalışıyor; istemci bunu telafi ediyor.

      • Her iki üründe de SQL sorgu özelliği var ama bunu farklı şekillerde uyguluyorlar.

      • Özellik tarafında Elastic hâlâ önde; özellikle Kibana’nın özellikleri Amazon fork’undan daha zengin.

      • Toplulaştırma özelliklerinde de Elastic son birkaç yılda çok sayıda optimizasyon ve yükseltmeye odaklandı.

      • Performans kullanım amacına göre değişir; iki ürün de Lucene (açık kaynak arama kütüphanesi) tabanlı.

      • Elastic Cloud, AWS üzerindeki OpenSearch’ten biraz daha iyi.

      • Kendi barındırma ve tuning yapılırsa iki ürün birbirine çok benziyor.

      • Elastic 9.0 ve OpenSearch 3.0’ın ikisi de yeni Lucene sürümleri kullanıyor; istemci ikisini de destekliyor.

      • Danışmanlık müşterilerim arasında açık kaynak lisansı ve AWS desteği nedeniyle OpenSearch’i tercih edenler giderek artıyor.

      • Eski Elasticsearch’ten OpenSearch’e geçmek için tüm verileri yeniden indekslemek gerekiyor ve kütüphaneleri de değiştirmeniz gerekebilir; epey zahmetli, kt-searchi bu yüzden yaptım.

      • Çok sayıda eski Elasticsearch 2.3 veritabanımız var, bu yüzden her veritabanı için paralel olarak OpenSearch ayağa kaldırıp servis başlarken toplu veri kopyalama yaptık. Şimdiye kadar OpenSearch’ten genel olarak memnunuz.

      • Ayrıntılı açıklama için teşekkürler; çok faydalı olmuş.

    • OpenSearch’te son dönemde eksikliğini hissettiğim şey enrich processors özelliğinin olmamasıydı (doküman bağlantısı verilmiş).

      • Yalnızca standart belge toplama ve arama özelliklerini kullanıyorsanız çoğunlukla uyumlu.
      • Ücretli sürümde sunulan gelişmiş özelliklerse çoğu zaman ya uyumlu değil ya da eksik.

    • Elasticsearch artık 9.0 ve ötesine ilerledi ve OpenSearch’ten 27.000 commit daha fazla.

      • Bu noktada buna bir drop-in replacement demek zor.
      • Bunların kaçının çekirdek özellik olduğunu bilmiyorum ama iki projenin ne kadar farklılaştığını gösteriyor.

    • Eylül 2024’ten itibaren Elasticsearch yeniden tamamen açık kaynak lisansına (AGPLv3) geçti.

      • Buna karşılık, geçmişte kandırılmış olma hissini hatırlatan bir yorum var.

      • Yine de Elastic Search hâlâ open-core; “enterprise” özellikler asla açık kaynak sürüme dahil edilmeyecek, buna karşılık OpenSearch’te böyle bir kısıtlama yok.

    • OpenSearch “tam” bir alternatif değil ama neredeyse uyumlu; 1.x sürümü Elasticsearch 7.10 ile uyumlu.

    • Aynı donanımda OpenSearch biraz daha yavaş. UI gerekiyorsa dikkat etmek lazım; Kibana fork’u yavaş ve çok bug’lı.

      • Gerçekte durum biraz daha karmaşık; her iki ürünün de güçlü olduğu iş akışları var.
      • Şirketimizde iki ürünü kapsamlı şekilde benchmark ettik; sonuçları merak ediyorsanız ilgili blog yazısına bakabilirsiniz.

    • OpenSearch adı aslında Amazon’un iştiraki A9’un geliştirdiği kişisel arama sonuçları toplama hizmetinden geliyor.

      • Aynı adın birden fazla anlama gelebileceği de belirtiliyor.

  • OpenSearch projesi için biraz üzücü bir durum var.

    • Elasticsearch lisans değişikliğine tepki olarak AWS ile birlikte oluşturulmuş refleksif bir proje.

    • Topluluk, oyuncusu kalmamış bir çok oyunculu oyun gibi; açık kaynak projeler için gerekli canlılıktan yoksun.

    • Elastic Search’ün yerini OpenSearch ile değiştiren bir şirket ya da kurumsal müşteri duymadım; hâlâ kendini kanıtlamış değil ve uzun vadeli bağlılığa dair güven de vermiyor.

    • Çeşitli SIEM platformları zaten kendi arama platformlarını geliştiriyor.

    • Elastic de bir SIEM platformu olan Elastic Security’yi çıkardı.

    • Elastic yeniden açık kaynak olduğunu duyursa da yöneticiler doğrulanmamış bir fork’a geçiş maliyetini üstlenmeyecektir; bu da projenin amacını belirsizleştiriyor.

      • Ben Elastic’i tekrar kullanmak istemiyorum. Lucene–Solr–özel genişletilmiş sürüm hattını doğrudan kullandım; Elastic Search’e sadece AWS kullanırken ihtiyaç duydum. Yine de OpenSearch’e geçtikten sonra onu gayet iyi kullanıyoruz.

      • Elastic’in uzun süre OpenSearch ve AWS nedeniyle ekonomik olarak darbe aldığını düşünüyorum.

  • OpenSearch’ün knn ve vektör özelliklerini kullanan var mı, gerçek büyük ölçekli üretimde durum nasıl, merak ediyorum.

    • OpenSearch uygulamasını bilmiyorum ama Redis için vektör setlerini HNSW yapısıyla kendim implemente etmiştim.

      • HNSW iyi implemente edilirse oldukça büyük ölçekte de iyi çalışıyor.
      • Tek bir HNSW’de ekleme hızı saniyede birkaç bin civarında; okuma çok daha hızlı (çok çekirdekli ortamlarda).
      • İlk büyük toplu insert çok yavaş olabilir ama paralelleştirilebilir.
      • HNSW’nin verimsiz tarafı bellek kullanımının yüksek olması; diskte tutulursa rastgele seek oluşuyor.
      • 1024 boyut gibi yüksek boyutlu vektörlerde quantization zorunlu.

    • Vektör embedding boyutu yüksekse, doğrudan knn yerine HNSW gibi approximate nearest neighbor arama yöntemleri önerilir.

      • Ben opensearchü metin, multimodal embedding ve metadata tabanlı hibrit aramada kullanıyorum.
      • Henüz tam büyük ölçekli üretimde değiliz ama opensearch olduğu için ölçeklenebilirlik konusunda olumlu beklentim var.

    • Benim deneyimimde bunu sürekli kullanıyoruz; performans embedding modeline bağlı ve indeks tuning’i çok önemli.

      • Lucene HNSW kullanırken Java heap RAM’i çok tüketiliyor.
      • FAISS veya nmslib eklentileri kullanılıyorsa JNI RAM’i de takip etmek gerekiyor.
      • 100 milyondan fazla vektör için büyük ölçekli ANN’i kolayca ölçeklemek kolay değil; ekibin yoğun desteğini gerektiriyor.

    • Kabul edilmiş bir caveat var: milyonlarca belge için arama performansı iyi ama KNN aramasında tüm embedding grafiğini RAM’e almak gerekiyor; asıl kritik nokta RAM yönetimi.

      • Sonuç kalitesi de nihayetinde embedding kalitesine bağlı.

  • Basitçe syslog parse eden ve alanları grafiğe döküp aratabilen bir log ingestion aracı istiyorum ama Opensearch veya ELK kurulumu fazla zahmetli geldi.

    • Elastic ve Opensearch’te bu kadar temel kurulumların bile şaşırtıcı derecede zor olmasına şaşırdım.

      • Her şey konfigürasyon odaklı, yani tarifleri kendiniz kurmanız gerekiyor.

      • opentelemetry gibi yardımcı araçlar var ama yine de kullanımı zahmetli.

      • Her iki araçta da resmî yönergeleri izlerseniz hızlıca kullanmaya başlayabilirsiniz; sorun özel mantık gerektiğinde çıkıyor.

      • Basit ihtiyaçlar için logstash olmadan da yapılabilir.

      • Elastic ve opensearch, uygulama metrikleri için pek uygun değil; o durumda prometheus ve grafana önerilir.

      • Elastic ekosistemine yatırım yaparsanız (beats, logstash vb.) birçok indeks şablonu ve pipeline yapılandırması kurabilirsiniz.

      • Günümüzde dynamic field mapping sayesinde Elasticsearch’e veri giriş çıkışı çok kolaylaştı.

      • Asıl büyük mesele performansı korumak.

    • Graylog’u denediniz mi? Biz iş yerinde oldukça memnun kullanıyoruz.
 
davidayo 2025-05-11

OpenSearch, Elasticsearch'ın lisans değişikliğinin ardından 2021'de, uyumlu bir alternatif olma hedefiyle ortaya çıktı. Büyük ölçüde uyumlu olsa da, özellikle Elasticsearch 7.10 ile 1.x sürümü düzeyinde, tamamen tak-çalıştır bir çözüm değildir. Elasticsearch daha fazla özellik ve optimizasyonla, özellikle Kibana ve aggregation tarafında, daha da gelişti. Performans uygulamaya bağlıdır; her ikisi de Lucene üzerine kuruludur. Bazı kullanıcılar OpenSearch'ü daha yavaş buluyor ve Kibana çatallarını hatalı görüyor. Elasticsearch Eylül 2024'te yeniden açık kaynağa (AGPLv3) dönmüş olsa da, bazıları gerçekten açık kaynak yapısı ve AWS desteği nedeniyle OpenSearch'ü tercih ediyor. Vektör arama önemli bir farklılaştırıcı olsa da, büyük ölçekli kurulumlar dikkatli RAM yönetimi gerektiriyor. Sonuç olarak seçim, her iki tarafın da güçlü ve zayıf yönleri olduğu için, belirli ihtiyaçlara bağlıdır. Davidayo ile OpenSearch üzerinde çalışıyorum: https://www.davidayo.com Güçlü bir yapay zeka aracı olan "AskPromptAI": https://askpromptai.com.