S3 bir dosya sistemi değil, dosya depolama teknolojisidir

 (calpaterson.com)
2 puan yazan GN⁺ 2024-03-11 | 1 yorum | WhatsApp'ta paylaş
  • Amazon S3, 2006’da ortaya çıkan erken dönem bulut teknolojilerinden biridir; dosya depolamada güçlüdür, ancak Unix dosya API’sinin yerini birebir alan bir dosya sistemi değildir
  • Unix dosya API’si, open, read, write, seek, close gibi dar bir arayüzün arkasında tamponlama, sayfa önbelleği, izinler ve IO zamanlamasını gizleyen bir derin modüle daha yakındır
  • S3, GetObject ve PutObject merkezli yapısıyla basit görünür; ancak Range ile yalnızca kısmi okuma mümkündür ve kısmi üzerine yazmayı desteklemez
  • Postgres, SQLite, MySQL, MongoDB ve Elasticsearch gibi veritabanları sayfa düzeyinde üzerine yazmaya dayandığından, SQLite ya da DuckDB dosyalarını olduğu gibi S3’e koyma yaklaşımı küçük veri kümeleri dışında pek uygun değildir
  • Yüksek okuma-yazma bant genişliği ve düşük operasyonel yük S3’ün güçlü yanlarıdır; ancak rename/move olmaması, yavaş listeleme, yalnızca XML API’si ve yerel test ortamının bulunmaması gibi kısıtlar da dikkate alınmalıdır

S3 dosya depolar ama dosya sistemi değildir

  • S3, 2006’da ortaya çıkan erken dönem bir bulut teknolojisidir ve o dönemde yaygın olan ifadeyle “object store” olarak adlandırılmıştır
  • Pratikte yaygın biçimde dosya deposu olarak kullanılır; ancak bunu “Amazon Cloud Filesystem” gibi anlamak yalnızca kısmen doğrudur
  • Dosya depolamada iyidir, fakat mevcut dosya sistemlerinin davranışlarını ve beklentilerini birebir karşılayamaz

Unix dosya API’si ve derin modüller

  • Unix dosya API’sinin özü şu beş çağrıyla özetlenebilir
    • open(filepath): dosyayı açar
    • file.read(size=100): mevcut konumdan okur ve konumu ileri taşır
    • file.write("hello, world"): mevcut konuma yazar ve konumu ileri taşır
    • file.seek(94): konumu belirli bir bayta taşır
    • file.close(): dosyayı kapatır
  • Bu çağrılar, gerçek sistem çağrılarının tamamı içinde çekirdeği oluşturur ve dosya okuma-yazma için gerekli asgari işlevlere yakındır
  • Dar bir arayüzün arkasında çok fazla işlem gerçekleştiği için Unix dosya API’si bir derin modül (deep module) olarak görülebilir
    • Tamponlama ve sayfa önbelleği
    • Parçalanma yönetimi
    • İzin yönetimi
    • IO zamanlaması
    • SD kartlardaki wear-levelling gibi özelliklerden de kullanıcının doğrudan ilgilenmesine gerek kalmadan yararlanılır

Sığ modüller ve YAML, ORM

  • Sığ modüllerde API yüzeyi, sundukları işleve kıyasla görece büyüktür
  • Günümüzde sığ bir modülü tanımaya yarayan ipuçlarından biri, arayüzünün YAML olmasıdır
    • YAML bir işaretleme dili gibi görünür, ancak pratikte neredeyse her türlü anlamsallığın üzerine bindirilebildiği yeniden kullanılabilir bir sözdizimi gibi kullanılır
    • DevOps alanında YAML çoğu zaman bir “programlama dili” gibi davranır
    • Bir YAML mini dili yineleme yapıları sunuyorsa Turing-complete olma ihtimali vardır
  • Sığ modüller her zaman kötü değildir
    • SQL ORM’ler doğası gereği sızdıran soyutlamalardır ve SQL’i anlamadan kullanmak zordur
    • Bazı durumlarda sığ bir modül mümkün olan en iyi biçim olabilir
  • Koşullar aynıysa daha derin modül daha iyidir

S3 API’si basittir ama dosya API’sinden farklıdır

  • Unix dosya API’si 1970’lerin başında yerleşti; uyumluluk için arayüz korunurken iç uygulama birçok kez değişti
  • Amazon S3, Unix dosya sistemi API’sini yeniden uygulamaz
  • S3’ün temel işlemleri Unix dosya API’siyle yalnızca kısmen örtüşür
    • GetObject(Bucket, Key, Range=None): nesnenin tamamını veya bir bölümünü okur
    • PutObject(Bucket, Key): nesnenin tamamını yazar
  • Bucket gibi ek bir kavram olsa da işlev/arayüz oranına bakıldığında S3’ün Unix dosya API’sinden daha basit olduğu söylenebilir
  • Belirleyici fark kısmi üzerine yazmanın olmamasıdır
    • GetObject’teki Range argümanıyla nesnenin bir bölümünü okumak mümkündür
    • Nesnenin yalnızca bir bölümünün üzerine yazmak mümkün değildir
    • Üzerine yazma, dosyanın tamamı düzeyinde yapılmalıdır
  • Bu fark nedeniyle S3, mevcut dosya kullanım senaryolarının yalnızca bir kısmına iyi uyar

Veritabanlarını S3’e olduğu gibi taşımak zordur

  • Birçok veritabanı verilerini dosya sistemi üzerindeki dosyalarda saklar
    • Postgres, her tablo için 2-3 dosya ve çeşitli yönetim dosyaları tutar
    • SQLite’ın tüm verileri tek bir dosyada saklamasıyla bilinir
    • MySQL, MongoDB ve Elasticsearch de verileri dosyalarda saklar
  • Sorun, veritabanlarının genel olarak sayfa düzeyinde kısmi üzerine yazmaya dayanmasıdır
    • Veriler genellikle 4KB veya 8KB gibi sayfalar halinde saklanır
    • Bir heap dosyasının içinde binlerce sayfa bulunabilir
    • Gerekli verileri saklamak için sayfaların kısmen üzerine yazılır
  • SQLite veritabanını S3’e koyarsanız her yazmada tüm veritabanı dosyasını yeniden yazmanız gerekir
  • S3 büyük yazmaları hızlı işleyebilir; ancak en küçük veri kümeleri dışında her seferinde tüm dosyanın üzerine yazma stratejisini kaldırmak zordur
  • Veritabanı dosyasını her seferinde yeniden yazmak, veritabanı geliştiricisinin inşa ettiği işlem bütünlüğünden yararlanmayı da zorlaştırır
  • S3’te son yazan kazanır

S3’ün iyi ve kötü yaptığı şeyler

  • S3’ün güçlü yanı, okuma ve yazma bant genişliğinin çok yüksek olmasıdır
    • İnternette S3’e saniyede 10GB’den fazla yazma veya S3’ten okuma örneklerini bulmak zor değildir
    • S3 yazma işleriyle finans sektöründen bir müşterinin ofis ağını doyuma ulaştırdığım bir deneyim de oldu
  • Kısmi üzerine yazmanın olmamasına ek olarak, dosya sistemlerinden farklı başka kısıtlar da vardır
  • S3’te rename veya move işlemi yoktur
    • Ad değiştirme CopyObject ardından DeleteObject ile yapılır
    • CopyObject, dosya boyutuyla orantılı doğrusal zaman alır
    • Çok sayıda dosyayı yanlış konuma yazdıktan sonra geri almak çok yavaştır
  • Dosya listeleme yavaştır
    • Okuma-yazma bant genişliği çok yüksek olsa da saklanan öğeleri listeleme işlemi çok daha yavaştır
    • Yavaş bir yerel dosya sisteminden bile daha yavaş olabilir
  • Buna karşılık operasyonel yükü dosya sistemlerinden daha düşüktür
    • Yalnızca bucket ve key adlarını belirtirsiniz; geri kalanını bulut halleder
    • Yedekleme, offsite replikasyon ve provizyonlama gibi tekrarlı işlerin yükünü azaltır
    • Provizyonlama yalnızca kapasite için değil, IO işlemleri için de geçerlidir

Kurumlar arası arayüzlerde derin modüller daha önemlidir

  • S3’ün ilk popüler bulut API’si olması, derin API’lerin avantajıyla bağlantılıdır
  • Derin API’ler, tek bir sistem içindeki modüller arası karmaşıklığı gizlemede yararlıdır; iki şirket arasındaki etkileşim gibi maliyeti yüksek ilişkilerde ise daha da önemlidir
  • Şirketler arasında bilgisayar sistemlerini bağlama işi geleneksel olarak integration olarak adlandırılmış ve adeta acının eş anlamlısı gibi görülmüştür
  • SAP gibi büyük kurumsal yazılımlar derin modül değildir
    • Kurumun neredeyse tamamının SAP’yi anlaması gerekir
    • Mevcut iş yapma biçimleriyle sürekli uyumlanması gerekir
    • SAP entegrasyon projeleri pahalı ve devasa olur; başarısızlık örnekleri de tekrarlanır
  • S3’ün iç karmaşıklığı SAP kurulumundan çok daha az değildir
    • Amazon, S3’e “Simple Storage Service” adını verdi; ancak gerçek S3 karmaşıklığı büyüktür
    • Kuyruk teorisi, IO çekişmesi, sharding ve dosya sistemlerinin ele aldığı birçok sorunu içerir
  • S3’teki “simple”, gerçek basitlikten çok derin arayüze yakındır

S3’e uyan istisnalar ve kalan kısıtlar

  • Bu, S3’ün kullanım senaryosuna göre pahalı olabileceği sorununu dışlamaz
  • Derin modül ve sığ modül kavramları John Ousterhout’un A Philosophy of Software Design kitabından gelir
  • S3 API’sini depolama katmanı olarak kullanmak üzere baştan tasarlanmış veritabanları da vardır
    • Snowflake buna bir örnektir
    • Ancak bu şeffaf bir taşıma değil, başlangıçta alınması gereken bir tasarım kararıdır
    • Snowflake, en azından 2016’ya kadar bu kararı çok erken almış bir örnekti
  • S3’te zorlananlar yalnızca veritabanları değildir
    • Birçok dosya biçimi ucuz seek varsayar
    • Zip dosyaları, S3’e kıyasla diskte daha iyi performans gösteren başlıca örneklerdendir

S3’te eksik bulunan noktalar

  • S3 API’si yalnızca XML’dir
    • JSON 2006’da da vardı, ancak o dönemde XML baskındı
    • Amazon’un SOAP’tan REST’e geçerken JSON sürümü çıkarmamış olması üzücü
  • Amazon, XSD schema bakımını da durdurdu
    • XML API’nin temel avantajlarından biri şemadır; ancak bugün standart belge web sitesidir
  • Amazon yerel bir test ortamı sağlamaz
    • Python’da özenli testler için moto kütüphanesi kullanılabiliyor
    • moto, ticari bir hizmeti test etmeye yarayan bir araç olmasına rağmen gönüllüler tarafından sürdürülüyor
  • Amazon S3 checksum destekler, ancak varsayılan olarak açık değildir
    • Amazon dayanıklılık konusunda çeşitli iddialarda bulunur
    • Gerçek bir sorun yaşandığına dair bir şey duymadım; ancak bu iddiaların test edildiği bir örnek de görmedim
  • Geçmişte S3’te eventual consistency tuzağı vardı
    • Bir dosyayı okuyup üzerine yazdıktan sonra tekrar okuduğunuzda hâlâ değişmemiş içeriği görebiliyordunuz
    • Kısa süreliğine ara sıra yaşanır ve kafa karışıklığı yaratırdı
    • Diğer S3 uygulamaları bu özelliği kopyalamadı; Amazon da birkaç yıl önce strong read-after-write consistency ile bunu düzeltti

İlgili okumalar

1 yorum

 
GN⁺ 2024-03-11
Hacker News yorumları

  • S3 dayanıklılığı abartı gibi görünse de güvenilir ve geleneksel dosya sistemleriyle karşılaştırılması zor görünüyor
    Fark yalnızca yazılımda değil, fiziksel altyapı ve güvenlik kültürünü de kapsıyor; AWS’in erişilebilirlik alanı izolasyonu diğer bulutlardan daha iyi gibi geliyor
    S3’te çalışırken GCP Blob Storage ile çok fiyat karşılaştırmasına maruz kaldım, ancak Google verileri aynı binaya ya da aynı binanın farklı bir odasına koyabiliyordu; bu yüzden AWS tarzı ayrıştırmayla adil bir karşılaştırma değildi
    Tüm organizasyon veri bütünlüğüne aşırı takıntılıydı, her şeye checksum ekliyordu ve doğal afetler gibi büyük olaylara da hazırlanıyordu
    S3 ölçeğinde, gama ışınlarının sabit disk plakalarına çarpmasıyla oluşan rastgele bit ters dönmeleri gibi bit rot bile tespit edilebiliyordu; disk üreticisine ve üretim dönemine göre arıza oranları bile ölçülerek belirli bir parti bozulsa da veri kaybı olasılığı azaltılıyordu
    Önemli verileri başka yerde tutmayacağımı söyleyecek kadar güveniyorum; S3 yerleştirme sistemini de bizzat geliştirdim

    • Diğer depolama şirketlerindeki deneyimler merak konusu
      Bu açıklama, Cinnabon’un hamurunu kendi yaptığı için övülmesi gibi geliyor; bahsedilen şeyler bir depolama şirketinin genelde yaptığı işler
      Her şeye checksum eklemek pek çok dosya sisteminin temel özelliği; ev bilgisayarında bile bit rot tespit edilip uyarı alınabiliyorsa büyük depolama sağlayıcıları bunu elbette yapar
      Disk üreticisine göre arıza oranlarını izlemek de yaygın; depolama şirketleri raporlar bile yayımlar, 6 kişilik bir BT ekibinde bile bunu elektronik tablolarla yönetiyorduk
      AWS dışında da, AWS ortaya çıkmadan çok önce depolama alanında çalışan birçok akıllı insan vardı
    • AWS’in erişilebilirlik alanı izolasyonu tüm sağlayıcılardan daha iyi değil
      rsync.net’in coğrafi yedekli hesapları, örneğin Fremont’taki birincil depolama ile Denver’daki ikincil depolama gibi farklı eyaletlerde veya ülkelerde bulunur
      S3’ün ölçeği sayesinde bit rot tespit edebildiği iddiası da doğru değil; kişisel bir sunucuda ZFS çalıştırınca da küçük ölçekte bit rot gayet iyi tespit edilir
      [1] he.net merkezi
    • Verilere checksum eklemek paranoyadan ziyade, Reed-Solomon algoritmasını çalıştırmak için hangi blokların kullanılamaz olduğunu bilmek gerektiğinden doğal olarak zorunlu bir iş
      Bu tür bozulma olayları yeterince çoksa, tekil veri bloklarını başka makinelere taşıyarak sistemi “iyileştirmek” için bir sinyal olarak da kullanılabilir
      Genel olarak bahsedilenler depolama sistemlerinde oldukça tipik işler; S3’e özgü değil
    • Google’ın verileri aynı binada sakladığı doğru gibi görünmüyor
      Google Cloud Storage belgelerine göre veriler birden çok bölgeye kopyalanır ve her bölge farklı kümelere eşlenir
      https://cloud.google.com/compute/docs/regions-zones/zone-vir...
    • “Buna inanın” yerine test sonuçlarına inanmak isterim
      S3’ün dayanıklılığını, bütünlüğünü ve tutarlılığını Jepsen kadar sıkı biçimde doğrulamış tarafsız bir üçüncü taraf var mı merak ediyorum
      Birileri S3 uyumlu bulut depolama hizmetlerini titizlikle karşılaştırsa korkutucu ve büyük sorunlar ortaya çıkabilir; belki böyle bir karşılaştırma zaten vardır

  • S3’te gerçekten faydalı olanın okuma/yazma hızından çok listeleme olduğunu düşünüyorum
    Sürümsüz bucket’larda ya da silme işaretçisi olmayan bucket’larda belirli bir önekle listeleme pratikte sabit zamanlı gibi çalışır; 100 milyar nesneli bir bucket’ta bile rastgele bir dizgeden sonra gelen alfabetik sıradaki 1000 anahtar istenebilir
    Ayraç olarak / kullanmak sadece varsayılandır; herhangi bir karakter kullanılarak ortak önek kümeleri alınabilir ve dizinler gerçekte var olmaz, yalnızca gerektiğinde yaratılmış gibi görünür
    Bu özellik sayesinde performans kaygısı olmadan verileri gerekli tanımlayıcılara göre birden fazla şekilde bölebilirsiniz
    Eğer listeleme sadece yavaş olsaydı, dosya önekine göre sorgulama yapılamasaydı ve anahtar sayısıyla orantılı olarak yavaşlayan geleneksel bir Unix dosya sistemi gibi davransaydı S3 hiç kullanışlı olmazdı

    • Pek ikna edici değil
      Bir önekin önündeki ve arkasındaki anahtarları çekebilme becerisi, 1970’lerden beri var olan veritabanı indekslerinin temel özelliği; bu yüzden özellikle etkileyici değil
      Kullanım senaryoları farklı olabilir ama bucket listelemenin yavaşlığı yüzünden engellendiğim çok oldu; bucket biraz büyüdüğünde bile anahtarları listelemek, okumaktan daha uzun sürüyor
      Hatırladığım kadarıyla listeleme 1 Mbps’nin altında bir seviyedeydi, ancak şu anda test edebileceğim büyük bir bucket yok
    • Düz sözlüksel anahtar hiyerarşisi ile dizinlerle iç içe geçmiş dosya sistemi hiyerarşisi arasındaki fark örneğe bakınca açıkça görülür
      dir1/a/000000 ile dir1/a/999999 arasında öğeler ve dir1/b varken, gerçek hiyerarşik bir dosya sisteminde ls dir1/ yalnızca "a" ve "b" adlı iki öğeyi dolaşıp döndürmekle yetinir
      Buna karşılık ayraç işlemesi olmayan düz dizge indeksli bir anahtar-değer deposu, "b"ye ulaşmadan önce "a/00000" ile "a/999999" arasındaki 1 milyon dizin girdisinin üzerinden geçmek zorundadır
      Bu yüzden basit düz hiyerarşide bir dizinin içeriğini listelemek gerçek bir dosya sistemindeki O(doğrudan çocuk) değil, O(tüm özyinelemeli çocuklar) olur ve çok daha yavaştır
      Ancak listeleme algoritmasına / gibi bir ayraç karakteri bildirilirse, sözlüksel önek ağacı bir sonraki / noktasında alt ağacı verimli şekilde atlayabilir
      Amazon S3 belgeleri de CommonPrefixes alanının daha derin seviyelerde iç içe geçmiş milyonlarca anahtarı atlayıp özetlediğini açıkça belirtir
      https://docs.aws.amazon.com/AmazonS3/latest/userguide/using-...
      Gerçek uygulamanın gerçekten dolaşmayı azaltıp azaltmadığını, yoksa dolaştıktan sonra yalnızca sonucu mu küçülttüğünü test etmedim; ama azaltmasını umarım
    • 1993’teki XFS’ten itibaren, HPFS’ten etkilenmiş iyi UNIX dosya sistemleri dizinleri bir tür B-ağacı olarak uyguluyor
      Bu nedenle öğe sayısıyla orantılı olarak yavaşlamazlar; dosya önekine göre listeleme de çok hızlıdır
    • S3 kullanımının %99’u zaten bilinen bir anahtarla nesne getirmek gibi geliyor
      Önekle listelemeyi temel özellik olarak görmek tuhaf hissettiriyor
    • Burada “sabit zaman” tanımımız aynı mı bilmiyorum
      Tek bir ağ çağrısıyla 1000 anahtar almak, arka uçtaki karmaşıklık hakkında hiçbir garanti vermez

  • Yakın zamanda S3 varlık yönetimi betiği üzerinde çalışırken listeleme hızına şaşırdım
    Bir iş arkadaşım dosya listesi önbelleğine ihtiyaç olduğunu söyleyip önceden doldurulmuş bir önbellek gönderdi; başta bunun gerçekten gerekli olamayacağını düşündüm ama kendim kontrol edince durumun farklı olduğunu gördüm
    Tekil varlıklar için yaklaşık 100 bin kök dizin var; her birinde 5-6 dizin ve az sayıda dosya bulunuyor, toplam dosya sayısı muhtemelen 1 milyonun altında ve derinlik en fazla 3 seviye civarında
    Bu dosyaları özyinelemeli olarak listelemek kelimenin tam anlamıyla 15 dakika sürdü
    Stack Overflow ve ChatGPT’nin hız artırma önerilerinden çeşitli şeyler denedim ama anlamlı bir sonuç alamadım; bunun neden bu kadar yavaş olduğunu anlamıyorum
    Amazon’un bunu neden düzeltmediğini bilmiyorum; dışarıdan bakınca tekil bucket’lara birkaç B-tree eklemek yeterli olacakmış gibi görünüyor
    Eğer zor bir problemse nedenini duymak ilginç olur

    • S3 temelde bir anahtar-değer deposudur
      Nesneleri “dizin” gibi görebilmek yalnızca bir önek filtresinden ibarettir; bu bir dosya sistemi değildir ve dizin kavramı da yoktur
    • “Özyinelemeli” ifadesiyle “dizin” ve “seviye” konularını uzun uzun açıklayan kısım beni endişelendiriyor
      S3’te nesneleri en hızlı listeleme yönteminde özyinelemeye hiç gerek yoktur; yalnızca bir önek altındaki tüm nesneleri listelemek yeterlidir
      Yol ayırıcı kullanıp S3 anahtarlarını klasör yapısı gibi göstererek “klasör klasör” dolaşırsanız çok daha yavaş olur
      ListObjectsV2 çağrılırken delimiter geçirilmemeli; ayırıcı özelliği kullanılmazsa “dizinler” ve “seviyeler” performansı etkilemez
      İstenen toplam süreye ulaşmak için tek bir listeleme işini birden çok önek için paralel listeleme işlemlerine bölmek gerekir
    • Bu meselenin ilginç sonuçlarından biri, S3 bucket silmenin basit olmamasıdır
      İçinde nesne olan bir bucket silinemez ve S3’e tek seferde tüm nesneleri silmesini de söyleyemezsiniz
      Her nesne için ayrı silme API isteği göndermeniz gerekir; bunun için de nesneleri 1000’er 1000’er listeleyen istekler göndermeniz gerekir ve bu listeleme çağrıları hem zaman alır hem de maliyetlidir
      Durumu şu yazı iyi özetliyor: https://cloudcasts.io/article/deleting-an-s3-bucket-costs-mo...
      Bir S3 bucket’ını hızla ortadan kaldırmanın en hızlı yolu, sonunda o bucket’ın ait olduğu AWS hesabını silmektir
    • Nedeni çok daha sıradan olabilir
      Tek bir istekte 10 bin nesne listeleyebilirsiniz ve sonraki 10 bin nesneyi almak için önceki isteğin sonucuna ihtiyaç vardır; yani her şey seridir
      1 milyon dosyayı listelemek için ardışık 100 istek gerekir; gidiş-dönüş süresi yalnızca 50 ms olsa bile sadece gidiş-dönüşler 5 saniye eder, düz bir yinelemede listenin kendisini oluşturma maliyeti ayrıca vardır
      10 bin öğelik listeleme maliyeti yazma maliyetine yakındır ve bu başlı başına epey yavaştır; ayrıca her listelemenin güçlü tutarlılığa sahip bir snapshot olması da muhtemeldir, bu da ek maliyet getirir
      B-tree’ler, dizin gezintisi yapmıyorsanız pek yardımcı olacak gibi görünmüyor; o durumda bile darboğazın ağ işlemleri ve dışarıya açılmış API olması muhtemeldir
      Sonuçta dosya listesi sorgulamak o kadar önemli bir kullanım senaryosu değildir; genelde nesne yaşam döngüsü gibi özelliklerle istenen iş S3’e bırakılır ve iç dosya sistemi katmanında verimli biçimde işlenmesi sağlanır
    • S3 bucket içinde dizinler olduğunu düşünmek iyi bir model değildir
      Hepsi nesnedir; web arayüzü yalnızca eğik çizgiyle ayrılmış önekleri daha hoş görünecek şekilde sunar
      Her nesnenin bir anahtarı vardır ve bu anahtarın içinde eğik çizgi bulunabilir; isterseniz her bölümü dizin olarak düşünerek rahat edebilirsiniz
      Ama normalde dizinler üzerinde yaptığınız işlemleri denemeye kalktığınızda bu yanılsama bozulur

  • S3’ü yapanlar bunun bir dosya sistemi olmadığını biliyordu; nesne deposu adı da yazıda işaret edilen farkları açıklamaya çalışan bir ifadeydi diye düşünüyorum
    “Nesnelerin popüler olması”, yürütülebilir kod ile yerel durumu birleştiren yazılım bileşeni anlamındaki nesnelerle ilgilidir; ancak S3’ün ilk örnekleri “canlı nesneyi serileştirip başka bir süreçte deserileştirmek” gibi şeyler değildi
    Örneklerin tamamı web sitesi statik varlıkları türündeydi ve o dönemde veritabanı tarafında da “binary large object” veya “blob” terimlerinde nesne anlamı kullanılıyordu
    S3, veritabanına koyması zor olan şeyleri saklanan bir yer olmaya daha yakındı; ilk tasarlandığında hedeflenen çıkış kullanım senaryoları içerik indeksinin başka bir yerde olduğunu varsaydığı için listelemenin yavaş olması da tam olarak bu niteliği açıklar

    • Yazar, “nesne deposu”nun nesne yönelimli programlamayla ilgisi olmayan bir depolama sistemi terimi olduğunu bilmiyor gibi görünüyor
      https://en.wikipedia.org/wiki/Object_storage
    • Yazarın nesne yönelimli programlama ile nesne deposunu karıştırıyor gibi görünmesi endişe verici
      GCP’nin açıklamasına göre nesne deposu, yapılandırılmamış verileri nesne birimlerine ayırıp yapısal olarak düz bir veri ortamında saklayan bir mimaridir
      https://cloud.google.com/learn/what-is-object-storage
      Yani yapılandırılmamış veri, düz yapı ve tüm öğe bazında çalışan okuma-yazma işlemleri esastır

  • S3 ne bir dosyadır ne de hele hele bir dosya sistemi
    Dosya soyutlamasından beklenen şey değiştirilebilirliktir; dosyanın bir kısmını düzenleyebilmeli, büyütebilmeli, küçültebilmeli, rastgele ofsetlerden okuyup yazabilmelisiniz.
    Bir dosyayı elinize aldıktan sonra tekrar köke ya da üst bir kavrama dönmeniz gerekmemelidir; oysa S3 yalnızca değiştirilebilir bir liste üzerinde değiştirilemez nesneler sunar ve bir şeyi değiştirmek için kopyalayıp yeniden yüklemeniz gerekir.
    Asıl dosya soyutlaması, diskteki sektörleri bulup bunları istemciye kesintisiz bir tampon gibi göstermektir; S3 ise başka bir problemi çözer.
    Birçok kişi UNIX’in “her şey dosyadır” şeklindeki iyi fikrini, her şeyin kesintisiz bir sanal tampon gibi görünmesi gerektiği anlamına gelecek şekilde yanlış anlıyor.
    Asıl önemli nokta, ister dosya olsun ister sistemin süreçlere göstermek istediği başka bir nesne olsun, temel yaprak düğümlerin bulunması; dizinler dâhil her şeyin dizinlerde listelenebilmesi ve özyinelemeli bir ağaç yapısının olmasıdır.
    Bir dosya sistemini oluşturan şey, belirli bir yaprak düğümün türü değil dizinlerdir.
    Soket ya da framebuffer gibi yeni yaprak türleri eklemek neredeyse önemsizdir ve bu fikre zarar vermez; ancak liste gibi başka türde kapsayıcılar eklemek dosya sistemi yapısını karmaşıklaştırır ve kavramsal tutarlılığı bozar.
    S3 bunları yapmaz ama bu sorun değil.
    Veritabanına uymayan şeyleri oraya koyup bakmadığınız süre boyunca bit rot oluşmamasını umarsınız sadece.
    S3’ü dosya sistemi gibi yapma isteğinin, müşterilerin S3’ün iyi yaptığı işi yanlış anlamasından ve ürün yönetiminin bu yanlış anlamayı engellemek yerine kabul etmesinden kaynaklandığını düşünüyorum.

    • S3’ün bir dosya sistemi olmadığına katılıyorum.
      Daha uygun benzetme blok depolama aygıtıdır; ancak blok boyutunun keyfi olduğu ve anahtar eklenebildiği çok tuhaf bir blok aygıtına daha yakındır.
      Dosya sistemi, blok depolama aygıtı üzerine yerleşen bir soyutlama olduğundan, “S3 dosya sistemi” de S3’ü temel blok deposu gibi kullanıp onun üzerinde yer alan bir soyutlama olmalıdır.
    • Salt okunur dosya sistemlerinin bu tanıma nasıl uyduğunu merak ediyorum.

  • Dosya sistemi, blok aygıtı üzerine kurulmuş bir soyutlamadır.
    Blok aygıtı devasa bir bayt dizisi sunar ve örneğin “273041 konumuna şu 300 baytı yaz” gibi blok düzeyinde okuma/yazma yapmanıza olanak tanır.
    Blok aygıtının kendisi de gerçek donanım üzerine kurulmuş bir soyutlamadır; dolayısıyla “şu 300 baytı yaz” demek, gerçekte “2 numaralı platter’daki kafayı 6 numaralı konuma hareket ettir” gibi işlemlere dönüşür.
    S3, ham depolama üzerine kurulmuş başka bir soyutlamadan ibarettir ve katı biçimde düz bir anahtar-nesne deposudur.
    Dosya sistemi özelliklerine ihtiyacınız varsa bunları uygulamada hayata geçirirsiniz ya da bir dosya sistemi kullanırsınız.
    Yalnızca ekleme gerekiyorsa, ekleme zincirini bir veritabanıyla izleyip parçaları S3’te saklayabilirsiniz; uymuyorsa başka bir şey kullanırsınız.
    Kopyalama gerekiyorsa, veritabanında aynı nesneye yeni bir referans oluşturabilirsiniz; uymuyorsa başka bir şey kullanırsınız.
    S3 birçok kişiye iyi uyuyor, bu yüzden onu başka bir şeye dönüştürmeye çalışmamak gerekir.
    Yerleşik alan terimlerinin anlamını değiştirmeye çalışmayı da bırakmak gerekir; dosya sistemi ders kitaplarında açıklanan bir kavramdır ve S3 hiçbir zaman dosya sistemi olduğunu iddia etmemiştir.
    İşletim sistemi tasarımı hakkında biraz çalışmak da gerçekten faydalı ve eğlencelidir.

  • Apache Arrow’un object_store’u ile Apache OpenDAL API’sini karşılaştıran bir tartışma https://github.com/apache/arrow-rs/issues/3888 adresinde yapılmıştı.
    Apache OpenDAL, S3 ve çeşitli bulut depolama hizmetleri dâhil olmak üzere birçok backend üzerinde dosya sistemi benzeri bir API sağlayan bir kütüphanedir.
    GreptimeDB ve Databend gibi bazı veritabanı sistemleri, bulut depolamadaki verilere erişmek için OpenDAL’ı daha iyi bir S3 SDK’sı gibi kullanır.
    S3 üzerinde dosya sistemi benzeri bir arayüz yönetmeye yönelik başka çözümler olarak Alluxio ve JuiceFS de var; ancak Apache OpenDAL’ın aksine ayrı dağıtım ve kendilerine ait dahili metadata servisi gerektirirler.

    • TrinoDB için yerel önbellek katmanı olarak Alluxio’nun OpenDAL ile değiştirilebilir olup olmadığından pek emin değilim.

  • S3’ten söz ederken Backblaze B2’den de bahsetmeye değer.
    Fiyatı S3’ten 3 kat düşük olduğu için çok hoşuma gidiyor; Backblaze ile bir bağım yok.

    • Backblaze B2 ucuzdur ama üretim ortamında kullanacaksanız maliyete dâhil etmeniz gereken şeyler vardır.
      Her hafta PST 11:30-13:30 arasında 2 saatlik bir bakım penceresi bulunur; genelde kesinti olmaz ama bazen ABD mesai saatlerinin tam ortasında tüm hizmeti etkileyen arızalar da yaşanır.
      Hata oranı kullanılamaz seviyeye çıktığında destek talebi açmamız gerekti; son birkaç yılda kabaca yılda bir kez bunu yaşadık.
      Destek ekibi, kendi taraflarında hata günlükleri ya da görünürlük yokmuş gibi sayısız soru soruyor ve sorunu gerçekten incelemiyor.
      Yüklemenin başarılı olduğu yanıtını verip gerçekte B2 sisteminde 0 bayt olarak saklanan sahte başarı durumları da var; bu yüzden başarı kodlarında bile yüklemeyi mutlaka doğrulamak gerekir.
      Log4j2 CVE’si gibi yüksek önem dereceli açıklar çıktığında, 10 saatlik kesinti gibi uzun arızalar da yaşanabilir.
      Fiyatı mükemmel, ancak daha olgun bulut depolama servisleriyle doğrudan karşılaştırılabilecek bir ürün değil.
    • Alternatif hizmetlerde temel mesele her zaman verinin, o şirkete güvenebildiğiniz ölçüde güvende olmasıdır.
      Yine de iki katmanlı harici yedeklemeyle bunun bir ölçüde telafi edilebileceğini düşünüyorum.
    • B2 iyiydi ama IPv4 adres maliyeti ödeyerek kullanmaya değecek kadar değil.
      Kendini multicloud çözümü diye pazarlayıp NAT gateway ve IPv4 ücretlerinin her yerde eklendiği bir durumda benimsenebilirliğini fiilen ortadan kaldırması şaşırtıcı.
      Okumanın çok, yazmanın az olduğu bir kullanımımız vardı; B2 bant genişliği ücretlerini ödesek bile tasarruf edebiliyorduk, ancak NAT64 gateway’den geçmek ya da B2’ye erişmek için saatlik ücret ödemek gerekirse durum böyle olmuyor.

  • Güzel bir yazı; bulut depolamayı rclone mount ile FUSE üzerinden bağlama yolculuğuna başlamadan önce okumuş olsaydım faydalı olurdu
    Birçok yinelemeden sonra rclone’da S3, Google Cloud Storage, Azure Blob, OpenStack Swift, Oracle Object Storage gibi depolamaları POSIX’e benzeyen bir dosya sistemi katmanına uyduran bir VFS katmanı oluştu; asıl rclone mount kodu da bunun üzerinde ince bir katman
    VFS katmanının çeşitli uyumluluk seviyeleri var; off düzeyinde yalnızca dizin önbelleklemesi yapıyor
    Bu modda, yazıda söylendiği gibi aynı dosyayı aynı anda okuyup yazamazsınız, dosyanın ortasına yazamazsınız ve dosyalar yalnızca sıralı olarak yazılabilir
    Şaşırtıcı biçimde, bu kısıtlarla bile epey çok şey düzgün çalışıyor
    Bir sonraki seviye olan writes, aynı dosyayı aynı anda okuma-yazma, dosyanın ortasına yazma gibi uygulamaların istediği POSIX özelliklerinin çoğunu destekliyor; ancak dosyanın yerel bir kopyasını oluşturma ve dosya kapatıldığında bunu asenkron olarak yükleme maliyeti getiriyor
    VFS önbellekleme modu dokümantasyonu, yazıdaki kısıtları iyi yansıtıyor: https://rclone.org/commands/rclone_mount/#vfs-file-caching
    Temelde S3’te gerçek dizinler de yok; bu yüzden içinde dosya olmayan bir dizininiz olamıyor ve dizinlerin değişiklik zamanı gibi geçerli metaverileri de bulunmuyor
    / ile biten 0 baytlık dosyalar olan dizin işaretçileri oluşturabilirsiniz; rclone dahil birçok araç bunu destekliyor
    Boş dizinlerin olmaması genelde büyük sorun değil; çünkü VFS katmanı bunları sahte olarak oluşturuyor ve çoğu uygulama kısa süre sonra içine bir şey yazıyor
    Sonuçta S3 gibi görünen bir şeyi POSIX dosya sistemi gibi göstermek oldukça fazla iş ve açık bir dosyanın adını değiştirme gibi davranışların ve zorlu uç durumların arkasında çok sayıda hile var
    rclone’un düşük seviyeli move/sync/copy komutları bu tür işlemler yapmıyor ve S3 API’sini neredeyse olduğu gibi kullanıyor
    S3 API’sinde bir şeyi değiştirebilseydim, listeleme sırasında metaveriyi de okuyan bir seçenek olmasını isterdim
    rclone dosya değişiklik zamanını nesne metaverisinde saklıyor, ancak bunu toplu olarak okumanın bir yolu olmadığı için her nesne için HEAD yapmak gerekiyor
    Ya da yükleme sırasında nesnenin Last-Modified değerini ayarlayabilmek de iyi olurdu

    • Metaveriyi anahtar adının kendisine kaydetmek gibi bir yolla bunun etrafından dolaşılabilir mi diye düşünüyorum
      Anahtar uzunluğu sınırı 1024 olduğu için saklanabilecek metaveri miktarı sınırlı, ama dosya yolunu hesaba katsanız bile oldukça geniş
      Normalize edilmiş bir yolda geçersiz olan // gibi bir ayırıcı kullanıp /path/to/file.txt//mtime=1710066090 şeklinde koyabilirsiniz
      Yine önekle “dizini” alabilir, // değerini önek gibi kullanarak dosyayı doğrudan getirebilirsiniz
      Ancak böyle bir biçim diğer yazılımlarla uyumluluğu ciddi biçimde bozacak gibi görünüyor
    • Listelemeye metaveriyi dahil eden bir seçenek olmasının iyi olacağına katılıyorum
      MinIO’da, uygun yetkiler olduğunda listelemeye metaveri ve etiketleri dahil eden metadata=true adlı “gizli” bir parametre eklediler
      Bir genişletme olduğu için güvenilir biçimde kullanılabilecek bir şey değil, ama rclone her zaman deneyip mümkünse kullanabilir
      / ile biten 0 baytlık dosyalar da mümkün, ancak listelemedeki paylaşılan öneklerin kendisini dizin olarak da görebilirsiniz
      O zaman dizinlerin durumu olmaz ve içinde nesne yoksa var olamaz; bunun da artıları ve eksileri var
      Yükleme sırasında Last-Modified ayarlanabilseydi istemci kısıtları azalırdı, ama sunucu zamanının referans alınmasının da bir avantajı var
      İstemci tarafı çoğaltma veya yansıtma işlemlerinde de aynı kısıtlarla başa çıkmak gerekiyor
      Kişisel olarak en büyük şikayetim, tek bir nesnenin sürüm bilgilerini döndüren bir HeadObjectVersions olmaması
      ListObjectVersions, verilen önekin gerçekten bir önek mi yoksa nesne anahtarı mı olduğunu bilemediği için her zaman küme çapında bir işlem olmak zorunda kalıyor
      AWS yakın zamanda GetObjectAttributes ekledi, ancak ona çok yakışacak sürüm bilgisi bunun içine konmadı

  • S3’teki “Simple”, “derin değil” anlamına değil, gereksinimleri karşılamak için en az sayıda parçaya ihtiyaç duyduğu anlamına geliyor
    Dağıtık, merkezi, çoğaltmalı, yüksek erişilebilirlikli, yüksek dayanıklılıklı, yüksek bant genişlikli, düşük gecikmeli, güçlü tutarlılığa sahip, senkron, ölçeklenebilir bir nesne depolamaya ve üstüne HTTP REST API’ye ihtiyacınız varsa, bunu S3’ten daha basit yapmanın zor olduğunu düşünüyorum
    AWS S3’e uzun süre içinde birçok özellik eklendi, ancak temel davranış aynı kaldı

    • Yazının kullandığı terimlerle “gerekli asgari parçalar” tam olarak derin anlamına geliyor
      Ousterhout’un 『A Philosophy of Software Design』 kitabının ölçütlerine göre basitlik karmaşık olmamak demek; Rich Hickey’nin “Simple Made Easy” konuşması da aynı bağlamda
      Buna karşılık “derin”, küçük bir arayüzle içeride karmaşık pek çok işlev sunmak anlamına geliyor; bu yüzden S3 için “basit”ten çok bu ifade daha uygun
      Bu, S3’te pek bir şey olmadığı anlamındaki basitlikten farklı
      https://www.infoq.com/presentations/Simple-Made-Easy/
    • Yazının ifadesini izlersek, basitliğin neredeyse derinliği ve dar bir arayüzü ima ettiğini de söyleyebiliriz