Join the Webinar
Loading...
2024年1月 Zilliz Cloud ローンチ
オープンソースの Milvus を基盤に構築された、最も高性能なマネージドベクトルデータベースである Zilliz Cloud の最新機能強化を探る、限定ウェビナーにご参加ください。開発者や技術専門職向けに設計された本セッションでは、ベクトルデータベース革新の最前線を掘り下げます。
Zilliz Cloud が、高性能なマネージドベクトルデータベースとしての地位をさらに強化し、エンタープライズ本番環境に対応し、AI エコシステムに統合されるよう、どのように進化しているかをご紹介します。
本ウェビナーは、ベクトルデータベースのトレンドや進歩への理解を深めたい開発者や AI 専門家にとって必見です。この洞察に満ちたセッションで、当社の VP of Engineering とともに、比類ないパフォーマンスとスケーラビリティを通じて非構造化データと AI アプリケーションを変革する Zilliz Cloud の役割について学びましょう。
今すぐ席を予約し、ベクトルデータベース技術の未来の一翼を担いましょう！
本日のセッション、ええと、Zilliz Cloud 2024年1月の製品ローンチ、Zilliz Cloudで最高性能のベクトル検索を提供する、にご参加いただき本当にありがとうございます。まずいくつかの事務連絡事項をお伝えしてから、すぐにセッションに入りたいと思います。まず、このウェビナーは録画されていますので、途中で退出する必要がある場合でも、数日以内にオンデマンド版へのアクセスを入手できます。ご質問がある場合は、すでにどなたかが音声が聞こえないとおっしゃっていたと思いますが、画面下部のQ&Aツールにそのまま貼り付けてください。それでは機能に入る前に、ええと、ulu cloudとは何かについて少しお話ししたいと思います。
まず、これは実際に最も広く採用されているオープンソースのベクトルデータベースを基盤にしていますが、私たちは依然として多くのエンジニアリングリソースを投資して、BUをさらに良くし続けています。その後、安定したBUバージョンは引き続きnew sales cloudにデプロイされます。つまり、それがbusiness cloudの中核になります。ええと、しかしその上で、実際にはvuを本当に再エンジニアリングし、最適化しようとしています。そのため、visと比較して、より優れたパフォーマンスとより低いTCOを得られることになります。
ええと、私たちが本当にやろうとしているもう1つのことは、Mel visを大きく超えて、より柔軟なデプロイメントとセキュリティ機能の両方を含む、いくつかの重要なエンタープライズ機能を構築し、この本番環境対応プラットフォームを作成することです。もう1つ本当に重要なことは、ええと、非構造化データプラットフォームを構築し、データの接続と変換を支援したいということです。そのため、現在パブリックプレビュー中のpipelinesを含むいくつかの機能や、より多くのコネクターとインテグレーションを構築しています。それについても後ほどお話しします。つまり基本的には、データ、ええと、データとAIのエコシステムに十分に統合されたこのようなプラットフォームを構築したいと考えています。
では、さっそくこれに入りましょう。ええと、とてもエキサイティングな、ええと、ローンチのハイライトです。ええと、これは先ほど述べた柱です。ええと、最適化されたbuから始めましょう。つまり、このローンチの本当に重要なハイライトはCardinalです。
ええと、Cardinalは非常に効率的なベクトル検索エンジンです。高速な近似最近傍探索、ええと、私たちがA NNSと呼ぶもののために設計されています。幅広いタスクに対応でき、さまざまなデータ形式をサポートし、支出に焦点を当て、ええと、すみません、速度と効率に焦点を当て、リソース制限内でより多くのユーザーリクエストを可能にします。X 86とarmの両方のハードウェア向けに最適化されており、Cardinalはオープンソースbuに対して10倍のパフォーマンス向上を提供します。これにより、ベクトル検索が迅速かつより効率的になり、AIアプリケーションとユーザー体験が向上します。このローンチのもう1つの重要なハイライトは、数か月のベータを経て、最も期待されていたNovus two, drug threeがsales cloudで一般提供開始となったことです。
ここにいくつかのハイライトを挙げていますが、1つ目はco-sign metricsです。これは高度な類似度メトリクスで、特に、ええと、NALPで人気があります。ええと、co-signは事前のベクトル正規化の必要性をなくします。ええと、つまり、ええと、開発者が今co-sign計算を行いたい場合、より簡単になります。次に2つ目の本当に重要な機能はranch searchです。個人的には、この、ええと、この機能がとても気に入っています。ええと、Jamesが後ほどこれについてもう少し話します。
この機能は、実際に一部の特定のユースケースに対して、より正確なデータ検索方法を提供します。ええと、top K searchを超えてベクトルクエリの範囲を広げます。ええと、レコメンデーションエンジンにとって潜在的に有益であり、ユーザーに対してより関連性の高い提案を保証します。もう1つの本当に重要な機能はabsurd observeです。データ管理において、データセットの更新と削除をシンプルにします。特に、データの一貫性とityが重要な動的環境において価値があります。
それでは、本番環境対応の柱に移りましょう。ええと、非常に重要なのは、エンジニアリングチームが実際にかなり数か月を費やして、より細かなロールベースのアクセス制御を構築したことです。ええと、私たちの堅牢なアクセス制御により、実際に4つのクラスターとプロジェクトロールを提供しています。つまり、これは運用権限のためのもので、プロジェクトや請求を管理できます。そして、さらに重要なこととして、データレイヤーの権限も提供しています。
たとえば、特定のデータを追加したり表示したりしたい場合、ええと、データレイヤーについては、3つのビルディングと1つのカスタマーロウがあります。ええと、基本的には、ユーザーが適切な仕事に対して適切なアクセス権を持つことを保証しながら、セキュリティとチームワークを本当に支援し強化するものです。それから、ここでお話ししたいもう一つの非常にエキサイティングな発表は、私たちが GCP marketplace で利用可能になったことです。そしてさらに良いニュースとして、GCP marketplace 経由でサインアップすると、すべての新規ユーザーが利用できる標準の100ドルクレジットに加えて、追加で100ドルのクレジットを受け取ることができます。さて、最後の柱は、非構造化データの合理化についてです。
ええと、昨年ローンチした Confluent と Air byte collect connectors について、非常に多くの好意的なフィードバックをいただき、本当に嬉しく思っています。ええと、現在は、簡単なデータ移行と変換のために、Databricks と Slack connectors を導入しています。これらのクラウドへのストリーミングとバッチの両方のデータインポートをサポートし、モデルの更新やデータのアップロードといったタスクを行うチームや個人を支援します。さて、この新機能の詳細説明のために、当社のエンジニアリング担当VPである James をご紹介できることを大変嬉しく思います。
James、ようこそ。ええと、まず何よりも、vu について本当に話したいです。ええと、vu 2. 3 についてですが、ええと、VU コミュニティや zills Cloud にリリースしてからかなり数か月が経ちました。VU と Zeus の間で、なぜ機能の優先順位がそこにないのか話してもらえますか？はい。
ええと、まず第一に、私たちは zes Cloud に新機能を公開することについて非常に慎重です。ええと、その理由は、私たちの、ええと、little called を非常に安定させ、また以前のすべての機能や、embed でリリースされた多くの最新機能とも互換性を保ちたいからです。そのため、オープンソースユーザーにそれらすべての機能を試してもらい、より多くのフィードバックを提供してもらいたいと考えています。これらの機能はおそらく非常に初期段階にあります。そのため、インターフェースと制限の両方について、いくつか調整を行う可能性があります。
しかし一方で、私たちは、このクラウドでは、ユーザーがより安定した機能とインターフェースを使用できることを望んでいます。ええと、本番環境のすべてのユーザーにとって、互換性は非常に重要になると信じているからです。ですので、オープンソースの最新と比較して、約3〜6か月の遅れを維持することが私たちの主要な目標です。はい。ええと、これは、すべてのコールユーザーにとって、新機能について少し辛抱が必要かもしれない、ということを意味します。
ええと、実際には、今月まもなく meals 2. 4 をリリースする予定で、ええと、より多くの embedding サポート、たとえば、ええと、scale、Sparsing embeddings のような inverter index など、さらにエキサイティングな機能が含まれています。そしてそれらの機能は、おそらく今年の半ばごろに those called に入る予定です。また、ええと、sus により多くの制限を設けることができる理由の一つは、ええと、これが持続可能性を保証するだけでなく、この製品を正しい方法で使いたいユーザーを導くものでもあるからだと思います。ええと、たとえば、クラウド上で作成されるコレクション数を制限しました。ええと、多くのユーザーが自分たちの rack アプリケーションを構築したいと考えていることが分かったからです。ええと、ユーザーがやろうとしていることは、各コレクションを1テナント用として、何百もの sof コレクションを構築することです。はい。
しかし、ええと、これはクラスターに大きな負荷をかけました。ですので実際、マルチテナントアプリケーションを構築したい場合、ええと、それを行う推奨される、推奨される方法は、Protection Key と呼ばれる機能を使うことです。これにより、1つのコレクションで数百万のテナントをサポートできます。そして検索を行うときに、ええと、必要なテナントを非常に素早くフィルターできますし、それによってパフォーマンスも大幅に向上し、システムの負担も軽減されます。素晴らしいです。本当に素晴らしいヒントですね。
ええと、これらのクラウドの使い方に関してご質問があれば、どうぞ遠慮なく、ええと、私たち、サポートチームまでご連絡ください。私たちは喜んでお手伝いします。ええと、それでは mailbox 2. 3. についてもう少し話しましょう。
先ほど述べたように、funnel の非常に興味深い機能の一つは Range Search です。実際、すべてのベンダーがこの種の機能を持っているわけではありません。Range Search について、そしてどのようなユースケースに最適なのか、もう少し教えていただけますか？それから、実際に人々がこれをどのように強力に活用できるかについて、少しデモを見せていただけますか。もちろんです。では、先ほど、ええと、提供されている機能として research を挙げました。
ええと、私としては、I, I, I would prefer for afterbecause、ええと、つまり多くのユーザーも、ええと、after を inspect するのが好きです。そうですね。しかし Ring search については、ええと、つまり、ほとんどの Vector database では、そうですよね？ええと、今のところ私たちがやっていることは、ええと、近傍、ええと、nearest neighbor search における n approach と呼ばれるものです。そして、ええと、通常、通常、ええと、私たちが行うのは top key クエリを実行することです。つまり、クエリベクトル埋め込みを渡すと、データベースは、ええと、top key の最も類似した最近傍を返します。
しかし、多くのユースケースでは、ええと、私たちは、ええと、探している key の正確な数が何なのか、わからないのですが、一定の距離範囲内にあるすべてのデータを取得したいだけなのです。うーん、このニーズは、ええと、異常検知や、ええと、いくつかの画像、ええと、研究で特に一般的です。ですので、うーん、さらに top key モードでは、ええと、特定の領域から、ええと、取得したいデータ量が非常に大きくなる可能性があります。うーん、例えば、距離が 0. 5 から 1 の間にあるすべてのベクトルを取得したいと言った場合、ええと、cosign metrics ですよね？非常に大量のエンティティが得られるかもしれません。
そうですね。そのため、単一の RPC が処理できる制限を超える可能性があります。したがって、そのようなケースでは、Cent を、ええと、iterator 機能と組み合わせて使用できます。ええと、そのため、すべてのデータを一つずつイテレートするだけでよく、ええと、RPC の制限を超えないこと、またメモリを壊さないことを確認できます。ですので、私たちのテストでは、ええと、iterator を使うことで、10 million、760 次元のデータを 10 分未満でスキャンできます。
また、この機能を使って、すべてのデータ、ええと、クラスター全体のすべて、すべて、すべてをエクスポートすることもできます。ですので、これはほとんどの Vector database にとって本当に有用になります。いったんすべての埋め込みを入れると、ええと、ベンダーロックインが発生し、ベクトル埋め込み自体を取り出す方法がなくなりますが、ええと、research と hre を使えば、間違いなく役立ちます。では次に、私たちの、私たちの、私たちの research について簡単なデモをお見せします。では始めましょう。
実は、ええと、簡単なデモを作成してあります。このデモでは、たくさんの、ええと、データがあります。ええと、men py という、Python ファイルがあり、ええと、各ステップを実行、実行します。最初に行うことは、どのようなデータがあるのかを素早く見てみることです。はい。つまり、ええと、実際には 10 K のデータがあり、ええと、PK Field は 0 から 10 K まで、ええと、いくつかの説明があり、ええと、幅と高さもあり、これは、ええと、inte numbers です。
そしてもちろん、ええと、full 32 lectures もあります。また、私は、ええと、バックエンドで meals cluster を起動しています。では、はい、最初のステップとして行うのは、preparation、ええと、collection を実行することです。このデモで行うことは、mul に接続し、collection を作成し、それから、ええと、demo, s and tt という collection name を作成します。10 K をこの中に、この中に、ええと、このクラスターに挿入します。
そして、ええと、次のステップとして私がやることは、ええと、従来の検索か、ええと、あるいは単に、ええと、トップキー検索です。おっと。ああ、名前を変更、変更する必要があります。よし、それでは何が得られたか見てみましょう。つまり上では、ええと、私は、私は距離がゼロ、ええと、0 の最も類似した結果を得ました。
9 0. 9、つまりほとんど同じで、同じ、ええと、この中にあるということですよね？そして、ええと、もし、もしそれを見ていくと、ええと、このものについて他の、ええと、ID がいくつか得られて、ええと、ええと、cosign me metrics、ええと、類似度が 0. 8 で、これも非常に似ています。そして、ええと、ええと、このデモでは、だいたい 100 件の結果が得られました。では、この検索デモで何をしたかを見てみると、つまり、私たちがしたことは接続して、コレクションを作成して、検索を行いました。
検索では、100 件の制限があります。また、たくさんの afus も指定しています。はい。co-sign metrics を使っています。はい。
そして最後に、最後に、出力する、あるいは recall を出力しますよね？つまり、それがどう、何、何と呼ぶのでしょう？ああ、素晴らしい。recall は 1. 0 です。つまりすべて順調です。これが従来の検索です。
では ring search では何が起こるでしょうか、もう一つのテストを実行してみましょう。correction を as に入れています。なのでまだ、ええと、recall は 1. 0 になります。ええと、そしてもし、もしこれを見てみると、私は、ええと、0. 75 から 1. の範囲で検索しようとしています。
0。ええと、驚くことではありませんが、やはり IV がゼロに等しい、ええと、最も類似した結果が得られますよね？そして類似度は top K として行ったものと同じです。そして下にスクロールすると、たくさんの、ええと、ええと、他の ID が得られ、そして、ええと、最後の結果については、そうですね？距離はだいたい 0. 75 です。それが範囲です。
コードを取り出して見てみると、私が指定したものです。つまり site D、ええと、site difference があります。なので検索を行うとき、ええと、top gate を指定する代わりに、範囲も指定します、ええと、それは poems の中にありますよね？radius equals to 0 7 5 と言いました。つまり、ええと、ええと、最も可能性の低い、ええと、その、最も可能性の低いデータでも類似度が 0, 7, 5 より大きくなければならないという意味です。これが私たちが research と呼ぶものです。はい。そして research は few drinks と一緒に使うこともできます。
その場合、私たちができることは、フィルタリング検索を行うことができ、別の条件として、これは 500 より小さい、を持たせることができます。最後の結果を見てみると、そうですね？いくつかの W が 500,000、ええと、500 より大きいことがわかります。ええと、例えば、これを見てみると、W が 5、ええと、5, 7, 8 であることが確実にわかりますよね？しかし、もし Turing search を、ええと、rings と一緒に実行すると何が起こるかというと、結果は Turing なしの場合よりもずっと少なくなることがわかりますよね？そしてすべての結果を詳しく見ると、ええと、これらはすべて実際に 500 未満であることがわかります。つまり、ring search の最も主要な部分は、作業できる、ええと、それは literature と一緒に使用できるということです。例えば、デモを実行して、最初の chain result を与えられたとき、ええと、私は、私はそのうち 8 件をスキップしました、ええと、ええと、トップ、ええと、最も可能性が高いものはまだ、ええと、ええと、0 9, 9 の類似度があります。
ええと、そして top、top 10 では、0, 7, 5 になりますよね？そしてまだ続けることができます。そして、ええと、11 番目は実際には、ええと、10 番目より少し、ええと、さらに遠いです。そして、ええと、さらに 10 件の結果が得られ、続けると、さらに 10 件が得られ、続けます。いいですか？つまり、すべての結果が得られます。これらの iterative features によって、クライアントが OM や opposite limitations になることを心配せずに、非常に大きなデータセットを取得できます。
はい。素晴らしい。それはとても exciting に聞こえます。ええと、では少し話題を切り替えて、Cardinal について少し話しましょう。ええと、Cardinal について具体的には、私は、ええと、Novus のためにすでに nowhere を得た、その背後にあるストーリーをぜひ聞きたいです。
ええと、エンジニアリングチームが「Zeus専用の新しい検索エンジンをもう一つ作る必要がある」と考えるに至ったきっかけは何だったのでしょうか。はい。私たちのCardinalを構築する最初のアイデアは、統一されたVectorインデックスを実現することでした。なぜなら、emailでは、noというライブラリがあり、Fast HW diskのようなあらゆるVector検索ライブラリを統合して、すべての機能をこのVectorインデックスに合わせようとしていたからです。私たちはそれらのインデックスに多くの変更を加え、それには膨大な時間がかかりましたし、また、すべてのVectorインデックスが同じ機能を持つように維持することにも時間がかかりました。そこで、ある日、リリース後に、これがサポートしていない特定の機能、たとえばfeaturing featuresのような機能に対応できていないことが分かりました。
それで、私たちは本当に苦労し、さまざまなVectorデータ型をサポートするために、独自のインデックスを構築し始めました。また、4 32、BF 16、FP 16 binary vectorsのようなさまざまなデータ型もサポートしたいと考えました。私たちは、graph based indexとVFのようなinverted file indexの両方など、異なるindex tabをサポートするVectorインデックスを構築したいと考えています。sq pqなどの異なるation algorithms、in memory、on this、さらにはS3のようなremote storageといった異なるstorageを備えたインデックスを構築したいと考えています。GPU supportを備えたVectorインデックスを構築したいのです。そのため、新しいインデックスだけに対して多くのリファクタリングを行い、インデックスのあらゆる部分がprofitableであることを確認しました。それが、このCardinalの始まりです、すみません。
素晴らしいです。では、顧客の視点から、Cardinalの良いユースケースにはどのようなものがあるのかについてお話しできますか？ これは速度だけでなく、効率性にも関わるものだと理解しています。その点についてもう少しお話しいただけますか？おそらくアーキテクチャをお見せしながら、そのアーキテクチャに沿って話せると思います。もちろんです。先ほど申し上げたように、Cardinalは実際には非常にプラガブルです。アーキテクチャを見ると、プラガブルなcontent、colonizersがあり、distance calculatorsがあります。co-sign metricsを持つことができます。
L two metricsを持つこともできますし、さまざまなcustomized metricsも持つことができます。また、インデックスの主要部分もすべて分割しています。プラガブルなindex builderがあり、つまり、さまざまな種類のインデックスを構築できます。インデックスを持つことができますし、異なるsearchersを持つこともできます。同じgraph上で検索するために、異なるalgorithmを使用できます。
はい。非常に柔軟になるため、興味深い点は、さまざまな組み合わせができることです。たとえば、Hand W Indexにはquantitationsがありませんよね？しかしfastには、おそらく最も強力なquantitations algorithmがあります。そこで、それらをすべて組み合わせると、graph index上でquantitationを行うことが可能になります。はい。
一方で、あらゆる種類の実装があるため、多くのquery conditionsに基づいて、graph indexを使うかinver indexを使うかを動的に選択できます。top keyが非常に大きい場合、graph indexを使うのはあまり効率的ではないかもしれません。その場合はFF indexを選びます。top Kが非常に小さい場合は、間違いなくgraph indexを選びます。はい。
そして、異なるcomparison algorithmsを実装することもできます。パラメータ間で自動的にindexを選択できます。実際に、auto indexと呼んでいる強力なツールがあります。これは、こちら側から特定の知識を追加しなくても、すべてのパラメータをチューニングするのに役立ちます。すべてのnot tuning作業を代わりに行ってくれるのです。
はい。そして、これらすべての最適化のおかげで、ええと、最適化により、ええと、今回のリリースで、ええと、私たちの高性能な、ええと、タイヤは、オープンソースソリューションと比較して10倍以上の性能向上を達成しました。私たちが、ええと、meals向けに持っているものです。そして、そして最もエキサイティングな部分は、メモリ使用量も50%削減したことです。つまり、各1 CUパフォーマンス、ええと、インスタンスについて、もともとは1,000,007個の60次元データしか保存できませんでしたが、今では、それはone, 1をサポートできます。
ycで2百万件のlecturesです。はい。そして一方で、ええと、私たちのディスクインデックスについては、ええと、このcardinalによって、私たちはまた、ええと、私たちの第一世代の、ええと、ええと、those cloudインデックスと比較して50%の性能改善を達成しました。はい。そしてmodel over kindには、ええと、スカッターフィルタリングのための広範な最適化があります。
はい。ですので、ええと、MUは実際にpre preを導入した最初の、ええと、データベースであり、これは、ええと、ほぼすべての正確なデータベースにおける標準機能になっています。はい。perfusionの基盤の上に構築して、ええと、私たちはCardinalで多くの最適化を実装しました。特にグラフインデックスの接続性に関してです。ええと、また、異なるデータオロジー、異なる、ええと、クエリ条件に基づいて異なるフィルタリングアルゴリズムを選択する、指定されたオプティマイザーもあります。
そしてこれにより、強力なフィルタリング性能の向上につながります。はい。ですので、ええと、性能についてもっと詳しく知りたい場合は、たぶん自分で試してみたいと思うでしょう。実際に私たちには、ええと、vector B benchという、ええと、オープンソースの、ええと、ライブラリがあります。ですので、ええと、私たちにはたくさんのテストケースがあります。
これらのテストテストケースを実行して、ええと、主流のvector dbsの性能を比較できます。はい、journeyが続いていると聞けてとてもエキサイティングです。私たちは今も、すべてのお客様に利益をもたらすため、cuttingの上により良いものを構築し続けています。ええと、ではロールベースのアクセス制御に移りましょう。私自身も少し調査して、ええと、そしてthose cloudの、ええと、ロールベースのアクセス制御は、市場の他のどのベクターデータベースベンダーと比較しても最も先進的だと気づきました。
私たちはcon、ええと、control plane上に4つのrowがあり、data plane上にも別の4つのrowがあります。ですのでJames、チームがなぜこれを構築することが非常に重要だと考えているのか、ぜひあなたから聞きたいです。というのも、私たちはおそらく過去3、4か月を費やして、少しずつ、このようなきめ細かな、ええと、RAYeahを実現したと思うからです。つまり、私は、ステータスセキュリティとエンタープライズ対応であることが私たちの最優先事項です。ですので、ええと、これは私たちのクラウドサービスだけでなく、すべてのオープンソースユーザーにも当てはまります。ええと、すべてのオープンソースユーザーに対しても、TLS、ええと、ユーザー認証、そして私たちのbackを有効にすることを推奨しています。
はい。ええと、私たちのクラウドについては。思うに、ええと、私たちはまた、多くの時間を費やして、すべての、ええと、エンタープライズ対応機能、すべてのcomplaints、すべての、ええと、データセキュリティ機能に取り組んできました。多くのA IGC開発者にとっては、ええと、現時点では、彼らの、彼らのロジックを動作させることを優先しているかもしれないことは分かっています。はい。
しかし、ええと、つまり、データセキュリティは依然として主要な懸念事項になるでしょう。はい。これは特に、あなたのベクター、ええと、データが逆向きにエンジニアリングされて、ええと、何らかの機密情報または、または元の情報を作成、再作成できる場合に当てはまります。はい。さらに、あなたのデータに対するリスクです。
ですので、ええと、RECは私たちの、ええと、データセキュリティの主要機能の1つになります。ですので、ええと、このcallはadmin regretやread onlyなどのロールをサポートしました。はい。ええと、それは私たちが、ええと、enterprise、ええと、adminを通じてすべての内部ユーザーを管理するのに役立ちます。はい。
そして、ええと、まず最初に、私たちは、次のメジャーリリースで、エンタープライズティア向けに ldap、ええと、認可、そして、ええと、カスタマイズされたロール機能を導入する予定です。ですので、ええと、SEC セキュリティ要件をお持ちの方はご期待ください。また、私たちの BIOC もご覧いただくとよいでしょう。ええと、これは、ええと、このリリースでは、すべてのデータをお客様自身の VPC に保存でき、ええと、Zillow は私たちの A PC に制御ポイントのみをデプロイします。このアプローチにより、データのセキュリティを最大化し、ええと、すべてのデータが引き続きお客様の管理下にあることを保証します。そして、ええと、これは、ええと、最も厳格な、ええと、プライバシー保護の下にあります。
はい。BIOC bring、bring your own cloud をまもなく発表する予定ですので、ご期待ください。ええと、最後に、Databricks Spark connectors についてお話ししましょう。ええと、James、画面を共有してもらえますか？先に私の共有を停止します。もちろん。
では、ええと、SPARK connector を簡単に紹介させてください。はい。私たちは、ええと、実際に Spark と、spark のすべてのデータ処理および ML 機能を組み合わせたシームレスな統合を提供しています。私たちは、ええと、すべての、ええと、ベクターデータストレージと検索、ええと、互換性を備えた、ええと、その、その統合により、さまざまな興味深いアプリケーションが可能になります。ええと、たとえば、ええと、データを mules に効率的に一括投入したり、複数の mules 間、または他のストレージのようなものの間でデータを移動したりできます。はい。そして、spark と lead を活用して、mules 内のデータを分析できます。
それでは、spark Connector で何ができるかを簡単にデモできます。少々お待ちください。はい。では、ええと、あなたが開発者で、すべての構造化データを検索しようとしているとしたらどうでしょうか？この smart connector がなければ、ええと、まず最初にやらなければならないのは、Spark Job、Spark job を実行することです。ええと、そこで行うのは、あなたの after data を読み出し、前処理を行い、ええと、すべてのデータを埋め込みモデルに入れ、そして埋め込み後に、ただ、ええと、すべてのデータを別のストレージに保存します。
それは S3 かローカルストレージになるでしょう。ですので、ええと、そこから次にやらなければならないのは、ええと、コードを書いて、ええと、すべての、ええと、データを Vector database にプッシュすることです。そしてユーザーは、その後ユーザーは Vector DB 上で検索を実行できます。私たちの新しい、ええと、spark connector によって、ええと、これはずっと簡単になります。ですので、ええと、spark は直接いくつかの mul、ええと、ユーティリティ関数を実行でき、それが直接、ええと、あなたのデータを他のオープンソース mul に入れ、さらにあなたの results code も、ええと、とてもシンプルなコードで行えます。では、どのように Spark connector を実行できるかについて、とても簡単なデモをお見せします。はい。
では、ええと、私がやろうとしているのは、ええと、いくつかのデータを、ええと、MySQL、ええと、クラスターにダンプし、すべての、ええと、データを移行することです。ですので、ええと、最初に、ええと、特別な I do、ええと、spark claim があります。ええと、データフレームにいくつかのデータを書き込もうとしますよね？そして第2段階では、ええと、データストリームを読み、ええと、データフレームを my に入れ、別のデータ、ええと、データフレームとして読み出します。はい。そして重要な部分はここです。たった、ええと、おそらく20行のコードで、ええと、すべての order datas の inbound を実行して ware に入れることができます。
はい。まず最初に、ええと、あなたは、ええと、どのような、ええと、tokenize を使用するかを決めます。そして、ええと、それから、それが元の MySQL データフレームを変換します。次のステップは、ええと、埋め込みモデルを指定することです。今、ええと、私たちが使用しているのは word, two lecture で、ええと、tokens が入力です。そして、ええと、出力は、ええと、実際には 1 28 次元のベクトルです。
ですので、この、ええと、変換の後ですね？すべての I embed を含む別の、ええと、データフレームが得られます。はい。そして、ええと、最後の、最後のステップは、ええと、この、ええと、mill データフレームをロードすることです。ですので、ええと、この、このデータフレームでは、いくつかの、ええと、key pounds を指定する必要があります。たとえば、ええと、mills host は何か、mills part は何か、どの種類の接続をロードするのか、ええと、実際の vector field name、vector dimensions、ええと、この、ええと、mural の、ええと、この mul collection の primary key field は何か、などです。そして save を実行します。
それから起こることとしては、SparkでMySQLからすべてのデータを取り出し、埋め込みを行い、その埋め込みデータをすべてMulesに入れます。そうです。ええと、この機能は、Spark、オープンソースのSparkだけで動作するわけではありません。もしDatabricksユーザーであれば、そのプラットフォーム上に大量のデータがあるかもしれません。そして、ええと、私たちはDatabricksとの統合も発表しました。
ですので、ええと、ほんの少しのコードで、Databricksからすべてのデータを取り出し、すべての埋め込みと分析を行って、データの内部にあるものをすべて見つけることができます。さらに、Databricksコネクタを使えば、ベクトルデータに対して多くの分析を行うことができます。ええと、例えば、Spark ML leadsを使って分散クラスタリングを行うことができますし、あるいはベクトルデータの異常を見つけた場合にも、そうです。Sparkは多くの分散計算を行うのを支援でき、一方でmealsはスケーラブルなストレージになるのを支援できます。ですので、mulとsparkleの両方が非常に密接に連携して動作し、私たちの結果であるcalledやDatabricks stepとも同様に連携します。
それは素晴らしいですね。そして、ええと、James、私の理解では、私たちは公開していて、これはcalledだけでなく、ええと、notebook、ウェブサイト上のnotebookもあります。ですので、興味のある方は誰でも確認できますし、私たちから、ええと、その、そのリンクをメールでもお送りできます。また、もし確認したい場合は、ええと、それでは締める前に、ええと、James、少し気になっているのですが、あなたはすでにCardinalや将来のセキュリティ面でのエキサイティングなことについて話してくれました。ええと、しかし、今後6〜12か月で、それらのクラウドをどのように思い描いていますか？どのようなエキサイティングなことが起こるのでしょうか？わかりました、では、ええと、私は、そうですね、最優先事項はコスト削減になると思います。
ですので、今後12か月でベクトルデータストレージのコストを大幅に削減することを目指しており、2、2、3、4の低下を目標にしています。そうです。AIアプリケーションの継続的な成長に伴い、ええと、今年中にベクトルデータの量が爆発的に増加すると思います。ですので、ええと、コストはすべてのユーザーにとって、またすべてのEIDCアプリケーション開発者にとって、非常に非常に重要になります。そうです。
そして、ええと、第二に、私たちはthose callサービスに取り組んでいます。ですので、ええと、導入への対応を強化し、すべてのアプリケーションをより使いやすくします。そうです。ええと、それらにはすべて同様の要件がありますよね？マルチテナンシー、ええと、大量のホットデータがありますが、ええと、多くのwormテナントやcotenもあります。では、クエリしたいデータをすべてどのように分離できるか、ええと、彼らは弾力性を求めています。なぜなら、ええと、彼らのアプリケーションは非常に速く成長しているからです。
ですので、私たちは新しいサービスティアをリリースしなければなりません。ええと、このティアは、クエリとストレージの両方に対して完全なオンデマンド課金を提供するように設計されます。つまり、何百万ものテナントを持つ、ええと、rackアプリケーション設計者のあらゆるニーズに対応するものです。そうです、私たちは、私たちは自動スケーリング機能も備えています。ええと、それにより、ワークロードに必要なリソースを調整できるようにします。
そうです。そして第三に、検索品質の最適化だと思います。すべてのrackアプリケーションにおいて、検索品質は実際に非常に非常に重要です。ですので、those callは、スパースmeetings、スパースとdancing meetingsの間のheavy research、そしてクエリランキングといった機能を導入する予定であり、それらはユーザーがより正確な結果を見つけるのに役立ちます。そうです。
ええと、最後に挙げるとすれば、実際にはインテグレーションと使いやすさです。私たちは pipeline と呼ばれるものをリリースしました。これは、データのチャンク化、埋め込み、検索、ランキングなどの一連の操作をユーザーが実行できるように設計されています。はい。ですので、データの入出力を容易にするために、これらの cloud pipeline で、マルチモデル検索や、より多くのユーザー定義関数など、さらに多くの機能をサポートしていく予定です。はい。今後、これらの cloud pipeline は、多くのオープンソースプロジェクトや他のソースプロジェクトとも連携し、いわゆるクラウドと他のデータプロバイダーとの間でシームレスなデータ統合を実現していきます。
とてもワクワクするニュースです。どうぞご期待ください。新しいエキサイティングな機能がリリースされるたびに、必ず最新情報をお届けします。私の方からの質問は以上です。ええと、視聴者の皆さんから何か質問はありますか？qand a ボックスに質問を投稿していただければ、James が回答を手伝ってくれます。数分待って、どなたか手を挙げたい方がいるか見てみましょう。
はい。質問があります。ええと、これは Pine Con や V Deviate のような他のマネージドソリューションと比べてどうですか？ああ、それは良い質問ですね。はい、良い質問です。はい。
それに、私のお気に入りの質問でもあります。はい。ええと、比較のどの部分を見たいのかは分かりませんが、一般的な考えをいくつかお伝えできます。まず第一に、私たちにはオープンソースプロジェクトがあり、それはかなり長い間運用されています。
ですので、those cloud では完全に、完全にオープンソースソリューションの上に構築しています。したがって、もちろんベンダーロックインはありません。そうですよね。また、パフォーマンスとコストについて質問されていますので、それを確認する最も簡単な方法は、私たちの Vector V bench を直接実行していただくことです。そこには、Pine Coin、Vivid Cauldron、そしてその他の主要な retro dvs とのパフォーマンス比較があります。
私たちのテスト結果では、ええと、これが公平な比較になると言っているわけではありません。なぜならデータは私たちのベンチマークから来ているからです。はい。現在、実際には競合他社すべてよりもかなり高速です。また、私たちはディスク、ディスクソリューション、capacity Terra を提供しているため、すべてのデータをメモリに置くのではなく、その一方でほとんどのデータをディスク上に置いています。そのため、メモリコストも節約できます。
もし A ITC 検証のようなものを構築していて、非常に非常に高速なパフォーマンスを求めているわけではない場合、capacity optimizing の仕組みは多くの費用を節約するのに役立つと思います。素晴らしいです。ええと、Vector DB bench のリンクもチャットに貼りました。ですので、ぜひご自身で確認してみてください。他に質問があるか見てみましょう。
あと2分ほど待ちます。はい。それから、もう一つ言及したいのは enterprise Ready についてです。これも非常に大きな違いになります。というのも、Vector two db について話すとき、すべての Vector database が実際にデータベースであるわけではないからです。ですので、データベースと言うときに私たちが期待するのは、多くの管理ツールがあり、可視化があり、データバックアップがあり、マイグレーションがあり、障害復旧がある、そういったものです。
ですので、Vector DB を選ぶ際には、それらはすべて非常に重要な評価項目になります。そうですよね？それから機能性もです。どのような機能をサポートできるのか。ええと、すべてのベクトルベースにはフィルタリング検索があるかもしれませんし、メタフィルタリングがあるかもしれませんが、パフォーマンスは非常に非常に異なります。はい。ですので、すべての機能について、また非常に重要になるいくつかのエンタープライズ機能についても、たくさん確認する必要があります。はい。
ええと、チャットにこれ以上質問がないようなので、ええと、それでは、本当にジェームズに感謝を、ありがとうと言いたいです。そして、ここに来て、私たち参加者全員に、Zillow cloud の新機能などを共有してくれて、次回のローンチを楽しみにしています。ありがとうございます。では皆さん。またお会いしましょう。
Meet the Speaker
Join the session for live Q&A with the speaker
James Luan
VP of Engineering at Zilliz
James Luan is the VP of Engineering at Zilliz. With a master's degree in computer engineering from Cornell University, he has extensive experience as a Database Engineer at Oracle, Hedvig, and Alibaba Cloud. James played a crucial role in developing HBase, Alibaba Cloud's open-source database, and Lindorm, a self-developed NoSQL database. He is also a respected member of the Technical Advisory Committee of LF AI & Data Foundation, contributing his expertise to shaping the future of AI and data technologies.