Join the Webinar
Loading...
このウェビナーについて
AIアプリケーション向けの高いスケーラビリティとパフォーマンスを備えたベクトルデータベースサービスであるZilliz Cloudの技術概要を紹介する月例デモにご参加ください
取り上げるトピック
- Zilliz Cloudのスケーラブルなアーキテクチャ
- 開発者に使いやすいUIの主な機能
- セキュリティのベストプラクティスとデータプライバシー
- 最近の製品リリースのハイライト
このウェビナーは、開発者がZilliz Cloudの機能と、それがAIプロジェクトをどのように支援できるかを学ぶ絶好の機会です。今すぐ登録してコミュニティに参加し、最新のベクトルデータベース技術に関する情報を常に入手しましょう。
WEBVTT
1 00:00:03.825 --> 00:00:04.355 おはようございます。
2 00:00:04.385 --> 00:00:06.395 こんにちは、ええと、こんばんは。
3 00:00:06.425 --> 00:00:07.675 どちらにいらっしゃるかによりますね。
4 00:00:07.845 --> 00:00:10.555 本日のセッションにご参加いただき、誠にありがとうございます。
5 00:00:11.125 --> 00:00:13.995 本日は実は、私たちの初めての月例、ええと、
6 00:00:14.315 --> 00:00:15.435 ZILLS Cloud製品デモです。
7 00:00:16.015 --> 00:00:18.755 ええと、私はsfiです。私はheのメンバー、ええと、
8 00:00:18.875 --> 00:00:20.315 ここZillowsのチームメンバーです。
9 00:00:20.495 --> 00:00:22.875 同僚の、ええと、Ameeと一緒にいます。
10 00:00:23.185 --> 00:00:25.675 彼はソリューションアーキテクトの一人ですよね？
11 00:00:25.695 --> 00:00:28.075 そう、それで合っています。あなたの肩書きですよね、Amik。
12 00:00:28.075 --> 00:00:29.235 皆さんに挨拶しますか？
13 00:00:29.965 --> 00:00:33.225 皆さん、こんにちは。ええと、ここに参加できて、ええと、とても嬉しいです
14 00:00:33.725 --> 00:00:36.625 そして、ええ、私はただのソリューションアーキテクトで
15 00:00:36.625 --> 00:00:39.625 そして、ええと、ええ、楽しみにしています、ええと、
16 00:00:40.045 --> 00:00:42.345 今月の、ええと、
17 00:00:42.345 --> 00:00:43.665 月例デモで皆さんをご案内することを。
18 00:00:44.495 --> 00:00:46.125 素晴らしいです。では始めましょう。
19 00:00:46.905 --> 00:00:50.485 ええと、では、ええと、本日は皆さんにご紹介できることをとても嬉しく思います
20 00:00:50.485 --> 00:00:53.125 このZillow Cloud、私たちのスケーラブルで
21 00:00:53.385 --> 00:00:55.565 高性能なベクトルデータベースソリューションを。
22 00:00:58.315 --> 00:01:00.895 ええと、やってみます、はい。
23 00:01:01.115 --> 00:01:05.095 それでは、ええと、アジェンダには、ええと、2つの項目があります、ええと、
24 00:01:05.095 --> 00:01:06.615 短いウェビナーになりますので。
25 00:01:07.035 --> 00:01:09.855 まず最初に、皆さんに大まかな
26 00:01:10.175 --> 00:01:13.175 概要をお伝えします、ええと、zills Cloudとは何かについて。
27 00:01:13.435 --> 00:01:15.495 ええと、もし私たちのことをあまりご存じでなければ、
28 00:01:15.845 --> 00:01:18.295 その後、amekが簡単な製品デモを行います。
29 00:01:22.105 --> 00:01:26.525 はい。ええと、はい。
30 00:01:26.745 --> 00:01:30.885 ええと、皆さんの中にはご存じの方もいると思いますが、ULU Cloudは、ええと、
31 00:01:30.885 --> 00:01:35.685 buの上に構築されています。ええと、buはこの最も有名な、
32 00:01:36.025 --> 00:01:37.645 ええと、すみません、こうは言いません。
33 00:01:37.875 --> 00:01:41.245 最も人気のあるオープンソースの、ええと、ベクトルデータベースで、ええと、
34 00:01:41.465 --> 00:01:44.325 私たちはLinux Foundationに寄贈しました
35 00:01:44.985 --> 00:01:46.925 2020年に、ええと、
36 00:01:46.925 --> 00:01:49.525 なぜなら私たちは、ツールを構築することを本当に信じているからです
37 00:01:49.595 --> 00:01:51.765 開発者が信頼し、specし、
38 00:01:51.865 --> 00:01:54.525 貢献できるツールを、ええと、ここにある数字は、
39 00:01:54.705 --> 00:01:56.205 そのストーリーをかなり物語っています。
40 00:01:56.745 --> 00:02:00.085 私たちは32K以上のスターを達成しました、ええと、
41 00:02:00.325 --> 00:02:01.845 今年の初めだったと思います、
42 00:02:02.505 --> 00:02:06.485 そして6,800万以上のDockerプルが見られています。
43 00:02:06.905 --> 00:02:10.565 つまり中核として、VUSは目的特化型に構築されています、ええと、
44 00:02:10.675 --> 00:02:13.205 皆さんが扱っているもののために、ベクトルデータベースとして目的特化型に構築され、
45 00:02:13.685 --> 00:02:14.725 保存、インデックス作成、
46 00:02:14.725 --> 00:02:17.405 そして埋め込みの管理を行います、ええと、
47 00:02:17.405 --> 00:02:20.605 皆さんのために、ええと、機械学習モデルから出てくるものです。
48 00:02:21.025 --> 00:02:24.365 ええと、セマンティック検索レコメンデーションを構築している場合でも
49 00:02:24.365 --> 00:02:28.205 システムでも、その他の、ええと、ベクトル検索アプリケーションでも、
50 00:02:28.795 --> 00:02:31.725 これは皆さんのニーズに合わせてスケールするインフラです。
51 00:02:35.945 --> 00:02:39.035 ええと、millは、millは素晴らしいです。私たちは皆気に入っています。
52 00:02:39.135 --> 00:02:43.315 ええと、ですが、ええと、ええと、私たちは開発者から、そして
53 00:02:43.455 --> 00:02:44.635 また一部の、ええと、
54 00:02:44.775 --> 00:02:48.355 アプリケーションをプロトタイプから本番環境へ移行する際の
55 00:02:48.425 --> 00:02:50.475 いくつかの課題について、DevOps の人たちと話しました。
56 00:02:51.015 --> 00:02:53.155 ええ、そこでそれらのクラウドが登場し、
57 00:02:53.155 --> 00:02:56.635 そして、ええ、3つの重要な、いわば3本柱を構築します
58 00:02:56.655 --> 00:02:59.885 この、ええ、課題を支えるために。
59 00:03:00.305 --> 00:03:03.485 まず1つ目は、私たちの、私たちの Cardinal 検索エンジンです。
60 00:03:03.625 --> 00:03:04.645 聞いたことがあればですが。
61 00:03:05.185 --> 00:03:09.405 ええ、ですから、ええ、VU ユーザーであっても、気に入るはずです
62 00:03:09.405 --> 00:03:13.005 なぜなら、それは、ええ、この箱から出してすぐに10倍高速な、ええ、
63 00:03:13.035 --> 00:03:14.565 パフォーマンスを提供するからです。
64 00:03:15.025 --> 00:03:17.285 そして私たちは、
65 00:03:17.305 --> 00:03:19.005 手動のインデックスツール調整の頭痛の種を取り除きました
66 00:03:19.105 --> 00:03:20.605 そして彼女との調整の損失のようなものも
67 00:03:20.605 --> 00:03:22.125 それは本当に時間がかかり
68 00:03:22.145 --> 00:03:24.325 多くの、ええ、専門知識を必要とします。
69 00:03:25.185 --> 00:03:28.125 自動インデックス機能は基本的に、
70 00:03:28.165 --> 00:03:31.165 通常は自分で見つけ出さなければならないすべての最適化を処理します。
71 00:03:32.265 --> 00:03:37.245 ええ、インフラ、DevOps の、ええ、人たち向けに、私たちはこれを
72 00:03:37.305 --> 00:03:39.485 真のクラウドネイティブな分散システムとして構築しています。
73 00:03:40.225 --> 00:03:43.365 ええ、これは単にクラウドラッパーを付けた bu ではありません。
74 00:03:43.465 --> 00:03:46.725 ええ、多くの、ええ、オープンソースプロジェクトは、
75 00:03:46.725 --> 00:03:50.365 ただ、ええ、自分たちのオープンソースの、ええ、製品を
76 00:03:50.905 --> 00:03:52.845 クラウド上の Kubernetes クラスターに入れて
77 00:03:52.905 --> 00:03:54.405 フルマネージドと呼んでいます。
78 00:03:54.905 --> 00:03:55.965 ええ、私たちはそれはしません。
79 00:03:56.185 --> 00:03:59.565 ええ、villa は実際にゼロから設計されています、ええ、
80 00:03:59.585 --> 00:04:01.845 水平スケーリングと高可用性のために
81 00:04:02.155 --> 00:04:05.085 なぜなら、スイートを壊すことなくスケールアップまたはスケールダウンできるからです
82 00:04:05.625 --> 00:04:08.645 そして分散アーキテクチャは、より優れた適合性
83 00:04:08.785 --> 00:04:09.925 とコスト効率を意味します。
84 00:04:10.665 --> 00:04:13.605 最後に、ここでは本番データを扱っているので、
85 00:04:14.105 --> 00:04:17.565 ええ、私たちは、ええ、セキュリティを非常に、非常に真剣に考えています。
86 00:04:18.145 --> 00:04:20.565 ええ、セキュリティと信頼性の両方を確保します。
87 00:04:21.095 --> 00:04:24.205 私たちが話しているのは、ええ、よりよくテストされたパフォーマンスで、
88 00:04:24.205 --> 00:04:26.165 エンタープライズのセキュリティ要件を満たすものです
89 00:04:26.275 --> 00:04:27.885 なぜなら、誰も自分の CISO に
90 00:04:27.885 --> 00:04:31.525 なぜ適切なセキュリティ制御のないソリューションを選んだのかを
91 00:04:31.565 --> 00:04:32.965 説明したくないからです。
92 00:04:35.895 --> 00:04:37.155 ええ、それでは、ええ、
93 00:04:37.155 --> 00:04:39.235 Cardio 検索エンジンの技術的な詳細を
94 00:04:39.295 --> 00:04:40.755 もう少し深く見ていきましょう。
95 00:04:41.375 --> 00:04:44.235 以前に Novis を使ったことがあるなら、気づくでしょう。
96 00:04:44.235 --> 00:04:46.755 ここで対処している、いくつかの一般的な痛み、ええ、です。
97 00:04:47.005 --> 00:04:48.635 まずはインデックス作成です。
98 00:04:49.415 --> 00:04:52.915 私たちは、皆その手順を知っています。何時間も費やして、
99 00:04:53.455 --> 00:04:56.115 パラメーターを調整し、ベンチマークを実行し、
100 00:04:56.415 --> 00:05:00.035 それでも最適なパフォーマンスに達したのか疑問に思うのです。
101 00:05:00.495 --> 00:05:03.155 自動インデックスシステムは基本的にこれを代わりに処理します。
102 00:05:03.615 --> 00:05:05.355 それはあなたのデータセットを分析し
103 00:05:05.575 --> 00:05:06.915 そして何であれ、ええ、
104 00:05:07.235 --> 00:05:10.635 基盤となるオンラインハードウェアのハードウェアが、最も
105 00:05:10.915 --> 00:05:11.915 効率的な検索戦略を選択します。
106 00:05:12.295 --> 00:05:14.435 つまり、そこにはもう推測の余地はありません。
107 00:05:15.135 --> 00:05:17.155 コアアーキテクチャはかなり単純です
108 00:05:17.665 --> 00:05:19.875 インデックス構築を備えたアルゴリズム層
109 00:05:19.935 --> 00:05:22.955 そして量子化のための検索パーコレーション層
110 00:05:23.015 --> 00:05:27.035 さらに、グラフ IVF ハイブリッドを使用したリファインメントとストレージ
111 00:05:27.395 --> 00:05:29.755 アプローチで、これは業界でも実際に非常にユニークです。
112 00:05:30.185 --> 00:05:32.675 競合のほとんどはおそらく、いや、
113 00:05:32.675 --> 00:05:34.955 ほぼ IVF のようなものを使っているだけで、ええと、
114 00:05:35.015 --> 00:05:38.675 しかしこの種の IVF は、ええと、すみません、主に使われているのはグラフです。
115 00:05:39.055 --> 00:05:42.355 ええと、しかしこのタイプのグラフ IVF ハイブリッドは、ええと、興味深いです
116 00:05:42.455 --> 00:05:45.075 ワークロードに基づいて容量
117 00:05:45.135 --> 00:05:47.075 とパフォーマンスのトレードオフを調整しない限り。
118 00:05:47.495 --> 00:05:50.675 私たちのテストでは、約50%多い容量を得ており
119 00:05:50.735 --> 00:05:55.435 検索速度は、ええと、vis より最大10倍速いことが確認されています。
120 00:05:56.285 --> 00:06:00.135 ええと、低レベルの最適化もたくさん行いました、ええと、
121 00:06:00.375 --> 00:06:01.735 カーネルレベルのものや CPU
122 00:06:01.735 --> 00:06:03.655 およびメトリクス分析によって、絞り出せました、
123 00:06:04.195 --> 00:06:05.415 ええと、バッドあたりのパフォーマンスを。
124 00:06:07.105 --> 00:06:10.125 では、クラウド Cloud native
125 00:06:10.505 --> 00:06:11.525 そして fully managed についてもう少し話しましょう。
126 00:06:11.755 --> 00:06:14.045 それが実際には何を意味するのか。
127 00:06:14.785 --> 00:06:18.045 ええと、ここに比較を載せています。皆さんが
128 00:06:18.045 --> 00:06:19.085 理解しやすいようにです。
129 00:06:19.625 --> 00:06:23.885 ええと、ご覧のとおり、ええと、私たちが構築したものは、
130 00:06:23.885 --> 00:06:26.485 単なるホステッドソリューションではなく、fully managed のようなクラウドコードです。
131 00:06:26.485 --> 00:06:27.605 というものです。
132 00:06:28.265 --> 00:06:32.125 ええと、一番左の列を見ると、ええと、
133 00:06:32.185 --> 00:06:34.045 それはほぼ open source のようなものですよね？
134 00:06:34.465 --> 00:06:35.965 VIS
135 00:06:36.025 --> 00:06:38.325 または他の open source ベクターデータベースを運用したことがある人なら、ええと、
136 00:06:38.775 --> 00:06:40.965 運用上のオーバーヘッドが非常に多いことを知っています。
137 00:06:41.585 --> 00:06:44.605 ええと、open source 版は開発には素晴らしいと
138 00:06:44.705 --> 00:06:46.885 私たちは言えますが、本番環境に到達すると、
139 00:06:47.145 --> 00:06:49.685 データ移行からスケーリング、アップグレードまで、
140 00:06:49.825 --> 00:06:52.605 すべて自分で対応することになります、ええと、
141 00:06:52.605 --> 00:06:55.045 市場にはいくつかのホステッドソリューションがありますが。
142 00:06:55.345 --> 00:06:58.845 ええと、インフラストラクチャと Kubernetes 管理は得られます、ええと、
143 00:06:58.865 --> 00:07:00.365 しかし、運用関連の大部分については依然として
144 00:07:00.365 --> 00:07:01.605 自分で責任を負うことになります。
145 00:07:02.185 --> 00:07:04.805 ええと、私たちの管理アプローチが異なる点は、
146 00:07:04.835 --> 00:07:07.325 そうした本番環境の悩みをすべて私たちが処理することです。
147 00:07:07.665 --> 00:07:10.885 そのため、ゼロダウンタイムのスケーリングがあり、スケールアップ
148 00:07:11.265 --> 00:07:13.765 またはサービス中断なしでスケールダウンできます。
149 00:07:13.865 --> 00:07:15.045 これは非常に重要だと考えています。
150 00:07:15.665 --> 00:07:18.245 ええと、自動バックアップとデータ移行。
151 00:07:18.465 --> 00:07:20.605 そのため、カスタムスクリプトを書く必要も
152 00:07:20.865 --> 00:07:21.925 このプロセスを管理する必要もありません。
153 00:07:22.825 --> 00:07:25.325 ええと、特定のユースケースに基づく
154 00:07:25.325 --> 00:07:26.445 パフォーマンスチューニングがあります。
155 00:07:26.745 --> 00:07:29.565 つまり、実際のワークロードパターンに基づいて最適化します。
156 00:07:29.745 --> 00:07:32.935 ええと、うーん、それについては後でもう少し共有します。もちろんです。
157 00:07:32.935 --> 00:07:34.815 つまり、自動スケーリングがあり、ええと、
158 00:07:35.235 --> 00:07:37.175 そして手間のかからないアップデートとパッチ適用があります。
159 00:07:37.315 --> 00:07:38.615 つまり、セキュリティパッチ
160 00:07:38.615 --> 00:07:41.415 や発生するバージョンアップグレードは、ええと、まさに
161 00:07:41.415 --> 00:07:43.255 裏側で行われるので、心配する必要はありません。
162 00:07:44.045 --> 00:07:46.375 これは本質的に、チームがインフラの管理ではなく、
163 00:07:46.775 --> 00:07:48.575 機能の構築に集中できることを意味します。
164 00:07:50.325 --> 00:07:53.465 では、うーん、クラウドネイティブの大きな部分は、
165 00:07:53.465 --> 00:07:54.545 マルチテナンシーをどう管理するかでもあります。
166 00:07:54.605 --> 00:07:57.745 うーん、amik、ええと、ここでの
167 00:07:57.885 --> 00:07:59.545 マルチテナンシーの仕組みを説明してもらえますか？
168 00:08:01.675 --> 00:08:02.965 はい、もちろんです。
169 00:08:03.025 --> 00:08:07.205 マルチテナンシーに関しては、3つの、ええと、レイヤー、つまり3層のアプローチがあります。
170 00:08:07.385 --> 00:08:09.045 ええと、マルチテナンシーに関してです。
171 00:08:09.585 --> 00:08:12.925 うーん、1つ目はデータベース指向のマルチテナンシーです。
172 00:08:13.505 --> 00:08:15.245 2つ目はコレクション指向、
173 00:08:15.905 --> 00:08:18.445 そして3つ目はパーティション指向です。
174 00:08:19.225 --> 00:08:23.085 うーん、今ご覧になっているものは、ええと、私たちのパーティを説明しています。
175 00:08:23.085 --> 00:08:25.045 ええと、今ご覧の図は、私たちの
176 00:08:25.045 --> 00:08:28.125 パーティション指向の、ええと、マルチテナンシー、
177 00:08:28.685 --> 00:08:31.325 具体的にはパーティションキーに基づくマルチテナンシーを説明しています。
178 00:08:32.225 --> 00:08:35.965 そして、ええと、コレクションの作成時に、うーん、
179 00:08:35.985 --> 00:08:39.005 実際にテナントフィールドを指定して
180 00:08:39.745 --> 00:08:42.285 それをパーティションキーフィールドにすることができます。
181 00:08:43.065 --> 00:08:44.325 そして VIS
182 00:08:44.825 --> 00:08:49.205 または Zillow は基本的に、パーティションキー フィールドの
183 00:08:49.205 --> 00:08:52.845 ハッシュ値に従って、エンティティをパーティションに保存し、
184 00:08:53.185 --> 00:08:54.885 その特定のパーティションキーを含む
185 00:08:54.950 --> 00:08:56.805 パーティションだけを検索します。
186 00:08:57.665 --> 00:09:00.925 そして、この戦略が非常に効果的である理由は、
187 00:09:00.925 --> 00:09:04.685 Novus のコレクションがサポートできるテナントの最大数に関する
188 00:09:04.685 --> 00:09:06.445 制限を取り払うからです。
189 00:09:07.105 --> 00:09:09.765 ええと、例えば、コレクションにおける
190 00:09:10.505 --> 00:09:14.565 テナントの最大数は、ええと、10,000未満です。
191 00:09:15.025 --> 00:09:18.485 しかし、パーティションキーに基づくアプローチでは、
192 00:09:18.505 --> 00:09:22.085 サポートできるテナント数は、うーん、1,000万を超えます。
193 00:09:23.005 --> 00:09:25.445 さらに、パーティションキーに基づくマルチテナンシーの
194 00:09:25.645 --> 00:09:29.045 アプローチでは、例えば、うーん、
195 00:09:29.185 --> 00:09:30.445 テナントごとに1つのコレクションを使う場合
196 00:09:31.065 --> 00:09:33.725 またはすべてのテナントに対して1つのコレクションを持ち、
197 00:09:33.725 --> 00:09:36.605 そのうえで、うーん、すべての、
198 00:09:37.105 --> 00:09:38.245 うーん、各パーティションにフィルタリングシステムを使う場合よりも、はるかに高速です。
199 00:09:38.865 --> 00:09:41.005 そのため、これは拡張性
200 00:09:41.005 --> 00:09:44.285 および、ええと、速度の面で、私たちが提供する中で最も
201 00:09:44.545 --> 00:09:46.085 動的なオファリングです。
202 00:09:48.055 --> 00:09:51.765 いいですね。うーん、では続けて、
203 00:09:51.765 --> 00:09:54.485 ええと、エンタープライズ機能について少し話しましょう。
204 00:09:55.185 --> 00:09:58.165 ええと、本番データを扱うとき、セキュリティが
205 00:09:58.165 --> 00:09:59.925 重要であることは明らかです。
206 00:10:00.545 --> 00:10:02.525 私たちはこれを多層的なアプローチで構築しています。
207 00:10:02.785 --> 00:10:04.165 ええと、認証があります
208 00:10:04.165 --> 00:10:08.045 複数レベルでのSSOアクセス制御を通じたものです、ええと、
209 00:10:08.345 --> 00:10:09.685 またバックエンドのプライベートな
210 00:10:09.865 --> 00:10:12.005 エンドポイントにより、決して公開されないようにします
211 00:10:12.005 --> 00:10:13.165 あなたのデータがインターネットに。
212 00:10:13.585 --> 00:10:15.445 そしてすべてがエンドツーエンドで暗号化されています、
213 00:10:15.445 --> 00:10:17.165 転送中も保存時もです。
214 00:10:17.665 --> 00:10:19.085 ええと、デプロイメント側では、
215 00:10:19.625 --> 00:10:22.485 ご覧のとおり、これは次のような形で構成されています、
216 00:10:22.485 --> 00:10:25.205 実行したい場所が
217 00:10:25.245 --> 00:10:28.205 A-W-S-G-C-P Azure でも、bring your cloud でも柔軟性を提供するためです。
218 00:10:28.415 --> 00:10:30.645 これについては、後でもう少し詳しくお話しします。
219 00:10:31.025 --> 00:10:32.245 ええと、すべてサポートされています。
220 00:10:32.625 --> 00:10:34.525 ええと、ここで重要なのは、もし必要であれば
221 00:10:34.525 --> 00:10:37.205 データを自分のVPC内に保持することができます
222 00:10:37.815 --> 00:10:40.445 右側のこのアーキテクチャ図を見てください。
223 00:10:40.625 --> 00:10:43.005 ええと、各顧客には物理的に分離されたクラスターが割り当てられます、
224 00:10:43.545 --> 00:10:44.645 共有リソースはありません。
225 00:10:44.955 --> 00:10:47.605 あなたのサービスは他の顧客から完全に分離されています。
226 00:10:48.305 --> 00:10:50.805 ええと、下部の紫色のレイヤー、そこは、ええと、
227 00:10:50.805 --> 00:10:52.805 すべてのデータストレージを処理する場所です
228 00:10:53.075 --> 00:10:54.365 組み込みの暗号化付きで。
229 00:10:54.985 --> 00:10:57.245 稼働時間を心配している方のために言うと、ええと、
230 00:10:57.255 --> 00:10:59.725 私たちはマルチAZデプロイメントで運用しており、ええと、
231 00:10:59.725 --> 00:11:02.445 99.95%のSOAです。
232 00:11:02.585 --> 00:11:05.085 これは稼働時間で、SOAの組み込みバックアップ
233 00:11:05.305 --> 00:11:08.365 および災害復旧が、ええと、標準で付いています。
234 00:11:10.085 --> 00:11:13.545 ええと、それでは、ええと、BIOCについてもう少しお話ししましょう。
235 00:11:13.635 --> 00:11:16.025 データ主権を維持したいという
236 00:11:16.025 --> 00:11:19.785 多くのお客様からのフィードバックを聞いてきましたし、運用負荷も最小化したいということでした。
237 00:11:20.285 --> 00:11:22.145 そこで昨年BIOCをリリースしました。
238 00:11:22.425 --> 00:11:25.945 実は本日、もう一つ非常に大きなアップグレードを発表しました、
239 00:11:26.205 --> 00:11:27.545 ええと、RBLCへのものです。
240 00:11:27.575 --> 00:11:28.785 リンクは少し後で載せます
241 00:11:28.845 --> 00:11:30.665 もしこれに関心があれば確認できるように、
242 00:11:30.725 --> 00:11:32.145 ええと、デプロイメントモデルです。
243 00:11:32.925 --> 00:11:35.265 それで、ええと、お客様のニーズに応えるために、
244 00:11:35.405 --> 00:11:37.665 bring all on cloudオプションを提供しています。
245 00:11:38.215 --> 00:11:39.865 これは、必要とするチーム向けです
246 00:11:39.865 --> 00:11:42.825 通常はコンプライアンス要件のために、すべてを自分たちのVPC内に保持する必要があるチーム、
247 00:11:42.845 --> 00:11:44.465 または内部セキュリティポリシーのためです、
248 00:11:45.005 --> 00:11:49.305 現在は、ええと、AWS
249 00:11:49.305 --> 00:11:52.585 とA GCPで利用可能で、Azureサポートは近日提供予定です。
250 00:11:53.185 --> 00:11:55.405 ええと、もちろん左側にはまだ、
251 00:11:55.665 --> 00:11:58.845 ご覧のとおり、私たちの完全マネージドサービスもまだあります、
252 00:11:58.955 --> 00:12:01.565 基本的にvis Rayは特に設計されています
253 00:12:01.665 --> 00:12:03.285 クラウドネイティブなデプロイメント向けに。
254 00:12:03.745 --> 00:12:06.285 これはA-W-S-G-C-PまたはAzureで実行できます。
255 00:12:06.465 --> 00:12:07.725 私たちがすべて対応します。
256 00:12:07.795 --> 00:12:12.605 スケーリング、アップグレード、更新、メンテナンス、ええと、つまり、ええと、
257 00:12:12.785 --> 00:12:15.765 それが、ええと、それが、Zillow Cloud cellサービスです。
258 00:12:17.555 --> 00:12:20.255 では、どのようにするかについてもう少しお話しします
259 00:12:20.965 --> 00:12:25.095 まさに当社のBIOCで、ワークロードを安全にします。
260 00:12:25.575 --> 00:12:28.985 というのも、BIOCは、
261 00:12:29.165 --> 00:12:31.345 新しいものではないと聞いていますが、
262 00:12:31.345 --> 00:12:33.145 多くのベンダーが実際には正しく実装できていません。
263 00:12:33.645 --> 00:12:35.825 そこで、私たちのアプローチを皆さんに共有したいと思います。
264 00:12:36.125 --> 00:12:38.945 この図は、当社のセキュリティアーキテクチャを示しており、
265 00:12:39.505 --> 00:12:42.065 2つの異なる環境、
266 00:12:42.555 --> 00:12:45.425 つまりCloud VPCと顧客管理VPCがあります。
267 00:12:45.925 --> 00:12:49.345 左側にはCloud VPCがあり、
268 00:12:49.725 --> 00:12:52.905 ここには当社のコントロールパネル、リソース管理用のBLCコントローラー、
269 00:12:52.905 --> 00:12:53.985 そして
270 00:12:54.365 --> 00:12:56.585 パフォーマンス追跡用のシステムモニターが含まれています。
271 00:12:57.205 --> 00:13:00.305 右側は顧客管理VPCです。
272 00:13:00.565 --> 00:13:04.225 ここには、監視ツールとともに
273 00:13:04.225 --> 00:13:05.305 Kubernetesクラスター上で稼働するデプロイメントが含まれています。
274 00:13:06.045 --> 00:13:09.625 「outbound 443」とラベル付けされた矢印が見えると思います。
275 00:13:09.925 --> 00:13:12.825 これは皆さんのためにこのようにしています。
276 00:13:12.925 --> 00:13:15.625 すべてがHTTPで暗号化されています。
277 00:13:16.125 --> 00:13:17.585 そして最も重要なのは、
278 00:13:17.655 --> 00:13:20.745 この接続を開始できるのは顧客側だけだということです。
279 00:13:20.855 --> 00:13:22.905 外部から到達できるものは何もありません。
280 00:13:23.765 --> 00:13:28.105 そのため、非常に安全になります。
281 00:13:28.975 --> 00:13:31.785 そして、スケールやvisのようなリソース管理が必要な場合は、
282 00:13:31.785 --> 00:13:35.225 厳格に制限された権限を通じて行われます。
283 00:13:35.725 --> 00:13:38.425 これは実際に新しくリリースされたシステムで、
284 00:13:38.695 --> 00:13:40.065 顧客が制御します。
285 00:13:40.605 --> 00:13:44.545 特定の部屋に対して、請負業者に特定の鍵を渡すようなものだと考えてください。
286 00:13:44.625 --> 00:13:45.705 建物全体への
287 00:13:46.005 --> 00:13:48.265 マスターキーではありません。
288 00:13:48.325 --> 00:13:49.785 それが安全性を確保する方法です。
289 00:13:50.205 --> 00:13:53.145 このアウトバウンドのみの通信と
290 00:13:53.245 --> 00:13:54.385 制御された権限の組み合わせにより、
291 00:13:54.615 --> 00:13:58.545 B-R-B-B-I-O-Cは真にエンタープライズグレードのセキュリティを実現します。
292 00:14:01.135 --> 00:14:04.315 では、非常に手短にですが、実は先週、
293 00:14:04.715 --> 00:14:07.875 Milvusの新しいバージョンをリリースしました。
294 00:14:08.135 --> 00:14:09.715 たしか先週だったと思います。
295 00:14:10.415 --> 00:14:13.435 今回リリースした最も重要な機能は、
296 00:14:13.675 --> 00:14:16.595 実はMilvus 2.5がZilliz
297 00:14:16.595 --> 00:14:17.755 Cloudでパブリックプレビューとして利用可能になったことです。
298 00:14:18.145 --> 00:14:21.875 テキスト検索、
299 00:14:22.145 --> 00:14:25.755 テキストマッチング、ビットマップインデックスなど、多くの優れた機能があります。
300 00:14:25.985 --> 00:14:28.955 後ほど確認していただけるように、
301 00:14:28.975 --> 00:14:30.035 リリースノートを載せておきます。
302 00:14:30.575 --> 00:14:34.235 ですが、最もワクワクするのは全文検索です。
303 00:14:34.815 --> 00:14:36.955 Amik、私たちのテキスト検索が具体的に
304 00:14:37.055 --> 00:14:38.835 どのように機能するのか、もう少し共有してもらえますか？
305 00:14:41.665 --> 00:14:42.755 はい、もちろんです。
306 00:14:42.895 --> 00:14:46.075 全文検索の背後にある原理は、
307 00:14:46.075 --> 00:14:49.835 まず生のテキストデータを
308 00:14:50.225 --> 00:14:51.295 プラットフォームに入力することです。
309 00:14:51.755 --> 00:14:55.535 そして、それをアナライザーにかけます。
310 00:14:55.535 --> 00:14:59.295 基本的にはそれを生成し、ええと、生テキストの
311 00:14:59.715 --> 00:15:02.215 それらの、ええと、トークンに分解します。
312 00:15:02.995 --> 00:15:06.535 そしてその後、ええと、それらのトークンを、うーん、
313 00:15:06.925 --> 00:15:11.655 それらを変換する関数に渡し、うーん、
314 00:15:12.265 --> 00:15:16.755 単語をスパース埋め込みに変換します。
315 00:15:17.555 --> 00:15:20.135 そしてそれが起こると、うーん、
316 00:15:20.315 --> 00:15:22.855 次にそれらのスパース埋め込みを、うーん、
317 00:15:22.855 --> 00:15:25.615 発生するフィルタリング
318 00:15:25.615 --> 00:15:27.375 または検索に基づいてコレクション内でグループ化し、うーん、
319 00:15:27.435 --> 00:15:32.095 そしてそれを使って、ええと、ええと、それを私たちの BM 25、ええと、
320 00:15:32.095 --> 00:15:36.775 スコアリングアルゴリズムに入れて、うーん、特定の top K 結果を生成します。
321 00:15:37.555 --> 00:15:39.415 うーん、そしてユーザーが受け取る結果
322 00:15:39.415 --> 00:15:43.975 に基づいて、ユーザーはその後、うーん、ある程度修正し
323 00:15:44.275 --> 00:15:46.215 アナライザーに挿入するテキストクエリ
324 00:15:46.215 --> 00:15:48.175 を反復していくことができます。
325 00:15:48.755 --> 00:15:51.575 そして、うーん、そのフィードバックループによって、ええと、
326 00:15:51.575 --> 00:15:52.575 時間とともにより良い結果を生成できます。
327 00:15:55.555 --> 00:16:00.525 いいですね。うーん、ではより exciting なデモ部分に入りましょう。
328 00:16:00.625 --> 00:16:02.285 ええと、Amik、画面共有してもらえますか？
329 00:16:03.075 --> 00:16:04.005 はい、もちろんです。
330 00:16:06.685 --> 00:16:08.385 うーん、いいですね。
331 00:16:08.805 --> 00:16:13.675 では、そこに入っていくと、これは Zillow cloud の、ええと、
332 00:16:14.055 --> 00:16:15.235 UI とプラットフォームそのものです。
333 00:16:15.965 --> 00:16:19.145 そして左側には、クラスターを作成できる
334 00:16:19.145 --> 00:16:21.145 セクションがあります。
335 00:16:21.885 --> 00:16:25.945 うーん、バックアップの管理や、ええと、
336 00:16:26.115 --> 00:16:29.185 異なる、ええと、プラットフォームからの移行もできます。
337 00:16:29.285 --> 00:16:33.625 つまり、私たちは、ええと、VIS から Zillow への移行を
338 00:16:34.125 --> 00:16:36.065 さまざまな組織内でサポートしています。
339 00:16:36.845 --> 00:16:40.745 うーん、そして私たちが提供する機能の
340 00:16:40.765 --> 00:16:44.225 全体的な目的は、Zillow cloud
341 00:16:44.745 --> 00:16:46.545 プラットフォームをできるだけ簡単に使えるようにし、
342 00:16:46.565 --> 00:16:48.225 皆さんのチーム側で必要となる作業量を
343 00:16:49.025 --> 00:16:51.705 減らすことです。
344 00:16:51.885 --> 00:16:53.985 私たちのプラットフォームを使い始めるため
345 00:16:54.405 --> 00:16:57.985 だけでなく、私たちのプラットフォーム上で皆さんが立ち上げる
346 00:16:57.985 --> 00:17:00.505 その、その、そのコンピュートユニットを維持するためにもです。
347 00:17:00.645 --> 00:17:03.505 したがって、それが私たちが、ええと、
348 00:17:03.505 --> 00:17:05.585 多くの外部データソースからの移行をサポートしている理由です。
349 00:17:06.405 --> 00:17:10.425 うーん、また既存の組織については、ジョブの管理、
350 00:17:10.445 --> 00:17:14.185 共同作業者の管理、うーん、
351 00:17:14.285 --> 00:17:16.225 さらにはアラートの設定もできる UI を提供しています。うーん、
352 00:17:16.525 --> 00:17:19.585 データがインポートまたはエクスポートされたときに管理するためです。
353 00:17:19.885 --> 00:17:23.865 そして最後に、うーん、Steff が言及していたように、ええと、私たちは、
354 00:17:24.005 --> 00:17:26.105 プライベートエンドポイントの作成を可能にするだけでなく、
355 00:17:26.105 --> 00:17:27.865 特定のネットワークの管理も可能にしています。
356 00:17:27.865 --> 00:17:30.585 そして最後に、Datadog、
357 00:17:30.585 --> 00:17:35.185 Prometheus、そして、うーん、S3 との統合を提供し、うーん、皆さんのチームが
358 00:17:35.205 --> 00:17:37.465 ログを一元化された場所で管理できるようにしたり、
359 00:17:38.085 --> 00:17:41.665 バックアップファイルを Amazon S3 にプッシュしたりできるようにしています。
360 00:17:42.615 --> 00:17:44.875 うーん、ここでさらに深く掘り下げたいと思います
361 00:17:45.175 --> 00:17:46.435 どのように、クラスターを作成するかです。
362 00:17:47.175 --> 00:17:50.645 ええと、当社では3つのプランを提供しています。無料プラン、
363 00:17:50.645 --> 00:17:52.005 serverless、そしてdedicatedです。
364 00:17:52.315 --> 00:17:55.205 当社のエンタープライズのお客様の多くはdedicatedプランを選択されています。
365 00:17:55.545 --> 00:17:59.005 そしてちょうど今日、実際に、ええと、その機能をリリースしました。
366 00:17:59.145 --> 00:18:01.445 つまり、ええと、そちら側のユーザーが
367 00:18:01.445 --> 00:18:05.005 自分でBYOクラスター、BYOCクラスターを立ち上げられる機能です。
368 00:18:05.725 --> 00:18:09.285 以前は、それを管理するには、ITの、ええと、ええと、ITの、
369 00:18:09.285 --> 00:18:12.165 個人貢献者がそのシステムを管理する必要がありました。
370 00:18:12.625 --> 00:18:16.205 ええと、クラスターに名前を付けることができます。ええと、無料
371 00:18:16.205 --> 00:18:19.525 およびserverlessのCLクラスターでは、ええと、GCPUのみがサポートされていますが、
372 00:18:19.525 --> 00:18:22.285 dedicatedでは、3つすべてのCLO主要クラウドが
373 00:18:22.285 --> 00:18:24.525 サポートされており、これらの既存リージョンもサポートされています。
374 00:18:25.495 --> 00:18:28.075 ええと、CUタイプも3つあります。
375 00:18:28.215 --> 00:18:31.755 つまりperformance optimizedは、最も高い、ええと、
376 00:18:31.775 --> 00:18:33.875 最も低いレイテンシーと最高のスループットが必要なケース向けです。
377 00:18:34.455 --> 00:18:36.915 ええと、capacity optimizedは、それでも、
378 00:18:36.915 --> 00:18:38.195 非常に良好なLAレイテンシーが得られます。
379 00:18:38.195 --> 00:18:39.875 およそ100ミリ秒のレイテンシーが得られますが、
380 00:18:39.935 --> 00:18:43.275 ええと、より強化されたストレージ機能を備えています。
381 00:18:43.295 --> 00:18:45.435 そして最後に、extended capacityは
382 00:18:46.135 --> 00:18:49.355 最も手頃なソリューションで、ええと、
383 00:18:49.535 --> 00:18:52.715 500ミリ秒未満から1秒未満のレイテンシーですが、
384 00:18:52.715 --> 00:18:56.675 そのCUは、ええと、さらに多くのベクトルを保存できます。
385 00:18:57.395 --> 00:19:01.175 ええと、では戻りますが、これは既存のクラスターで、
386 00:19:01.175 --> 00:19:03.215 私がすでに作成したものです。
387 00:19:04.155 --> 00:19:07.695 ええと、ここでは、CUサイズとプランで
388 00:19:08.165 --> 00:19:09.855 クラスターの詳細を管理できます。
389 00:19:10.195 --> 00:19:12.375 必要であれば、ここでプランをアップグレードできます。
390 00:19:12.995 --> 00:19:16.135 ええと、CUも手動でスケールできます。
391 00:19:16.755 --> 00:19:20.705 ええと、そしてここでコレクションを管理できます。
392 00:19:21.285 --> 00:19:24.465 ええと、コレクションは、ええと、先ほど述べたように
393 00:19:24.465 --> 00:19:26.625 マルチテナンシーに使うこともできますし、
394 00:19:27.205 --> 00:19:29.785 または、特定のフィールドを持つ特定のコレクションを自分で作成できます。
395 00:19:29.805 --> 00:19:30.905 そうですね、特定のフィールドです。
396 00:19:31.005 --> 00:19:32.985 ここでスキーマを定義できます。
397 00:19:33.445 --> 00:19:35.545 ええと、そして高度な設定内でも、
398 00:19:35.545 --> 00:19:36.665 動的フィールドを作成できます。
399 00:19:36.665 --> 00:19:39.305 たとえば、スキーマを作成したとして、ええと、
400 00:19:39.925 --> 00:19:41.505 データをコレクションにロードし、
401 00:19:41.765 --> 00:19:44.905 その後、そのスキーマに、ええと、別の、ええと、
402 00:19:45.405 --> 00:19:46.585 列を追加したい場合です。
403 00:19:46.585 --> 00:19:48.625 動的なdi動的フィールドも追加できます。
404 00:19:49.005 --> 00:19:51.745 そして、もし、または、ええと、
405 00:19:52.255 --> 00:19:53.345 パーティションキーによる
406 00:19:53.345 --> 00:19:54.745 マルチテナンシーを実行したい場合は、ここで有効にできます。
407 00:19:55.565 --> 00:19:56.705 ええと、同様に、
408 00:20:00.405 --> 00:20:01.745 metricsタブは、ええと、
409 00:20:02.395 --> 00:20:04.305 あなたの、ええと、CUの健全性について示します。
410 00:20:04.645 --> 00:20:08.585 つまり、計算、ええと、計算能力です
411 00:20:09.045 --> 00:20:11.665 または、いくつの、ええと、
412 00:20:11.815 --> 00:20:14.625 ベクトルが保存されているか、ええと、などに対するストレージ容量です。
413 00:20:15.125 --> 00:20:17.105 そしてユーザーについても、ここで
414 00:20:17.105 --> 00:20:18.385 少し
415 00:20:18.385 --> 00:20:22.145 ロールベースのアクセス制御を行い、ええと、誰が制御権を持つかを確認できます。
416 00:20:23.065 --> 00:20:26.125 ええと、たとえば、複数の、ええと、
417 00:20:26.185 --> 00:20:28.965 ここでも異なるユーザーロールを、ええと、選択できます。
418 00:20:30.095 --> 00:20:35.065 ええと、できます、ええと、それから、ええと、これはより、
419 00:20:35.165 --> 00:20:36.985 ええと、コレクションレベルであり、一方で
420 00:20:36.985 --> 00:20:38.145 こちらはよりクラスターレベルです。
421 00:20:38.205 --> 00:20:43.185 ですので、ここでは異なる権限を割り当てることができます、ええと、
422 00:20:43.605 --> 00:20:46.145 異なる、ええと、粒度のレベルに対してです。
423 00:20:46.565 --> 00:20:50.645 ええと、そしてこのスライドが、ええと、最もよく説明していると思います。
424 00:20:50.825 --> 00:20:54.845 つまり、ええと、組織レベルでは、ええと、
425 00:20:54.985 --> 00:20:57.685 プロジェクトレベルと同様に権限を割り当てることができます。
426 00:20:57.825 --> 00:21:00.045 それが実際にコントロールプレーンに保存されるものです。
427 00:21:00.265 --> 00:21:02.085 そして、データに誰がアクセスするかについて
428 00:21:02.085 --> 00:21:03.965 慎重な顧客向けのデータプレーン内では、
429 00:21:04.265 --> 00:21:08.405 クラスターレベルのロールを提供しています、ええと、それは、ええと、
430 00:21:08.455 --> 00:21:10.045 UIでご覧になっていたもので、
431 00:21:10.045 --> 00:21:11.125 データベースレベル、
432 00:21:11.185 --> 00:21:13.605 そして、コレクションレベルでもあります。
433 00:21:15.545 --> 00:21:19.005 ええと、ですのでクラスター内で、ええと、
434 00:21:19.185 --> 00:21:20.845 データベース権限と
435 00:21:20.845 --> 00:21:21.925 クラスター権限の間で選択できることがわかります。
436 00:21:21.925 --> 00:21:25.085 さらに、たとえば、読み取り専用、読み取り、ReadWrite
437 00:21:25.185 --> 00:21:27.965 または管理者権限もあります。
438 00:21:28.585 --> 00:21:33.255 ええと、そして最後に、ええと、この画面では、
439 00:21:33.275 --> 00:21:34.495 ええと、バックアップを生成できます。
440 00:21:34.495 --> 00:21:36.935 データの自動バックアップをスケジュールすることもできますし、
441 00:21:37.315 --> 00:21:38.775 手動バックアップをスケジュールすることもできます。
442 00:21:38.995 --> 00:21:43.295 さらに、これらのバックアップを、ええと、S3バケットにプッシュすることもできます
443 00:21:43.565 --> 00:21:46.545 私たちの、ええと、インテグレーションを使ってです。
444 00:21:47.765 --> 00:21:52.045 ええと、そしてコレクション自体の中では。
445 00:21:52.185 --> 00:21:54.245 つまり、コレクションをクリックすると、
446 00:21:54.905 --> 00:21:58.795 確認できるのは、管理する方法も提供できるということです、ええと、
447 00:21:59.555 --> 00:22:00.995 各個別のコレクションをです。
448 00:22:01.015 --> 00:22:03.835 ここでは、作成されたスキーマを確認できます、ええと、
449 00:22:03.835 --> 00:22:05.995 フィールドタイプや値とともにです。
450 00:22:06.655 --> 00:22:08.675 ええと、ここでデータをインポートできます。
451 00:22:09.215 --> 00:22:11.755 ええと、データを挿入したい場合は、私たちは、ええ、
452 00:22:11.825 --> 00:22:15.975 それをシームレスに、ええと、
453 00:22:16.435 --> 00:22:17.775 実行するために必要な、ええと、APIコードを提供します。
454 00:22:18.355 --> 00:22:21.195 ええと、データのプレビューも確認できます。
455 00:22:21.255 --> 00:22:23.115 ここでは、ベクトルが一覧表示されているのを確認でき、
456 00:22:23.115 --> 00:22:24.315 必要なすべてのフィールドも表示されます。
457 00:22:25.055 --> 00:22:27.395 そして最後に、ベクトル検索を実行できます
458 00:22:27.755 --> 00:22:29.315 実際にプラットフォーム内でもです。
459 00:22:29.695 --> 00:22:32.855 ですので、ここにクエリベクトルを入力できます、ええと、
460 00:22:34.395 --> 00:22:36.775 topの値を変更したり、フィルターを追加することもできます。
461 00:22:37.395 --> 00:22:39.655 つまり、フィルターもまた別の方法です
462 00:22:39.655 --> 00:22:42.655 コレクションレベルでマルチテナンシーを実行するための、ええと、
463 00:22:42.755 --> 00:22:44.815 フィルタリング用のコレクションを指定するための方法です。
464 00:22:44.815 --> 00:22:47.575 ただし、パーティションキーの使用を強くお勧めします
465 00:22:47.915 --> 00:22:49.255 マルチテナンシーを実行するには、単に
466 00:22:49.255 --> 00:22:52.775 パフォーマンスがはるかに優れているからです、ええと、私たちの、
467 00:22:52.775 --> 00:22:55.255 アルゴリズムでは、パーティションキーに基づく
468 00:22:55.255 --> 00:22:58.055 マルチテナンシーアプローチを使用する場合、コレクションレベルの、ええと、
469 00:22:58.205 --> 00:23:00.495 フィルタリングベースのマルチテナンシーアプローチと比べてです。
470 00:23:01.555 --> 00:23:03.815 ええと、ここでは実際にベクトル検索も
471 00:23:03.955 --> 00:23:07.135 実行できます、ええと、そして、ええ、結果を見ることができます。
472 00:23:07.395 --> 00:23:11.455 ええと、ええ、そうですね、これで、ええと、
473 00:23:11.845 --> 00:23:16.245 これで、デモは終わりです、ええと、
474 00:23:16.545 --> 00:23:18.125 私のほうは、そう思います。
475 00:23:20.855 --> 00:23:22.945 いいですね。何か、ええと、質問はありますか？
476 00:23:23.205 --> 00:23:25.745 ええと、Q&A に貼り付けてください。
477 00:23:26.405 --> 00:23:29.065 ええと、実はもう一人のチームメンバーである John、私たちの責任者で、
478 00:23:29.065 --> 00:23:31.145 ええと、DevRel の責任者もここにいます、ええと。
479 00:23:31.565 --> 00:23:35.625 なので、ええと、デモに関して
480 00:23:36.245 --> 00:23:40.945 または製品や何でも、ええと、それらに関連することについて、ええと、
481 00:23:41.135 --> 00:23:42.425 遠慮なく私たちに送ってください。
482 00:23:43.325 --> 00:23:45.330 これは私たちがデモを行う初めての機会です。
483 00:23:45.985 --> 00:23:48.525 何かフィードバックがあれば、ええと、
484 00:23:49.305 --> 00:23:51.045 それも本当にありがたいです。
485 00:23:51.045 --> 00:23:55.885 私たちのほうに送ってください。はい。
486 00:23:55.985 --> 00:23:58.845 ええと、すべてをうまく説明できたようですね。
487 00:23:58.845 --> 00:24:00.405 今のところ質問はありませんが、
488 00:24:00.425 --> 00:24:03.765 後で何か思いついたら、ええと、遠慮なく
489 00:24:03.765 --> 00:24:08.525 私たちの、ええと、ああ、ええと、定期的なトレーニングの予定がありますね。
490 00:24:09.345 --> 00:24:11.765 ええと、定期的なトレーニングとはどういう意味ですか？
491 00:24:11.765 --> 00:24:14.285 Google と同じように、私たちは、この種の
492 00:24:14.285 --> 00:24:15.645 デモを、ええと、毎月行う予定です。
493 00:24:16.225 --> 00:24:19.205 実際、私たちは多くの、ええと、ウェビナーもあります、ええと、
494 00:24:19.345 --> 00:24:21.685 さまざまな種類の、ええと、トピックを扱うためのものです。
495 00:24:21.875 --> 00:24:24.245 その一部はよりハンズオンで、一部は
496 00:24:24.245 --> 00:24:27.285 トレンドについて話すものです、例えば
497 00:24:27.385 --> 00:24:31.045 他の、ええと、ああ、わかりました。
498 00:24:31.605 --> 00:24:33.045 今のところ正式な
499 00:24:33.195 --> 00:24:34.445 種類のプログラムはないと思います。
500 00:24:34.585 --> 00:24:38.005 ええと、でも、ええと、私たちの、ええと、ウェブサイト Learn に行けば
501 00:24:38.005 --> 00:24:41.365 まだたくさんのリソースがあります、
502 00:24:41.745 --> 00:24:43.725 そして those are come slash learn
503 00:24:44.065 --> 00:24:46.245 そこにはたくさんの良いリソースがあります。
504 00:24:50.955 --> 00:24:54.645 はい。では、ええと、ひとつ、ああ、ここに質問がひとつあると思います。
505 00:24:55.785 --> 00:24:56.845 ええと、Sergo、
506 00:24:56.905 --> 00:24:59.925 ZI と vus についてもっと知りたい場合は、
507 00:25:00.145 --> 00:25:03.365 ええと、遠慮なく私たちにメッセージを送ってください。
508 00:25:03.505 --> 00:25:06.645 できます、つまり、それが、ええと、単発のもので、あなたが
509 00:25:06.645 --> 00:25:09.525 特定の機能のようなものについて
510 00:25:09.865 --> 00:25:13.005 何か学びたい場合や、特定のユースケースがある場合は、ええと、
511 00:25:13.095 --> 00:25:14.765 サポートを通じて私たちに連絡できます
512 00:25:15.345 --> 00:25:19.125 または、オープンソースの vu のユースケースがある場合は、Vu の、
513 00:25:19.465 --> 00:25:22.285 ええと、オフィスアワーが毎週2回予定されています。
514 00:25:22.745 --> 00:25:27.315 ええと、ですので、ええと、mill.io のウェブサイトを、ええと、
515 00:25:28.135 --> 00:25:31.715 このクラウド向けの meals オフィスアワーについて確認できますし、
516 00:25:31.715 --> 00:25:32.835 z cloud.com に連絡できます。
517 00:25:32.835 --> 00:25:34.195 サポートページがあります。
518 00:25:34.335 --> 00:25:37.555 書面形式で私たちに連絡できます。ありがとうございます。
519 00:25:38.505 --> 00:25:41.645 ええと、my young、あなたは、質問したいんですよね、ええ、
520 00:25:41.645 --> 00:25:42.925 ライブで質問して大丈夫です。
521 00:25:42.925 --> 00:25:47.425 大丈夫です。ええ。話したいですか？
522 00:25:47.625 --> 00:25:49.425 ミュートを解除して話せると思います。ええ、
523 00:25:50.215 --> 00:25:51.215 ええ。ええと、今のところ
524 00:25:51.215 --> 00:25:53.385 質問はありません。わかりました。
525 00:25:53.685 --> 00:25:57.785 でも、ええと、あなたが用意しているセッションから、ええと、学んだら、
526 00:25:58.135 --> 00:26:01.785 それから、ええと、その後で、ええと、
527 00:26:02.535 --> 00:26:06.225 LinkedIn に質問を投稿します。それでよければ。ええ、
528 00:26:06.655 --> 00:26:07.655 ええ。では、
529 00:26:07.655 --> 00:26:10.065 vis.io にリンクを貼りました。
530 00:26:10.065 --> 00:26:13.065 すみません、vis io slash Discord にもう1つあります。
531 00:26:13.325 --> 00:26:17.025 ええと、それはまた別の、ええと、素晴らしい、ええと、
532 00:26:17.175 --> 00:26:19.585 チャンネルコミュニティで、ええと、私たちや、
533 00:26:19.645 --> 00:26:23.385 他の、他の、ええと、他の開発者で、
534 00:26:23.925 --> 00:26:25.065 ええと、Melva と Zoles を使っている人たちとつながれます。
535 00:26:27.045 --> 00:26:28.295 わかりました。ありがとうございます。
536 00:26:32.625 --> 00:26:35.035 わかりました。ええと、今日はこれで大丈夫だと思います。
537 00:26:35.255 --> 00:26:37.315 ええと、皆さんのお時間に本当に感謝します。
538 00:26:37.575 --> 00:26:42.455 ええと、それでは、ええと、ええと、引き続き連絡を取り合いましょう。バイバイ。
Meet the Speaker
Join the session for live Q&A with the speaker
Ameek Singh
Solutions Architect, Zilliz
Ameek is a Solutions Architect at Zilliz where he helps enterprise customers takes best advantage of Zilliz’s best in class vector database solution. Previously, he was a Solutions Architect at Databricks and Sales Engineer at Fivetran. He graduated from UC Berkeley with a degree in Data Science