インデックス

DocStoreインデックスは、コレクションと同じ場所の.storh/indexesに保存されます。通常のファイルで、レコードだけから生成され、いつでも再構築できます。メソッドチェーンまたはschemaから宣言できます。

$docs->indexes()
    ->field('slug')->unique()
    ->field('kind')
    ->field('publishedAt')->range()
    ->sync();

インデックスの種類：

• kindやstatusのようなフィールド向けの等価インデックス：異なる値ごとにファイルを1つ使うため、特定の値を検索するときは一致する値のファイルだけを読み取ります
• slugのようなフィールド向けのユニークインデックス：書き込み時に一意性を検証し、重複値があると、何も書き込む前にput()が失敗します
• スカラー値向けの範囲インデックス：スパースなシーク用チェックポイントを備えたソート済みファイルで、gt、gte、lt、lte、between、prefixに対応します

範囲インデックスは、同じフィールドに対するorderByにも対応できます。limitを使い、結果全体をメモリに展開してソートすることなく、インデックス順の昇順または降順で結果を返します。

クエリで一意でない等価インデックス付きフィールドに対するeq条件を2つ組み合わせると、storhはそのフィールドの組み合わせに自動複合バケットを使用できます。これにより、別のインデックス宣言を追加しなくても、選択性の高い2フィールドの絞り込みを高速に保てます。

一貫性と修復

レコードファイルをアトミックに置き換えた後、コレクションの書き込みロック下でインデックス項目を更新するため、レコードとインデックスは一緒に切り替わります。verify()は各インデックスを全レコードのスキャン結果と照合して不整合を報告します。reindex()は設定済みの全インデックスをレコードファイルから再構築します。repair()は破損したレコードを隔離してから再構築します。

$docs->reindex();

$plan = $docs
    ->query()
    ->where('slug')->eq('home')
    ->explain();

クエリプランナーが設定済みのインデックスを使える場合、explain()はindex_scanを返し、使えない場合はfull_scanを返します。