Skalering og grænser

storh er fillagerbaseret lagring, ikke en relationel forespørgselsmotor. De praktiske grænser med referencetal fra benchmarks (50k poster, Apple M1 Pro):

• Direkte opslag er reelt ubegrænset, når filsystemet kan håndtere filantallet, og samlingen bruger UUID-haleopdeling. En direkte læsning tager få mikrosekunder; en holdbar skrivning af én post er begrænset af fsync med nogle få tusinde pr. sekund.
• Scanninger af segmenterede logfiler, markørlæsninger og tidsintervalslæsninger fungerer fint op til omkring 1M poster, når segmentstørrelserne er konfigureret til arbejdsbelastningen. Masseindsættelser kører med titusinder af poster pr. sekund; gendannelse efter en afbrudt loghale afspiller hundredtusinder af poster pr. sekund ved genåbning.
• Køhandlinger føjer kompakte hændelser til én holdbar logfil, så køtilføjelse, hentning, fuldførelse, genindsættelse i køen og rydning undgår unødig mappeaktivitet med én fil pr. job. Massehentning og fuldførelse fordeler låsning og fsync over hele batches.
• Feltbaserede scanninger pr. fil i DocStore bliver langsommere efter cirka 10k poster, fordi hver matchende scanning skal gennemgå individuelle filer. Erklær indekser for de felter, du filtrerer på; indekserede lighedsforespørgsler giver svar på cirka et millisekund uanset samlingens størrelse.
• storh er ikke beregnet til ad hoc-relationelle forespørgsler, joins, filtrering med mange sekundærindekser eller analytiske scanninger på tværs af mange felter. Flyt samlinger til et SQL-spejl, når du har brug for disse læsemønstre; behold det autoritative datasæt i en rigtig database, når du har brug for transaktioner på tværs af flere poster.

Brug DocStore, når direkte læsninger dominerer, SegmentedLog, når tilføjelser og ordnede læsninger dominerer, og Queue til enkel, holdbar arbejdsfordeling. Se Valg af motor for en sammenligning side om side.