クラスタ構成のQdrantでsnapshotを作成/復元する
クラスタ構成のQdrantでsnapshotを復元する際のめも
前提
[重要] Qdrantはクラスタ構成であること。
面倒なことにQdrantは1ノードの構成なのかクラスタ構成なのかでsnapshotの復元方法が異なる。
環境
手順
collection作成~point追加
これを使ってamazon_reviewというcollectionを作成 HuggingFaceのデータセットからamazonのレビューを取得して5000件ほどembeddingして追加。
data downloadとかembeddingに少し時間かかるので、自分で適当なcollectionとpointを作成したほうが早い。
snapshot作成
POST collections/amazon_review/snapshots
デフォルトでsnapshotのディレクトリは./snapshotsになっている。
コンテナの中に入って確認したらこんな感じ。
root@3396583d4622:/qdrant# ls -lh snapshots/amazon_review/ total 73M -rw-r--r-- 1 root root 73M Aug 26 07:52 amazon_review-8556042130106098-2023-08-26-07-52-28.snapshot
snapshotが作成されていることが確認できたので、collectionを削除。
DELETE collections/amazon_review
snapshot復元
snapshotの復元方法は二つあるがクラスタ構成の場合はAPIを使って復元する方法一択になる。
まずcollectionを作成する。
PUT collections/amazon_review
{
"vectors": {
"size": 768,
"distance": "Cosine"
}
}
次にsnapshotを復元する。
PUT /collections/amazon_review/snapshots/recover
{
"location": "http://qdrant_primary:6333/collections/amazon_review/snapshots/amazon_review-8556042130106098-2023-08-26-07-32-20.snapshot"
}
ポイントはsnapshot復元前にcollectionを作成しておくこと。そして作成時にvectorsのsizeはsnapshotのものに揃えておくこと。 ここが間違っているとエラーになる。
collectionを作成せずにrecoverすると以下のエラーが返ってくる。
{
"error": "Wrong input: Failed to download snapshot from http://qdrant_primary:6333/collections/amazon_review/snapshots/amazon_review-8556042130106098-2023-08-26-07-52-28.snapshot: status - 404 Not Found"
}
download snapshot でエラーが発生してstatus 404なのでlocationが間違っているように見えるが、単純にcollectionがないだけである。
そしてややこしいことに、本当にsnapshotが存在しない場合も
PUT /collections/amazon_review/snapshots/recover
{
"location": "http://qdrant_primary:6333/collections/amazon_review/snapshots/hogehogehoge.snapshot"
}
同様のエラーが返ってくる...
{
"error": "Wrong input: Failed to download snapshot from http://qdrant_primary:6333/collections/amazon_review/snapshots/hogehogehoge.snapshot: status - 404 Not Found"
}
collectionがないことに気づかず無駄な時間を使ったのでこのエラーが出た場合は注意.
参考
docker composeでqdrantのクラスタ構成を構築する
ベクトル検索エンジンのqdrantをdocker-composeを使ってクラスタ構築した際のメモ。
結論
composeファイルはこんな感じ。
version: "3.9" services: qdrant_primary: image: "qdrant/qdrant:v1.4.1" ports: - "6333:6333" environment: QDRANT__CLUSTER__ENABLED: "true" command: [ "./qdrant", "--uri", "http://qdrant_primary:6335" ] qdrant_secondary: image: "qdrant/qdrant:v1.4.1" environment: QDRANT__CLUSTER__ENABLED: "true" command: [ "./qdrant", "--bootstrap", "http://qdrant_primary:6335" ]
説明
環境変数を使う場合は、QDRANT__CLUSTER__ENABLED をTrueにする。
qdrantでクラスタ構築する場合は、config.ymlか環境変数でクラスタモードを指定する必要がある。
今回はお手軽に環境変数で指定する。
ノード間での内部通信ができるようにする
qdrantではデフォルトで内部通信にport 6335が使われる。 クラスタ管理する際はすべてノードがこのportで通信できるようにしておく必要がある。
またクラスタ内の全ノードと連携するために、二つ目以降のノードはいずれかの一つのノードを知っておく必要がある。なので、最初のノードが自身のURLを提供するようにしておく。
このあたりの設定はCLIでserver起動する際の引数で指定する。
今回使うのは --uriと--bootstrapの二つ。
--uriでノードのURIを指定する。このURIは他のノードが到達できるようにしておく必要がある。
--bootsrapで--uriで指定された既存のノードのURIを指定する。
問題
100%再現していないけど、docker imageのv1.4.1を使うと稀にqdrant_secondaryのほうでleader is not established within 10 secsというエラー(panic)が発生して、qdrant_secondaryがクラスタに追加されなかった。
他にも、collectionを作成しようとするとqdrant_primaryのほうでleader is not establishedが発生して安定しない時期があった。
v1.4.0を使うと発生しなくなり、その後v1.4.1に戻してからは発生していない。
自分の環境の問題な気がするけど問題の切り分けができてない。
参考
max clause countの動的生成ロジック
背景
Elasticsearch8.0から indices.query.bool.max_clause_countがdeprercatedになりました。
これまで自分で設定できていましたが、動的に設定されるようになったということでどういうロジックで値が決まるのかコードを参照しながら確認します。
max clause countが何かについてはこちらの記事を確認ください。
続きを読む