# Skalning & gränser

storh är fillagring i första hand, inte en relationsdatabasmotor för frågor. De praktiska
gränserna, med referensvärden från [riktmärkena](https://storh.inline0.dev/sv/docs/benchmarks)
(50k poster, Apple M1 Pro):

- Punktåtkomst är i praktiken obegränsad när filsystemet klarar filantalet och samlingen använder UUID-tail-sharding. En punktläsning tar några mikrosekunder; en beständig skrivning av en enskild post begränsas av fsync till några tusen per sekund.
- Skanningar av segmenterade loggar, markörläsningar och tidsintervallsläsningar fungerar bra upp till ungefär 1M poster när segmentstorlekarna har konfigurerats för arbetsbelastningen. Massinläggningar når tiotusentals poster per sekund; återställning av en avklippt svans spelar upp hundratusentals poster per sekund vid återöppning.
- Köåtgärder lägger till kompakta händelser i en enda beständig logg, så köläggning, hämtning, slutförande, återköning och rensning slipper katalogändringar från en fil per jobb. Masshämtning och slutförande fördelar låsning och fsync över hela batchar.
- Fältskanningar fil för fil i `DocStore` försämras vid över ungefär 10k poster eftersom varje matchande skanning måste gå igenom enskilda filer. Deklarera [index](https://storh.inline0.dev/sv/docs/indexes) för fälten du filtrerar på; indexerade likhetsfrågor besvaras på ungefär en millisekund oavsett samlingens storlek.
- storh är inte avsett för ad hoc-relationsfrågor, kopplingar, filtrering med många sekundärindex eller analytiska skanningar över många fält. Skicka samlingar till en [SQL-spegel](https://storh.inline0.dev/sv/docs/sql-mirror) när du behöver sådana läsmönster; behåll källsystemet i en riktig databas när du behöver transaktioner över flera poster.

Använd `DocStore` när punktläsningar dominerar, `SegmentedLog` när tillägg och ordnade läsningar dominerar och `Queue` för enkel beständig arbetsfördelning. Se [Välj en motor](https://storh.inline0.dev/sv/docs/engines#choosing-an-engine) för en jämförelse sida vid sida.