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 (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 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 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 för en jämförelse sida vid sida.