OSS kullanırken, verilerinizi gerçekte nasıl kullandığınıza göre depolama sınıflarını planlayarak ve abonelik ile kullandıkça öde faturalamayı birleştirerek maliyetleri önemli ölçüde azaltabilirsiniz.
Dikkat edilecekler
Aşağıdaki örneklerdeki birim fiyatlar, 30 Temmuz 2024 tarihinde Alibaba Cloud resmi web sitesinde yayımlanan detaylı OSS fiyatlandırmasından alınmıştır. Tek tek faturalandırılabilir öğelerin birim fiyatları, fiyatların toplandığı tarihe bağlı olarak farklılık gösterebilir. Her zaman Object Storage Service pricing sayfasında yayımlanan verilere bakın.
Aşağıdaki örnekler yalnızca yaygın depolama ve veri isteği senaryolarını kapsar. Diğer OSS özelliklerini kullanıyorsanız ek faturalandırılabilir öğeler uygulanabilir. Daha fazla bilgi için Billable items konusuna bakın.
Paket kapasitesi artışının beklentilerinizle uyumlu olup olmadığını kontrol edin
Verileri bir pakette depoladığınızda depolama ücretleri, verilerin depolama kapasitesine ve depolama sınıfına göre tahakkuk eder.
Maliyetlerinizi daha ayrıntılı görüntülemek için hesap düzeyindeki OSS kullanımını düzenli olarak sorgulayın ve kullanım ayrıntılarını bir CSV dosyası olarak dışa aktarın. Bu dosya, mevcut hesaptaki her paketin depolama kapasitesini listeler; böylece kapasite artışının beklenen olup olmadığını değerlendirebilirsiniz. Ayrıntılı adımlar için Query resource usage of an Alibaba Cloud account konusuna bakın.
Kapasite beklenmedik şekilde artarsa diğer kullanıcıların OSS kaynaklarınızda yetkisiz işlem yapmasını önlemek için Erişim Kontrol Listesini (ACL) özel olarak ayarlayın veya bir paket ilkesi yapılandırın. Bu tür işlemler arasında, kapasitenin ani artışına neden olan istenmeyen çok sayıda nesne yüklemek ve internet üzerinden giden trafiğe bağlı yüksek ücretlere yol açan nesnelere kötü niyetli erişim bulunur. Daha fazla bilgi için Reduce the risks of unauthorized access caused by AccessKey pair leaks konusuna bakın.
Paket sahibinin internet üzerinden giden trafik ve veri getirme ücretlerini azaltma
Bir paket sahibinin, diğer kullanıcıların paketteki verilere internet üzerinden erişmesine izin verdiğini ve istek sahiplerinin internet üzerinden giden trafik ile Seyrek Erişilen veriler okunduğunda oluşan kapasite ücretlerini ödemesini istediğini varsayalım. Bu durumda paket sahibi isteyen-öder modunu etkinleştirebilir. Ayrıntılı adımlar için Pay-by-requester konusuna bakın.
Aşağı yönlü trafik planları, isteyen-öder modu etkinleştirildikten sonra istek sahiplerinin OSS'den bir istemciye internet üzerinden veri indirdiğinde oluşan internet üzerinden giden trafik ücretlerini karşılayamaz. Bu modda internet trafiği ücretleri yalnızca gerçek kullanıma göre tahakkuk eder.
Yaşam döngüsü kuralları yapılandırma
OSS maliyetlerinizi daha etkili yönetmek ve azaltmak için maliyet verimliliğini en üst düzeye çıkarmak amacıyla yaşam döngüsü yönetim ilkelerinden tam olarak yararlanmanızı öneririz.
Erişim sıklığına ve yanıt süresi gereksinimlerine göre depolama sınıflarını geçirme
Bir veri kümesine daha az sıklıkla erişildiğinde veya verilere gerçek zamanlı erişim artık gerekli olmadığında erişim performansını etkilemeden verileri otomatik olarak daha düşük maliyetli bir depolama sınıfına taşımak için uygun yaşam döngüsü kuralları yapılandırın.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Depolama sınıfını Arşiv olarak ayarlarsanız ve Arşiv nesnelerinin gerçek zamanlı erişimini etkinleştirmezseniz verilere gerçek zamanlı olarak erişemez ve bunları okumadan önce nesneleri geri yüklemeniz gerekir.
Verilerinizin özelliklerine ve erişim sıklığına bağlı olarak belirli nesneleri önek veya etikete göre filtreleyebilir ve bunlar için yaşam döngüsü kuralları yapılandırabilirsiniz. Nadiren erişilen soğuk veriler otomatik olarak daha düşük maliyetli Arşiv depolamaya geçirilirken sıkça erişilen sıcak veriler daha hızlı okuma için Standart depolamada kalır. Bu yaklaşım depolama maliyetlerini optimize eder ve veri erişim verimliliğini artırır.
Aşağıdaki örnekler depolama maliyetlerinin nasıl hesaplandığını ve gereksinimleriniz için en uygun depolama sınıfının nasıl seçileceğini gösterir.
Nesnelerin önceki sürümlerini silme
Bir paket için sürüm oluşturma etkinleştirildikten sonra verilerin üzerine yazılması veya silinmesi işlemi önceki sürümler olarak korunur. Pakette çok sayıda önceki sürüm biriktiğinde artık ihtiyacınız olmayanları silmek ve depolama maliyetlerini azaltmak için yaşam döngüsü kurallarını kullanın.
Önerilen eylem
Nesneler belirtilen gün yaşına ulaştığında otomatik olarak silinmesi için bir yaşam döngüsü kuralı yapılandırmanızı öneririz.
Önceki yapılandırma örneğinde OSS son değiştirilme tarihi 200 günden eski olan nesnelerin önceki sürümlerini otomatik olarak siler. Ayrıntılı adımlar için Lifecycle rules based on last modification time konusuna bakın.
Süresi dolmuş parçaları silerek depolama maliyetlerini azaltma
Çok parçalı bir yüklemeden sonra parçaları birleştirmek için CompleteMultipartUpload işlemini çağırmazsanız parçalar pakette belirsiz bir süre kalır, depolama kapasitesini tüketir ve depolama ücretlerine neden olur.
Önerilen eylem
Parçalar belirtilen gün yaşına veya belirtilen bir tarihe ulaştığında otomatik olarak silinmesi için bir yaşam döngüsü kuralı yapılandırmanızı öneririz.
Önceki yapılandırma örneğinde OSS oluşturulma tarihi 2 günden eski olan parçaları otomatik olarak siler. Ayrıntılı adımlar için Lifecycle rules based on last modification time konusuna bakın.