Veri depoları için en iyi uygulamalar

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 tablolar gibi 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, bunlar ayrıca otomatik unutulma hakkı işleme ile oyuncu verilerini tanımlamaya 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. Ardından, o oyuncunun profillerini listelemek için User_123456/Profile anahtarını ListKeysAsync() fonksiyonuna geçirebilirsiniz.

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 kaydetme 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ıkta döngü başlatmadan ö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 gürültü 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 alma ile yeniden deneyin. Her gecikmeye rastgele gürültü 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 sağlayamayacak işlemlerden kaynaklanan hataları yeniden denemeyin.

Her anahtar için veri deposu yeniden denemelerini sırayla işleyin. Daha yeni bir isteğin başarılı olduktan sonra yeniden denemesi, 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.

SetAsync yerine UpdateAsync'ı tercih edin

Bir yazma işlemi mevcut değere bağlı olduğunda veya birden fazla sunucunun aynı anahtarı yazabileceği durumlarda UpdateAsync() kullanmayı 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çok sunucunun okuduğu ancak nadiren güncellediği paylaşılan veriler için, aynı kaydın kopyalarını içeren birden fazla anahtar arasında okumaları dağıtın. Bu yaklaşımı yalnızca anahtar başına okuma kısıtlamasını ele almak için kullanın; gereksiz istekleri azalttıktan sonra. Yazma kısıtlamalarını çözmez veya deneyim düzeyi veya sunucu düzeyi istek bütçelerini artırmaz.

Örneğin, bir deneyim boyunca Admin Abuse olayının Hava Durumu'nu değiştirdiğini düşünün. Her sunucu, mevcut havayı tek bir Weather anahtarından okursa, o anahtar okuma verimlilik sınırına ulaşabilir, oysa hava nadiren değişir. Bunun yerine, Weather_1, Weather_2 ve Weather_3 gibi sabit bir anahtar seti altında kopyaları saklayın. Her sunucu, başlangıçta DataModel.JobId'sini sabit sete hashleyerek bir parça atayarak, okumaların anahtarlar arasında yayılmasını sağlar. Her sunucu yalnızca atanan kopyasını okur.

Paylaşılan anahtarları, hava durumu kopyalarını içerecek şekilde anket yaparken, ilk okumadan önce rastgele bir başlangıç gecikmesi ekleyin ve sonraki okumalar arasında sınırlı rastgele gürültü ekleyin. Sunucuların değişiklikleri gözlemleme hızını, okuma verimlilik sınırı ile dengeleyen bir anket aralığı seçin. Her sunucunun aynı anda okuma yapmasını önleyin, örneğin, paylaşılan bir olay bildiriminden hemen sonra. Daha fazla bilgi için Tekrarlayan istekleri sıraya koyun bölümüne bakın.

Hava durumu değiştiğinde, her kopyayı güncelleyin. Bu yazmalar anahtarlar arasında atomik değildir, bu nedenle sunucular geçici olarak farklı hava durumu durumları okuyabilir. Kaydın çoğaltılması, yazmaları artırır ve tutarlılığı ve gelecekteki geçişleri daha karmaşık hale getirir. Bu yaklaşımı, tüm okuyucular arasında atomik güncellemeler gerektiren veriler için veya zaten anahtar başına okuma verimlilik sınırının altında kalan veriler için kullanmayın.

Bir operasyon iş akışı oluşturun

Mevcut araçları birlikte kullanın:

1. 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ın sınırlarına yaklaştığında veya aştığında sizi bilgilendirir ve rehberlik ve gösterge tablolarına bağlantılar içerir.
2. İ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.
3. 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.
4. Kasvetli bir şekilde ölçeklendirin. Öncelikle gereksiz depolama ve istekleri azaltın. Mevcut kullanım, varsayılan kotaları aşıyorsa, Genişletilmiş Hizmetleri değerlendirin.

Open Cloud ve oyun sunucuları, deneyim düzeyi 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 sayılır ve sürümler, daha önceki değerleri incelemenize veya geri yüklemenize olanak tanır.

Geçici ve hızla değişen veriler için bellek depoları kullanın. Bellek deposu verileri otomatik olarak süresi dolduğunda sona erer ve kalıcı veri deposu depolamasına eklenmez.

Test verilerini test sona erdiğinde silin ve süresi dolmuş olaylar veya emekliye ayrılmış özellikler için verileri kaldırın. Bir veri deposunu silme için 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ığından emin olun.