スキーマデザイナー

スキーマデザイナー画面では、サンプルデータを使用して新しいスキーマをインタラクティブに設計できます。

図 1. スキーマデザイナー画面

スキーマデザイナー画面には、スキーマに変更を加えたときに即座にフィードバックを提供する多くのパネルがあります。たとえば、

サンプルドキュメントをアップロード/貼り付けて、フィールドを検索し、正しいフィールドタイプとインデックス作成戦略を推測します。
フィールド、動的フィールド、フィールドタイプ、およびサポートファイルを編集するためのスキーマエディターツリー
選択したフィールドに基づいてサンプルテキストのテキスト分析パイプラインを表示するテキスト分析パネル
スキーマの変更がクエリのマッチング、ソート、ファセット、およびヒットハイライトにどのように影響するかを確認するためのクエリテスターパネル
公開する前にデザイナーが行ったすべての変更のレポートを表示するための変更の表示ダイアログ

スキーマデザイナーでは既存のスキーマを編集できますが、主な目的は、サンプルデータから新しいスキーマを安全に設計するのに役立つことです。変更を安全に試して、クエリ結果への影響をすぐに確認できます。公開されたスキーマを使用してデータがインデックス化されると、スキーマに加えることができる変更の種類には、完全な再インデックス作成が必要になるまで、重大な制限があります。新しいスキーマを設計する場合、スキーマデザイナーは変更を加えるとサンプルデータを自動的に再インデックス化します。ただし、デザイナーは公開されたスキーマを使用するコレクション内のデータを再インデックス化しません。

認可要件

Solr インストールでルールベースの認可プラグインが有効になっている場合、ユーザーはスキーマデザイナーを使用するために config-edit および config-read アクセス許可を持っている必要があります。

はじめに

スキーマデザイナーに初めて入ると、新しいスキーマを作成するように求められます。

新しいスキーマの意図されたユースケースを反映する短い名前を選択します。新しいスキーマの開始点としてコピーするソーススキーマを選択する必要があります。Solr には、検索アプリケーションのカスタムスキーマを作成するのに適した開始点となる _default スキーマが含まれています。スキーマが公開されると、新しいスキーマの作成に使用でき、ダイアログの [コピー元] ドロップダウンリストに表示されます。

新しいスキーマを作成したら、次のステップは、Solr にインデックスを作成する予定のデータのサンプルをアップロードまたは貼り付けることです。スキーマデザイナーは、JSON、CSV、TSV、XML、および JSON 行（jsonl）をサポートしています。

サンプルドキュメントをテキスト領域に貼り付ける利点は、サンプルを編集して、分析されたスキーマでの変更の影響をすぐに確認できることです。アップロード機能は、多数のサンプルドキュメントがある場合に便利です。スキーマデザイナー API では、最大 1,000 個のサンプルドキュメントまたは最大 5MB のアップロードが可能ですが、ほとんどの場合、開始するには少数のドキュメントのみが必要です。

ドキュメントを分析ボタンをクリックして、サンプルドキュメントをスキーマデザイナー API に送信して、新しいスキーマを生成します。

一時的な Configset とコレクション

舞台裏では、Schema Designer API は、一時的なConfigsets（スキーマ + solrconfig.xml + サポートファイル）を Zookeeper に作成します。さらに、Schema Designer API は、サンプルドキュメントを保持するための一つのシャードとレプリカを持つ一時的なコレクションを作成します。これらのリソースはディスクに永続化され、スキーマが公開されるか、Schema Designer API のクリーンアップエンドポイント（/api/schema-designer/cleanup）を使用して手動で削除されるまで存在します。

新しいスキーマを設計中にブラウザ画面を閉じても、再度アクセスしたときに利用可能です。以前に作成したスキーマの名前をセレクトボックスで選択するだけで、スキーマがデザイナーUIにロードされます。

テキストエリアには表示されませんが、以前にアップロードされたサンプルドキュメントは一時的なコレクションにインデックスされます。

インデックスされたドキュメントのJSON表現をテキストエリアにロードするには、クエリ結果パネルのドキュメントを編集ボタンをクリックします。

信頼されたConfigSets

solrconfig.xmlから追加のライブラリをロードしたり、Solrの特定機能を使用したりする場合は、ConfigSetの信頼が必要です。信頼されたConfigSetの詳細については、ConfigSet APIセクションを参照してください。

Schema Designer APIを使用することは、ConfigSetアップロードAPIを使用するのと同じ効果がConfigSetの信頼にあります。

認証されている場合
- 元のConfigSetが信頼されている場合、変更中のConfigSetも信頼されたままになります。
- 元のConfigSetが信頼されていない場合、変更中のConfigSetは決して信頼されません。
認証されていない場合
- 作成された一時的なConfigSetは信頼されません。

一時的なConfigSetを公開する際、一時的なConfigSetの信頼が、永続的なConfigSetの信頼を設定するために使用されます。

サンプルドキュメントの反復的な投稿

複数のファイルにサンプルドキュメントが分散している場合は、Schema Designer APIにPOSTし、デザイナーUIでスキーマをロードしてスキーマを設計できます。APIを使用して新しいスキーマを「準備」し、SolrのtechproductsのサンプルファイルをSchema Designerバックエンドに反復的に投稿する方法の例を以下に示します。

#!/bin/bash

SOLR_INSTALL_DIR="path/to/solr/install"

DIR_WITH_SAMPLE_FILES="$SOLR_INSTALL_DIR/example/exampledocs"

SOLR_URL=https://127.0.0.1:8983

MY_NEW_SCHEMA="myNewSchema"

echo "Preparing new schema: ${MY_NEW_SCHEMA}"
curl -s -o /dev/null -w "%{http_code}" -XPOST \
  "$SOLR_URL/api/schema-designer/prep?configSet=${MY_NEW_SCHEMA}&copyFrom=_default"
echo ""

SAMPLE_FILES=( $(ls ${DIR_WITH_SAMPLE_FILES}/*.{xml,csv,json,jsonl}) )
for f in "${SAMPLE_FILES[@]}"
do
  echo "POST'ing contents of $f to Schema Designer analyze endpoint ..."
  curl -s -o /dev/null -w "%{http_code}" -XPOST \
    "$SOLR_URL/api/schema-designer/analyze?configSet=${MY_NEW_SCHEMA}" -d @"$f"
  echo ""
done

サンプルドキュメントをSchema Designerバックエンドに送信した後、ブラウザのSchema Designer画面で準備されたスキーマを開くことができます。

Schema Designer APIは、主に開発者がプログラム的に使用するのではなく、UIでのインタラクティブなエクスペリエンスをサポートすることを目的としています。Configsetとスキーマをプログラムで作成および管理するには、Configsets APIおよびSchema APIのセクションを参照してください。

スキーマエディタ

サンプルドキュメントを分析した後、Schema Designerは中央パネルのスキーマエディタにスキーマをロードします。エディタは、フィールド、動的フィールド、フィールドタイプ、およびファイルで構成されるツリーコンポーネントとしてスキーマをレンダリングします。スキーマオブジェクトの詳細については、フィールドを参照してください。

スキーマ vs. Configset

Configsetにはスキーマが含まれているため、技術的にはSchema Designerは舞台裏でConfigsetを操作します。ただし、Configsetは技術的な実装の詳細であり、新しい検索アプリケーションを設計する際に主に焦点を当てるべきは、フィールドとそれらのタイプです。したがって、Schema Designerは、UIでConfigsetの複雑さを公開するのではなく、Configsetのスキーマの側面に主に焦点を当てています。

スキーマエディタツリーのルートノードをクリックすると、以下を含むトップレベルのスキーマプロパティを絞り込むことができます。

言語: _defaultスキーマには、多くの一般的な言語のテキストフィールドが含まれています。スキーマにすべてのテキストアナライザーを含めるか、検索アプリケーションがサポートする必要がある言語に基づいてサブセットを選択できます。デザイナーは、不要な言語のすべてのフィールドタイプを削除します。テキスト分析と言語の詳細については、言語分析を参照してください。
動的フィールドを使用すると、Solrはスキーマで明示的に定義していないフィールドをインデックス化できます。動的フィールドは、Solrに追加できるドキュメントにある程度の柔軟性を提供することで、アプリケーションの脆弱性を軽減できます。スキーマの動的フィールドのデフォルトセットを有効にしておくことをお勧めします。このオプションをオフにすると、スキーマからすべての動的フィールドが削除されます。動的フィールドの詳細については、動的フィールドを参照してください。
フィールド推測（別名「スキーマレスモード」）を使用すると、Solrはインデックス作成中に検出された不明なフィールドに「最適な」フィールドタイプを検出できます。フィールド推測では、フィールド名からスペースを削除するなど、いくつかのフィールド変換も実行します。スキーマデザイナーを使用してサンプルドキュメントに基づいてスキーマを作成する場合は、この機能を有効にする必要がない場合があります。ただし、この機能が無効になっていると、入力データがスキーマと完全に一致していることを確認するか、インデックス作成エラーが発生する可能性があります。スキーマレスモードの詳細については、スキーマレスモードを参照してください。
この機能を有効にすると、スキーマにrootおよびnest_pathフィールドが追加されます。ネストされた子ドキュメントのインデックス作成の詳細については、ネストされたドキュメントのインデックス作成を参照してください。

検索アプリケーションの動作にどのように影響するかを完全に理解している場合にのみ、これらのトップレベルのスキーマプロパティを変更してください。最初は、デフォルト設定のままにして、スキーマのフィールドとフィールドタイプに注意を集中できます。

スキーマフィールド

エディタツリーのフィールドノードをクリックすると、スキーマ内のフィールドの概要と、Solrによるフィールドのインデックス方法を制御するプロパティが表示されます。

スキーマに多数のフィールドがある場合は、ツリーの上部にあるフィルターを使用して、タイプまたは機能で表示されるフィールドをフィルタリングできます。たとえば、docValuesが有効になっているフィールドをフィルタリングするには、featureを選択し、docValuesを選択してenabledをオンにします。

フィールドを編集するには、ツリー内のフィールドの名前をクリックして、ツリーの右側にあるメインエディタパネルにフィールド情報をロードします。

特定のフィールドのプロパティを変更する前に、代わりにフィールドタイプのプロパティを変更する必要があるかどうかを検討してください。フィールドタイプに適用された変更は、そのタイプを使用するすべてのフィールドに適用されるためです。

必要な変更を加えたら、フィールドを更新ボタンをクリックします。Schema DesignerバックエンドAPIは、変更をスキーマに適用し、必要に応じてサンプルドキュメントを一時的なコレクションに再インデックス化します。単一値のdocValuesフィールドを多値に変更するなど、一部の変更では、基になるLuceneインデックスを削除して最初から再構築する必要がある場合があります。変更に完全な再構築が必要な場合は、Schema Designerが警告します。

さらに、サンプルデータに基づいてフィールドを互換性のないタイプに変更すると、デザイナーは変更を自動的に元に戻します。たとえば、テキストデータを持つフィールドを数値タイプに変更すると、デザイナーによって拒否されます。

インデックスされたデータを持つコレクションですでに使用されているスキーマのフィールドプロパティを変更する場合は注意が必要です。デザイナーは、使用中のスキーマに対して互換性のない変更を行うのを防ぐことはできません。通常、新しいフィールドとフィールドタイプを追加するのは、既存のスキーマにとって安全な操作です。フィールドやフィールドタイプのプロパティを変更すると、インデックスが破損する可能性があります。

Schema Designerは、スキーマからのフィールドの削除をサポートしていません。

テキスト分析

ツリーでテキストベースのフィールドを選択すると、テキスト分析パネルに、サンプルドキュメントからのテキストがインデックス作成のためにどのように分析されるかが表示されます。

フィールドのテキスト分析戦略を変更する必要がある場合は、フィールドタイプを編集する必要があります。テキスト分析の詳細については、アナライザーを参照してください。

クエリテスター

クエリテスターパネルでは、現在のスキーマを使用してサンプルドキュメントセットに対して実行されたクエリを試すことができます。

クエリテスターを使用すると、一致、ソート、ファセット、ハイライトなど、スキーマへの変更がクエリの動作にどのように影響するかを確認できます。クエリテスターフォームは、Solrで利用可能なすべての可能なクエリ機能を実証することを目的としたものではありません。

スキーマに変更を加えるたびに、クエリ結果を更新するためにクエリテスターフォームが再送信されます。これにより、テストクエリがサンプルドキュメントを検出する必要があるにもかかわらず正しい結果が返されない、つまり、テキスト分析されたフィールドタイプではなくstringを使用するなど、フィールドが正しくインデックスされていない場合に、マッチングの問題について知ることができます。

マッチングの問題は、キャッチオール_text_フィールドなど、フィールドがデフォルトの検索フィールドにコピーされなかったことを示している可能性もあります。

クエリテスターフォームには、並べ替えドロップダウンで並べ替えをサポートするすべてのフィールドがリストされます。並べ替える必要のあるフィールドがリストされていない場合は、単一値であり、インデックスが作成されているか、docValuesが有効になっていることを確認してください。

同様に、テスターフォームには、ファセットを計算できるすべてのフィールドがリストされます。フィールドがファセットドロップダウンにリストされていない場合は、インデックスが作成されているか、docValuesが有効になっていることを確認してください。

変更を表示

変更を表示ボタンをクリックして、現在の編集セッション中にスキーマに加えられた変更のレポートを表示します。公開されていない変更は、コピー元の元のスキーマ（_defaultなど）または公開されたスキーマと比較されます。

スキーマを使用してインデックスされたデータを持つコレクションがある場合、既に公開されているスキーマを変更する際には注意が必要です。

公開

新しいスキーマを公開すると、新しいコレクションを作成する際に利用できるようになります。公開ダイアログには、公開操作によって既存のコレクションに影響があるかどうかが表示されます。もちろん、新しいスキーマの場合、影響を受けるコレクションはありません。また、公開中に新しいスキーマを使用する新しいコレクションを作成し、新しいコレクションにサンプルドキュメントをインデックスするかどうかを選択することもできます。

スキーマデザイナーによるこのスキーマへの将来の変更を禁止することもできます。ただし、この設定はスキーマデザイナーのUIにのみ適用され、Schema APIを直接使用してスキーマを変更することを妨げるものではありません。

公開操作が完了すると、一時的なConfigsetとコレクションが削除され、スキーマデザイナーのUIは新しい状態にリセットされます。

あるいは、Zookeeperに公開する代わりに、スキーマ、solrconfig.xml、およびサポートファイルを含むzipファイルにConfigsetをダウンロードすることもできます。このzipファイルは、Configsets APIを使用して他のSolrインスタンスにアップロードしたり、バージョン管理に保存したりできます。