Gerçek Zamanlı Çok Oyunculu Oyun için hangi Veritabanı (RDBMS vs NoSQL vs BOTH) kullanılacak?

Bir veritabanı gerektiren gerçek zamanlı çok oyunculu bir oyun üzerinde çalışıyorum (oyuncu profilleri, arkadaşlar, kilit açma, haberler vb. Gibi özellikler için) Bu standart bir PC oyunu (tarayıcı tabanlı değil) ve bir istemci-sunucu kullanacak mimari. Ben veritabanları kullanmak için yeniyim ve son birkaç gündür sıcak tartışmalara tökezlediğim bazı araştırmalar yaptım: RDBMS vs NoSQL. Şu anda NoSQL doğru eğik ama her biri (RDBMS ve NoSQL) kullanımları hakkında okuduktan sonra, her ikisini de kullanmak için cazipim. Bunun garip gelebileceğini biliyorum, ama durumumu açıklayayım:

Ekibim, sınırsız mySQL depolama ve bant genişliği sunan paylaşılan bir web barındırma paketine sahiptir; tek uyarı, aynı anda yalnızca 25 bağlantıya sahip olabilmemizdir (paylaşılan barındırma kuralı). Haber güncellemeleri, topluluk özelliklerini (yorumlar, hayran resmi yükleme vb.) Ve benzerlerini göndermek için web sitem için (şüphesiz tipik bir kullanım) kullanmayı planlıyorum. Hepsi iyi ve iyi - ama! işlerin ilginç olduğu yer burası ... Web sitemde yayınlanan aynı bilgileri oyun içinde göstermek istiyorum. Bu, hem web sitem hem de oyunum için mySQL kullanmak anlamına gelir. Haber gönderileri ve benzerlerine ek olarak, sohbet ve sunucu listesi gibi şeyler için oyun içinde kullanmayı planlıyorum. Çoğunlukla bu 25 bağlantı kuralı hakkında endişeliyim.

Hangi soru sormam için beni yönlendiriyor Soru # 1: Bu işe yarar mı ve daha iyi bir alternatif var mı?

Şimdi bunun yanı sıra, NoSQL'in ne kadar iyi performans gösterdiğini ve gerçek zamanlı oyunlar için ne kadar uygun olduğunu okudum (yanlış olabilirim, buraya ulaşmak için büyük bir RDBMS vs NoSQL alev savaşı yürüdüm ve muhtemelen yanıyorum). Temel olarak, tüm oyun nesnesi verilerim için MongoDB kullanmak istiyorum.

Ve yine, bazı bağlam sağlarsanız yararlı olacaktır: Ücretsiz bir 240MB MongoDB paketi sunan bir ana bilgisayar (MongoLab) buldum, yükseltme gerekene kadar kullanmayı planlıyorum. 240 MB verildiğinde, yaklaşık 60.000 oyuncuyu depolayabileceğimi hesapladım (her oyuncu kabaca 4KB ise ve depolanabilecek diğer şeyleri göz ardı edersek). Depolama alanı ve gelecekte daha fazla para ödemek zorunda (oyunumuz başarılı olursa) sorun değil. Şu anda tüm oyun nesnesi verilerim için MongoDB'yi kullanmayı planlamamın tek nedeni, bu oyun nesnesi verilerine ne sıklıkta erişileceğidir (örneğin, bir oyuncunun öldüğü, bir eşyayı aldığı, bir silah ateşlediği vb.) ayrıca şema içermeyen düz belgeler gibi (bu da oyun nesnesi verilerinin eşlenmesini kolaylaştırır). Şunu not etmeliyim ki, bir zamanlar,

Oyuncu profil bilgilerini görüntülemek için web sitemde aynı MongoDB'yi kullanmayı planlıyorum (tam tutarlılıkla ilgilenmiyorum, oyun içi güncellemelerden biraz gecikme olması iyi). Bu da beni ikinci sorum olan Soru # 2'ye yönlendiriyor: Bu iyi bir fikir mi yoksa daha iyi yapmam gereken bir şey mi var?

Oyun buna benzer bir başlangıç ​​deneyimine sahip olacak:

1. Müşteri girişleri (MongoDB)
2. Müşteri, sohbet odalarıyla oyun içi ana sayfada (MySQL)
3. İstemci sunucu listesine gider (MySQL)

4. İstemci bir sunucuya bağlanır ve içinde oynatır

5. Sunucu tüm oyuncular için güncellemeleri bildirir (MongoDB)

Tam da işe yarayacağını hayal ettiğim gibi. Bu size iyi geliyor mu veya bu planın nasıl geliştirilebileceğine dair önerileriniz var mı?

Benim önerim, oyununuzun oluşturduğunuz ve veritabanını sorgulamakla ilgilenen bir web servisiyle iletişim kurmasını sağlamaktır. Bu noktada, web hizmeti uygulamalarını "değiştirerek" (web hizmeti arayüzünüz her zaman aynı kalır, böylece oyununuz bozulmaz) farklı veritabanlarını denemek ve hangisinin sizin için doğru olduğuna karar vermek çok basittir.

Veritabanınızı doğrudan internete maruz bırakmamak da çok daha güvenli.

bir seferde yalnızca 25 bağlantımız açık olabilir (paylaşılan barındırma kuralı).

Bu, oyununuz için fazlasıyla yeterli. Sorun, web siteniz birden çok bağlantı kullanıyorsa, bitebilir. Web sunucunuzu, geri kalanını oyun sunucunuz için bırakarak yalnızca az sayıda kullanacak şekilde yapılandırmanız gerekir. Oyun sunucunuzun gerçekten 1'den fazla bağlantıya ihtiyacı yoktur, ancak bir avuç bulundurmaktan yararlanabilir.

Şimdi bunun yanı sıra, NoSQL'in ne kadar iyi performans gösterdiğini ve gerçek zamanlı oyunlar için uygun olduğunu okudum (yanlış olabilirim, buraya ulaşmak için büyük bir RDBMS vs NoSQL alev savaşı yürüdüm ve muhtemelen yanıyorum). Temel olarak, tüm oyun nesnesi verilerim için MongoDB kullanmak istiyorum.

Biraz yanlış bir argüman, çünkü her iki sistem de hızlı tempolu gerçek zamanlı bir oyun için ana mağaza olarak kullanmak için yeterince hızlı değil - gerçekten hafızadaki değerleri tutmanız ve değiştirmeniz gerekiyor. Bu yüzden veritabanına sadece kesinlikle ihtiyacınız olduğunda vurursunuz, bu da tüm karakteri sık sık (örneğin dakikada bir kez) kurtarmak olabilir, bu noktada hız farkları ihmal edilebilir hale gelir.

Komik olan şey, eğer MongoDB'yi en yüksek hız için ayarlarsanız, makul hızlı bir oyun içinden senkronize yazma yapabilmeniz için yeterince hızlı olacak bir noktaya gelebilirsiniz, ancak bu maliyette olacaktır. veri bütünlüğünden kaynaklanır çünkü yazmalar arabelleğe alınır. Bu, bir çökme durumunda bu verileri kaybettiğiniz anlamına gelir, bu nedenle yazma işlemini hiç yapmadan çok az nokta vardı ve düzenlemeyi bellekte gerçekleştirip daha sonra kaydettiğinizden hala daha yavaş, böylece her iki dünyanın en kötüsünü elde edersiniz .

Şu anda tüm oyun nesnesi verilerim için MongoDB'yi kullanmayı planlamamın tek nedeni, bu oyun nesnesi verilerine ne sıklıkta erişileceğidir (örneğin, bir oyuncunun öldürüldüğü, bir öğeyi aldığı, bir silah ateşlediği vb.)

Bir oyuncu bir silahı ateşlediğinde neden veritabanına yazmanız gerektiğini kendinize sorun. Bu neden oyun sunucusunda hafızada ele alınamıyor? Oyununuz çökerse ve daha sonra yeniden başlarsa ve oyuncu beklediklerinden daha fazla mermi olduğunu öğrenirse, bu kritik bir iş sorunu mu?

Ayrıca düz şema içermeyen belgeleri de seviyorum (bu da oyun nesnesi verilerini haritalamayı kolaylaştırıyor).

Bu, NOSQL yaklaşımını seçmek için performans sorunundan çok daha iyi bir nedendir.

Oyuncu profil bilgilerini görüntülemek için web sitemde aynı MongoDB'yi kullanmayı planlıyorum (tam tutarlılıkla ilgilenmiyorum, oyun içi güncellemelerden biraz gecikme olması iyi).

Bu iyi ve mantıklı. Daha sonra ayrı bir örnek kullanmak isteyebilirsiniz, böylece web okumaları oyun okumaları ve yazımları ile yarışmaz, ancak bu sorun, bunun bir sorun olacak kadar popüler olma sorununa kıyasla çözülmesi önemsiz bir sorundur.

Şahsen sadece iki veritabanından birini seçerdim, hangisinin benim için daha az işe yarayacağını ve bunun üzerinde standardize edeceğim - ama isterseniz iki ile devam edemezsiniz.

Tüm gerçek zamanlı verilerin uygulama belleğinde tutulması gerekir, başka her şey saçma olur.

Kullanıcıların giriş verilerini, istatistikleri vb. Tutmak oldukça hafif bir iştir, bu yüzden cesur olacağım ve istediğinizi hemen hemen kullanabileceğinizi söyleyeceğim. Web sitesine dikkat etmek isteyebilirsiniz, ancak kullanıcı listeleri gibi şeyler uygun bir önbellek sistemi yapmazsanız çok fazla veritabanı performansı emebilir.

Ve bummzack'in dediği gibi, her şeyi aynı ağda tutmalısınız. Bunun da ötesinde, ücretsiz şeyler hakkında dikkatli olun, 240 MB ücretsiz veritabanı depolama alanı iyi geliyor, ancak makine muhtemelen çok sayıda ücretsiz kullanıcı arasında bölünmüş olduğundan servis oldukça yavaş olabilir.

Veritabanı başına 60.000 kullanıcınıza güveniyor musunuz? Değilse, veritabanı yazılımının güvenliği konusundaki uzmanlığınız üst düzey değilse ve sonuçta ortaya çıkan sorunları çözebileceğinizden emin değilseniz, "istemciden veritabanı erişimi" fikrini karıştırmalısınız.