以前、「1つのデータベースに対し10,000個のレンジインデックスを作れるか」という議論がありました。
このような課題に直面したとき、もともとの課題はなにかと立ち戻って考える事が重要です。
当時の状況としては約1,000エンティティが存在しており、1エンティティ当たり10フィールド分のインデックスが必要だろうという推測のもと、
10,000レンジインデックスという数が出てきていました。
結論から申し上げると、マークロジックでは10,000(ないしは数百)レンジインデックスを作るのはお勧めしません。
ユニバーサルインデックス
まず始めに考えるべき事は、本当に10,000フィールド(またはエレメント)分のレンジインデックスが必要かということです。
実はマークロジックにデフォルトで存在するユニバーサルインデックスで事足りている可能性があります。
ユニバーサルインデックスにより、取り込んだドキュメントに対する全文検索や特定のセクションに対する検索が可能なため、
多くの場合で特定のインデックスを高速アクセスのために設定するという作業は必要ありません。
レンジインデックス
ユニバーサルインデックスは高速検索を可能とします。
ではいつレンジインデックスが必要となるのでしょうか？検索ケースとしては、データ型固有の範囲検索などの不等価演算
(例えば「2012年1月1日以降に掲載された記事を検索」)があります。
掲載日に日付型のレンジインデックスを使用すると、何々以上などという範囲検索が可能となります。
また、レンジインデックスは値のリスト取得や、ファセット作成などにも活用できます。
詳しくはインサイドMarkLogicサーバーをご参照ください。
一般的なアプリケーションでは、ドキュメントの複数あるいは全フィールドに対する検索は必要ですが、大量の不等価演算や
ファセットが必要となることはありません。
つまり大概のアプリケーションでは、ほとんどの検索をユニバーサルインデックスで行い、少量のレンジインデックスを補足的に利用するということになります。
フィールド機能
マークロジックにおいて、フィールド機能とは複数エレメントに同一名でアクセスするために使用します。
複数の異なるデータソースからデータ統合する場合、名前の異なる複数エレメントを同じ名前で参照したいことがあります。
例えば、２つの本に関するデータベースがあったとし、片方では”published-date”、他方では”pub-date”と同じ内容のエレメントに複数の名前があったとしましょう。
初見では、２つの異なる型のデータのようにみえ、別々のレンジインデックスを使いたくなるかもしれません。
しかしながらマークロジックのフィールド機能を使うことで、一つの名前で複数エレメントにアクセスできるようになるため、インデックスの数を減らすという活用もできます。
トリプル
どうしても様々なフィールドに対して横断検索をしたいといったことがあるかもしれません。
極端な例とはなりますが、マークロジックではトリプルデータを保持できるため、SPARQLのFILTER機能やcts:triples()ファンクションで不等価検索も可能です。
10,000レンジインデックスはダメなのか？
10,000レンジインデックスの代替案を考える前に、まずは当初の質問に戻ってみましょう。
答えはNOとなります。指標としてレンジインデックス数は最大でも100個とすべきです。
むしろほとんどのアプリケーションではそれ以下であるべきです。
レンジインデックスは必ずメモリ上にロードされるため、サーバ起動時間が長くなったり、メモリ枯渇の原因になる可能性があります。
また、各フォレストごとに関連するデータのインデックスを保持します。
更にフォレストは、1つかそれ以上のスタンドという単位に分解できます。
各スタンドはインデックスごとに2つ存在するメモリマップされたファイルを管理します。
通常1ホストあたり12フォレスト(6マスター、6レプリカ)と約100スタンド程度が存在します。
従って10,000レンジインデックスでは数百万のファイルを扱わないといけないことになってしまうでしょう。
まとめ
もし数百数千のレンジインデックスを作成しようとしている場合、もう一度データがどう扱われるか考え直してみてください。
きっとユニバーサルインデックスのみで事足りるケースが多い事に気づくと思います。
そしてユニバーサルインデックスで足りない場合は、フィールド機能やトリプル検索なども考えてみてください。
