Nesne depolama neden disk değil?
Amazon S3, Google Cloud Storage ya da Backblaze B2 gibi nesne depolama servisleri ucuz ve neredeyse sınırsız. Ama bir diskten farklı çalışıyorlar. Bir dosyayı açıp ortasından okuyamıyor, bir kısmını değiştiremiyorsun. Her şey HTTP üzerinden “şu nesneyi ver, bu nesneyi koy” gibi isteklerle oluyor.
Oysa yazılımların çoğu dosya sistemi bekliyor: klasörler, izinler, open, read, write. Bu beklentinin standart adı POSIX. Veri işleme betikleri, veritabanları, eski uygulamalar hep bu dili konuşuyor.
JuiceFS’in fikri: İkiye böl
JuiceFS, Apache 2.0 lisanslı açık kaynak bir dosya sistemi. İşi iki parçaya ayırıyor:
- Veri: Dosyaların içeriği nesne depolamaya gidiyor.
- Üst veri (metadata): Dosya adı, boyutu, izinleri, klasör yapısı hızlı bir veritabanında duruyor. Redis, PostgreSQL, MySQL, TiKV ya da SQLite olabilir.
Bilgisayarındaki JuiceFS istemcisi bu ikisini birleştirip sana sıradan bir klasör gösteriyor. Uygulaman farkı bilmiyor.
Dosyalar buluta olduğu gibi gitmiyor. Önce en fazla 64 MB’lık parçalara (chunk), onlar da varsayılan olarak 4 MB’lık bloklara bölünüyor. Bu yüzden S3 panelinde dosyalarını değil, numaralı klasörler ve bloklar görüyorsun. Büyük bir dosyanın ortasından okumak istediğinde sadece gereken bloklar iniyor.
Asıl hız: Önbellek
Buluta her istek gecikme demek. JuiceFS bunu katmanlı önbellekle çözüyor:
- Üst veri hem işletim sisteminde hem istemcinin belleğinde kısa süre tutuluyor.
- Okunan veri için bellekte bir tampon var.
- Asıl kazanç yerel disk önbelleği. Varsayılan boyutu 100 GB. İnen her blok SSD’ne de kopyalanıyor.
Videodaki deneyde büyük bir video dosyası ilk okumada internetten tek tek blok blok indiği için uzun sürüyor. Aynı komut ikinci kez çalışınca bir saniyenin altında bitiyor. Çünkü veri artık yerel diskte.
Sıralı okumada JuiceFS sonraki blokları önceden de indiriyor. Yazma için de bir seçenek var: --writeback ile dosya önce yerel diske yazılıp buluta sonra gönderiliyor. Çok sayıda küçük dosyada hız kazandırıyor, ama yerel disk bu arada bozulursa veri kaybolabiliyor.
“1 PB’lık disk” nereden geliyor?
Videonun başlığındaki 1 PB, gerçek bir kapasite değil. JuiceFS’e kota koymazsan, bağladığın klasör df komutunda varsayılan olarak 1,0 PB görünüyor. Gerçek sınır, bulut hesabının ve faturanın sınırı.
Nerede işe yarar?
- Yapay zekâ ve veri işleri. Yüzlerce gigabaytlık eğitim verisini önce indirmek yerine doğrudan klasör gibi okuyabilirsin.
- Kubernetes. Birçok makine aynı JuiceFS’i aynı anda bağlayıp ortak dosya paylaşabiliyor. Belgelere göre bir istemci dosyayı kapattıktan sonra diğerleri açtığında son hâlini görüyor.
- Ev sunucusu. Bulut depolamayı yerel bir ağ diski gibi kullanmak.
Dikkat edilecekler: Mac’te çalışması için macFUSE kurman gerekiyor. Üst veri veritabanını da ciddiye almalısın. O giderse bulut tarafındaki bloklar sahipsiz bir yığına dönüşür. Yedeğini al.
Videonun son kısmında JuiceFS’in ölçüm verileri Better Stack’in kendi izleme ürününe bağlanıyor. O kısım bir ürün tanıtımı. JuiceFS’in kendisi Prometheus biçiminde ölçüm veriyor, istediğin araçla izleyebilirsin.
Düşün
- Bir veriyi “nerede durduğu” ile “nasıl bulunduğu” diye ikiye ayırmak, başka hangi sistemlerde karşına çıkıyor?
- Önbellekte duran veriyle buluttaki veri birbirinden ayrılırsa ne olur? Bu riski nasıl sınırlardın?
Videoyu izle
Kaynaklar (5, İngilizce)
Kendi cümlelerimizle yazılmış bir özettir, çeviri değildir. Tüm kaynaklar yukarıda.