🚀 Zilliz Cloudを無料で試す、完全管理型のMilvus—10倍の高速パフォーマンスを体験しよう!今すぐ試す>>

milvus-logo
LFAI
  • Home
  • Blog
  • 2023年、milvusコミュニティを支配するキーワード・トップ10を発表

2023年、milvusコミュニティを支配するキーワード・トップ10を発表

  • Engineering
January 21, 2024
Jack Li, Fendy Feng

2023年を締めくくるにあたり、Milvusコミュニティの目覚ましい歩みを振り返ってみましょう:25,000のGitHubスターを誇り、Milvus 2.3.0をローンチし、Dockerイメージのダウンロード数が1,000万を超えました。この投稿では、チャットの履歴を分析し、ディスカッションの上位10キーワードを明らかにすることで、コミュニティの中心を探ります。

#1位 バージョン - AIGCの台頭がMilvusの急速な反復を後押し

意外なことに、「バージョン」が2023年に最も議論されたキーワードに浮上した。この発見は、この年のAIの波に根ざしたものであり、AIGCアプリケーションの幻覚の問題に取り組むための重要なインフラとしてのベクトル・データベースである。

ベクトル・データベースをめぐる熱狂は、milvusを迅速な反復の段階へと駆り立てる。コミュニティは2023年だけで20のバージョンをリリースし、様々なアプリケーションに最適なMilvusのバージョンを選択するための問い合わせでコミュニティに殺到するAIGC開発者の要求に対応した。このようなアップデートを経験されたユーザーの皆様には、機能・性能向上のため、最新バージョンのご利用をお勧めいたします。

Milvusのリリース計画にご興味のある方は、公式サイトのMilvusロードマップページをご参照ください。

データベース操作における基本的な役割を反映し、"検索 "が第2位となりました。MilvusはTop-K ANN検索からスカラーフィルタ検索、範囲検索まで様々な検索機能をサポートしています。Milvus 3.0(ベータ版)のリリースが間近に迫っており、多くのRAGアプリ開発者が待ち望んでいるキーワード検索(スパース埋め込み)が約束されています。

検索に関するコミュニティの議論は、パフォーマンス、機能、原則に焦点を当てています。ユーザーは、属性フィルタリング、インデックスしきい値の設定、待ち時間の懸念への対処についてよく質問します。クエリや検索に関する文書Milvus機能強化提案(MEPs)、Discordでのディスカッションなどのリソースは、Milvusでの検索の複雑さを解明するための参考資料となっています。

#3 メモリ - メモリオーバーヘッドを最小化するための性能と精度のトレードオフ

「メモリ」もまた、この1年のコミュニティでの議論の中心となった。特徴的なデータ型として、ベクトルは本質的に次元が高い。ベクトルをメモリに格納することは、パフォーマンスを最適化するための一般的な手法ですが、データ量の増大により、利用可能なメモリは限られています。MilvusはMMapやDiskANNのような技術を採用することでメモリ使用量を最適化している。

しかし、データベースシステムにおいて、低いメモリ使用量、優れた性能、高い精度を同時に達成することは依然として複雑であり、メモリオーバーヘッドを最小化するために性能と精度のトレードオフが必要である。

人工知能が生成したコンテンツ(AIGC)の場合、開発者は通常、厳しい性能要件よりも高速な応答と結果の正確さを優先します。MilvusがMMapとDiskANNを追加することで、データ処理と結果の精度を最大化しながらメモリ使用量を最小化し、AIGCアプリケーションの実用的なニーズに沿ったバランスを実現しています。

#4インサート - データ挿入をスムーズに

効率的なデータ挿入は開発者にとって重要な関心事であり、Milvusコミュニティでは挿入速度の最適化について頻繁に議論されています。Milvusは、ストリーミングデータとバッチデータを巧みに分離することにより、ストリーミングデータの効率的な挿入とインデックスの構築に優れています。この機能により、Pineconeのような他のベクターデータベースプロバイダーと比較して、非常にパフォーマンスの高いソリューションとして際立った存在となっています。

以下は、データ挿入に関する貴重な洞察と推奨事項です:

  • バッチ挿入:バッチ挿入:1行挿入よりもバッチ挿入の方が効率的です。特に、ファイルからの挿入はバッチ挿入を凌ぐスピードがあります。1,000万レコードを超える大規模なデータセットを扱う場合は、bulk_insert インタフェースを使用して、インポート処理を合理化および高速化することをご検討ください。

  • 戦略的なflush() の使用:各バッチ終了後にflush() インタフェースを呼び出すのではなく、すべてのデータ挿入が完了した後に 1 回呼び出す。バッチ間でflush() インタフェースを過度に使用すると、断片化されたセグメントファイルが生成され、システムにかなりの圧縮負荷がかかる可能性があります。

  • 主キーの重複排除:Milvusはデータ挿入にinsert インタフェースを使用する場合、プライマリキーの重複排除を行いません。主キーの重複排除が必要な場合は、upsert インタフェースを導入することを推奨します。ただし、upsertの挿入パフォーマンスは、insert の挿入パフォーマンスよりも低くなります。

#5 コンフィギュレーション - パラメータの迷路の解読

Milvusはオブジェクトストレージ、メッセージキュー、Etcdなど多くのサードパーティ製コンポーネントを統合した分散ベクターデータベースである。ユーザはパラメータを調整し、それがMilvusのパフォーマンスに与える影響を理解することに苦労し、「コンフィギュレーション」は頻繁に議論されるトピックとなった。

コンフィギュレーションに関する質問の中でも、「どのパラメータを調整するか」は、状況によってパラメータが異なるため、間違いなく最も困難な側面である。例えば、検索パフォーマンスパラメーターの最適化は、挿入パフォーマンスパラメーターの最適化とは異なり、実務経験に大きく依存する。

どのパラメータを調整するか」が明確になれば、「どのように調整するか」というその後の問題は、より管理しやすくなります。具体的な手順については、Milvusの設定方法をご参照ください。Milvusはバージョン2.3.0から動的なパラメータ調整に対応しており、変更を反映させるための再起動が不要になったことは大きなニュースである。具体的な手順については、Milvusのオンザフライ設定を参照してください。

#6 ログ - トラブルシューティングのコンパスをナビゲートする

"ログ "はトラブルシューティングコンパスの役割を果たします。Milvusのログのエクスポート、ログレベルの調整、GrafanaのLokiのようなシステムとの統合について、ユーザはコミュニティにガイダンスを求めた。ここでは、Milvusログに関するいくつかの提案を紹介する。

  • Milvusログの表示とエクスポート方法:Milvusのログは、GitHubリポジトリで公開されているexport-milvus-log.shスクリプトをワンクリックで簡単にエクスポートすることができます。

  • ログレベルMilvusは多様なユースケースに対応するため、複数のログレベルを用意しています。ほとんどの場合、infoレベルで十分であり、debugレベルはデバッグ用である。Milvusのログが過剰になる場合は、ログレベルの設定ミスの可能性があります。

  • MilvusのログをLokiのようなログ収集システムと統合することで、将来のトラブルシューティングの際にログの取得を効率化することをお勧めします

#7 クラスタ - 本番環境へのスケーリング

Milvusが分散ベクターデータベースであることから、"クラスタ "という言葉はコミュニティで頻繁に議論されるトピックです。クラスタ内でのデータのスケーリング、データ移行、データのバックアップと同期などが話題の中心です。

本番環境では、堅牢なスケーラビリティと高可用性が分散データベースシステムの標準要件です。Milvusのストレージとコンピュテーションを分離したアーキテクチャは、コンピュテーションノードとストレージノードのリソースを拡張することでシームレスなデータスケーラビリティを実現し、無限のデータスケールに対応します。Milvusはまた、マルチレプリカアーキテクチャと堅牢なバックアップおよび同期機能により、高可用性を提供します。 詳細はCoordinator HAをご参照ください。

#8.ドキュメント - Milvusを理解するための入り口

「ドキュメンテーション」もまた、コミュニティでのディスカッションでよく取り上げられるキーワードのひとつです。

Milvusを理解するための入り口として、コミュニティからの問い合わせの約80%は公式ドキュメントに答えがあります。Milvusを使用する前、または何か問題が発生した際に、ドキュメントを読むことをお勧めします。また、様々なSDKリポジトリにあるコード例からMilvusの使い方を知ることができます。

#9 デプロイメント - Milvusの旅の簡素化

シンプルなデプロイはMilvusチームの継続的な目標です。このコミットメントを達成するために、私たちはMilvus Liteを導入しました。Milvus LiteはMilvusの代替となる軽量な製品で、K8sやDockerに依存しない完全な機能を備えています。

より軽量なNATSメッセージングソリューションを導入し、ノードコンポーネントを統合することで、デプロイメントをさらに合理化しました。ユーザーからのフィードバックに応え、機能の強化とデプロイ操作の簡素化を継続的に行いながら、依存関係のないスタンドアロン版のリリースに向けて準備を進めています。Milvusの迅速な反復は、デプロイメントプロセスの継続的な改良に対するコミュニティの継続的なコミットメントを示しています。

#10 削除 - 影響の解明

削除」に関する一般的な議論は、削除後のデータ数の変化、削除されたデータの継続的な検索可能性、削除後のディスク領域の回復の失敗を中心に展開されます。

milvus2.3では、count(*) 式を導入し、エンティティカウント更新の遅延に対応しています。削除されたデータがクエリで保持されるのは、おそらくデータ一貫性モデルの不適切な使用によるものである。ディスク領域回復失敗の懸念は、Milvusのガベージコレクション機構を再設計するための洞察を促します。このアプローチにより、リカバリのための時間的余裕を確保することができる。

結論

トップ10のキーワードからは、Milvusコミュニティにおける活発な議論を垣間見ることができます。Milvusが進化し続ける中、このコミュニティはソリューションを求める開発者にとって貴重なリソースであり続け、経験を共有し、AI時代のベクターデータベースの発展に貢献しています。

2024年に私たちのDiscordチャンネルに参加して、このエキサイティングな旅に参加してください。そこでは、私たちの優秀なエンジニアと関わり、同じ志を持つMilvus愛好家とつながることができます。また、毎週火曜日の12:00~12:30 PM PSTに開催されるMilvus Community Lunch and Learnにもご参加ください。Milvusを前進させるために、あなたの考え、質問、フィードバックを共有してください。皆様の積極的なご参加を歓迎いたします。一緒にイノベーションを起こしましょう!

Like the article? Spread the word

続けて読む