Senna設計方針

想定する用途

• 多数の著者が頻繁に更新する大規模な文書セットが対象
• 多数のユーザが頻繁に検索サービスを利用
• 検索精度が重視される
• スモールスタート & スケールアウト

求められる要件

• 検索スループット → 大
• 更新スループット → 大
• 文書許容量 → 大
• 適合率 → 高
• 再現率 → 高
• メタ情報 → 柔軟に活用

本質的なトレードオフ

• 検索スループット ←→ 更新スループット
• 適合率 ←→ 再現率
• 文書許容量 ←→ 検索スループット
• 文書許容量 ←→ 更新スループット

方針: 可能な限り高いレベルで両立し、運用時にバランスを調整可能とする。

メタ情報の重要性

メタ情報:

• 書誌情報(著者・表題・著作日時‥)
• ハイパーリンク
• タグ・ブックマーク
• 閲覧履歴
• etc..(アプリケーション毎に様々)

多数の著者によって書かれた文書セットでは、文書の内容は均質ではなく、 本文に対する全文検索の結果だけでは十分な精度が得られない場合が多い。

精度を向上させるために、有効なメタ情報を検索結果の算出に適切に加味させることが必要。 有効なメタ情報は、アプリケーションのドメインに大きく依存する。

本文情報やメタ情報のデータ構造を自由に表現し、 これらを柔軟に組み合わせてクエリを記述できることを目指す。

方針: データ構造とクエリの記述力を重視する。

現時点ではリレーショナルモデルがこの方針に合致する最適なモデルだと考えている。 二つのアプローチでリレーショナルデータベースと全文検索エンジンとの融合を目指す。

• アプローチ1: 既存のDBMSに組み込む
• アプローチ2: 独自のDBMSを作る

方針: それぞれのアプローチに適した異なるレイヤのAPIを、性能を阻害しない形で提供する。

方針: DBMSのクエリ言語に自然な形で全文検索クエリを埋め込めるようにする。

DBMSと検索エンジン間のインピーダンス不整合を抑えることを重視する。 全文検索条件と他の検索条件は自然に組み合わせて記述できることを目指す。 また最適なパスでクエリが実行されることを目指す。

方針: DBMS本体の改造は最小限に留める。インタフェースの改善を開発元に要求する。

DBMSの準備する拡張インタフェースの枠組を越えた無理な改造はなるべく加えない。 機能や性能を阻害している要因をDBMSの開発元に伝えて改善を要求する。

方針: 全文検索エンジンとしてのSennaの基本性能を最大限発揮する。

データモデルの方針

方針: 性能を阻害しない範囲で最大限柔軟性に配慮する。

設計者の想定を越えるような用途を期待する。

従来の全文検索インデックスを更に部品に分解し、 それぞれfirst-class objectとして操作可能とする。

現時点ではビューとして一般化することを考えている。

• 実体化のタイミングを制御可能とする
• インデックスとキャッシュはビューの範疇と考える
• 全文検索インデックスはビューの組み合わせで表現する

アプリケーションインタフェースの方針

方針: アプリケーションのプロセスモデルを選ばない。

様々なプロセスモデルのアプリケーションとの組合せを想定する。 ライブラリ, コマンド, クライアント・サーバ 等のインタフェースで使用できる。 一つのデータベースを複数スレッドand/or複数プロセスで共有可能とする。

クエリ言語の方針

方針: 拡張性の高い言語を利用する

実は現時点ではクエリ言語の仕様は完全には固まっていない。 SQLで十分な可能性も不十分な可能性もあると考えている。 そこで構文やセマンティックスを容易に拡張可能な言語をベースとして用いる。 現状では、Scheme上の埋め込み言語としてクエリー言語を実装する。

方針: 簡潔な記述を目指す

実用的で簡潔にクエリーを書き下させるように配慮する。

方針: Scheme言語処理系としての完成度を追求しない。

クエリ言語はScheme上に構築されているが、 Schemeそのものがクエリ言語というわけではない。 Schemeは専らグルー(糊)として機能する。 宣言的に記述されたクエリを、Senna API実行シーケンスに翻訳する処理に活用するが、 検索処理の主要なループの中でSchemeのコードが動くことは想定しない。

独自DBMSはScheme言語処理系を内包するが、 その汎用プログラミング言語としての完成度は追求しない。 代わりに以下のポイントを重視する。

• 起動の速さ
• footprintの小ささ
• C関数の呼出しコストの小ささ