Indexen

DocStore-indexen worden naast de collectie opgeslagen onder .storh/indexes. Het zijn gewone bestanden die volledig uit de records zijn afgeleid en op elk moment opnieuw kunnen worden opgebouwd. Definieer ze fluently of via een schema:

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

Indextypen:

• gelijkheidsindexen voor velden zoals kind of status: één bestand per unieke waarde, zodat een puntzoekopdracht alleen het bestand met de overeenkomende waarde hoeft te lezen
• unieke indexen voor velden zoals slug: ze worden tijdens het schrijven afgedwongen; een dubbele waarde veroorzaakt een fout bij put() voordat er iets wordt geschreven
• bereikindexen voor scalaire waarden: een gesorteerd bestand met sparse seek-checkpoints, voor gt, gte, lt, lte, between en prefix

Bereikindexen kunnen ook orderBy op hetzelfde veld beantwoorden met een limit, rechtstreeks op basis van de indexvolgorde, oplopend of aflopend, zonder het volledige resultaat in het geheugen op te bouwen en te sorteren.

Wanneer een query twee eq-predicaten combineert op velden met een niet-unieke gelijkheidsindex, kan storh automatisch een samengestelde bucket voor dat veldpaar gebruiken. Zo blijven selectieve filters op twee velden snel zonder dat u een extra index hoeft te definiëren.

Consistentie en herstel

Schrijfbewerkingen werken indexvermeldingen bij nadat het recordbestand atomair is vervangen, onder het schrijfslot van de collectie, zodat records en indexen samen worden bijgewerkt. verify() vergelijkt elke index met een volledige scan van de records en rapporteert afwijkingen; reindex() bouwt elke geconfigureerde index opnieuw op uit de recordbestanden; repair() zet beschadigde records in quarantaine en bouwt de indexen vervolgens opnieuw op.

$docs->reindex();

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

explain() retourneert index_scan wanneer de planner een geconfigureerde index kan gebruiken, en anders full_scan.