Storh

Fájlalapú rekordok a PHP számára: JSONC dokumentumok, csak hozzáfűzhető szegmentált naplók és naplóalapú várólisták UUIDv7 azonosítókkal.

Terminál

composer require storh/storh

Kezdés

GitHub

Legújabb kiadás v0.5.2 2026-09-24 MIT PHP 8.2+

PHP

$pages = $docs
    ->query()
    ->where('kind')->eq('page')
    ->orderBy('title')
    ->limit(20)
    ->get();

A gyakorlatban

A két részből álló gyors kezdés: egy dokumentum a tárolási gyökérben, majd egy naplóbejegyzés és egy várólistafeladat mellette.

Egy gyökér, három motor

Az StorageRoot::resolve() egyesíti az alapkönyvtárat és a névteret egy gyökérben, és minden motor az első használatkor létrehozza alatta a saját könyvtárát.

Minden motor StorageRecord objektumokat ad vissza id() és data() értékekkel. A várólista minden igényt és befejezést hozzáfűz az eseménynaplójához.

A gyors kezdés elolvasása

Dokumentumok

use Storh\DocStore;
use Storh\Queue;
use Storh\RecordQuery;
use Storh\SegmentedLog;
use Storh\StorageRoot;

$root = StorageRoot::resolve(__DIR__ . '/var/storh', 'demo');

$docs = new DocStore($root, 'pages');
$home = $docs->put([
    'kind' => 'page',
    'title' => 'Home',
]);

$loaded = $docs->get($home->id());

Napló és várólista

$log = new SegmentedLog($root, 'events');
$log->put([
    'type' => 'page.saved',
    'pageId' => $home->id(),
]);

foreach ($log->stream(RecordQuery::all()->after($home->id())->limit(50)) as $record) {
    // Process records lazily.
}

$queue = new Queue($root, 'jobs');
$jobId = $queue->enqueue(['task' => 'render', 'pageId' => $home->id()]);

$job = $queue->claim();
if (null !== $job) {
    $queue->complete($job->id());
}

JSONC dokumentumtár

Rekordonként egy JSONC fájl, UUIDv7 azonosítók, particionálás két karakterrel az UUID utolsó csoportjából, atomi csere és adatfolyam-alapú mezőszűrők.

Szegmentált napló

Csak hozzáfűzhető, hosszelőtaggal és ellenőrző összeggel ellátott JSON sorokból álló szegmensek, ritka indexek, kurzoros és időtartomány szerinti olvasás, összeomlás utáni helyreállítás és tömörítés.

Naplóalapú várólista

A feladatok a függőben, feldolgozás alatt és kész állapotok között mozognak tömör, csak hozzáfűzhető várólista-eseményekkel.

UUIDv7 rekordok

Rendezhető, idő szerint címezhető azonosítók a stabil kurzorokhoz, korlátozott keresésekhez és particionálásbarát tárolási útvonalakhoz.

Atomi írások

Az ideiglenes fájlba írás és az atomi átnevezés biztosítja a rekordok épségét. Írófolyamat összeomlása után a következő megnyitás eltávolítja az árván maradt ideiglenes fájlokat.

Sérült írások helyreállítása

A szegmensolvasások ellenőrzik a hossz- és ellenőrzőösszeg-mezőket; a helyreállítás csonkolja a részleges, záró sorokat.

Fájlalapú

Nincs adatbázis-kiszolgáló, keretrendszer-adapter vagy Composer futtatókörnyezet-csomag; a hívó egy könyvtárat ad meg.

Olvasás JSONC segítségével

A rekordfájlok tartalmazhatnak megjegyzéseket és záró vesszőket. Az storh tömör, egysoros JSON formátumban ír, ezért a megjegyzések a következő írásig megmaradnak.

Lekérdezésépítő

Folyékony lekérdezések, például where('status')->in([...]) a DocStore és a SegmentedLog esetén; a DocStore ott használ másodlagos indexeket, ahol rendelkezésre állnak.

Másodlagos indexek

A gyűjtemény mellett fájlként tárolt egyenlőségi, egyedi és tartományindexek, amelyek a rekordokból származnak, és bármikor újraépíthetők.

Sémák

Az opcionális gyűjteménysémák ellenőrzik minden írás érvényességét, és meghatározzák, mely mezők kapnak indexet.

SQL tükör

Töltse be a gyűjteményeket az SQLite vagy az MySQL rendszerbe egyesítésekhez, kereséshez és jelentésekhez, miközben a fájlok maradnak a hiteles adatforrások. Csak használatkor szükséges az ext-pdo vagy az ext-mysqli.

Miért Storh?

Könyvtár, nem kiszolgáló

Adjon meg egy alapkönyvtárat, az storh pedig oda ír. A PHP 8.2 és az ext-json szükséges hozzá, de nincs szükség Composer futtatókörnyezet-csomagokra vagy keretrendszer-adapterre.

Egy rekordforma, három elrendezés

A dokumentumok, naplók és várólisták mind UUIDv7 azonosítót és adattömböt tárolnak. Válassza ki a munkaterhelésnek megfelelő lemezelrendezést, és tárolja mindhárom típust egy gyökér alatt.

Futtatható ellenőrzések

Az verify() teljes fájlbejárással veti össze az indexeket és a napló állapotát. Az repair() karanténba helyezi a sérült rekordokat és csonkolja a sérült naplóvégeket, a CLI pedig JSON adatot ír ki a cron feladatokhoz és állapotellenőrzésekhez.

Konfigurációval együtt közölt teljesítménymérések

Az README motoronként 50,000 rekord mediánját teszi közzé egy Apple M1 Pro gépen, PHP 8.5 használatával; ilyen például az 5,6 µs-os közvetlen olvasás. Ezekben a futásokban minden írás fsync művelettel történik, ezért az írási sebesség a fájlrendszertől függ.

Összehasonlítás

Az storh fájlalapú tárolás, nem relációs lekérdezőmotor, ezért ezek az eszközök olyan feladatokat is ellátnak, amelyeket ez nem fed le.

Storh összehasonlítása más eszközökkel
Eszköz	Amiben jó	Különbségek Storh-hoz képest
SQLite	Amiben jóÖnálló SQL motor egyetlen fájlban, szerializálható ACID-tranzakciókkal, amelyek programösszeomlás vagy áramkimaradás esetén is fennmaradnak. Dokumentációja alkalmi adatfájlok helyettesítőjeként mutatja be.	Különbségek Storh-hoz képestAz storh rekordonként egy JSON fájlt tart fenn, és az alapcsomagjához nincs szükség PDO-illesztőprogramra. Nincsenek több rekordra kiterjedő tranzakciói; dokumentációja az ilyen feladatokat valódi adatbázisra bízza. A fájlokat hiteles adatforrásként megtartva a gyűjteményeket az SQLite rendszerbe töltheti egyesítésekhez és jelentésekhez.
MySQL	Amiben jóRelációs adatbázis, amelyet többszálú SQL kiszolgáló szolgál ki, kliensprogramokkal és könyvtárakkal, adminisztrációs eszközökkel és széles API-választékkal.	Különbségek Storh-hoz képestAz storh az PHP folyamaton belül, egy könyvtárral dolgozik, így nincs üzemeltetendő kiszolgáló. Egyesítésekhez, kereséshez és jelentésekhez a gyűjteményeket az MySQL rendszerbe tükrözi, meglévő mysqli-kezelőn keresztül is; a fájlok maradnak az igazság forrásai.
SleekDB	Amiben jóLapos fájlalapú dokumentum-adatbázis PHP nyelven, harmadik féltől származó függőségek nélkül, amely séma nélküli adatokat egyszerű JSON fájlokban tárol. Lekérdező API nyelve egyesítéseket, szöveges keresést, csoportosítást és feltételek megadását, valamint beágyazott tulajdonságok szűrését is támogatja.	Különbségek Storh-hoz képestAz storh egyetlen gyökér alatt egyesíti a dokumentumtárat, a csak hozzáfűzhető szegmentált naplót és a naplóalapú várólistát, és minden írást fsync művelettel tartósít, mielőtt tároltnak jelzi. Az egyesítések nem részei az storh rendszernek; ezekhez a gyűjteményeket az SQLite vagy az MySQL rendszerbe tölti.

Források, bejelölve 2026. október 14.

Kérdések és válaszok

Rövid válaszok a Storh dokumentációjából.

Dokumentáció megtekintése

Kezdje a gyors kezdéssel, majd a Motor kiválasztása útmutató alapján válassza ki a munkaterheléséhez illő DocStore, SegmentedLog vagy Queue motort.