Mastelio keitimas ir apribojimai

storh yra failais pagrįsta saugykla, o ne reliacinių užklausų variklis. Praktinės ribos, remiantis našumo bandymų orientaciniais skaičiais (50k įrašų, Apple M1 Pro):

• Prieiga pagal įrašo ID iš esmės neribota, jei failų sistema gali apdoroti failų skaičių, o kolekcija naudoja UUID galinių simbolių skaidymą į dalis. Vieno įrašo skaitymas trunka kelias mikrosekundes; patvarus vieno įrašo įrašymas ribojamas fsync greičio – keli tūkstančiai per sekundę.
• Skenavimas segmentuotame žurnale, skaitymas naudojant žymeklius ir skaitymas pagal laiko intervalą patogiai veikia iki maždaug 1M įrašų, jei segmentų dydžiai parinkti pagal apkrovą. Masinis įrašų pridėjimas pasiekia dešimtis tūkstančių įrašų per sekundę; nutrūkusio žurnalo galo atkūrimas iš naujo atidarant sistemą apdoroja šimtus tūkstančių įrašų per sekundę.
• Eilės operacijos prideda kompaktiškus įvykius į vieną patvarų žurnalą, todėl įtraukimas į eilę, rezervavimas, užbaigimas, grąžinimas į eilę ir išvalymas nesukelia atskiro failo kiekvienai užduočiai katalogų kaitos. Masinis rezervavimas ir užbaigimas leidžia visai partijai dalytis užrakto ir fsync sąnaudomis.
• DocStore laukų skenavimas kiekviename faile lėtėja viršijus maždaug 10k įrašų, nes per kiekvieną tinkamą skenavimą reikia peržiūrėti atskirus failus. Deklaruokite indeksus laukams, pagal kuriuos filtruojate; indeksuotos lygybės užklausos įvykdomos maždaug per milisekundę, neatsižvelgiant į kolekcijos dydį.
• storh nėra skirtas ad hoc reliacinėms užklausoms, sujungimams, intensyviam filtravimui pagal antrinius indeksus ar analitiniam daugelio laukų skenavimui. Kai reikia tokių skaitymo šablonų, perkelkite kolekcijas į SQL veidrodį; jei reikia kelių įrašų transakcijų, pagrindinius duomenis laikykite tikroje duomenų bazėje.

Naudokite DocStore, kai dažniausiai skaitoma pagal įrašo ID, SegmentedLog, kai vyrauja pridėjimas ir skaitymas nustatyta tvarka, ir Queue paprastam patvariam užduočių paskirstymui. Žr. Variklio pasirinkimas, kur pateikiamas palyginimas greta.