Parçalama

DocStore her kayıt için bir dosya yazar. Parçalama olmadan büyük bir koleksiyondaki tüm dosyalar tek bir dizinde birikir ve girdi sayısı arttıkça dizin işlemleri yavaşlar. Bu nedenle storh, kayıt dosyalarını kayıt kimliğinin iki karakterine göre gruplara ayırır:

pages/data/2d/018bcfe5-6800-7000-8000-2d5dba6274da.jsonc

Grup, UUID kimliğinin son grubunun başından (24. ve 25. karakterler) alınır; bu kısım rastgele entropi içerir. İki onaltılık karakter 256 grup sağlar; dolayısıyla 100 bin kayıtlı bir koleksiyonda her dizinde ortalama 400 dosyadan az bulunur.

Neden baş değil de son kısım

UUIDv7 kimlikleri 48 bitlik milisaniye zaman damgasıyla başlar; bu nedenle birbirine yakın zamanda oluşturulan kimliklerin baştaki karakterleri aynıdır. Öneke göre parçalama, her yazma yoğunluğunu aynı yoğun dizine yönlendirir ve grupları ancak zaman geçtikçe değiştirir. Son baytlar her kayıt için rastgele olduğundan yazmalar ilk kayıttan itibaren eşit dağılır.

Parçalama, okumaları ve sorguları etkilemez: get() grubu kimlikten hesaplar ve stream() tüm gruplardaki kayıtları kimliğe göre sıralı döndürür; böylece imleçle sayfalama, koleksiyon tek bir sıralı listeymiş gibi çalışır.

Ölçekte

Grup sayısı hiçbir zaman artmaz: iki onaltılık karakter, koleksiyonun boyutu ne olursa olsun 256 dizin demektir. Artan, grup başına dosya sayısıdır:

Modern dosya sistemleri dizin girdilerini indeksler; bu nedenle her grupta birkaç bin dosya olması, tekil aramaları hızlı tutar. 1 milyon kayıt, get() ve indeksli sorgular için rahatça yönetilebilir. Depoyu açma süresi koleksiyon boyutundan bağımsız olarak sabittir: sahipsiz geçici dosyaları temizleme işlemi yalnızca ölü bir yazıcı işareti, önceki bir sürecin yazma ortasında çöktüğünü gösterdiğinde çalışır. Ölçek büyüdükçe doğrusal artan işlemler, tüm koleksiyonu kapsayan işlemlerdir: indekssiz taramalar, reindex() ve verify() tüm kayıt dosyalarını tek tek dolaşır; bunları toplu işler olarak ele alın. Koleksiyon başına yaklaşık 10 milyon kaydı aştığınızda grup başına kayıt sayısı ve toplam inode kullanımı önem kazanmaya başlar. Koleksiyonları bölün veya tarama odaklı veriler için, dosya sayısını tasarımı gereği düşük tutan segmentli günlüğü kullanın.

Diğer motorlar

SegmentedLog ve Queue parçalama yapmaz; çünkü kayıt başına bir dosya oluşturmazlar. Günlük, segments/ altındaki segment dosyalarına ekleme yapar; bu dosyalar varsayılan olarak max_segment_bytes (1 MiB) ile sınırlandırılır. Kuyruk ise olayları tek bir queue.log dosyasına ekler. Tasarım gereği dosya sayısı düşük kalır.