Bir depolama kuruluş stratejisi tasarlama

Tamamlandı

Verileri depolaması gereken bir uygulama tasarlarken, uygulamanın verileri depolama hesapları, kapsayıcılar ve bloblar arasında nasıl düzenleyeceğini düşünmek önemlidir.

Depolama hesapları

Tek bir depolama hesabı, bloblarınızı düzenlemek için yeterince esnektir. Ancak, maliyetleri mantıksal olarak ayırmak ve verilere erişimi denetlemek için gerektiğinde daha fazla depolama hesabı kullanmanız gerekir.

Kapsayıcılar ve bloblar

Uygulamanızın yapısı ve depolanan veriler, kapsayıcıları ve blobları adlandırma ve düzenleme stratejinizi yönlendirmelidir.

Blobları veritabanı içeren bir depolama düzeninin parçası olarak kullanan uygulamaların genellikle verileriyle ilgili herhangi bir şey belirtmek için kuruluşa, adlandırmaya veya meta verilere yoğun bir şekilde güvenmesi gerekmez. Bu uygulamalar genellikle blob adı olarak GUID değerlerini kullanır ve veritabanı kayıtlarında bu tanımlayıcılardan faydalanır. Uygulama, blobların nerede depolandığını ve içerdikleri veri türünü belirlemek için veritabanını kullanır.

Diğer uygulamalar Azure Blob Depolama daha çok kişisel dosya sistemi gibi kullanır. Kapsayıcı ve blob adları anlamı ve yapısını gösterir. Bu tür uygulamalardaki blob adları genellikle geleneksel dosya adları gibi görünür. İçerdikleri veri türünü belirtmek için .jpg gibi dosya adı uzantıları içerebilirler. Bu tür uygulamalar blobları düzenlemek için sanal dizinleri kullanır. Bloblar ve kapsayıcılar hakkındaki bilgileri depolamak için sıklıkla meta veri etiketlerini kullanırlar.

Blobları ve kapsayıcıları düzenleme ve depolama konusunda dikkat etmeniz gereken birkaç önemli nokta vardır.

Adlandırma sınırlamaları

Kapsayıcı ve blob adlarının uzunluk sınırları ve karakter kısıtlamaları gibi uymaları gereken kurallar vardır. Adlandırma kuralları hakkında daha ayrıntılı bilgi için bu modülün sonundaki Daha Fazla Okuma bölümüne bakın.

Genel erişim ve güvenlik sınırı olarak kapsayıcılar

Varsayılan olarak bloblara erişmek için kimlik doğrulaması gerekir. Ancak tek tek kapsayıcıları, kimlik doğrulaması olmadan bloblarının genel olarak indirilmesine izin verecek şekilde yapılandırabilirsiniz. Genel indirme, statik web sitesi varlıklarını barındırma ve dosya paylaşma gibi birçok kullanım örneğini destekler. Blob içeriklerini indirme işlemi web üzerinden diğer verileri okumakla aynı şekilde çalıştığından bu yaklaşım işe yarar. Blob URL'sinde bir tarayıcıyı veya GET isteğinde bulunabilecek herhangi bir şeyi işaret edersiniz.

Genel erişimin etkinleştirilmesi ölçeklenebilirlik açısından önemlidir. Doğrudan Blob Depolama'dan indirilen veriler, sunucu tarafı uygulamanızda herhangi bir trafik oluşturmaz. Genel erişime hemen izin vermeseniz bile genel kullanıma açık olmasını istediğiniz veriler için ayrı kapsayıcılar kullanmayı veya veri erişimini denetlemek için bir veritabanı kullanmayı planlayın.

Dikkat

Depolama URL'lerini bilen herkes, herhangi bir kimlik doğrulaması veya denetim olmadan genel erişim için yapılandırılmış bir kapsayıcıdaki blobları indirebilir. Herkesle paylaşmak istemediğiniz blob verilerini asla herkese açık bir kapsayıcıya eklemeyin.

Azure, genel erişime ek olarak kapsayıcılarda gelişmiş izinler sunan paylaşılan erişim imzası özelliğine de sahiptir. Duyarlık erişim denetimi, ölçeklenebilirliği daha da geliştiren senaryolara olanak tanır, bu nedenle kapsayıcıları güvenlik sınırları olarak düşünmek yararlı olur.

Blob adı ön ekleri (sanal dizinler)

Kapsayıcılar düz. Herhangi bir iç içe yerleştirmeyi veya hiyerarşiyi desteklemez. Bloblarınıza finans/bütçeler/2017/q1.xls gibi dosya yolları gibi görünen hiyerarşik adlar verirseniz, API'nin listeleme işlemi sonuçları belirli ön eklere göre filtreleyebilir. Bu yaklaşım, listede dosya ve klasör hiyerarşik bir sistemmiş gibi gezinmenizi sağlar.

Bazı araçlar ve istemci kitaplıkları, Blob Depolama bir dosya sistemi gibi görselleştirmek ve gezinmek için bu yaklaşımı kullanır. Klasörde yapılan gezintiler, o klasördeki blobların listesine ayrı bir çağrı yapılmasını sağlar. Bu özellik genellikle sanal dizinler olarak adlandırılır.

Dekont

Hesabın hiyerarşik ad alanı özelliğini etkinleştirirseniz, dizinler artık sanal değildir. Bunun yerine, doğrudan üzerinde çalışabileceğiniz somut, bağımsız nesneler haline gelirler. Herhangi bir dosya içermeden bir dizin bulunabilir. Bu modülde yalnızca hiyerarşik ad alanı özelliği etkin olmayan hesaplar açıklanmaktadır.

Blob türleri

Verileri depolayabileceğiniz üç farklı blob türü vardır:

  • Blok blobları, birbirinden bağımsız ve paralel olarak karşıya yüklenebilecek farklı boyuttaki bloklardan oluşur. Bir blok blobuna veri yazmak için verilerin bloklara yüklenmesi ve bloba gönderilmesi gerekir.
  • Ekleme blobları , mevcut verileri güncelleştirmeyi veya silmeyi değil, yalnızca yeni verileri eklemeyi destekleyen özel blok bloblarıdır. Bu amaçla verimlidirler. Ekleme blobları, günlükleri depolama veya akış verilerini yazma gibi senaryolar için idealdir.
  • Sayfa blobları , rastgele erişimli okuma ve yazma işlemleri içeren senaryoları destekler. Sayfa blobları, Azure Sanal Makineler tarafından kullanılan sanal sabit disk (VHD) dosyalarını depolamak için kullanılır. Bunlar, rastgele erişim içeren tüm senaryolar için mükemmeldir.

Blok blobları, özellikle ekleme veya sayfa bloblarına ihtiyaç duyulmayan tüm senaryolar için en iyi seçimdir. Blok tabanlı yapısı, blobun tek tek parçalarına hızlı karşıya yükleme ve indirme işlemlerini ve verimli erişimi destekler. Çoğu istemci kitaplığı blokları otomatik olarak yönetir ve işler. Bazıları performansı en üst düzeye çıkarmak için paralel karşıya yüklemeleri ve indirmeleri de işler.

Bilgilerinizi kontrol edin

1.

Müşterilerinizin profil ve sipariş bilgilerini depolamanız gerektiğini düşünelim. "En iyi 100 müşterim kim?" ve "belirli bir coğrafi bölgede kaç müşteri yaşıyor?" gibi soruları yanıtlamak için verileri sorgulamanız gerekiyor. Doğru veya yanlış: Blob depolama bu veriler için doğru bir seçenek midir?

2.

Bloblar yapılandırılmamış veri depolama sağlar. Yapılandırılmamış ne anlama gelir?