You’re in!
ウェビナー
月例製品デモ：Zilliz Cloud の力を発見する
WEBVTT
1 00:00:03.495 --> 00:00:06.315 私の名前はChris Elloで、ここZillizで働いています。
2 00:00:06.845 --> 00:00:10.075 今日は毎月恒例の、ええと、クラウドデモを行います。
3 00:00:10.535 --> 00:00:11.595 そして皆さんにはぜひ
4 00:00:11.735 --> 00:00:15.795 質問をチャットかQ&Aのどちらかに入力していただきたいです。
5 00:00:16.375 --> 00:00:20.555 ええと、それで、ええと、このセッション中に、もし、
6 00:00:20.735 --> 00:00:22.675 もしJRIが、ええと、質問を見つけたら、
7 00:00:22.755 --> 00:00:24.555 できるだけ早く回答していきます。
8 00:00:25.175 --> 00:00:28.355 ええと、ただデモの最後には回線も開放します。
9 00:00:28.555 --> 00:00:30.275 というのも、扱いやすい人数のグループだと思うので、
10 00:00:30.295 --> 00:00:32.595 Jayに直接質問できるようにします。
11 00:00:33.215 --> 00:00:34.835 ええと、それから、ええと、必ず
12 00:00:34.835 --> 00:00:36.235 それらを録画に残すようにします。
13 00:00:36.735 --> 00:00:40.035 ええと、では、ええ、さっそく、ええ、始めましょう。
14 00:00:40.215 --> 00:00:44.915 それでは、簡単に、ええと、クラウドについて説明します。
15 00:00:45.015 --> 00:00:47.275 そして、ここにいる皆さんは、ええと、
16 00:00:47.305 --> 00:00:49.195 Milvusについて少しはすでにご存じのはずです。
17 00:00:49.255 --> 00:00:51.155 そうでなければ、ええと、今日参加されていないでしょうから。
18 00:00:51.255 --> 00:00:53.835 ですが基本的に、Zilliz cloudは
19 00:00:53.895 --> 00:00:55.955 私たちのオープンソースプロジェクト、ええと、Milvusの上に構築されています。
20 00:00:56.695 --> 00:01:00.715 そして、ええと、私が思うに、多くの人々、
21 00:01:00.855 --> 00:01:02.515 あるいは多くの企業は、ええと、
22 00:01:02.515 --> 00:01:03.715 オープンソースプロジェクトを持っている場合、
23 00:01:04.065 --> 00:01:06.315 単にホスト版を提供するだけです。
24 00:01:06.575 --> 00:01:09.115 そのオープンソースプロジェクトのホスト版を、少しだけ、
25 00:01:09.215 --> 00:01:11.915 その、追加の、たとえば請求ロールのようなものを付けたり、
26 00:01:12.055 --> 00:01:13.475 あるいは少しセキュリティがあるかもしれない程度で提供します。
27 00:01:14.055 --> 00:01:16.675 しかし私たちは最初から、
28 00:01:16.675 --> 00:01:19.075 単なるホスト版以上のものである必要があると判断しました。
29 00:01:20.015 --> 00:01:22.835 そして、ええと、これらはある意味、3つの、
30 00:01:22.835 --> 00:01:26.195 MilvusとZillizの中核的な違いです。
31 00:01:26.695 --> 00:01:29.475 まず1つ目は、Milvusの下には非常に高性能な
32 00:01:29.615 --> 00:01:32.075 検索エンジンがあります。GitHubに行くと、
33 00:01:32.075 --> 00:01:35.675 nowhere、K-N-O-W-H-E-R-Eというものを目にするかもしれません。
34 00:01:36.065 --> 00:01:38.155 それがMilvusにおける私たちの検索エンジンです。
35 00:01:38.935 --> 00:01:43.195 そして、ええと、さらに、ええと、11種類のインデックスもサポートしています。
36 00:01:43.375 --> 00:01:45.555 ええと、ですので、非常に便利です。
37 00:01:45.555 --> 00:01:47.835 なぜなら、ええと、その、私たち一人ひとりが
38 00:01:47.835 --> 00:01:50.235 ユースケースに紐づいた非常に独自の、ええと、一連の
39 00:01:50.235 --> 00:01:51.635 要件を持つことになるからです。
40 00:01:51.635 --> 00:01:55.115 ですから、私たちのユースケースに適合する
41 00:01:55.115 --> 00:01:56.675 インデックスを選べることは本当に良いことです。
42 00:01:57.335 --> 00:01:59.755 しかし、Zilliz Cloudを作成したとき、
43 00:01:59.985 --> 00:02:01.035 それだけでは十分ではないと判断しました。
44 00:02:01.415 --> 00:02:03.435 私たちはMilvusよりもさらに高性能であることを
45 00:02:03.435 --> 00:02:04.515 確実にしたかったのです。
46 00:02:04.895 --> 00:02:08.315 また、インデックスを選ぶ負担を
47 00:02:08.315 --> 00:02:09.915 皆さんの肩から取り除きたいとも考えました。
48 00:02:09.935 --> 00:02:11.515 そこでAuto Indexというものがあります。
49 00:02:11.515 --> 00:02:14.155 これについてはJayがデモの中で簡単に話します。
50 00:02:14.935 --> 00:02:18.035 そしてさらに、皆さんには非常に独自の要件があるため、
51 00:02:18.425 --> 00:02:21.275 皆さんのユースケースの中には、ええと、つまり、
52 00:02:21.365 --> 00:02:24.035 非常に厳しいレイテンシ要件がある場合もあるでしょうし、
53 00:02:24.095 --> 00:02:25.155 あるいは多くの人が
54 00:02:25.305 --> 00:02:27.275 皆さんのアプリケーションを攻撃している場合もあります。
55 00:02:27.295 --> 00:02:28.355 そのため、多くのクエリが
56 00:02:28.355 --> 00:02:29.595 データベースに到達します。
57 00:02:29.905 --> 00:02:32.115 誰もが異なる要件を持っています。
58 00:02:32.815 --> 00:02:35.075 ですから、私たちは皆さんの実際のニーズに合うように
59 00:02:35.135 --> 00:02:38.635 データベースをチューニングできるよう支援し、
60 00:02:38.695 --> 00:02:40.915 それを本当にシンプルな方法で行いたいと考えています。
61 00:02:41.695 --> 00:02:43.995 さらに、これは、ええと、クラウドネイティブなデータベースです。
62 00:02:43.995 --> 00:02:45.915 もちろん、それは多くの専門用語のように聞こえたり、
63 00:02:45.915 --> 00:02:48.155 単なる話のように思えるかもしれませんが、結局のところ、
64 00:02:48.335 --> 00:02:51.995 本質的には、ええと、私たちがスケーラブルであることを確実にし、
65 00:02:52.215 --> 00:02:54.475 皆さんが自動でスケールアップ、スケールダウンできるようにすることです。
66 00:02:54.615 --> 00:02:56.315 これについてもJayが説明します。
67 00:02:56.935 --> 00:03:00.325 そして最後に、ええと、つまり、SaaSアプリケーションは
68 00:03:00.325 --> 00:03:02.445 安全である必要があり、ええと、
69 00:03:02.545 --> 00:03:04.685 皆さんの、ええと、セキュリティチームが求める
70 00:03:04.685 --> 00:03:08.005 コンプライアンスや規制上の、ええと、認証をすべて
71 00:03:08.325 --> 00:03:09.485 提供する必要があります。
72 00:03:11.485 --> 00:03:14.665 ええと、先ほど述べたように、Cardinalは私たちの検索エンジンです。
73 00:03:15.325 --> 00:03:18.785 そして、ええと、ここは実際には飛ばして、
74 00:03:18.785 --> 00:03:20.865 Jayにもっと詳しく説明してもらいます。
75 00:03:21.725 --> 00:03:23.625 ええと、そしてここでご覧のように、つまり、
76 00:03:23.625 --> 00:03:25.665 open source MilvusとZillizの違いが
77 00:03:25.665 --> 00:03:28.025 もう少し詳しく示されています。
78 00:03:28.445 --> 00:03:31.265 ですから、ええと、もちろん、つまり、私はMilvusでは利用できない機能を
79 00:03:31.265 --> 00:03:33.025 すべて選びました。
80 00:03:33.025 --> 00:03:35.825 なので、皆さんには、おお、Zillizはものすごく素晴らしい、
81 00:03:35.845 --> 00:03:37.945 というふうに見えるかもしれませんが、願わくば
82 00:03:37.965 --> 00:03:40.425 理解していただけると思います。つまり、移行、バックアップ、
83 00:03:41.025 --> 00:03:43.705 キャパシティプランニングの更新、自動スケールなど、
84 00:03:43.705 --> 00:03:46.185 これらは私たちが、つまり、
85 00:03:46.185 --> 00:03:47.825 その負担を皆さんの肩から取り除き、
86 00:03:47.925 --> 00:03:51.025 完全マネージドの、ええと、Zilliz cloudに移そうと考えたものです。
87 00:03:52.875 --> 00:03:56.615 ええと、私たちはエンタープライズ対応を維持するためにも
88 00:03:56.755 --> 00:03:58.055 非常に努力しています。
89 00:03:58.635 --> 00:04:01.335 ですので、ええと、私たちのセキュリティページには
90 00:04:01.335 --> 00:04:03.175 この詳細がたくさんありますが、
91 00:04:03.515 --> 00:04:05.175 私たちは、つまり、
92 00:04:05.235 --> 00:04:08.015 あらゆるレベルからセキュリティを見るようにしたいのです。つまり、
93 00:04:08.035 --> 00:04:12.055 皆さんのデータからロールに至るまで、
94 00:04:12.405 --> 00:04:15.135 さらにはZilliz Cloudとのインターフェース方法に至るまでです。
95 00:04:16.725 --> 00:04:19.585 そして最後に、念のためですが、つまり、私たちには、ええと、
96 00:04:19.655 --> 00:04:21.905 基本的に、ええと、3つの異なる提供形態があります。
97 00:04:22.005 --> 00:04:24.665 Milvusがあり、これは3つの異なるバージョンで提供されます。
98 00:04:24.845 --> 00:04:27.065 ええと、ライト版は、ええと、
99 00:04:27.125 --> 00:04:28.265 実際には組み込み版です。
100 00:04:28.325 --> 00:04:29.905 ですので、本当に小さなものにそれを入れることができます
101 00:04:30.005 --> 00:04:31.665 あるいは、単にそれらをJupyter Notebookに投げ込むこともできます。
102 00:04:32.285 --> 00:04:35.145 私たちには、ええと、スタンドアロン版があり、
103 00:04:35.145 --> 00:04:36.825 そして完全分散版もあります。
104 00:04:36.965 --> 00:04:40.425 ですので、誰もが始められる本当に強力な、ええと、あの、
105 00:04:40.445 --> 00:04:41.705 データベース群です。
106 00:04:42.205 --> 00:04:43.905 またZilliz Cloudもあり、これは
107 00:04:43.905 --> 00:04:45.545 今日のデモで取り上げるものです。
108 00:04:46.045 --> 00:04:48.905 そして、ええと、Zilliz Cloud BYOCもあります。
109 00:04:48.915 --> 00:04:53.145 そこでは、ええと、その、ええと、
110 00:04:53.145 --> 00:04:54.545 データプレーンをコントロールプレーンから分離しています。
111 00:04:54.605 --> 00:04:56.265 ですので、これは企業向けになります。
112 00:04:56.265 --> 00:04:59.785 非常に厳格な、ええと、セキュリティ要件を持つ企業向けですが、
113 00:05:00.245 --> 00:05:01.585 結局のところ本当に、
114 00:05:01.925 --> 00:05:03.105 一度構築すればよいだけです。
115 00:05:03.105 --> 00:05:06.265 これらのインスタンスのいずれかに移行する必要がある場合でも、ええと、データベースを、ええと、
116 00:05:06.285 --> 00:05:09.105 再構築させることはありません。
117 00:05:09.605 --> 00:05:11.985 ですが今日はZilliz Cloudに焦点を当てます。
118 00:05:12.565 --> 00:05:14.305 では、ここで私は話すのをやめて、
119 00:05:15.125 --> 00:05:17.905 バトンをJayに渡します。
120 00:05:19.485 --> 00:05:21.995 どうもありがとう、Chris。おはようございます。
121 00:05:22.145 --> 00:05:25.395 皆さん、こんばんは。画面を共有します。
122 00:05:25.395 --> 00:05:26.515 少々お待ちください。
123 00:05:30.215 --> 00:05:33.695 はい、皆さん私の画面が見えていますよね？いいですね。
124 00:05:34.075 --> 00:05:36.455 ええと、ではリコールについて、ええと、
125 00:05:36.455 --> 00:05:37.735 リコール率のチューニングについてはすぐに話しますが、
126 00:05:37.835 --> 00:05:39.855 少しだけ立ち戻りたいと思います。
127 00:05:40.475 --> 00:05:43.695 そしてRAGについて少し話します。ええと、
128 00:05:43.875 --> 00:05:45.855 つまり検索拡張生成です。
129 00:05:46.355 --> 00:05:47.495 ええと、なぜなら、ご存じのように、それは、
130 00:05:47.495 --> 00:05:49.775 ベクトルデータベースにとって最も人気のあるユースケースであり、
131 00:05:49.775 --> 00:05:51.975 おそらく現在のキラーアプリのようなものだからです。
132 00:05:52.095 --> 00:05:53.095 ベクトルデータベースにとってですね。
133 00:05:53.155 --> 00:05:56.015 ですので、多くのZillizの機能を
134 00:05:56.015 --> 00:05:58.125 その文脈の中に位置づけたいと思います。ええと、多くの
135 00:05:58.125 --> 00:05:59.565 皆さんが本当に関心を持っていると
136 00:05:59.565 --> 00:06:00.845 思われる特定のユースケースですからね。
137 00:06:01.225 --> 00:06:03.885 では、RAGによって何ができるのでしょうか？
138 00:06:03.905 --> 00:06:07.365 それは、あらゆるデータを
139 00:06:08.225 --> 00:06:11.445 現代の大規模言語モデルのコンテキストウィンドウに含めることを可能にします。
140 00:06:11.745 --> 00:06:13.405 ええと、つまり別の言い方をすると、
141 00:06:13.405 --> 00:06:15.725 LLMがもともと訓練されていなかったトピックについて
142 00:06:15.955 --> 00:06:18.725 質問に答えられるようにする、ということです。
143 00:06:18.725 --> 00:06:21.245 たとえば社内向けのドキュメントかもしれません。
144 00:06:21.625 --> 00:06:23.805 法律事務所であれば、現在の訴訟で提出した
145 00:06:23.805 --> 00:06:25.325 申立書かもしれません。
146 00:06:25.345 --> 00:06:27.405 医師であれば、患者に関するあらゆるデータかもしれませんし、
147 00:06:27.405 --> 00:06:28.405 そういった形で、ほら、
148 00:06:28.405 --> 00:06:29.365 例は延々と続きますよね。
149 00:06:29.705 --> 00:06:32.525 ええと、これが機能する仕組みは埋め込みモデルによるもので、
150 00:06:32.525 --> 00:06:35.725 これは非常に高価な事前訓練済みの、そうですね、
151 00:06:36.025 --> 00:06:39.285 ええと、意味的コンテキストの空間的な表現のようなものです。
152 00:06:39.345 --> 00:06:42.205 空間内に、です。言い換えると、それはテキストの塊のようなもので、
153 00:06:42.205 --> 00:06:43.525 何らかの意味的な意味を持っていて、
154 00:06:44.105 --> 00:06:46.805 その意味的な意味は何らかの位置によって表され、
155 00:06:47.145 --> 00:06:49.245 ええと、測定可能な座標を持っているわけです、そうですよね？
156 00:06:49.705 --> 00:06:53.925 つまりベクトルデータベースは、あるテキストの塊と
157 00:06:53.925 --> 00:06:55.285 別のテキストの塊との距離を測定し、
158 00:06:55.335 --> 00:06:58.685 それによって、そのテキストが別のテキストに対して
159 00:06:58.835 --> 00:07:01.645 意味的にどれほど関連しているかを示す何らかの指標が得られます。
160 00:07:01.665 --> 00:07:04.885 完全に一致する語彙があるかどうかに関係なく、です。そうですよね？
161 00:07:04.885 --> 00:07:07.325 ですからこれは非常に、ええと、これはある種の転換なんです。
162 00:07:07.505 --> 00:07:09.125 つまり、従来の検索からの、ですね。
163 00:07:09.275 --> 00:07:12.285 たとえば Apache Lucin のように、長い間
164 00:07:12.305 --> 00:07:14.045 語彙一致に大きく依存してきたものから、です。そうですよね？
165 00:07:14.045 --> 00:07:15.605 つまり、あるテキストの塊が
166 00:07:15.755 --> 00:07:18.485 別のテキストの塊と語彙的な一致をまったく持たない場合でも、
167 00:07:18.705 --> 00:07:20.205 意味的には関連している可能性があり、
168 00:07:20.345 --> 00:07:23.005 それらはベクトル空間内でより近くに配置されます。
169 00:07:23.005 --> 00:07:25.405 そしてそれこそがベクトルデータベースによって可能になること、つまり
170 00:07:25.405 --> 00:07:26.765 それらの距離を測定することなんです、そうですよね？
171 00:07:27.585 --> 00:07:31.005 では、Zilliz はここでどのように役立つのでしょうか、そうですよね？
172 00:07:31.865 --> 00:07:34.525 すべてのデータ、つまりすべての
173 00:07:34.525 --> 00:07:36.845 患者データ、あるいは、つまり、私たちが関心を持っている
174 00:07:36.845 --> 00:07:38.485 検索対象のものを
175 00:07:38.485 --> 00:07:41.365 小さなチャンクに分割し、それらに埋め込みを付けて
176 00:07:41.365 --> 00:07:42.325 Zilliz に読み込んだら、ですね。
177 00:07:42.395 --> 00:07:43.605 Zilliz に読み込まれた状態です、そうですよね？
178 00:07:43.905 --> 00:07:47.685 Zilliz にベクトルクエリを送ることができ、
179 00:07:47.785 --> 00:07:50.525 いま送ったものに最も近いベクトルを
180 00:07:50.785 --> 00:07:52.725 返すように依頼できます、そうですよね？
181 00:07:52.755 --> 00:07:55.765 ここで Zilliz は距離の測定を行い、
182 00:07:55.765 --> 00:07:58.085 近似最近傍、または a and n と呼ばれるものを
183 00:07:58.285 --> 00:07:59.365 実行します。
184 00:07:59.705 --> 00:08:02.285 ええと、厳密な最近傍ではなく近似を利用するのは、
185 00:08:02.285 --> 00:08:04.965 総当たりで、つまり幾何学的な距離測定を、
186 00:08:05.185 --> 00:08:07.605 すべてのノードと、それに接続された他のすべてのノードに対して
187 00:08:07.635 --> 00:08:10.605 行い、ええと、空間内で、そして
188 00:08:10.625 --> 00:08:11.765 妥当な時間内に返すことは、
189 00:08:11.765 --> 00:08:13.765 現在、多くのユースケースでは
190 00:08:14.245 --> 00:08:15.845 実現困難だからです、そうですよね？
191 00:08:15.945 --> 00:08:17.245 結果を比較的
192 00:08:17.245 --> 00:08:19.285 素早く返せるようにしたいわけです。
193 00:08:19.285 --> 00:08:21.885 たとえ、すべての一致を取得しなくてよい、
194 00:08:22.015 --> 00:08:23.405 と言ったとしても、そうですよね？
195 00:08:23.825 --> 00:08:25.685 ええと、実際には、
196 00:08:25.705 --> 00:08:28.005 100ミリ秒や
197 00:08:28.005 --> 00:08:30.525 500ミリ秒で返すことのほうが重要で、分単位ではありません、そうですよね？
198 00:08:30.525 --> 00:08:33.085 それはほとんどの場合、使い物にならないですから。
199 00:08:33.545 --> 00:08:34.885 ええと、ですので a
200 00:08:34.885 --> 00:08:37.285 and n インデックスの仕組みは、もちろん範囲外ですが、
201 00:08:37.285 --> 00:08:40.165 このウェビナーの内容ですが、Zilliz には非常にシンプルな抽象化
202 00:08:40.165 --> 00:08:43.365 レイヤーが用意されていて、ええ、リコール精度と
203 00:08:43.595 --> 00:08:46.605 クエリレイテンシのトレードオフを行えます。
204 00:08:46.865 --> 00:08:49.965 つまり、覚えていればですが、近似しているわけですよね？
205 00:08:50.185 --> 00:08:53.085 検索ですべての近傍を取得した場合、そこで私たちは
206 00:08:53.915 --> 00:08:56.845 Zilliz で level パラメータと呼ばれるものを公開しています。
207 00:08:56.845 --> 00:08:58.245 それについては、すぐに説明します。
208 00:08:58.395 --> 00:09:00.125 これは、ここにあります。ええと、
209 00:09:01.225 --> 00:09:03.845 そしてこれは、ベクトルデータベースが
210 00:09:04.135 --> 00:09:07.245 パイプラインのどこに位置するかによって非常に役立ちます。
211 00:09:07.545 --> 00:09:09.165 ユーザー向けのパイプラインであれば、
212 00:09:09.165 --> 00:09:12.525 おそらくレイテンシをより速くする方向に調整したいはずです。
213 00:09:12.525 --> 00:09:13.685 というのも、ユーザーはおそらく
214 00:09:13.685 --> 00:09:15.125 何かを待っているからです。
215 00:09:15.425 --> 00:09:16.885 もし、そうですね、より
216 00:09:16.885 --> 00:09:19.005 分析系のパイプラインがある場合、ええ、
217 00:09:19.025 --> 00:09:21.245 そして本当に、できるだけすべての、
218 00:09:21.245 --> 00:09:23.805 つまり、可能な限り最高のリコールを得ることに関心があるなら、
219 00:09:23.805 --> 00:09:25.165 リコール寄りにしたいかもしれませんよね？
220 00:09:25.185 --> 00:09:26.645 そしてそのバランスはあなた次第です。
221 00:09:26.945 --> 00:09:29.925 私たちはこれを非常にシンプルな抽象化を通じて提供していますよね？
222 00:09:29.945 --> 00:09:32.645 これは、これは私たちの Python、SDK を使った
223 00:09:32.675 --> 00:09:34.525 クエリの例です。ええ、
224 00:09:34.625 --> 00:09:36.125 上部にクエリベクトルが見えます。
225 00:09:36.225 --> 00:09:37.765 つまり、それが実際に
226 00:09:37.765 --> 00:09:38.845 データベースに伝えているベクトルです。
227 00:09:39.075 --> 00:09:40.965 この特定の位置に最も近い
228 00:09:41.105 --> 00:09:42.285 近傍をすべてください、ということです。
229 00:09:42.825 --> 00:09:45.165 そして基本的には、そうですね、私は、ええ、
230 00:09:45.295 --> 00:09:46.325 最も近い3件をくださいと言っています。
231 00:09:46.465 --> 00:09:49.245 これが top K で、先ほど述べた levels パラメータは、
232 00:09:49.245 --> 00:09:50.645 まさにここにあります。
233 00:09:50.705 --> 00:09:55.205 これはデフォルトで1になっていて、ええ、最大10まで設定でき、
234 00:09:55.785 --> 00:09:57.445 これをいろいろ試すことができます。
235 00:09:57.465 --> 00:09:58.925 そしてこれはクエリ単位で行われますよね？
236 00:09:58.925 --> 00:10:00.325 つまり、あるクエリを1で送信し、
237 00:10:00.325 --> 00:10:01.885 別のクエリを10で、別のクエリを5で送信して、
238 00:10:01.885 --> 00:10:03.925 いろいろ試しながら、そうですね、
239 00:10:04.075 --> 00:10:06.325 それぞれのシナリオでリコールがどう見えるか、
240 00:10:06.825 --> 00:10:09.885 そしてそれぞれのシナリオでレイテンシがどう見えるかを確認できます。
241 00:10:09.885 --> 00:10:11.125 ですから、その点で非常に柔軟です。
242 00:10:11.185 --> 00:10:13.005 この作業を行うたびにインデックス全体を
243 00:10:13.005 --> 00:10:14.125 再構築する必要はありません。
244 00:10:14.475 --> 00:10:16.485 これは、これは、これは非常に、ええと、そうですね、
245 00:10:16.585 --> 00:10:18.325 その場で行う調整のようなものですよね？
246 00:10:18.325 --> 00:10:19.365 それは、とても良い点です。
247 00:10:19.705 --> 00:10:21.165 ええ、参考までに、多くの
248 00:10:21.165 --> 00:10:22.725 他のベクトルデータベースソリューションでは、
249 00:10:23.155 --> 00:10:25.965 たいていの場合、単一のインデックスを選びます。
250 00:10:26.385 --> 00:10:28.685 ええ、ほとんどの場合、1つのインデックスを選びます。そうですね、
251 00:10:28.685 --> 00:10:31.925 それが HNSW であれ、disk NN であれ、face であれ、
252 00:10:31.985 --> 00:10:33.805 あるいは、今ある他の種類の、ええと、
253 00:10:33.825 --> 00:10:36.325 既製の、あの、インデックスアルゴリズム
254 00:10:36.325 --> 00:10:38.325 なんかも、あの、
255 00:10:38.465 --> 00:10:39.925 それぞれにトレードオフがあるんですよね？
256 00:10:39.925 --> 00:10:41.405 それぞれに、その、トレードオフをしていて
257 00:10:41.405 --> 00:10:44.005 再現率の精度とクエリ遅延の間で、
258 00:10:44.005 --> 00:10:45.365 結局それを使うことになり、
259 00:10:45.365 --> 00:10:46.605 それに縛られるような形になります。
260 00:10:46.905 --> 00:10:49.645 ええと、Milvus では、それらを入れ替えることができますよね？
261 00:10:49.645 --> 00:10:52.605 つまり、望むなら別のものに入れ替えられるのですが、
262 00:10:52.985 --> 00:10:54.845 それは、ええと、手動のプロセスです。
263 00:10:55.065 --> 00:10:57.965 それぞれの、あの、
264 00:10:57.975 --> 00:10:59.325 インデックスアルゴリズムの特性を知っている必要がありますよね？
265 00:10:59.325 --> 00:11:02.845 そこでこれは、Zilliz cloud のお客様に公開しているもので、
266 00:11:03.185 --> 00:11:06.965 そして繰り返しになりますが、これは、私たちが、ほら、
267 00:11:06.985 --> 00:11:08.685 ここにマネージドサーバーがあり、
268 00:11:08.685 --> 00:11:11.165 このようなベクトルの複雑さの多くを抽象化して
269 00:11:11.225 --> 00:11:15.765 お客様のために扱い、非常にわかりやすい、あの、
270 00:11:15.855 --> 00:11:19.445 レバーを提供して、それを操作することで、あの、
271 00:11:19.445 --> 00:11:20.565 その、再現の行われ方を変えられる、という別の方法です。
272 00:11:20.625 --> 00:11:22.565 なので、ええと、繰り返しますが、これについては
273 00:11:22.565 --> 00:11:24.645 無理にメモを取らなくても大丈夫です、ええと、
274 00:11:24.645 --> 00:11:26.445 この通話の最後にドキュメントをすべて送れますが、
275 00:11:26.445 --> 00:11:28.605 これは強調しておくことが本当に重要だと思います、あの、
276 00:11:28.605 --> 00:11:29.765 なぜなら
277 00:11:29.765 --> 00:11:32.405 多くのお客様がこれに非常に大きな有用性を見いだしていることが
278 00:11:32.405 --> 00:11:33.645 わかっているからです、あの、
279 00:11:33.705 --> 00:11:36.525 そして多くの、
280 00:11:36.525 --> 00:11:38.365 多くのユースケースで大きな柔軟性を与えてくれます。つまり、
281 00:11:38.365 --> 00:11:39.725 必ずしも何かを入れ替える必要がないのです。
282 00:11:40.225 --> 00:11:42.765 そして繰り返しになりますが、これはすべて、Chris が
283 00:11:42.855 --> 00:11:45.565 先ほど触れた、その Cardinal、あの、
284 00:11:45.755 --> 00:11:48.245 インデックスエンジンの一部です。
285 00:11:48.245 --> 00:11:49.885 Cardinal には他にも多くの利点がありますが、
286 00:11:49.905 --> 00:11:52.325 あまり詳しくは入りません。ただ、思いつくところでは、あの、
287 00:11:52.325 --> 00:11:54.485 Quantization に関して私たちが行っている
288 00:11:54.695 --> 00:11:59.085 興味深いことがたくさんあります。そこでは、ええと、多くのベクトルには、あの、多数の、
289 00:11:59.115 --> 00:12:01.605 非常に多くの浮動小数点数が付随しています。
290 00:12:01.985 --> 00:12:04.325 それらを切り詰めると、あの、もしかすると、
291 00:12:04.345 --> 00:12:07.685 再現率の精度で 2% や 3% 程度失うかもしれませんが、
292 00:12:08.105 --> 00:12:12.485 一方で、コンピュートとストレージについては、30%、40%、50% 以上
293 00:12:12.505 --> 00:12:14.165 節約できる可能性がありますよね？
294 00:12:14.225 --> 00:12:17.445 ですから、それは一部の人たちが、ええと、選びたいトレードオフです。
295 00:12:17.585 --> 00:12:20.565 あの、そして、そして、Cardinal はお客様のスタックを見て、
296 00:12:20.565 --> 00:12:22.045 お客様のパイプラインを見て、
297 00:12:22.065 --> 00:12:23.805 必要な調整を行います。
298 00:12:23.805 --> 00:12:25.365 つまり、そこには多くのインテリジェンスが組み込まれていて、
299 00:12:25.365 --> 00:12:26.565 他にも多くのチューニングや
300 00:12:26.785 --> 00:12:30.685 そして、ええと、あの、私たちが行った調整があります。
301 00:12:30.685 --> 00:12:33.645 ほぼあらゆるユースケースに合うようにするためですよね？
302 00:12:33.985 --> 00:12:35.645 ええと、ご存じのとおり、私たちはまた非常に密接に
303 00:12:35.645 --> 00:12:37.285 お客様と連携しています。もし、そうですね、
304 00:12:37.405 --> 00:12:38.645 最先端のユースケース
305 00:12:38.785 --> 00:12:42.045 あるいは何か、ええと、お客様がやりたいことがあって、
306 00:12:42.045 --> 00:12:43.885 それが現在 auto Index で可能なことの
307 00:12:43.885 --> 00:12:45.805 範囲外にある場合でも、
308 00:12:46.025 --> 00:12:48.085 私たちはそれも調整できますし、
309 00:12:48.085 --> 00:12:49.805 皆さんと協力して、
310 00:12:49.805 --> 00:12:52.005 Zilliz が適切に動作していること、ええと、そして、
311 00:12:52.005 --> 00:12:53.805 適切な技術的トレードオフを行っていることを確認します。
312 00:12:53.805 --> 00:12:56.165 ええと、そしてそれは、ある程度この、
313 00:12:56.475 --> 00:12:59.765 このマネージドサービス、ええと、ソリューションを維持しながら、ですよね？
314 00:12:59.865 --> 00:13:02.885 ですので、ええと、それが、その、それがだいたい、
315 00:13:02.985 --> 00:13:04.725 そのレベルパラメータについてのすべてです。
316 00:13:04.725 --> 00:13:07.365 少しスケールの話に移りたいと思います。
317 00:13:07.645 --> 00:13:09.525 スケールについて話すことも重要だと思うからです。
318 00:13:09.985 --> 00:13:13.805 ええと、私たち Zilliz では、ええと、
319 00:13:13.865 --> 00:13:15.845 最初からスケールを考えていますよね？
320 00:13:15.845 --> 00:13:18.925 つまりデータベース全体が、何十億もの、
321 00:13:18.925 --> 00:13:20.725 非常に多くのベクトルを想定して設計されているんです。
322 00:13:20.725 --> 00:13:23.205 そして実際に、そうですね、200億、
323 00:13:23.205 --> 00:13:26.445 300億、400億ベクトルを超えるワークロードを運用しているお客様もいます。
324 00:13:26.505 --> 00:13:28.165 ええと、そして非常にうまく動作しています。
325 00:13:28.625 --> 00:13:31.085 そしてこここそが、Zilliz が本当に際立つところです。
326 00:13:31.465 --> 00:13:34.605 ええと、たとえば、ベクトル空間が、
327 00:13:34.865 --> 00:13:37.645 そうですね、2000万ベクトル未満、
328 00:13:37.645 --> 00:13:39.165 あるいは1000万ベクトル未満かもしれませんよね？
329 00:13:39.225 --> 00:13:40.325 おそらく今ある他の
330 00:13:40.485 --> 00:13:41.525 ほとんど何を使ってもよいでしょう。
331 00:13:41.605 --> 00:13:44.525 最近登場した、本当に優れた、ええと、そうですね、
332 00:13:44.525 --> 00:13:46.485 ベクトルソリューションはたくさんあると思います。
333 00:13:46.565 --> 00:13:49.285 既存のレガシープレイヤーによる多くの追加機能もあり、
334 00:13:49.505 --> 00:13:51.725 そうですね、自社のお客様に、
335 00:13:51.725 --> 00:13:53.645 この機能を使えるようにしてほしい一方で、そうですね、
336 00:13:53.665 --> 00:13:54.845 現在すでに使っているものから
337 00:13:54.845 --> 00:13:56.005 移行しなくてもよいようにしたいわけです。
338 00:13:56.005 --> 00:13:58.085 それは SQL データベースかもしれませんし、非 SQL データベースかもしれません。ええと、
339 00:13:58.085 --> 00:14:00.445 データウェアハウスかもしれませんし、そうですね、その他いくつかの
340 00:14:00.465 --> 00:14:01.685 ソリューションかもしれませんよね？
341 00:14:02.225 --> 00:14:07.135 ええと、そしてそれは、それは、それは、一般的には大丈夫です。そうですね、
342 00:14:07.135 --> 00:14:09.495 もし、もしあなたが、そうですね、数百万程度の
343 00:14:09.555 --> 00:14:11.295 ベクトルを見ているなら、それで問題ありませんよね？
344 00:14:11.525 --> 00:14:14.335 数億に達し始めると、そうですね、
345 00:14:14.395 --> 00:14:17.215 そして、10億ベクトルを大きく超えると、ええと、
346 00:14:17.215 --> 00:14:19.055 アーキテクチャがはるかに重要になり始めますよね？
347 00:14:19.875 --> 00:14:22.215 そしてそれらのデータベースは、
348 00:14:22.515 --> 00:14:24.095 異なるユースケース向けに設計されていましたよね？
349 00:14:24.095 --> 00:14:26.375 それらは、NoSQL のユースケース向けに設計されていたか、
350 00:14:26.375 --> 00:14:28.055 あるいは SQL のユースケース向けに設計されていたのです。
351 00:14:28.055 --> 00:14:31.615 それらは、あなたが望む場所にデータを保存するようには設計されていません
352 00:14:31.615 --> 00:14:32.775 ベクトルを保存したい場所、
353 00:14:32.775 --> 00:14:35.535 つまりベクトル空間で最も近いベクトル同士をディスク上で一緒にすることで、
354 00:14:35.535 --> 00:14:37.815 それを正しく読み込むときに、必要なベクトルをすべて
355 00:14:37.815 --> 00:14:40.495 一度にまとめて取得できるようにする、ということです
356 00:14:40.495 --> 00:14:42.775 あちこちからシャードを読み込む代わりに、
357 00:14:42.775 --> 00:14:45.375 なぜならそれが、あなたの、あなたの、あなたのデータベースの設計だからです。
358 00:14:45.375 --> 00:14:47.575 ですから、そのように考慮すべき細かいことがたくさんあります。
359 00:14:47.755 --> 00:14:49.895 ええと、ベクトルデータベースを選ぶときには、繰り返しになりますが、
360 00:14:50.235 --> 00:14:52.685 スケールについて話しているとしても、それが、
361 00:14:52.685 --> 00:14:54.805 数億に達しないのであれば、
362 00:14:54.805 --> 00:14:55.645 おそらく問題ないでしょう、つまり、
363 00:14:55.645 --> 00:14:56.725 他の多くのものでも大丈夫です。
364 00:14:56.785 --> 00:14:59.165 しかし、本番環境でベクトルワークロードを動かすことに
365 00:14:59.165 --> 00:15:01.885 本気で取り組んでいて、大量のデータがある場合、ええと、
366 00:15:01.885 --> 00:15:04.205 検索対象にする必要があり、それはマルチテナントかもしれませんし、
367 00:15:04.205 --> 00:15:05.925 マルチテナントではないかもしれません、ええと、つまり、
368 00:15:06.125 --> 00:15:07.925 Zilliz はこの点で本当に力を発揮します。
369 00:15:08.105 --> 00:15:11.565 それで、ええと、少し説明していきます
370 00:15:11.665 --> 00:15:13.965 これをどのように抽象化しているかについて、つまり、
371 00:15:13.965 --> 00:15:15.325 Zilliz cloud のお客様向けにです。
372 00:15:15.665 --> 00:15:18.285 ええと、基本的に私たちには、ええと、いくつかの
373 00:15:18.285 --> 00:15:19.765 CU タイプと呼んでいるものがありますよね？
374 00:15:19.765 --> 00:15:20.965 つまり、それらはコンピュートユニットです。
375 00:15:21.105 --> 00:15:24.445 これらは EC2 のインスタンス、AWS のインスタンスのように考えることができます
376 00:15:24.445 --> 00:15:27.685 非常に、つまり、それは、ええと、似たたとえです、ええと、
377 00:15:27.825 --> 00:15:31.565 つまり、各 cu がある程度の
378 00:15:31.565 --> 00:15:32.845 ベクトル容量を構成する、ということですね？
379 00:15:32.845 --> 00:15:34.125 ですから、たとえば、ええと、
380 00:15:34.125 --> 00:15:37.685 500万ベクトルがある場合、それはある量の cu に収まりますよね？
381 00:15:37.685 --> 00:15:40.925 そして私たちには、最適化されたさまざまなタイプの cu があります
382 00:15:41.105 --> 00:15:42.205 異なるユースケース向けに。
383 00:15:42.665 --> 00:15:45.605 ええと、主な2つはパフォーマンスとキャパシティです。
384 00:15:46.185 --> 00:15:48.725 ですから、最大のパフォーマンスが必要で、
385 00:15:48.725 --> 00:15:51.285 レイテンシがあなたにとって最も重要なものであるなら、
386 00:15:51.745 --> 00:15:54.645 利用できるパフォーマンス最適化 cu があります。
387 00:15:55.185 --> 00:15:58.725 ええと、もし、もし、ええと、あなたが、あなたが、あなたがより関心があるのが
388 00:15:59.365 --> 00:16:00.925 cu あたりの容量で、しかし
389 00:16:00.925 --> 00:16:02.445 レイテンシを少し犠牲にすることや
390 00:16:02.445 --> 00:16:06.525 同時実行性を少し犠牲にすることをいとわないなら、キャパシティ ICU もあります
391 00:16:06.525 --> 00:16:08.645 そして最初に、ええと、選ぶことができます。
392 00:16:08.945 --> 00:16:11.645 ええと、そしてそれは実際にはあなたのワークロード
393 00:16:11.945 --> 00:16:13.565 そしてアプリケーションの種類
394 00:16:13.565 --> 00:16:15.445 そしてもちろん、それがパイプラインのどこに位置するかに基づきます。
395 00:16:15.745 --> 00:16:17.445 ええと、そして、私たちの、私たちのチーム、私たちの、
396 00:16:17.445 --> 00:16:19.885 私たちのソリューションアーキテクトチームはもちろん対応可能です、ええと、
397 00:16:19.885 --> 00:16:21.445 この2つの製品の違いを
398 00:16:21.445 --> 00:16:22.525 一緒に確認するような形で、
399 00:16:22.785 --> 00:16:23.845 そして確実に、つまり、
400 00:16:23.845 --> 00:16:25.405 あなたに適したソリューションを選べるようにします。
401 00:16:25.865 --> 00:16:29.085 なので、ええと、主な、そ、その、その、主要な方法、
402 00:16:29.085 --> 00:16:31.325 ほとんどの人がスケーリングを行う方法は手動スケーリングです。
403 00:16:31.585 --> 00:16:34.245 ええと、つまり、単に選択できて、ええと、そして、
404 00:16:34.245 --> 00:16:36.005 そして、ちょっと、そこを見ていきます。
405 00:16:36.115 --> 00:16:37.405 実際の
406 00:16:37.545 --> 00:16:38.805 ui をお見せします。というのも、見ると役に立つからです。
407 00:16:38.825 --> 00:16:41.205 これが Zilliz cluster が
408 00:16:41.425 --> 00:16:43.725 Zilliz cloud の中でどのように見えるかです。
409 00:16:44.105 --> 00:16:47.165 ええと、ここにはいくつかのものがありますが、ええと、その、
410 00:16:47.165 --> 00:16:49.085 皆さんに注目してほしい主なものは
411 00:16:49.145 --> 00:16:51.285 CU size で、ここにあります。
412 00:16:51.585 --> 00:16:53.965 2 cu があり、現在の capacity は 2% です。
413 00:16:54.005 --> 00:16:55.085 この cluster にはあまり多く入っていません。
414 00:16:55.665 --> 00:16:58.365 そして、ほとんどの人が、ええと、
415 00:16:58.365 --> 00:17:00.285 スケーリングを行う方法は、単に scale ボタンをクリックして、
416 00:17:00.465 --> 00:17:03.365 追加できる cu を確認するというものです。
417 00:17:03.365 --> 00:17:05.085 そして当然、このリストは非常に、非常に大きいです。
418 00:17:05.465 --> 00:17:07.605 ええと、さらに高くすることもできます。
419 00:17:07.745 --> 00:17:10.565 ええと、私たちの支援が必要であれば、もちろんお手伝いできます。
420 00:17:10.585 --> 00:17:12.445 ただ、256 はかなり多く、
421 00:17:12.875 --> 00:17:14.645 何十億、何十億という規模になります。
422 00:17:14.945 --> 00:17:17.485 そして、ええと、もちろん私たちには、
423 00:17:17.515 --> 00:17:18.525 それを超えるお客様もいます。
424 00:17:18.705 --> 00:17:20.565 ええと、もちろん私たちは皆さんと非常に密に連携しますが、
425 00:17:20.945 --> 00:17:22.525 これがほとんどの人のやり方です。
426 00:17:22.625 --> 00:17:26.485 ええと、そしてたいていの場合、皆さんの vector count が増えても、
427 00:17:26.505 --> 00:17:29.045 vector count が、ええと、
428 00:17:29.065 --> 00:17:32.405 つまり、毎日、異常なペースで増えているのでない限り、ええと、
429 00:17:32.405 --> 00:17:33.805 このアプローチで概ね問題ありません。
430 00:17:34.225 --> 00:17:37.325 右側に表示されているように、auto scale 機能も
431 00:17:37.325 --> 00:17:38.485 用意しています。
432 00:17:38.485 --> 00:17:39.845 このビデオをちょっとどかします。
433 00:17:40.065 --> 00:17:42.165 ええと、右側にこの autoscale 機能があり、
434 00:17:42.195 --> 00:17:44.565 threshold を設定できます。
435 00:17:45.025 --> 00:17:46.925 つまり cu capacity の threshold です。
436 00:17:46.985 --> 00:17:48.725 ですので、つまり、皆さんが
437 00:17:48.725 --> 00:17:52.045 たとえば、query latency が上昇する可能性という
438 00:17:52.045 --> 00:17:54.525 リスクをどの程度許容できるかによります。
439 00:17:54.755 --> 00:17:57.445 90% まで上げて設定する人もいます。
440 00:17:57.465 --> 00:17:58.685 私たちとしてはそれはお勧めしませんが、
441 00:17:58.705 --> 00:18:00.525 まあ、実行できることではあります。
442 00:18:00.865 --> 00:18:02.365 ええと、ただ一般的には 70
443 00:18:02.365 --> 00:18:06.725 から 80% の間が、良い、安全な、ちょうどよい妥協点で、ええと、
444 00:18:07.025 --> 00:18:10.805 もし、もし cluster の capacity がそのレベルに達したら、
445 00:18:10.895 --> 00:18:14.205 自動的に次の tier にスケールアップします。つまり、
446 00:18:14.205 --> 00:18:15.725 一度に 2 cu を追加することになります。
447 00:18:16.185 --> 00:18:18.885 そして、それも言及しておくことが重要だと
448 00:18:18.945 --> 00:18:21.525 思います。なぜなら、ええと、皆さんは、
449 00:18:21.525 --> 00:18:23.205 決して次のような状況にはならないからです。
450 00:18:23.205 --> 00:18:24.765 つまり、過剰に割り当てられることはない、ということです。
451 00:18:24.825 --> 00:18:27.925 世の中にある他の多くのソリューションでは、
452 00:18:27.925 --> 00:18:29.845 水平スケールされたノードの数を、
453 00:18:29.845 --> 00:18:31.885 選ばされることになります。
454 00:18:31.905 --> 00:18:34.085 たとえば、水平スケールされたノードが10個あるとします。
455 00:18:34.085 --> 00:18:37.005 そして、彼らは、その数を変更することを
456 00:18:37.005 --> 00:18:38.045 非常に難しくしています。
457 00:18:38.105 --> 00:18:40.005 その理由は、インデックスのあり方、
458 00:18:40.025 --> 00:18:42.045 つまりそれらのノード全体に構築される方法にあります。
459 00:18:42.265 --> 00:18:44.765 ですから、増やしたい場合は、それは問題ありませんが、
460 00:18:44.765 --> 00:18:47.405 10個すべてを垂直スケールしなければなりませんよね？
461 00:18:47.405 --> 00:18:48.645 それは一般的に望むことではありません。
462 00:18:48.645 --> 00:18:50.765 基本的には倍増させる、つまり、
463 00:18:50.765 --> 00:18:52.245 クラスター全体の容量を倍増させることになります。
464 00:18:52.245 --> 00:18:54.445 場合によってはそれで問題ないこともありますが、
465 00:18:54.445 --> 00:18:56.005 たいていの場合、それは望むことではありません。
466 00:18:56.025 --> 00:18:58.205 やりたいことは、ベクトル数が増えるにつれて、
467 00:18:58.265 --> 00:18:59.485 線形に追加していくことです。
468 00:18:59.985 --> 00:19:02.365 そしてzillsでは、それを非常にうまく行えます。
469 00:19:02.425 --> 00:19:03.525 つまり、
470 00:19:03.545 --> 00:19:07.285 一度に2 cuずつ追加していくだけです。手動で
471 00:19:07.345 --> 00:19:10.205 自分で行うこともできますし、autoscale機能を使って行うこともできます。
472 00:19:10.625 --> 00:19:14.845 また、modify cluster endpointも使用できます。
473 00:19:14.985 --> 00:19:19.765 ですから、これを何らかの自動化に組み込みたい場合、
474 00:19:19.765 --> 00:19:23.085 つまりDevOpsパイプライン内の自動化に組み込みたい場合も、
475 00:19:23.085 --> 00:19:24.125 それも提供しています。
476 00:19:24.225 --> 00:19:27.365 APIを通じてすべてのクラスター指標を読み取ることができ、
477 00:19:27.385 --> 00:19:31.485 cu容量が過去にどこにあったか、そして
478 00:19:31.485 --> 00:19:33.405 システム内で起きている他の事象に基づいて、
479 00:19:33.405 --> 00:19:34.645 どこへ向かう可能性があるかを確認できます。
480 00:19:35.105 --> 00:19:36.405 また、そのendpointを使って、
481 00:19:36.405 --> 00:19:38.645 スケールアップやスケールダウンもできます。
482 00:19:38.645 --> 00:19:41.605 ですから、スケーリングに関しては、
483 00:19:41.605 --> 00:19:42.645 手動、自動の両方、
484 00:19:42.905 --> 00:19:44.325 そしてDevOpsパイプラインへの
485 00:19:44.325 --> 00:19:45.805 組み込みについて、多くの選択肢を提供しています。
486 00:19:46.385 --> 00:19:48.925 そしてまた、非常に重要なのは、
487 00:19:48.945 --> 00:19:50.245 スケーリング自体が、
488 00:19:50.505 --> 00:19:52.525 きれいな線形の形で行われるという点です。
489 00:19:52.745 --> 00:19:54.525 時間は大丈夫か確認しているだけです、はい。
490 00:19:54.745 --> 00:19:58.045 そして、それはユースケースに対して非常に柔軟なものとなり、
491 00:19:58.045 --> 00:20:00.125 多くのお客様が活用していて、
492 00:20:00.205 --> 00:20:01.485 本当に高く評価しているものです。
493 00:20:01.485 --> 00:20:02.645 そういうわけです。
494 00:20:02.745 --> 00:20:04.765 以上が、スケーリングについての簡単な説明です。
495 00:20:05.105 --> 00:20:09.325 次に、セキュリティについても少し触れたいと思います。
496 00:20:09.625 --> 00:20:13.725 当社には、当社のセキュリティ体制や、
497 00:20:13.955 --> 00:20:18.045 当社が何をしているのか、そしてそれが彼らの
498 00:20:18.105 --> 00:20:21.125 ポリシーネットワークにどのように適合するのかについて非常に、
499 00:20:21.825 --> 00:20:24.285 非常に関心を持つエンタープライズのお客様が多くいます。
500 00:20:24.285 --> 00:20:24.285 そして、本当に主要な点は、特に
500 00:20:24.505 --> 00:20:26.645 どのマネージドサービスにとっても重要なのは、
501 00:20:26.675 --> 00:20:30.605 そのマネージドサービスが同じ
502 00:20:30.605 --> 00:20:33.325 リージョンだけでなく、できれば他の
503 00:20:33.325 --> 00:20:35.045 マイクロサービスと同じアベイラビリティゾーンにデプロイされていることです。
504 00:20:35.155 --> 00:20:37.645 それらのマイクロサービスは定期的に
505 00:20:37.745 --> 00:20:39.325 それを呼び出すことになります。
506 00:20:39.505 --> 00:20:41.485 クエリだけでなく、メトリクスや
507 00:20:41.505 --> 00:20:41.485 スケーリングなどの用途でもです。
507 00:20:41.905 --> 00:20:45.605 ええ、ですので私たちは AWS の private link をサポートしており、
508 00:20:45.785 --> 00:20:48.525 GCP 上のそれに相当するものすべて、
509 00:20:48.865 --> 00:20:50.085 そして Azure でもサポートしています。
510 00:20:50.105 --> 00:20:51.765 つまりプライベートエンドポイントを作成でき、
511 00:20:52.145 --> 00:20:54.765 そうすることで、マイクロサービスから
512 00:20:55.145 --> 00:20:57.285 Zilliz のインストール環境へのすべてのトラフィックは、
513 00:20:57.355 --> 00:20:58.765 オープンなインターネットを経由しません。
514 00:20:58.765 --> 00:21:00.805 そのため、イングレスやエグレスの問題は発生しません。
515 00:21:01.225 --> 00:21:04.685 しかしより重要なのは、そのトラフィックが
516 00:21:04.685 --> 00:21:07.245 あなたの VPC 内に留まる、または
517 00:21:07.265 --> 00:21:08.805 AWS ネットワーク内に留まるということです。
518 00:21:08.805 --> 00:21:11.525 つまり、潜在的に何かを
519 00:21:11.525 --> 00:21:12.765 外部世界にさらすことがないのです。
520 00:21:13.265 --> 00:21:16.405 それから、私たちが提供している
521 00:21:16.405 --> 00:21:19.045 もう一つのものが、顧客管理の暗号化キーです。
522 00:21:19.385 --> 00:21:22.165 これも非常に多く要望されてきた機能で、
523 00:21:22.255 --> 00:21:25.405 お客様の KMS に接続できます。
524 00:21:25.405 --> 00:21:27.605 つまり A-W-S-K-M-S で、それに接続し、
525 00:21:27.665 --> 00:21:30.285 その KMS から私たちにキーを発行していただくと、
526 00:21:30.545 --> 00:21:32.765 私たちは基本的にすべてを暗号化します。
527 00:21:32.765 --> 00:21:36.565 つまり、ベクトル埋め込みを暗号化し、
528 00:21:36.625 --> 00:21:39.565 それに関連するすべてのメタデータも暗号化します。
529 00:21:39.985 --> 00:21:43.645 そしてクエリ時には、その場で復号し、
530 00:21:44.105 --> 00:21:46.845 a と n を実行してから、すべてを再暗号化します。
531 00:21:46.845 --> 00:21:47.965 そのため、保管時にはきちんと
532 00:21:47.965 --> 00:21:51.885 私たちの VPC 内で暗号化された状態が維持されます。
533 00:21:51.885 --> 00:21:54.245 そして当然ながら、お客様の KMS を通じて、
534 00:21:54.245 --> 00:21:55.765 それらのキーはいつでも無効化できます。
535 00:21:56.105 --> 00:21:58.845 そうすると Zilliz はお客様のデータに一切アクセスできなくなります。
536 00:21:58.845 --> 00:22:01.005 これも企業から非常に多く要望されている機能です。
537 00:22:01.025 --> 00:22:02.325 同様にです。
538 00:22:02.625 --> 00:22:04.885 そしてこれは私たちが本当に力を入れて取り組んだもので、
539 00:22:04.885 --> 00:22:07.085 非常に厳しい要件を持つ方々が
540 00:22:07.105 --> 00:22:10.245 確実に安心できるようにするためです。
541 00:22:10.265 --> 00:22:11.845 PII などに関してですね。
542 00:22:12.005 --> 00:22:13.805 というのも、このデータの多くは、繰り返しになりますが、
543 00:22:13.805 --> 00:22:14.725 最初に申し上げたように、
544 00:22:15.405 --> 00:22:16.485 組織内部のものだからです。
545 00:22:16.545 --> 00:22:19.605 ですから、それらの組織の CISO が
546 00:22:19.765 --> 00:22:22.325 そのすべてのデータが
547 00:22:22.705 --> 00:22:24.725 しっかりと自分たちの管理下にあり、
548 00:22:24.985 --> 00:22:28.605 必要であればいつでも無効化できると感じられることが非常に重要なのです。
549 00:22:28.705 --> 00:22:29.925 ええと、もし、もし問題があれば。
550 00:22:30.025 --> 00:22:31.085 では、ここで止めます。
551 00:22:31.125 --> 00:22:33.805 最後に約4分残っているのはわかっています、ええと、
552 00:22:33.825 --> 00:22:36.325 質問のために、ですが、ええ、ええと、喜んで
553 00:22:36.325 --> 00:22:37.325 今どんな質問にもお答えします、
554 00:22:37.325 --> 00:22:38.605 またはChris、お返しします。
555 00:22:38.905 --> 00:22:41.245 あなたは、ええと、スケールアップについて話していましたよね。
556 00:22:41.245 --> 00:22:43.765 前のトピックについて、スケールダウンはどうですか？
557 00:22:44.075 --> 00:22:48.205 はい、スケールダウンは、ええと、同じ方法で行われます。
558 00:22:48.345 --> 00:22:50.405 ええと、ここにあるこのscaleボタンに移動できます。
559 00:22:50.405 --> 00:22:51.725 1 cuにスケールダウンできます。
560 00:22:51.845 --> 00:22:52.885 ご希望なら今すぐそうできます。
561 00:22:53.265 --> 00:22:56.725 ええと、それからクラスターは1にスケールダウンします。
562 00:22:57.065 --> 00:22:58.485 ええと、また重要なのは、
563 00:22:58.485 --> 00:23:01.005 auto scaleはスケールダウンしないということです、そうですよね？
564 00:23:01.185 --> 00:23:04.085 それが、その、そしてその理由は、
565 00:23:04.085 --> 00:23:08.685 スケールダウンは本質的にスケールアップよりも
566 00:23:08.685 --> 00:23:10.125 危険な操作だからです。
567 00:23:10.465 --> 00:23:12.965 ええと、そして、ええと、
568 00:23:12.965 --> 00:23:14.125 クエリレイテンシが増加する可能性があります。
569 00:23:14.125 --> 00:23:17.245 本番アプリケーションが、
570 00:23:17.425 --> 00:23:19.725 ええと、そのパイプラインの不可欠な一部である場合、
571 00:23:20.005 --> 00:23:21.045 問題を経験する可能性があります。
572 00:23:21.785 --> 00:23:23.605 ですので、そこでその判断をしました。
573 00:23:23.745 --> 00:23:26.085 ええと、もし、もし、もしスケールダウンしたいなら、
574 00:23:26.085 --> 00:23:29.685 前に言ったようにプログラム的な方法で、
575 00:23:30.425 --> 00:23:33.085 私たちのquery cluster metricsエンドポイント
576 00:23:33.105 --> 00:23:34.725 およびmodify clusterエンドポイントを使って、
577 00:23:34.825 --> 00:23:37.085 プログラム的に行いたい場合はスケールダウンできます。
578 00:23:37.265 --> 00:23:40.245 または、UIを通じて実行できます、ええと、その、その、ええと、その、
579 00:23:40.245 --> 00:23:41.325 今お見せしたものです。
580 00:23:41.705 --> 00:23:43.885 ええと、でも、そうですね、それは、それは、本当に、ええと、
581 00:23:43.885 --> 00:23:45.640 多くの人々がよくやる一般的なことです、ただ
582 00:23:45.640 --> 00:23:48.565 何らかのインポートジョブを実行しているかもしれませんし、
583 00:23:48.825 --> 00:23:52.245 あるいは、ええと、大量のベクトルで実験していて、
584 00:23:52.245 --> 00:23:53.525 それらを一度にすべて削除し、
585 00:23:53.525 --> 00:23:55.205 その余分なキャパシティがある場合もあります。
586 00:23:55.205 --> 00:23:57.125 ただし繰り返しますが、スケールダウンはできます。
587 00:23:57.125 --> 00:23:58.205 段階的にですね。
588 00:23:58.205 --> 00:24:00.605 つまり、32から16まで一気に下げる必要はありません。
589 00:24:00.605 --> 00:24:02.765 その、段階的に進めて、
590 00:24:03.085 --> 00:24:04.125 パフォーマンスがどう見えるか確認できます。
591 00:24:04.385 --> 00:24:07.245 そして繰り返しますが、それは、それは、本当に、
592 00:24:08.005 --> 00:24:09.845 illusがどれほど柔軟で水平スケーラブルであるかの証です。
593 00:24:10.695 --> 00:24:13.235 なるほど。では、ええと、どなたか質問があれば、ええと、
594 00:24:13.235 --> 00:24:14.475 遠慮なく手を挙げてください。
595 00:24:14.475 --> 00:24:16.835 ミュートを解除しますので、質問できます。
596 00:24:16.855 --> 00:24:19.115 または、話すより入力したい場合でも大丈夫です。
597 00:24:20.015 --> 00:24:23.275 ええと、ですが、ええと、Jay、実は私からいくつか質問があります。
598 00:24:23.415 --> 00:24:26.875 それでは、ええと、データの取り込みについて少し話しましょう。
599 00:24:27.265 --> 00:24:29.875 データを効率的にデータベースへ取り込むには、
600 00:24:29.875 --> 00:24:30.955 どのような方法がありますか？
601 00:24:31.825 --> 00:24:36.195 はい。私たちは一括の、ええと、
602 00:24:36.415 --> 00:24:38.035 挿入、ええと、APIを提供しています。
603 00:24:38.615 --> 00:24:42.995 基本的な仕組みとしては、
604 00:24:43.215 --> 00:24:44.635 Zillizデータベース用のスキーマを定義し、
605 00:24:45.375 --> 00:24:48.515 Parquetファイルを送っていただくか、
606 00:24:48.815 --> 00:24:51.315 すべてのデータが入ったJSOファイルを
607 00:24:51.315 --> 00:24:52.915 送っていただくことができます。
608 00:24:53.415 --> 00:24:56.715 そして、それらを送るだけで、つまり、それらのS3へのリンクを、
609 00:24:56.715 --> 00:24:58.755 オブジェクトストレージがどこであれ、どこにあっても、
610 00:24:59.015 --> 00:25:00.315 認証されていれば大丈夫です。
611 00:25:00.615 --> 00:25:02.075 そして、インポートの並列化
612 00:25:02.075 --> 00:25:03.395 などはすべて、
613 00:25:03.495 --> 00:25:06.315 こちら側で処理しますよね？
614 00:25:06.975 --> 00:25:08.675 もう一つの方法は、
615 00:25:08.935 --> 00:25:11.755 uperエンドポイントを使うだけで、それも問題なく機能します。
616 00:25:11.755 --> 00:25:13.395 より反復的な形で行いたい場合は、
617 00:25:13.495 --> 00:25:14.595 それでも全く構いません。
618 00:25:14.595 --> 00:25:16.075 その方法でやっているお客様もたくさんいます。
619 00:25:16.575 --> 00:25:20.155 ただ、たとえば、そうですね、ええと、
620 00:25:20.635 --> 00:25:23.435 1億5000万個のベクトルを一度にすべて読み込みたいとして、
621 00:25:23.695 --> 00:25:25.635 それらがどこかにあるとしますよね？
622 00:25:25.635 --> 00:25:28.155 別のデータベースにあるのか、Snowflakeにあるのか、
623 00:25:28.295 --> 00:25:31.195 あるいはどこであれ、ええと、Parquet
624 00:25:31.195 --> 00:25:33.715 とJSONはかなり業界標準のファイル形式です。
625 00:25:33.815 --> 00:25:37.595 そして、ほとんどのETLパイプラインは、それらに、
626 00:25:38.135 --> 00:25:39.515 それらの形式に書き出すことができます。
627 00:25:39.515 --> 00:25:40.675 そして、私たちはその両方の形式を
628 00:25:40.675 --> 00:25:42.315 一括形式で受け付けています。
629 00:25:42.375 --> 00:25:45.675 そのため、ある種、ええと、あの、インポートを、ええと、
630 00:25:45.675 --> 00:25:47.715 非常に素早く行えるようになります。もし、ええと、
631 00:25:47.715 --> 00:25:49.355 別のベクトルデータベースソリューションから移行してくる場合です。
632 00:25:49.415 --> 00:25:51.275 ええと、私たちはそれらのベクトルデータベースソリューション専用の
633 00:25:51.275 --> 00:25:52.555 インポートパイプラインを用意しています。
634 00:25:52.735 --> 00:25:54.315 ええと、quadrantから移行してくる場合や、
635 00:25:54.315 --> 00:25:57.235 piから、Pine Coneから移行してくる場合、ええと、私たちは、
636 00:25:57.415 --> 00:25:59.155 ええと、その両方をネイティブにサポートしています。
637 00:25:59.155 --> 00:26:00.755 それらのホステッドソリューションそれぞれのAPIキーを
638 00:26:00.755 --> 00:26:02.275 渡していただくだけで、ええと、
639 00:26:02.275 --> 00:26:03.395 そのデータベースから直接データを
640 00:26:03.395 --> 00:26:04.715 吸い上げることができます。
641 00:26:05.055 --> 00:26:08.955 ええと、そこにはいくつかトレードオフがあります。すみません。
642 00:26:09.285 --> 00:26:10.395 そこにはいくつかトレードオフがあります。
643 00:26:10.455 --> 00:26:12.715 ええと、特にスキーマのような部分ですね。
644 00:26:13.015 --> 00:26:14.515 つまり、ある意味、
645 00:26:14.515 --> 00:26:15.675 すでに持っていたスキーマに縛られることになります。
646 00:26:15.975 --> 00:26:17.075 ええと、
647 00:26:17.075 --> 00:26:19.195 以前のソリューションから移行してくる場合です。
648 00:26:19.815 --> 00:26:21.115 スキーマを変更したい場合や、
649 00:26:21.115 --> 00:26:22.355 埋め込みモデルを変更したい場合、
650 00:26:22.415 --> 00:26:24.315 変更したいことがある場合は、ええと、
651 00:26:24.535 --> 00:26:27.115 それらのparquetを作成する必要があります
652 00:26:27.115 --> 00:26:28.355 先ほど述べたJSONファイルを使って、
653 00:26:28.615 --> 00:26:29.675 ええ、その方向で進めることもできます。
654 00:26:29.675 --> 00:26:30.715 そしてそれは、一般的に
655 00:26:30.715 --> 00:26:33.235 スキーマを変更したい場合に多くの人が行うことです。
656 00:26:33.615 --> 00:26:36.395 でも、その判断をする際に、あなたが支援してくれるんですよね、Jay、
657 00:26:36.395 --> 00:26:38.035 彼らがその判断をできるように手助けするということです。
658 00:26:38.545 --> 00:26:40.395 はい、もちろんです。つまり、別のものから移行してくる
659 00:26:40.395 --> 00:26:42.915 お客様と一緒に作業するときは、ええ、私たちは、
660 00:26:43.025 --> 00:26:45.485 現在どのようにセットアップされているかについて多くの質問をしますし、
661 00:26:45.485 --> 00:26:48.285 ご存じのように、私たちには非常に頼りになるチームがあり、
662 00:26:48.285 --> 00:26:50.405 ソリューションを提案できるだけでなく、
663 00:26:50.405 --> 00:26:52.725 皆さんがどこから移行してくる場合でも、
664 00:26:52.825 --> 00:26:54.165 インポートプロセスができるだけ
665 00:26:54.165 --> 00:26:55.525 スムーズになるよう支援することもできます。
666 00:26:55.955 --> 00:26:58.245 そうですね。それから、バルクインポートや
667 00:26:58.245 --> 00:26:59.845 バルクライター機能も忘れないでください。
668 00:27:00.085 --> 00:27:01.365 理由はわかりませんが、それを見落としていた
669 00:27:01.445 --> 00:27:02.765 お客様が何人もいました。
670 00:27:03.115 --> 00:27:05.885 彼らは一つずつ行うことに不満を感じていて、
671 00:27:05.885 --> 00:27:09.165 そこでJayが、「実はこういう別の機能があります」と言ったんです。
672 00:27:09.225 --> 00:27:11.845 そうです。かなり時間を節約できます。
673 00:27:12.035 --> 00:27:13.165 あります。間違いなくあります。
674 00:27:14.385 --> 00:27:17.685 では次に、ええと、
675 00:27:18.165 --> 00:27:19.965 複数の埋め込みについて少し話しましょう。
676 00:27:20.125 --> 00:27:22.045 特にハイブリッド検索を行おうとしている場合です。
677 00:27:22.145 --> 00:27:24.045 つまり、ええと、
678 00:27:24.115 --> 00:27:25.925 1行を見ると、持てるのは
679 00:27:25.925 --> 00:27:26.965 1つだけではないですよね？
680 00:27:26.965 --> 00:27:29.805 ベクトル埋め込みです。それは何で、なぜ重要なのでしょうか？
681 00:27:29.955 --> 00:27:31.645 はい、それは本当に、ええと、
682 00:27:32.125 --> 00:27:33.685 私たちにかなり特有のものだと思います。
683 00:27:33.745 --> 00:27:37.725 私たちはエントリごとに4つのベクトル埋め込みをサポートしています。
684 00:27:38.545 --> 00:27:42.325 つまり、2つのdenseと1つのsparseを持つことができます。
685 00:27:42.325 --> 00:27:43.805 4つのdenseと1つのsparseを持つこともできますし、
686 00:27:43.825 --> 00:27:45.125 3つのdenseと1つのsparseを持つこともできます。
687 00:27:45.585 --> 00:27:50.485 そしてクエリは、それぞれのベクトル埋め込みごとに
688 00:27:50.485 --> 00:27:51.765 分割して実行できます。
689 00:27:51.765 --> 00:27:53.085 つまり、それぞれに1つのインデックスがあるようなものです。
690 00:27:53.085 --> 00:27:55.285 たとえば、最初のdenseベクトルのセットに対して
691 00:27:55.285 --> 00:27:58.845 ANNだけを実行したい場合、
692 00:27:58.845 --> 00:27:59.965 それから2番目のdenseベクトルのセットに対して
693 00:27:59.965 --> 00:28:02.085 別のANNを実行できます。
694 00:28:02.505 --> 00:28:04.685 これは、異なる埋め込みモデルを
695 00:28:05.315 --> 00:28:06.605 テストしているときに非常に役立ちます。
696 00:28:06.865 --> 00:28:08.325 今はファインチューニングされた埋め込みモデルが
697 00:28:08.325 --> 00:28:10.205 たくさんありますし、あるいは自分でチューニングしている場合もあります。
698 00:28:10.505 --> 00:28:12.245 そして、ええと、それぞれの埋め込みについて、
699 00:28:12.915 --> 00:28:16.725 そのベクトル空間がどのように見えるのかを
700 00:28:16.745 --> 00:28:17.885 確認したいわけです。
701 00:28:17.965 --> 00:28:19.565 というのも、ご存じのように、同じテキストの一部を取り出して、
702 00:28:19.565 --> 00:28:21.165 異なる埋め込みモデルに通すことができるからです。
703 00:28:21.165 --> 00:28:22.925 そして完全に、その場所は完全に
704 00:28:22.925 --> 00:28:25.445 異なる可能性があります、ええと、チューニングがどうなっているかに基づいて。
705 00:28:25.545 --> 00:28:29.085 ですから、私たちはそれを、見たいと思っている顧客でよく見ます、
706 00:28:29.145 --> 00:28:31.445 このファインチューニングされたモデルを使う価値はあるのか？
707 00:28:31.465 --> 00:28:32.925 それによってどれくらいの利点が得られるのか？
708 00:28:33.425 --> 00:28:36.085 そして、それぞれにクエリを送ればいいんです、ほら、
709 00:28:36.105 --> 00:28:38.405 一日中ずっと、ええと、それで、どう見えるかを確認できます。
710 00:28:38.465 --> 00:28:40.285 ですから、それは非常に人気のあるユースケースです。
711 00:28:40.625 --> 00:28:42.685 ええと、私たちが見ているもう一つの人気のユースケースは
712 00:28:42.685 --> 00:28:43.845 疎ベクトルに関するものです。
713 00:28:44.265 --> 00:28:48.965 そして疎ベクトルは主に、ええと、ブレンドするために使われます、ええと、
714 00:28:49.225 --> 00:28:51.445 語彙検索とセマンティック検索を、ですよね？
715 00:28:52.315 --> 00:28:54.415 それで、ええと、最も人気があるものは、
716 00:28:54.495 --> 00:28:56.295 おそらくBM25で、これは何十年も前からあります。
717 00:28:56.795 --> 00:28:59.455 ええと、でも新しいものも出てきていて、いわゆる、
718 00:28:59.455 --> 00:29:01.575 Splayというものがあって、それも非常に興味深いです。
719 00:29:01.915 --> 00:29:05.055 ええと、そしてそれによって、私たちは、それらを横に並べて置けるようにしています、ええと、
720 00:29:05.075 --> 00:29:06.135 並べて、ええと、
721 00:29:06.155 --> 00:29:09.655 そして両方に対して、ハイブリッド検索を実行できます。
722 00:29:09.835 --> 00:29:13.215 ですから、ほら、これは非常に役立ちます、例えば、
723 00:29:13.835 --> 00:29:18.055 ええと、eコマースのユースケースで、たとえば、
724 00:29:18.495 --> 00:29:22.135 SKUやUPCコードがあり、それが非常にユニークで、
725 00:29:22.135 --> 00:29:24.015 そして、あなたが100パーセント確信しているような場合です、
726 00:29:24.015 --> 00:29:25.895 そのチャンクにはそのUPCコードが含まれていると。
727 00:29:26.275 --> 00:29:29.975 ですから、それに疎ベクトルを使うと、
728 00:29:30.265 --> 00:29:32.215 密と
729 00:29:32.435 --> 00:29:35.335 疎を一緒に組み合わせるので、セマンティックと
730 00:29:35.595 --> 00:29:36.855 語彙を一緒に組み合わせることになり、
731 00:29:37.115 --> 00:29:39.575 そして、それらの中でその正確なUPCコードを持つものに
732 00:29:39.575 --> 00:29:41.205 より大きな重みを付けます。
733 00:29:41.205 --> 00:29:43.845 つまり、それは基本的に、確率を高め、
734 00:29:43.845 --> 00:29:45.245 それらの結果を上位に押し上げます、
735 00:29:45.315 --> 00:29:47.405 一方で、セマンティックだけで行った場合、
736 00:29:47.905 --> 00:29:48.925 そこにあるかもしれないし、ないかもしれません。
737 00:29:48.925 --> 00:29:51.125 場合によっては、ほら、top Kを引き上げて、
738 00:29:51.125 --> 00:29:52.245 探しているものを正確に得る必要があるかもしれません。
739 00:29:52.505 --> 00:29:55.085 しかし、それによってクエリを微調整できます、
740 00:29:55.085 --> 00:29:58.765 そうしたユースケースに対して、ええと、セマンティックは素晴らしく、
741 00:29:58.945 --> 00:30:00.005 私たちはそれを使いたい、
742 00:30:00.185 --> 00:30:03.325 しかし、それは、ほら、私たちはかなり確信しているんです、
743 00:30:03.325 --> 00:30:04.325 これがその中に含まれていると、
744 00:30:04.345 --> 00:30:05.965 そして語彙マッチも行ってほしい
745 00:30:05.965 --> 00:30:07.165 という場合ですので、それもサポートしています。
746 00:30:07.955 --> 00:30:10.375 つまり、以前は、これを行うためのちょっとした
747 00:30:10.375 --> 00:30:11.975 ハック的な方法があったと思いますよね？
748 00:30:11.995 --> 00:30:13.735 こうした異なる埋め込みを持つことができて、
749 00:30:13.735 --> 00:30:15.695 ほら、異なるコレクションも、ですから、うん。
750 00:30:16.285 --> 00:30:20.015 何を、ほら、私たちはそれをより有用にするために何をしたのでしょうか、
751 00:30:20.015 --> 00:30:22.255 つまり、ハイブリッド検索を行う以外に、それを、
752 00:30:22.315 --> 00:30:23.815 ほら、一つのエンティティの下に置くことで。
753 00:30:25.035 --> 00:30:27.615 ええと、つまりそれは、私たちのインデックス戦略の
754 00:30:27.615 --> 00:30:29.535 仕組みの一部なんです。
755 00:30:29.565 --> 00:30:31.535 つまり私たちは、それぞれの、ええと、
756 00:30:31.635 --> 00:30:34.495 ベクトルエントリを個別に見ています。ええと、
757 00:30:34.515 --> 00:30:37.455 コレクション全体に対して単一のインデックスを持つのではなく、
758 00:30:37.455 --> 00:30:39.535 一般的には、ええと、多くの
759 00:30:39.535 --> 00:30:41.095 他のベクトルデータベースはそうしています。
760 00:30:41.155 --> 00:30:45.655 ですから私たちはデータベースが先で、インデックスが後です。多くの
761 00:30:45.655 --> 00:30:47.615 世の中のベクトルデータベースはインデックス
762 00:30:47.615 --> 00:30:48.775 が先で、データベースが後だと思います。
763 00:30:48.835 --> 00:30:50.215 ですから、それは、非常に、ええと、
764 00:30:50.215 --> 00:30:51.815 重要な違いだと思います。
765 00:30:52.195 --> 00:30:53.455 ええと、そしてそれは私たちの歴史に由来しています。
766 00:30:53.475 --> 00:30:56.095 ご存じのように、私たちの創業者は、Oracleに
767 00:30:56.155 --> 00:30:58.015 長い間いましたし、ええと、ご存じのように、
768 00:30:58.015 --> 00:31:01.095 データベース設計について非常に深い知識を持っています。ええと、
769 00:31:01.115 --> 00:31:02.535 そして、そして、そして、何が優れた
770 00:31:02.535 --> 00:31:03.655 データベース設計を構成するのか、ですよね？
771 00:31:03.655 --> 00:31:05.455 ですから、それは私たちにとって本当に良い基盤です。
772 00:31:05.755 --> 00:31:07.135 そしてその上に、ご存じのように、
773 00:31:07.255 --> 00:31:09.575 世界クラスのベクトル機能を追加しました。
774 00:31:09.745 --> 00:31:11.495 これにより、両方の良いところを得られるわけです。
775 00:31:11.495 --> 00:31:13.415 つまり、ご存じのように、実際のデータベースであることの
776 00:31:13.415 --> 00:31:15.055 多くの柔軟性が得られるわけです。
777 00:31:15.355 --> 00:31:18.815 ええと、しかし同時に、この、ご存じのように、優れた、ええと、
778 00:31:19.165 --> 00:31:21.175 非常にインテリジェントで、常に変化し続ける、
779 00:31:21.435 --> 00:31:25.055 しかし同時に、ええと、ご存じのように、皆さんにとって使いやすいものでもありますよね？
780 00:31:25.115 --> 00:31:26.175 そして、そして、私たちが作成した多くの
781 00:31:26.175 --> 00:31:27.415 抽象化を通じてです。
782 00:31:27.835 --> 00:31:31.055 ええと、そして、内部にある多くのパワーを
783 00:31:31.055 --> 00:31:32.815 活用できるようになります。ご存じのように、
784 00:31:32.815 --> 00:31:34.895 とても理解しやすいインターフェースを備えながらです。
785 00:31:35.675 --> 00:31:36.885 いいですね。では忘れないでください。
786 00:31:36.885 --> 00:31:38.765 もう少しの間、回線は開けておきます。
787 00:31:38.985 --> 00:31:41.965 質問があれば、q and aかチャットに入れるか、
788 00:31:41.965 --> 00:31:43.605 手を挙げてください。そうすればミュートを解除します。
789 00:31:44.145 --> 00:31:46.285 ええと、でもJay、あなたにもう一つ質問があります。
790 00:31:46.285 --> 00:31:47.925 まあ、いつも一つだけでは済まないんですが、
791 00:31:48.305 --> 00:31:51.325 もしよければ、少し話せればと思います。
792 00:31:51.515 --> 00:31:54.565 マルチテナンシーと、そのさまざまな方法について
793 00:31:54.675 --> 00:31:56.205 マルチテナンシーを実現する方法を。
794 00:31:56.435 --> 00:31:59.165 もちろんです。それから、それぞれの長所と短所は何でしょうか？
795 00:31:59.985 --> 00:32:04.925 では、ええと、Zillizでは、私たちは一般的に
796 00:32:05.155 --> 00:32:09.725 マルチテナンシーには論理的な分離を使うことを推奨しています。
797 00:32:09.825 --> 00:32:12.765 つまり、すべてのベクトルを単一の、ええと、コレクションに入れ、
798 00:32:13.345 --> 00:32:16.285 partition keyと呼ばれるものを使用して、
799 00:32:16.665 --> 00:32:20.645 テナント間でベクトル空間を論理的に分離します。ええと。
800 00:32:20.745 --> 00:32:23.965 たとえば、ええと、ご存じのように、少数のテナントがいる場合、
801 00:32:24.305 --> 00:32:27.925 基本的には、ええと、それらを立ち上げるときに、
802 00:32:28.065 --> 00:32:29.845 すべてにpartition keyを割り当てます。
803 00:32:29.845 --> 00:32:31.485 そのテナントに属するベクトルのものです。
804 00:32:31.825 --> 00:32:34.525 つまりクエリ時に、クエリを私たちに送るとき、
805 00:32:34.625 --> 00:32:36.165 そのパーティションキーを指定できます。
806 00:32:36.165 --> 00:32:38.005 そして Zilliz は基本的に残りの
807 00:32:38.005 --> 00:32:41.045 ベクトル空間を無視し、テナントのベクトル全体に対してのみ
808 00:32:41.045 --> 00:32:43.445 a と n を実行します、そうですよね？
809 00:32:43.905 --> 00:32:47.085 ええと、もう一つの方法は物理的な分離です、ええ、
810 00:32:47.085 --> 00:32:50.725 テナントごとに1つのコレクションを作成する方法で、ええ、
811 00:32:50.865 --> 00:32:52.205 それも同様に機能します。
812 00:32:52.505 --> 00:32:54.765 ええ、それを好むお客様も多くいます。というのも、
813 00:32:54.765 --> 00:32:57.125 顧客との SLA があり、
814 00:32:57.125 --> 00:32:58.845 いや、物理的な分離が必要だ、と定められている場合があるからです。
815 00:32:58.865 --> 00:33:00.045 他のテナントと
816 00:33:00.045 --> 00:33:02.005 混在させることはできない、ということですが、それも問題ありません。
817 00:33:02.065 --> 00:33:03.925 その場合の欠点は、つまり、
818 00:33:04.215 --> 00:33:05.645 クラスタ内に持てる
819 00:33:05.645 --> 00:33:07.405 コレクション数にはいくつか上限があることです。
820 00:33:07.785 --> 00:33:09.565 もちろんクラスタを増やすことはできますし、それは問題ありません。
821 00:33:09.565 --> 00:33:11.885 多くの方がその制限を回避するためにそれを使っています。
822 00:33:11.885 --> 00:33:14.525 しかし、パーティションキーによる論理的な分離では、つまり、
823 00:33:14.525 --> 00:33:15.845 かなり多く持つことができます。
824 00:33:15.845 --> 00:33:17.725 つまり、同じコレクション内に
825 00:33:17.725 --> 00:33:18.925 数百万のテナントを持つことができます。
826 00:33:19.225 --> 00:33:21.725 ええと、そしてすべてのクエリを
827 00:33:21.725 --> 00:33:23.685 その同じコレクションに送ることができ、ええ、
828 00:33:23.685 --> 00:33:25.365 それでも探しているものを正確に得られます。
829 00:33:25.425 --> 00:33:28.045 そしてさらに重要なのは、もし
830 00:33:28.765 --> 00:33:29.885 グローバルな a
831 00:33:29.885 --> 00:33:31.965 と n を全テナントに対して実行したい場合、たとえば
832 00:33:31.965 --> 00:33:33.205 分析ユースケース向けとか、
833 00:33:33.305 --> 00:33:34.845 あるいは単に、ただ見てみたい、
834 00:33:34.925 --> 00:33:36.165 これがどう見えるのか見たい、という場合です。
835 00:33:36.505 --> 00:33:39.965 ええと、1テナント1コレクションのモデルでは、
836 00:33:40.585 --> 00:33:43.765 それらすべてのコレクションに対して
837 00:33:43.765 --> 00:33:45.765 単一のクエリを送る必要がありますよね？
838 00:33:45.765 --> 00:33:46.845 それぞれのコレクションに、です。
839 00:33:47.385 --> 00:33:49.405 そしてそれらをまとめてマージすることになります。それに対して、
840 00:33:49.405 --> 00:33:50.925 すべてが単一のコレクションに入っていれば、
841 00:33:50.925 --> 00:33:52.845 1つの A と n を送るだけで、それが全部に対して実行されます。
842 00:33:52.925 --> 00:33:55.045 ですから、それらが、私たちは両方をサポートしています。
843 00:33:55.145 --> 00:33:57.165 ええ、つまり、それは完全にあなた次第です。
844 00:33:57.165 --> 00:33:59.245 そしてもちろん、私たちチームはあなたと非常に密に連携して
845 00:33:59.385 --> 00:34:01.205 どのトレードオフが適切かを見極めます。
846 00:34:01.515 --> 00:34:03.485 はい。そして通常、私には
847 00:34:03.485 --> 00:34:05.325 人々はたいてい、まずデータベース、
848 00:34:05.325 --> 00:34:07.925 コレクション、そしてパーティションから始めるように見えます。
849 00:34:07.925 --> 00:34:12.045 しかし、私たちから皆さんへのアドバイスは、ええ、
850 00:34:12.045 --> 00:34:14.845 ソリューションアーキテクトと腰を据えて話し、ユースケースをしっかり説明し、
851 00:34:14.845 --> 00:34:15.845 何を達成しようとしているのか、
852 00:34:16.265 --> 00:34:18.565 そうすれば彼らが手助けしてくれて、ほら、最初から
853 00:34:18.565 --> 00:34:20.965 あなたにとって最も理にかなう道を進めるようになります。
854 00:34:20.965 --> 00:34:22.925 後からやり直すようなことをしなくて済むわけです。
855 00:34:23.745 --> 00:34:26.685 それから、ええと、マルチテナンシーにも関連しているのが、
856 00:34:26.685 --> 00:34:29.725 RAC に関連するかなり高度な一連の
857 00:34:29.775 --> 00:34:31.885 ルールがあるということです、そうですよね？
858 00:34:31.945 --> 00:34:32.945 Jay？
859 00:34:33.575 --> 00:34:38.225 はい。ええと、RBAC は本当に、
860 00:34:38.565 --> 00:34:41.585 あなたの組織がどのような形になっているか、
861 00:34:42.045 --> 00:34:44.545 そしてあなた側で誰が何をすることを許可されているかに関するものです。
862 00:34:44.545 --> 00:34:45.745 ですから当然、私たちは皆さんと協力して、
863 00:34:45.745 --> 00:34:47.985 組織図を確認しますよね？
864 00:34:48.135 --> 00:34:50.785 適切な人たちが適切なものに
865 00:34:50.805 --> 00:34:52.865 アクセスできるようにし、さらに重要なのは、
866 00:34:52.865 --> 00:34:54.225 適切なマイクロサービスが
867 00:34:54.225 --> 00:34:55.385 適切なものにアクセスできるようにすることです、そうですよね？
868 00:34:55.385 --> 00:34:57.625 もしあるマイクロサービスが、
869 00:34:57.645 --> 00:35:00.025 特定のクラスターからのみ読み取るべきで、
870 00:35:00.025 --> 00:35:01.225 他のクラスターからは読み取るべきでない場合ですね？
871 00:35:01.225 --> 00:35:04.465 私たちは、それが API レベルで
872 00:35:04.645 --> 00:35:06.065 強制されるようにしたいのです。
873 00:35:06.125 --> 00:35:10.065 ですから、非常に細かな制御がたくさんあり、
874 00:35:10.065 --> 00:35:12.305 それをユーザー向けだけでなく、
875 00:35:12.405 --> 00:35:14.545 認証キー向けにも提供しています。
876 00:35:15.005 --> 00:35:17.425 ええと、そして当然ながら、皆さんのチームと
877 00:35:17.455 --> 00:35:20.145 非常に密接に連携して、確実に、
878 00:35:20.405 --> 00:35:22.145 すべてが強制され、
879 00:35:22.145 --> 00:35:24.465 皆さん側ですべての RAC が正しく設定されるようにします。
880 00:35:24.465 --> 00:35:27.265 そうすれば、もし、ええと、
881 00:35:27.485 --> 00:35:29.865 もしマイクロサービスが暴走しても、
882 00:35:29.865 --> 00:35:31.705 見るべきでないクラスターの内部を
883 00:35:31.705 --> 00:35:33.185 見ることは許可されない、と安心できます。
884 00:35:34.335 --> 00:35:35.935 素晴らしいです。ええと、それから、もし皆さんが、
885 00:35:35.935 --> 00:35:38.405 もし全員が ui を見ているなら、Jay が説明しなかった他の機能が
886 00:35:38.405 --> 00:35:40.085 たくさんあるのが分かると思いますが、
887 00:35:40.085 --> 00:35:41.205 それらはかなりシンプルだと思います。
888 00:35:41.505 --> 00:35:43.005 彼はバックアップについて話しましたが、
889 00:35:43.005 --> 00:35:46.205 もちろんそれらを移行として設定できますし、ええと、
890 00:35:46.385 --> 00:35:49.085 ジョブがどのように進んでいるかを確認することもできます。
891 00:35:49.385 --> 00:35:51.925 そしてもちろん、メトリクスでは、どのような種類の
892 00:35:51.925 --> 00:35:54.845 監視もできます。たとえ、ええと、他の DevOps ツール、たとえば、
893 00:35:54.905 --> 00:35:57.765 Datadog のようなものを使っていても、ほら、どれだけうまく
894 00:35:58.025 --> 00:36:01.125 皆さんのインスタンスがリソースを活用しているかを見ることができます。
895 00:36:02.995 --> 00:36:05.725 いいですね。ええと、では最後のスライドを共有します。
896 00:36:06.065 --> 00:36:07.365 質問はありませんが、
897 00:36:07.425 --> 00:36:10.435 ただ、ええと、ちょっと、見てみましょう。
898 00:36:10.985 --> 00:36:12.395 共有を停止しますので、お願いします、ありがとうございます。
899 00:36:14.825 --> 00:36:17.075 皆さんに、ええと、お知らせしたいだけです。
900 00:36:17.095 --> 00:36:18.755 では、これらのウェビナーに参加する以外に、
901 00:36:18.755 --> 00:36:20.515 私たちからどのようにサポートを受けられるでしょうか？
902 00:36:20.515 --> 00:36:22.115 Discord チャンネルに参加できます。
903 00:36:22.855 --> 00:36:25.755 ええと、こちらもあります。リンクもあります。
904 00:36:25.755 --> 00:36:28.235 そして、この後でこれらすべての情報をお送りします。
905 00:36:28.295 --> 00:36:32.235 ええと、本日のセッション後に、ええと、
906 00:36:32.655 --> 00:36:35.075 20分間のプライベートなオフィスアワーも設定できます。
907 00:36:35.655 --> 00:36:37.915 ええと、これは24時間365日対応できます。
908 00:36:38.175 --> 00:36:41.395 ですので、ええと、皆さんのMilvusとZillizの実装の両方で、
909 00:36:41.395 --> 00:36:43.355 確実にお手伝いできるよう対応しています。
910 00:36:43.855 --> 00:36:45.955 ええと、また、ええと、
911 00:36:46.215 --> 00:36:48.915 GitHubに課題を登録していただくこともできます。
912 00:36:48.915 --> 00:36:50.915 そこではエンジニアリングチーム全体も
913 00:36:50.915 --> 00:36:52.795 あらゆる質問に答えられるよう待機しています。
914 00:36:53.025 --> 00:36:55.755 それが機能リクエストであっても、バグを見つけた場合でも、
915 00:36:55.775 --> 00:36:57.755 あるいは何か少し難しいことがある場合でも、
916 00:36:57.755 --> 00:36:59.195 それが簡単であれば、そこに投稿してください。
917 00:36:59.895 --> 00:37:01.675 ええと、小さなチャットボットもあります。
918 00:37:01.675 --> 00:37:04.435 もちろん、私たちはドキュメントページ上の
919 00:37:04.435 --> 00:37:06.115 多くのチャットボットを動かしているので、
920 00:37:06.235 --> 00:37:08.155 そのスクリーンショットを少し載せておきました。
921 00:37:08.815 --> 00:37:11.915 それから、ええと、こちらには載せていませんが、
922 00:37:12.155 --> 00:37:14.235 プライベートなSlackチャンネルを設定することもできます。
923 00:37:14.255 --> 00:37:15.995 それも可能です。
924 00:37:15.995 --> 00:37:18.915 何らかのサポートを受ける方法として、それがお好みであれば。
925 00:37:19.815 --> 00:37:21.115 それでは、ええと、
926 00:37:21.175 --> 00:37:24.755 皆さんのZillizインスタンスの実装が
927 00:37:24.755 --> 00:37:26.475 大成功することを願っていますが、ぜひ遠慮なくご連絡ください。
928 00:37:26.535 --> 00:37:27.955 何を構築しているのか、
929 00:37:28.375 --> 00:37:30.075 状況はどうか、私たちにどうお手伝いできるかを教えてください。
930 00:37:30.415 --> 00:37:31.475 ええと、私たちはいつでも
931 00:37:31.495 --> 00:37:33.275 皆さんの成功を支援するためにここにいます。
932 00:37:34.335 --> 00:37:36.315 Jay、最後に何かアドバイスはありますか？
933 00:37:37.705 --> 00:37:39.765 いいえ、ええと、楽しんでください。ええと、これはクールな製品です。
934 00:37:40.205 --> 00:37:41.445 皆さんもきっと、そして、ええと、
935 00:37:41.445 --> 00:37:42.525 私たちはいつでもお手伝いします。もちろんです。
936 00:37:43.325 --> 00:37:45.405 素晴らしい。では、皆さん、良い一日を。
937 00:37:45.405 --> 00:37:46.565 またお会いしましょう。さようなら。