アプリケーションがコレクションを作成する際にシャードとレプリカの数を指定した場合、それが何を要求したのかはわかるはずです。

完全な schema.xml をアップロードする簡単な方法があると便利な場合もあるという点には同意しますが、それを実装するのは簡単ではないかもしれません。一方で、schema.xml を一連の curl コマンドに変換するスクリプトを書くことは簡単です。

Dima

これは別の問題ですが、アプリケーション開発者の視点から言えば、そのような情報（シャードやレプリカの数など）を指定する必要があるとは思えません。それはSolrサーバーの管理者が決めるべきことのように思えます。

何か明らかな点を見落としていない限り、それはそれほど簡単なことではないように思えます。なぜなら、理論的には、最初のスキーマの内容を私は知らない可能性があるからです。というのも、私は既存のSolrサーバーに隣接してインストールされるアプリケーションであり、それらのデフォルトの設定が何であるかはわからないからです。

スキーマを完全にゼロにして、タイプやフィールドを追加し、自分が明示的に追加したタイプやフィールドだけが存在することを確実にするための明らかな方法はあるのでしょうか？

--
Mark Raynsford | https://www.io7m.com

ConfigSet APIはコンフィグセットを管理するためのものです。スタンドアロンモードでコンフィグセットを使用する方法もありますが、SolrCloudが推奨されています。

コンフィグセットには solrconfig.xml、managed-schema.xml（クラシックスキーマファクトリを使用している場合は schema.xml）、およびそれらの2つの設定ファイルで参照されるその他のファイルが含まれます。スキーマだけをアップロードすることはできず、solrconfig も必要です。

リンク

ZK（ZooKeeper）に保存されている各コンフィグセットには名前があり、その名前はコレクションを作成する際に使用されます。既存のコレクションは異なるコンフィグ名を使用するように変更でき、コレクションをリロードすると変更が有効になります。

別のスレッドでの質問に答えると、SolrCloudがSolrを実行するための推奨方法です。次のメジャーバージョンでは、Solrがクラウドモードでのみ動作する可能性があっても驚きません。Solrの一部の高度な機能はクラウドモードでのみ動作します。

冗長性やレプリカが必要ない単純なシングルノードでの非ミッションクリティカルな状況では、埋め込みZKを使ってSolrを実行することができます。私もこの方法で動作するSolrのインストールがあります。しかし、もし高可用性や複数のレプリカが必要なら、この方法は推奨されません。

ありがとう、
Shawn

ありがとうございます。私の理解では、アプリケーションは既存のConfigSetの名前を受け取り、そのConfigSetをダウンロードし、スキーマを自分のものに置き換えてから、新しいスキーマに基づいた新しいConfigSetを作成するということになります。そして、その新しいConfigSetを参照するコレクションを作成するという流れで合っていますか？

私たちのケースでは、一度作成されたスキーマは不変として扱います。もしスキーマを変更する必要がある場合は、変更されたスキーマで新しいコレクションを作成し、古いコレクションの内容を再インデックス化します。

理解しました。

--
Mark Raynsford | https://www.io7m.com