Skálázás és korlátok

A storh fájlközpontú tárolás, nem relációs lekérdezőmotor. Gyakorlati határok, a teljesítménymérések referenciaadataival (50k rekord, Apple M1 Pro):

• A közvetlen hozzáférés gyakorlatilag korlátlan, ha a fájlrendszer kezelni tudja a fájlok számát, és a gyűjtemény UUID-karakteres végződés alapján osztja szét a fájlokat. A közvetlen olvasás néhány mikroszekundumot vesz igénybe; egyetlen rekord tartós írását az fsync korlátozza, másodpercenként néhány ezerre.
• A szegmentált naplók bejárása, a kurzoros olvasás és az időtartományos olvasás nagyjából 1M rekordig kényelmesen használható, ha a szegmensméretet a munkaterheléshez igazítják. A kötegelt hozzáfűzés másodpercenként több tízezer rekordot ér el; a részlegesen írt naplóvégek helyreállítása újranyitáskor másodpercenként több százezer rekordot játszik vissza.
• A sor műveletei tömör eseményeket fűznek egyetlen tartós naplóhoz, így a sorba állítás, lefoglalás, befejezés, újrasorba állítás és törlés nem okoz rekordonkénti fájlok miatti könyvtárterhelést. A kötegelt lefoglalás és befejezés a zárolást és az fsync-et teljes kötegek között osztja el.
• A DocStore fájlonkénti mezőbejárása nagyjából 10k rekord felett lelassul, mert minden egyezéskeresésnek végig kell járnia az egyes fájlokat. Deklaráljon indexeket a szűréshez használt mezőkhöz; az indexelt egyenlőségi lekérdezések a gyűjtemény méretétől függetlenül körülbelül egy milliszekundum alatt futnak le.
• A storh nem alkalmas alkalmi relációs lekérdezésekre, összekapcsolásokra, sok másodlagos indexet használó szűrésre vagy több mezőt átfogó elemző bejárásokra. Ha ilyen olvasási mintákra van szüksége, helyezze át a gyűjteményeket egy SQL tükörbe; több rekordot érintő tranzakciókhoz tartsa a nyilvántartás alapját egy valódi adatbázisban.

A DocStore használja, ha a közvetlen olvasás dominál, a SegmentedLog-et, ha a hozzáfűzés és a rendezett olvasás, a Queue-t pedig egyszerű, tartós feladattovábbításhoz. Az összehasonlításhoz lásd a Motor kiválasztása oldalt.