Bu uygulamaları, yaşam döngüsü boyunca güvenilir, ölçeklenebilir ve gözlemlenebilir verileri düzenlemek ve yönetmek için kullanın.
Verilerinizi düzenleyin
Daha az veri deposu oluşturun
Veri depoları, veritabanlarındaki tablolara benzer şekilde davranır. Küçük, sabit bir veri deposu seti kullanın ve kayıtları anahtar ile bunlar içinde düzenleyin. Örneğin, her oyuncunun profilini her oyuncu için ayrı bir veri deposu oluşturmak yerine tek bir PlayerData veri deposunda saklayın.
Her oyuncu için bir veya birkaç anahtar kullanın
Her oyuncunun kalıcı verilerini, verilerin 4 MB nesne boyutu sınırına uyduğu sürece tek bir anahtar altında saklayın. Örneğin, PlayerData veri deposunda User_123456 gibi bir anahtar kullanın. Bu desen, istekleri azaltır, ilgili değerleri atomik olarak güncellemenizi sağlar ve geri alma işlemlerini daha kolay hale getirir.
Bir oyuncunun verilerinin farklı bölümleri farklı erişim desenlerine veya anahtar başına boyut veya verimlilik sınırlarına yaklaşırsa, kaydı az sayıda belirleyici anahtara ayırın. Atomik olarak değişmesi gereken verileri aynı anahtar içinde tutun.
Statik anahtar desenleri ve önekleri kullanın
Anahtar adlarını, User_{UserId} gibi sabit tanımlayıcılardan ve statik desenlerden oluşturun. Değişebilecek görüntüleme adları veya diğer değerleri kullanmayın. Statik desenler, anahtarların sunucular ve araçlar arasında öngörülebilir olmasını sağlar. Veri depoları için, otomatik unutulma hakkı işleme oyuncu verilerini tanımlamanıza da olanak tanır.
İlgili anahtarları gruplamak için önekler kullanın. Örneğin, birden fazla karakter profilini destekleyen bir deneyim, User_123456/Profile/Warrior ve User_123456/Profile/Mage gibi anahtarlar kullanabilir. Daha sonra User_123456/Profile anahtarını ListKeysAsync() ile geçirerek o oyuncunun profillerini listeleyebilirsiniz.
Alanlar, bir veri deposunu alt bölümlere ayırmanın bir başka yoludur. Bir alan, o veri deposu örneğindeki her anahtara bir dize ekler ve varsayılan değer globaldır.
Veri deposu modüllerini değerlendirin
Üçüncü taraf veri deposu modülleri her zaman bir seçenek olup, birçok durumda sıfırdan sistemler inşa etmekten daha tercih edilebilir. Birini benimsemeden önce, sahipliğini, bakım durumunu ve özellik setlerini gözden geçirin. Verilerinizi modül olmadan nasıl erişeceğinizi ve taşıyacağınızı anlayın.
İstekleri azaltın ve dağıtın
Oyuncu verilerini bellekte tamponlayın
Bir oyuncunun verilerini bir oturumun başında yükleyin ve oyun oynama için sunucuya yerel bir kopyasını saklayın. Her değişiklik için bir veri deposu isteği göndermek yerine yerel kopyayı güncelleyin. Bunu periyodik olarak, oyuncu ayrıldığında, sunucu kapandığında ve satın alma işlemleri gibi kritik kontrol noktalarında kaydedin. Periyodik bir kayıt aralığı seçin; bu aralık istek sınırlarınız içinde kalmalı ve herhangi bir oturum kilidi süresinden daha kısa olmalıdır; oyuncu verileri ve satın alma örneği 180 saniye kullanır.
Tekrarlayan istekleri sıraya koyun
Her sunucudan aynı programda tekrarlayan istekler başlatmayın. Sabit bir sıklık döngüsüne başlamadan önce, her sunucuya veya oyuncuya rastgele bir başlangıç kaydırması atayın. Kesin bir ritim gerektirmeyen anket veya koordinasyon döngüleri için her aralığa sınırlı rastgele dalgalanma ekleyin. Bu desenler, istekleri zaman içinde dağıtır ve senkronize trafik zirvelerini azaltır.
Geçici hataları yeniden deneyin
İstekleri pcall() içinde sarın ve geçici hataları üstel geri dönüş ile yeniden deneyin. Her gecikmeye rastgele dalgalanma ekleyin, böylece sunucular aynı anda yeniden deneme yapmaz. Gecikmeyi ve deneme sayısını sınırlayın ve geçersiz istekler veya artık yararlı sonuçlar veremeyen işlemlerden kaynaklanan hataları yeniden denemeyin.
Her anahtar için veri deposu yeniden denemelerini sırayla işleyin. Daha eski bir istek, daha yeni bir isteğin başarılı olmasından sonra yeniden denendiğinde, daha yeni verileri geçersiz kılabilir. Ayrıca, bilinmeyen sonuçlarla yazmaları da dikkate alın: başarısız bir çağrı, sunucunun başarılı bir yanıt almadığı anlamına gelir, ancak arka uç yazmayı tamamlamış olabilir. Daha fazla bilgi için Veri deposu hata kodları ve sınırları ve Yeniden denemeler bölümüne bakın.
UpdateAsync'i SetAsync'ten tercih edin
Bir yazma işlemi mevcut değere bağlı olduğunda veya birden fazla sunucunun aynı anahtarı yazabileceği durumlarda UpdateAsync()'i tercih edin. UpdateAsync(), yazmadan önce geri çağrınıza en son değeri okur, bu da kaybolan güncellemeleri azaltır. SetAsync() anahtarı önce okumadan geçersiz kılar ve iki sunucu aynı anda yazarsa tutarsızlığa neden olabilir.
Yeni bir anahtar oluşturduğunuzda veya önceki değere bağlı olmayan bir değeri değiştirdiğinizde SetAsync() kullanın. İki yöntem arasındaki karşılaştırma için Set vs update bölümüne bakın.
Sıcak anahtarları parçalayın
Her anahtarın okuma ve yazma verimlilik sınırları vardır. Bir mantıksal kayıt, gereksiz istekleri azalttıktan sonra bu sınırları sürekli olarak aşıyorsa, onu belirleyici anahtarlar arasında parçalayın. Her sunucunun aynı veriyi aynı parçaya yönlendirmesi için User_{UserId}_Inventory_{ShardId} gibi bir tanımlayıcıdan sabit bir parça seçin.
Parçalama, tutarlılığı korumayı ve gelecekteki geçişleri gerçekleştirmeyi daha karmaşık hale getirir. Bir anahtar içinde kalan ve verimlilik sınırlarının altında kalan verileri parçalamayın.
Bir operasyon iş akışı oluşturun
Mevcut araçları birlikte kullanın:
- Gözlemleyin. İstekleri, yanıt durumunu, verimliliği ve depolamayı izlemek için Veri Depoları Gözlemlenebilirlik Gösterge Tablosu kullanın. Ekibinizin sürekli hatalara veya beklenmedik büyümelere yanıt verebilmesi için önemli veri deposu metrikleri için özel uyarılar yapılandırın. Creator Hub bildirimleri, depolamanızın sınırları aşmaya yaklaştığında veya aştığında sizi bilgilendirir ve rehberlik ve gösterge tablolarına bağlantılar içerir.
- İnceleyin. Veri depolarını, anahtarları, depolama kullanımını ve tahmini maliyetleri incelemek için Veri Depoları Yöneticisi kullanın. Deneyim 100'den fazla veri deposuna sahipse, Veri Depoları listesi boyut ve anahtar sayısını göstermez. Bu metrikler için Open Cloud veya Veri Depoları Toplu İşlemci kullanın.
- Düzeltin. Bireysel kayıtlar için Veri Depoları Yöneticisi'ni kullanın. Tekrarlanabilir veya büyük ölçekli iş akışları için Open Cloud veri deposu API'lerini veya Veri Depoları Toplu İşlemci kullanın.
- Kasvetli bir şekilde ölçeklendirin. Öncelikle gereksiz depolama ve istekleri azaltın. Meşru kullanım varsayılan kotaları aşıyorsa, Genişletilmiş Hizmetleri değerlendirin.
Open Cloud ve oyun sunucuları, deneyim düzeyindeki istek bütçesini paylaşır. Operasyonel Open Cloud betiklerini, canlı trafiği etkilemeyecek şekilde hız sınırlayın.
Veri yaşam döngüsünü yönetin
Her revizyon için yeni bir anahtar oluşturmak yerine veri deposu sürümlerini kullanın. Bir anahtarın yalnızca en son sürümü depolama kullanımına dahil edilir ve sürümler, daha önceki değerleri incelemenize veya geri yüklemenize olanak tanır.
Geçici ve hızlı değişen veriler için bellek depolarını kullanın. Bellek deposu verileri otomatik olarak süresi dolar ve kalıcı veri deposu depolamasına eklenmez.
Test verilerini test sona erdiğinde silin ve süresi dolmuş etkinlikler veya emekli olmuş özellikler için verileri kaldırın. Bir veri deposunu silinmek üzere işaretledikten sonra, onu geri yükleyebileceğiniz 30 günlük bir tampon süresi vardır. Bu 30 günün ardından, Roblox veri deposunu kalıcı olarak siler. Daha fazla bilgi için Veri Depoları Yöneticisi bölümüne bakın.
Unutulma hakkı işleme ayarlarını yapılandırın
Statik veri deposu ve anahtar desenlerini izleyen oyuncu verileri için otomatik unutulma hakkı (RTBF) işleme yapılandırın. Otomatik RTBF, uygun bir isteği işlerken silme şablonlarınızı uyguladığı için tercih edilen iş akışıdır.
Otomatik RTBF, veri şemanızı desteklemiyorsa, özel bir silme iş akışı yürütmek için silme hakkı webhook'unu kullanın. Her iki iş akışının da tüm eşleşen oyuncu verilerini kaldırdığını doğrulayın.