Škálování a limity

storh je úložiště založené na souborech, nikoli relační dotazovací engine. Praktické hranice s referenčními čísly z benchmarků (50 tisíc záznamů, Apple M1 Pro):

• Přístup k jednotlivým záznamům je prakticky neomezený, pokud souborový systém zvládne počet souborů a kolekce používá dělení UUID podle koncových znaků. Načtení jednoho záznamu trvá několik mikrosekund; trvalý zápis jednotlivého záznamu je omezen voláním fsync na několik tisíc za sekundu.
• Prohledávání segmentovaných protokolů, čtení pomocí kurzorů a čtení časových rozsahů pohodlně zvládají přibližně milion záznamů, pokud jsou velikosti segmentů nakonfigurovány pro dané použití. Hromadné přidávání dosahuje desítek tisíc záznamů za sekundu; obnova useknutého konce znovu přehraje stovky tisíc záznamů za sekundu při opětovném otevření.
• Operace s frontou přidávají kompaktní události do jediného trvalého protokolu, takže vložení do fronty, převzetí, dokončení, opětovné zařazení i vyprázdnění nevyžadují změny adresáře s jedním souborem pro každou úlohu. Hromadné převzetí a dokončení rozkládají náklady na zámky a fsync mezi celé dávky.
• Prohledávání polí po jednotlivých souborech v DocStore se zhoršuje nad přibližně 10 tisíc záznamů, protože každé odpovídající prohledávání musí projít jednotlivé soubory. Pro pole, podle kterých filtrujete, deklarujte indexy; dotazy s indexovanou rovností vracejí výsledky přibližně za milisekundu bez ohledu na velikost kolekce.
• storh není určen pro ad hoc relační dotazy, spojování, filtrování s intenzivním využitím sekundárních indexů ani analytické prohledávání mnoha polí. Pokud takové čtení potřebujete, přeneste kolekce do zrcadla SQL; pokud potřebujete transakce nad více záznamy, ponechte hlavní záznamy ve skutečné databázi.

Používejte DocStore, když převažuje přístup k jednotlivým záznamům, SegmentedLog, když převažuje přidávání a čtení v pořadí, a Queue pro jednoduché a trvalé rozesílání práce. Srovnání vedle sebe najdete v části Výběr modulu.