Mērogošana un ierobežojumi

storh ir vispirms failos balstīta krātuve, nevis relāciju vaicājumu dzinējs. Praktiskās robežas, pamatojoties uz veiktspējas mērījumiem (50k ierakstu, Apple M1 Pro):

• Tiešai piekļuvei praktiski nav ierobežojumu, ja vien failu sistēma spēj apstrādāt failu skaitu un kolekcijai tiek izmantota dalīšana pa UUID beigām. Tieša nolasīšana aizņem dažas mikrosekundes; noturīga viena ieraksta ierakstīšana ir ierobežota ar fsync un sasniedz dažus tūkstošus reižu sekundē.
• Segmentēta žurnāla skenēšana, nolasīšana ar kursoru un nolasīšana laika diapazonā ir ērti veicama līdz aptuveni 1M ierakstu, ja segmentu izmēri ir pielāgoti slodzei. Vairumierakstīšana sasniedz desmitiem tūkstošu ierakstu sekundē; nepilna žurnāla beigu atkopšana, atkārtoti atverot krātuvi, apstrādā simtiem tūkstošu ierakstu sekundē.
• Rindas darbības pievieno kompaktus notikumus vienam noturīgam žurnālam, tāpēc darbu ievietošana rindā, paņemšana, pabeigšana, atkārtota ievietošana un dzēšana neprasa katram darbam izveidot atsevišķu failu. Vairāku darbu paņemšana un pabeigšana sadala bloķēšanas un fsync izmaksas pa visu paketi.
• Atsevišķu failu lauku skenēšana laukā DocStore kļūst lēnāka, pārsniedzot aptuveni 10k ierakstu, jo katrā atbilstošajā skenēšanā jāpārbauda atsevišķi faili. Deklarējiet indeksus laukiem, pēc kuriem veicat filtrēšanu; indeksēti vienādības vaicājumi atbild aptuveni milisekundē neatkarīgi no kolekcijas lieluma.
• storh nav paredzēts patvaļīgiem relāciju vaicājumiem, savienojumiem, filtrēšanai ar daudziem sekundārajiem indeksiem vai analītiskai daudzu lauku skenēšanai. Ja jums nepieciešami šādi nolasīšanas veidi, ievietojiet kolekcijas SQL spogulī; ja nepieciešami vairāku ierakstu transakciju darījumi, glabājiet galveno datu kopiju īstā datubāzē.

Izmantojiet DocStore, ja galvenokārt veicat tiešu nolasīšanu, SegmentedLog, ja galvenokārt pievienojat ierakstus un lasāt tos secīgi, un Queue vienkāršai noturīgai darbu nosūtīšanai. Salīdzinājumu skatiet sadaļā Dzinēja izvēle.