Prilagajanje obsegu in omejitve

storh je shramba, ki najprej uporablja datoteke, in ne relacijski poizvedbeni pogon. Praktične meje s primerjalnimi številkami iz meritev (50k zapisov, Apple M1 Pro):

• Dostop do posameznih zapisov je praktično neomejen, če datotečni sistem zmore obvladovati število datotek in zbirka uporablja razdeljevanje na koncu po UUID. Branje posameznega zapisa traja nekaj mikrosekund; trajen zapis posameznega zapisa je omejen z fsync in doseže nekaj tisoč zapisov na sekundo.
• Pregledi segmentiranega dnevnika, branje s kazalcem in branje časovnih razponov so učinkoviti do približno 1M zapisov, če so velikosti segmentov prilagojene delovni obremenitvi. Množično dodajanje doseže več deset tisoč zapisov na sekundo; ob ponovnem odprtju obnovitev poškodovanega konca dnevnika ponovno predvaja več sto tisoč zapisov na sekundo.
• Operacije čakalne vrste dodajajo strnjene dogodke v en trajen dnevnik, zato se pri dodajanju, prevzemu, dokončanju, ponovnem uvrščanju in čiščenju izognemo ustvarjanju in brisanju ločene datoteke za vsako opravilo. Množični prevzem in dokončanje porazdelita stroške zaklepanja in fsync na celotne pakete.
• Pregledi polj po posameznih datotekah v DocStore se upočasnijo pri več kot približno 10k zapisih, ker mora vsak pregled poiskati ujemanja s pregledom posameznih datotek. Za polja, po katerih filtrirate, določite indekse; poizvedbe po indeksirani enakosti se izvedejo v približno milisekundi ne glede na velikost zbirke.
• storh ni namenjen priložnostnim relacijskim poizvedbam, združevanju, filtriranju z veliko sekundarnimi indeksi ali analitičnim pregledom številnih polj. Zbirke preusmerite v zrcalno kopijo SQL, kadar potrebujete takšne vzorce branja; sistem zapisov hranite v pravi podatkovni zbirki, kadar potrebujete transakcije nad več zapisi.

Uporabite DocStore, kadar prevladuje branje posameznih zapisov, SegmentedLog, kadar prevladujeta dodajanje in urejeno branje, ter Queue za preprosto trajno razpošiljanje nalog. Za neposredno primerjavo glejte Izbira pogona.