OpenSearch 3.0リリース - ベクターデータベース性能とAIベース検索インフラを大幅強化

 (opensearch.org)
12 ポイント 投稿者 GN⁺ 2025-05-09 | 3件のコメント | WhatsAppで共有
  • OpenSearch 3.0が正式リリースされ、OpenSearch 1.3比で9.5倍向上した性能を提供
  • GPUアクセラレーション、AIエージェント連携、ストレージ最適化など、ベクター検索向けの革新的な機能を多数追加
  • gRPC、Kafkaストリーミング、インデックス自動識別などにより、データ処理の効率と柔軟性を強化
  • 検索インフラの面では、Lucene 10、Java 21、モジュール型アーキテクチャを適用し、将来の拡張性と保守性を改善
  • AIおよびRAGベース検索の需要増加に対応するオープンソースコミュニティベースの次世代検索プラットフォームとして位置付け

OpenSearch 3.0正式リリース: AI時代に向けてベクター検索を最適化

  • OpenSearch Software FoundationはOpenSearch 3.0正式版を公開し、OpenSearch 1.3比で9.5倍の性能向上を発表
  • AI検索、レコメンデーションシステム、RAGなどで求められる大規模ベクターデータ処理性能を改善

ベクターエンジンの革新: 性能とコスト効率を同時に確保

  • GPUアクセラレーション（NVIDIA cuVSベース）: インデックス構築時間を最大9.3倍短縮し、高性能ワークロードを処理
  • Model Context Protocol (MCP)対応: AIエージェントとの連携により柔軟な検索ソリューションを構築可能
  • Derived Source機能: 重複するベクターデータを除去し、ストレージ使用量を1/3削減

データ管理機能: 柔軟性と拡張性を強化

  • gRPC対応: ノード間およびクライアント-サーバー間のデータ転送を高速化（実験的）
  • Pullベースのデータ収集: Kafka、Kinesisなどの外部ストリーミングシステムからOpenSearchが直接データを取得する構造を採用
  • Reader-Writer分離: 検索とインデクシングを分離し、それぞれの安定性と性能を確保
  • Apache Calcite統合: SQL/PPLで直感的なクエリビルダー機能を提供
  • インデックス種別の検出: ログインデックスを自動で識別し、適切な分析オプションを提供

検索インフラおよびプラットフォームコアの改善

  • Lucene 10へのアップグレード: 並列処理性能を向上させ、検索機能を高度化
  • Java 21を最小サポートランタイムに: 最新の言語機能と性能を活用可能
  • Javaモジュールシステム導入: モノリシック構造をライブラリベースへ移行し、保守性を向上

オープンコミュニティ中心の持続可能なイノベーション

  • OpenSearchはLinux Foundation傘下の独立コミュニティを基盤とするオープンソース検索プラットフォーム
  • AWS、SAP、Uberなどの主要企業と数千人のコントリビューターが参加
  • ベクターDB時代に合わせた拡張性と透明なガバナンスを強調し、誰でも参加できるエコシステムを志向
  • 詳細なリリース情報は公式ブログおよびリリースノートで確認可能

関連記事

3件のコメント

 
kaydash 2025-05-12

Elasticsearch は AGPL なので使うのが怖くて、ずっと OpenSearch だけをオンプレミスで使っています。
 
GN⁺ 2025-05-09
Hacker Newsのコメント

  • OpenSearchについて今まさに知ったところ。Elasticsearchのライセンス変更後、2021年にフォークされたプロジェクトとのことだが、今でもElasticsearchの代替として使えるのか、性能や機能比較が気になる。

    • KotlinでElasticsearchとOpenSearchの両方に対応するクライアント（kt-search）をメンテナンスしている。

      • よく使う機能の大半では、まだAPI互換性がある。

      • ベクトル検索のように、フォーク後に追加された機能は例外。

      • search_after のように一部機能は挙動が異なり、クライアント側でそれを吸収している。

      • 両製品ともSQLクエリ機能はあるが、実装方式は異なる。

      • 機能面では依然としてElasticが先行しており、特にKibanaの機能はAmazonフォーク版より充実している。

      • 集計機能でも、Elasticはここ数年で多くの最適化やアップグレードに注力してきた。

      • 性能は用途次第で、両製品ともLucene（オープンソースの検索ライブラリ）を基盤としている。

      • AWS上ではElastic CloudのほうがOpenSearchよりやや良い。

      • 自前でホスティングしてチューニングすれば、両製品はかなり近くなる。

      • Elastic 9.0とOpenSearch 3.0はどちらも新しいLuceneバージョンを使っており、クライアントはその両方をサポートしている。

      • コンサル先の顧客の中には、オープンソースライセンスとAWSサポートを理由にOpenSearchを好むケースが増えている。

      • レガシーなElasticsearchからOpenSearchへ移行するには、全データの再インデックスが必要で、ライブラリも変更が必要になることがあり、かなり面倒。それでkt-searchを作ることになった。

      • 古いElasticsearch 2.3のデータベースが多くあったので、各データベースごとにOpenSearchを並行して立て、サービス起動時にデータを一括コピーした。今のところOpenSearchには概ね満足している。

      • 詳しい説明に感謝、役に立ったという前向きな反応。

    • OpenSearchで最近残念だった点は、enrich processors機能がないこと（ドキュメントへのリンクあり）。

      • 標準的なドキュメント収集と検索機能だけを使うなら、ほとんど互換性がある。
      • 有料版で提供されていた高度な機能は、互換性がないか欠けていることが多い。

    • Elasticsearchはバージョン9.0以降まで進化しており、OpenSearchより27,000コミット多い。

      • もはや「drop-in replacement」とは言いがたい状況。
      • そのうちどれだけが中核機能かは分からないが、両プロジェクトがどれほど離れたかは分かる。

    • 2024年9月からElasticsearchは再び完全なオープンソースライセンス（AGPLv3）に戻った。

      • それについて、以前だまされた経験を思い出すような反応。

      • それでもElastic Searchは依然としてオープンコアで、「エンタープライズ」機能がオープンソース版に入ることは決してないだろう。一方OpenSearchにはその制約がない。

    • OpenSearchは「完全な」代替ではないが、ほぼ互換で、1.x系はElasticsearch 7.10と互換性がある。

    • 同じハードウェアではOpenSearchのほうがやや遅い。UIが必要なら注意が必要で、Kibanaフォークは遅くバグも多い。

      • 実際にはもう少し複雑で、両製品それぞれに強みのあるワークフローがある。
      • 会社で両製品を包括的にベンチマークした。結果が気になるなら、そのブログ記事を参照してほしい。

    • OpenSearchという名前は、もともとAmazon子会社のA9が開発した個人検索結果集約サービスに由来する。

      • 同じ名前でも複数の意味を持ち得るという話。

  • OpenSearchプロジェクトについて残念に思う。

    • Elasticsearchのライセンス変更への反発からAWSと一緒に作られた反射的なプロジェクトだ。

    • コミュニティが活動停止したマルチプレイヤーゲームのようで、オープンソースプロジェクトに不可欠な活気が足りない。

    • Elastic Searchを置き換えられる企業やエンタープライズ顧客を聞いたことがなく、まだ実証されておらず、長期的コミットメントへの信頼も薄い。

    • 各SIEMプラットフォームがそれぞれ独自の検索プラットフォームを作っている状況だ。

    • ElasticもSIEMプラットフォーム（Elastic Security）を出している。

    • Elasticが再びオープンソースだと打ち出しても、経営陣は実績のないフォークに移行コストを払わないだろうし、プロジェクトの存在意義も曖昧になっている。

      • Elasticはもう使いたくない。Lucene→Solr→カスタム拡張版の順で直接使ってきて、Elastic Searchが必要だったのはAWSを使うときだけだった。それでもOpenSearchへ移行してからは問題なく使えている。

      • Elasticは長い間、OpenSearchとAWSによって経済的な打撃を受けてきたのだと思う。

  • OpenSearchのknnやベクトル機能を使っている人はいるのか、実際の大規模運用ではどうなのか気になる。

    • OpenSearchの実装は分からないが、Redis向けのベクトルセットをHNSW構造で自作した経験がある。

      • HNSWはうまく実装されていれば、かなり大規模でもよく動く。
      • 単一HNSWの挿入速度は毎秒数千件程度で、読み取りはそれよりずっと速い（マルチコア環境で）。
      • 初回の大量挿入は非常に遅くなり得るが、並列化は可能。
      • HNSWの非効率な点はメモリ使用量が大きいことで、ディスク保存するとランダムシークが発生する。
      • 1024次元のような高次元ベクトルではquantization（量子化）が必須。

    • ベクトル埋め込みの次元数が高い場合、knnそのものよりHNSWのような近似最近傍探索方式を勧める。

      • 自分はopensearchをテキスト、マルチモーダル埋め込み、メタデータベースのハイブリッド検索に使っている。
      • まだ完全な大規模運用ではないが、opensearchなのでスケーラビリティには前向きな期待を持っている。

    • 自分の経験では常用している。性能は埋め込みモデル次第で、インデックスチューニングが重要。

      • Lucene HNSWを使うとJava Heap RAMをかなり消費する。
      • FAISSやnmslibプラグインを使う場合はJNI RAMにも気を配る必要がある。
      • 1億ベクトル超の大規模ANNを簡単にスケールさせるのは容易ではなく、チームの集中的な支援が必要。

    • 一般に受け入れられている注意点として、数百万ドキュメントの検索性能は良好だが、KNN検索では埋め込みグラフ全体をRAMに載せる必要があり、RAM管理が鍵になる。

      • 結果品質は結局のところ埋め込み品質に左右される。

  • syslogを簡単にパースしてフィールドをグラフ化・検索できるログ取り込みツールが欲しいが、OpensearchやELKの設定は難しすぎた。

    • ElasticもOpensearchも、こうした基本設定ですら意外と難しいことに驚いた。

      • 何もかも設定中心なので、自分でレシピを組み立てる必要がある。

      • opentelemetryのような助けになるツールもあるが、それでも不便さは残る。

      • どちらのツールも公式ガイドラインに従うだけならすぐ使える。問題はカスタムロジックが必要になったとき。

      • 単純な要件ならlogstashなしでも可能。

      • Elasticやopensearchはアプリメトリクスには向いておらず、その場合はprometheusやgrafanaを勧める。

      • Elasticエコシステムに投資すれば（beats、logstashなど）、さまざまなインデックステンプレートやパイプライン構成が可能になる。

      • 現在はdynamic field mappingのおかげで、Elasticsearchへのデータ入出力はかなり容易になった。

      • より大きな悩みは性能維持のほうだ。

    • Graylogを試したことはあるか、という質問。自分の職場ではかなりうまく使えている。
 
davidayo 2025-05-11

OpenSearch は、Elasticsearch のライセンス変更を受けて 2021 年に登場し、互換性のある代替を目指していました。特に 1.x は Elasticsearch 7.10 とおおむね互換性がありますが、完全なドロップインソリューションではありません。Elasticsearch はその後さらに進化し、より多くの機能や最適化を備えており、特に Kibana と集計機能でその傾向が顕著です。パフォーマンスはアプリケーション依存で、どちらも Lucene 上に構築されています。一部のユーザーは OpenSearch のほうが遅く、Kibana のフォークに不具合があると感じています。2024 年 9 月に Elasticsearch がオープンソース（AGPLv3）へ回帰したにもかかわらず、その真にオープンソースな性質と AWS のサポートを理由に OpenSearch を好む人もいます。ベクトル検索は主要な差別化要因ですが、大規模な実装には慎重な RAM 管理が必要です。最終的には選択は具体的なニーズ次第であり、どちらにも長所と短所があります。私は Davidayo とともに OpenSearch に取り組んでいます https://www.davidayo.com AI の強力なツール "AskPromptAI" https://askpromptai.com.