Ositus
DocStore kirjoittaa jokaiselle tietueelle oman tiedoston. Ilman ositusta suuri kokoelma kasaisi kaikki tiedostot yhteen hakemistoon, jolloin hakemistotoiminnot hidastuvat merkintöjen määrän kasvaessa. Siksi storh jakaa tietuetiedostot koreihin tietuetunnuksen kahden merkin perusteella:
pages/data/2d/018bcfe5-6800-7000-8000-2d5dba6274da.jsonc
Korin määrää UUID-tunnuksen viimeisen ryhmän alku (merkit 24 ja 25), joka sisältää satunnaista entropiaa. Kaksi heksadesimaalimerkkiä tuottaa 256 koria, joten 100k tietueen kokoelmassa kussakin hakemistossa on keskimäärin alle 400 tiedostoa.
Miksi loppu eikä alku
UUIDv7-tunnukset alkavat 48-bittisellä millisekuntiaikaleimalla, joten lähellä toisiaan luoduissa tunnuksissa on samat alkumerkit. Etuliitteen perusteella osittaminen ohjaisi jokaisen kirjoituspiikin samaan vilkkaaseen hakemistoon ja vaihtaisi koreja vasta ajan kuluessa. Loppumerkit ovat tietuekohtaisesti satunnaisia, joten kirjoitukset jakautuvat tasaisesti heti ensimmäisestä tietueesta alkaen.
Ositus ei näy luvuissa eikä kyselyissä: get() laskee korin tunnuksesta, ja stream() palauttaa tietueet tunnuksen mukaan lajiteltuina kaikista koreista, joten sivutus kohdistimella toimii kuin kokoelma olisi yksi järjestetty lista.
Suuressa mittakaavassa
Korien määrä ei koskaan kasva: kaksi heksadesimaalimerkkiä tarkoittaa 256 hakemistoa kokoelman koosta riippumatta. Tiedostojen määrä koriin sen sijaan kasvaa:
| Tietueita | Tiedostoja koria kohti |
|---|---|
| 10k | ~40 |
| 100k | ~390 |
| 1M | ~3,900 |
| 10M | ~39,000 |
Nykyaikaiset tiedostojärjestelmät indeksoivat hakemistomerkinnät, joten muutama tuhat tiedostoa säilöä kohden pitää pistehaut nopeina; miljoona tietuetta on sopiva määrä get():lle ja indeksoiduille kyselyille. Säilön avaaminen vie vakioajan kokoelman koosta riippumatta: orpojen väliaikaistiedostojen siivous suoritetaan vain, kun kuolleen kirjoittajan merkki osoittaa edellisen prosessin kaatuneen kesken kirjoituksen. Skaalautuessa lineaarisesti kasvavat kokonaisia kokoelmia käsittelevät toiminnot: indeksoimattomat haut, reindex() ja verify() käyvät kukin läpi jokaisen tietuetiedoston, joten käsittele niitä eräajoina. Kun kokoelmassa on noin 10 miljoonaa tietuetta, säilökohtaiset määrät ja inodejen kokonaismäärä alkavat merkitä: jaa kokoelmat osiin tai käytä segmentoitua lokia hakupainotteiselle datalle, sillä se pitää tiedostomäärän pienenä jo rakenteensa ansiosta.
Muut moottorit
SegmentedLog ja Queue eivät jaa tietoja osiin, koska ne eivät luo yhtä tiedostoa tietuetta kohden. Loki lisää tietoja segmenttitiedostoihin hakemistossa segments/, joiden kokoa rajoittaa max_segment_bytes (oletuksena 1 MiB), ja jono lisää tapahtumat yhteen tiedostoon queue.log. Tiedostomäärä pysyy pienenä jo rakenteensa ansiosta.