Nesne depolamanın evrimi, erken Ceph ve Swift uygulamaları gibi merkezi meta veri veritabanalarından, hiperskalaya sahip dağıtık mimarilere doğru kaymıştır. Bu geçiş, atomik yeniden adlandırmalar, katı sıralama gibi POSIX benzeri anlamların gereksinimi ile milyarlarca anahtarı SSD, HDD ve Bant katmanları arasında yönetmek için gerekli yatay ölçeklenebilirlik arasında temel bir gerilim oluşturmuştur. Temel sorun, geleneksel İki Aşamalı Taahhüt (2PC) protokollerinin veya Paxos tabanlı küresel uzlaşmanın gecikme cezalarını üstlenmeden dağıtılmış düğümler arasında eşzamanlı mutasyonları koordine etmektir.
Çözüm, her bir parçanın ait olduğu ad alanı bölümü ile ilgili olan bir şardlı uzlaşma mimarisi gerektirir; bu da Raft protokolünü kullanarak o sınır içindeki lineerleştirilebilen tutarlılığı sağlamaktadır. Bir Metadata Yönlendirici katmanı, dizin öneklerine dayalı olarak istemci taleplerini yönlendirir ve alan sorguları için yereliteyi korumak üzere tutarlı hashleme kullanırken yatay ölçeklenmeyi sağlamaktadır. Performans açısından, sıcak meta veriler, L1 için Redis ve L2 kalıcılığı için yerel RocksDB içeren bir Katmanlı Önbellek içerisinde yer alırken, soğuk meta veriler, dayanıklılığı tehlikeye atmadan depolama maliyetlerini azaltmak için S3 üzerinde Apache Parquet dosyalarına sıkıştırılmaktadır.
AWS S3'ten özel bir hibrit buluta geçiş yapan bir medya şirketi, kodlama profilleri, DRM anahtarları ve yaşam döngüsü durumlarını izleyen meta verilerin yönetimini yapması gereken 2 milyar video segmenti ile karşı karşıyadı. Başlangıçtaki mimarileri, otomatik parçalara ayırma ile birlikte MongoDB kullanıyordu, ancak bu yapı, parça taşımaları sırasında öngörülemeyen gecikme zirveleri (100-500 ms) yaşadı ve eşzamanlı klasör taşınmaları sırasında veri bozulmasına neden olan atomik çapraz parça işlemlerinden yoksundu.
Çözüm 1: CockroachDB (Dağıtık SQL)
Bu yaklaşım, yerel yatay ölçeklenmeyi ve Google Spanner benzeri mimarisiyle sıralama izolasyonu sunmaktadır. Ana avantajı, meta veriler üzerine karmaşık analiz sorguları için tanıdık SQL arayüzü sağlamasıdır. Ancak, sistem çok bölgedeki uzlaşma kopyalama nedeniyle yüksek yazma amplifikasyonu (3-5x) sergilemekteydi ve viral içerik yüklemeleri sırasında yazma rekabetinin arttığı zamanda gecikme sürekli olarak 20 ms'yi aşmaktaydı. Petabayt ölçeğindeki meta veri depolama için lisanslama maliyetleri, organizasyon için ekonomik olarak sürdürülebilir olmaktan çıkmıştır.
Çözüm 2: Apache Cassandra ile Hafif İşlemler (LWT)
Cassandra, büyük yazma verimliliği ve ayarlanabilir tutarlılık sağladı; Paxos tabanlı LWT'ler, lineerleştirilebilen işlemler sunmaktadır. Bu teknoloji, yüksek hızda akan meta veri akışlarını tek bir arıza noktası olmadan alım konusunda oldukça başarılıydı. Ne yazık ki, Paxos'un gecikmesi ortalama 15 ms oldu ve eşzamanlı erişim altında önemli ölçüde kötüleşti; “yükleme tarihine göre listele” sorguları için ikincil dizin oluşturma, pahalı tam tablo taramaları gerektirdiği için etkileşimli kullanıcı deneyimleri için uygun olmadı.
Çözüm 3: Raft ile Özel Dizin Başına Parça
Bu tasarım, her kullanıcı dizinini özel bir Raft uzlaşma grubuna eşleştirdi ve bir kanaldaki (erişim için birincil birim) işlemlerin lineerleştirilebilen ve hızlı bir şekilde yerel disk erişimi sağladı. Mimari, çapraz ağ koordinasyonu olmaksızın parça yerel işlemler aracılığıyla atomik yeniden adlandırmaları desteklemekteydi. Bu, viral dizinlerin (sıcak noktalar) yeniden parçalanmasında karmaşıklık getirmiş olsa da ve sofistike bir istemci yanlısı yönlendirme kütüphanesi gerektirse de, video içeriğinin doğal olarak yaratıcıya göre bölümlenmesinde mükemmel uyum sağladı.
Sonuç: Sistem, viral etkinlikler sırasında saniyede 80.000 meta veri işlemini başarıyla sürdürebilmiş ve P99 gecikmesi 3 ms'nin altında kalmıştır. Otomatik katmanlama politikaları, yaşlanan içeriğin %90'ını soğuk depolamaya taşıdı; toplam altyapı maliyetlerini %60 oranında azaltırken aktif içerikler için sıkı tutarlılık garantileri sağlamıştır.
Popüler bir nesne süresi dolduğunda veya güncellendiğinde meta veri önbelleğinde sürükleyici kalabalık sorununu nasıl önlersiniz?
Adaylar sıklıkla basit bir TTL tabanlı sona erme önerirken, sürükleyici korumasını göz önünde bulundurmamaktadır. Doğru yaklaşım, geri plandan yalnızca kiralama sahibinin yenileme yapmasını sağlamak ve diğerlerinin beklemesi veya kısa bir süre için eski verileri sunması için önbellek girişlerinin kısa ömürlü kiralama jetonları taşıdığı kiralama tabanlı önbellekleme uygulamaktadır. Bu yapıyı, olasılıklı erken sona erme (TTL'lere rastgele sarsıntı eklenmesi) ve singleflight modeli ( Go'nun singleflight paketinde uygulandığı gibi) ile birleştirin; bu, eşzamanlı kimlik bilgileriyle olan talepleri bir arka uç sorgusuna sıkıştırarak önbellek boşluğunda veritabanı aşımını önleyecektir.
Canlı bir parça bölme (yeniden parçalara ayırma) işlemi sırasında meta veri tutarlılığını nasıl sağlarsınız, küme kesintisi olmadan?
Birçok kişi geçiş sırasında yazmanın durdurulmasını önerir, bu da kullanılabilirlik gereksinimlerini ihlal eder. Doğru teknik, gölge dizinleme ve çift yazma protokollerini kullanır. Öncelikle, yeni hedef parçayı Raft günlük gönderimi kullanarak kaynak parçanın geriden gelen bir kopyası olarak başlatın. Senkronize olduktan sonra, yazma yolunu yeni parçaya geçirin ve yavaş okuma izinleri için eski parçanın içerisinde bir mezar taşı günlüğü tutarak bir süre sağlıklı kaldığından emin olun. etcd gibi bir koordinasyon hizmeti, yönlendirme tablosunu atomik olarak güncellerken, MVCC zaman damgaları geçiş sırasında okuma işlemlerinin tutarlı anlık görüntüler görmesini sağlamakta ve atomik geçiş tamamlanana kadar bölünme sınırını aşan talepleri reddetmektedir.
Asenkron çöp toplama veya katmanlama geçişleri sessizce başarısız olduğunda, meta veri dizinini fiziksel depolama katmanıyla nasıl uzlaştırırsınız?
Bu, dağıtık işlemler için bir olay kaynaklı yaklaşım ve Saga desenleri gerektirir. Meta veri hizmeti, Apache Kafka günlüğüne alan olayları (örneğin, "Katmanlama Başlatıldı") yayımlarken, depolama tüketicisi başarılı işleme gerçekleştirdiğini idempotent geri arama ile onaylar. Depolama katmanı, belirli bir zaman aşımı süresi içinde nesneyi geçiştirmezse, meta veri hizmeti bir Saga zaman aşımı olayı alır ve meta veri durumunu "SICAK" olarak geri döndürmek için bir telafi işlemi başlatır. Ek olarak, bir arka planda uzlaşma tarayıcısı uygulamaları ile Merkle ağaçları kullanarak, meta veri ve fiziksel depolama HEAD talepleri arasındaki uyumsuzlukları verimli bir şekilde belirlemek ve tam tablo taramaları gerektirmeden tutarsızlıkları onarmak için uygulama yapılmalıdır.