スキーマの作成とデータ・モデリング

DSE Searchスキーマは、テーブルとDSE Search Solrコア内のデータ間の関係を定義します。スキーマは、Solrでインデックスを作成するためにカラムを識別し、カラム名をSolr型にマッピングします。

Solrスキーマは、テーブルとSolrコア内のデータ間の関係を定義します。スキーマは、Solrでインデックスを作成するためにカラムを識別し、カラム名をSolr型にマッピングします。Solrスキーマ設定とオプションの詳細については、「Solr wiki」を参照してください。

テーブルとスキーマの定義

CQLテーブルは、Solrコアを作成する前にCassandra内に作成する必要があります。DSE Searchは、スキーマのフィールドとユニーク・キーの仕様をCassandraの主なコンポーネントにマップし、Solr用の合成ユニーク・キーを生成します。たとえば、以下は基本チュートリアルから抜粋したものです。

CREATE TABLE nhanes (
"id" INT,
"num_smokers" INT,
"age" INT,
  . . .
PRIMARY KEY ("id", "age")
);
<schema name="solr_quickstart" version="1.1">
<types>
 . . .
<fields>
<field name="id" type="int" indexed="true"  stored="true"/>
<field name="num_smokers" type="int" indexed="true"  stored="true"/>
<field name="age" type="int" indexed="true"  stored="true"/>
 . . .
<uniqueKey>(id,age)</uniqueKey>
 . . .

スキーマにはユニーク・キーが必要です。ユニーク・キーは、SQLでのプライマリ・キーと似ています。スキーマのユニーク・キーは、クラスターの各ノードにドキュメントを送るために使用するCassandraプライマリ・キーにマップされます。

indexed="true"のフィールドにはインデックスが作成され、フィールドが検索可能になるようにLuceneでセカンダリ・ファイルとして格納されます。インデックスが作成されたフィールドは、stored属性値に関係なく、LuceneではなくCassandraに格納されます。ただし、コピー・フィールドは除きます。コピー先フィールドはCassandraには格納されません。
  • indexed="false"のフィールドをCassandraに格納し、フィールドが検索クエリーで返されるようにするには、stored="true"を設定します。
  • フィールドを無視するには、indexed="false"stored="false"の両方を設定します。
  • 検索を有効にするが、値を返さないようにする(たとえば、ユーザーをパスポート番号で見つけてユーザーを表示しても、パスポート番号は表示しないようにする)には、indexed="true"stored="false"を設定します。
  • 検索を有効にし、値を返すには、indexed="true"stored="true"の両方を設定します。

ユニーク・キーの定義

DataStax Enterpriseでは、Solrクエリー結合の例で示すように、単純または複合プライマリ・キーおよび複合パーティション・キーを使用しているCQLテーブルをサポートしています。

サンプル・スキーマ

CQLコレクション・セットのクエリーからの以下の例では、単純なプライマリ・キーを使用しています。
<schema name="my_search_demo" version="1.5">
<types>
<fieldType class="solr.StrField" multiValued="true" name="StrCollectionField"/>
<fieldType name="string" class="solr.StrField"/>
<fieldType name="text" class="solr.TextField"/>
<fieldType class="solr.TextField" name="textcollection" multiValued="true">
<analyzer>
<tokenizer class="solr.StandardTokenizerFactory"/>
</analyzer>
</fieldType>
</types>
<fields>
<field name="id"  type="string" indexed="true"  stored="true"/>
<field name="quotes"  type="textcollection" indexed="true"  stored="true"/>
<field name="name"  type="text" indexed="true"  stored="true"/>
<field name="title" type="text" indexed="true" stored="true"/>
</fields>
<defaultSearchField>quotes</defaultSearchField>
<uniqueKey>id</uniqueKey>
</schema>

DSE Searchは、ID、引用、名前、およびタイトルの各フィールドのインデックスを作成します。

CQLプライマリ・キーとSolrユニーク・キーのマッピング

フィールドがCassandraの複合プライマリ・キーまたは複合パーティション・キーのカラムの場合、Solrスキーマではユニーク・キーを丸かっこで囲む必要があります。そのようなテーブルのスキーマには、単純なプライマリ・キーとは異なる構文が必要です。
  • SolrスキーマのCQLテーブルにフィールドとして現れる各複合プライマリ・キー・カラムを、他のカラムと同様にリストします。
  • 丸かっこで囲まれているキー・カラムを使用してユニーク・キーを宣言します。
  • CQLテーブルで順序が指定されるキーと同様に、uniqueKey要素内のキーの順序を指定します。
  • 複合パーティション・キーを使用する場合は、Solr uniqueKeyに余分な丸かっこの組を含めないでください。
    Cassandraパーティション・キー CQL構文 Solr uniqueKey構文
    単純なCQLプライマリ・キー CREATE TABLE ( . . . a <type> PRIMARY KEY, . . . );

    (aはパーティション・キーとプライマリ・キーの両方です)

    <uniqueKey>a</uniqueKey>
    注: 単一キーの場合、丸かっこは必要ありません。
    複合プライマリ・キー

    基本チュートリアルには、CQL複合プライマリ・キーを使用するCassandraテーブルのスキーマが含まれています。

    CREATE TABLE ( . . . PRIMARY KEY ( a, b, c ) );

    (a はパーティション・キーで、 a b cはプライマリ・キーです)

    <uniqueKey>(a, b, c)</uniqueKey>
    複合パーティション・キー CREATE TABLE ( . . . PRIMARY KEY ( ( a, b), c );

    (a b はパーティション・キーで、 a b cはプライマリ・キーです)

    <uniqueKey>(a, b, c)</uniqueKey>

結合を使用していない場合にパーティション・キーをオーバーライドする

特殊なパーティション・キーフィールドは、結合に対して内部で使用されます。結合を使用する予定がない場合は、schema.xmlファイル内のこのフィールド宣言をdocValuesおよびindexedプロパティに対してのみオーバーライドできます。
<field name="_partitionKey" type="string" indexed="false"/>
ドック値を無効にするには、docValues="false"を追加します。
<fieldname="_partitionKey" type="string" docValues="false"/>

スキーマの変更

Solrスキーマを変更した場合は、Solrコアを再度読み込む必要があります。インデックスを再作成すると、混乱を引き起こす可能性があります。パフォーマンスの低下はインデックスの再作成によって発生します。スキーマは絶対に必要な場合のみに変更し、スケジュールされたダウンタイム中にインデックスを再作成するように計画します。