noSQL - Web tabanlı oyun için geçerli bir seçenek mi? [kapalı]

Bir fırsattan ve sıkıntıdan, bir arkadaşım ve ben web tabanlı bir oyun yapmaya karar verdik. Bu django'da genellikle web uygulamaları programladığım için yapacağım ilk 'oyun'.

Oyun için aynı çerçeveyi kullanmayı seçtim, ancak veri depolama konusunda tam olarak emin değilim, çünkü gelecekteki gereksinimleri ve DB ile ilgili sorunları öngöremiyorum. Son zamanlarda, noSQL hareketi güç kazanıyor ve bu bölgeyi keşfetmek istiyorum.

Bu nedenle aşağıdaki sorularım var:

• Bir noSQL veri depolama alanı (MongoDB gibi belge tabanlı) web tabanlı bir oyun için uygun olur mu?
• MySQL gibi geleneksel bir RDBMS kullanarak ortaya çıkabilecek sorunlar nelerdir?
• Oyun sırasında veya cron işleri gibi zamanlı etkinliklerde MongoDB kullanıcıları arasında veri tutarlılığı nasıl sigortalanır?

Oyuna genel bakış: Oyuncu canavarlarla dövüşerek ve eşya kazanarak tipik macera oyunu.

• Bazı veriler tüm oyuncular arasında statiktir: eşyalar, silahlar, iksir, haritalar vb.
• Oynatıcıya bağlı bazı veriler: envanter, metrikler (istatistikler), ilerleme durumu vb.
• Bir oyuncunun başka bir oyuncunun istatistiklerini ve durumunu bilmesi gerekebilir
• Zamanlanan görevler belirli bir zaman aralığında çalıştırılacak

NoSQL veritabanı web tabanlı bir oyun için uygun mudur?

Kesinlikle! Genel olarak, ilişkisel olmayan veritabanları (MongoDB gibi) oyunlar için çok daha iyidir, çünkü ilişkisel veritabanlarından (SQL gibi) daha fazla performans gösterirken verileri modelleme konusunda daha esnektirler. seçim.

Geleneksel bir RDBMS kullanarak ortaya çıkabilecek sorunlar nelerdir?

İlişkisel veritabanlarını kullanmanın iki önemli dezavantajı vardır:

• Verileri modelleme biçiminizde esneklik eksikliği
• Verim

İlişkisel bir veritabanı kullanmak, verileri modelin ihtiyaçlarını karşılayan veritabanı yerine veritabanının ihtiyaçlarına uyacak şekilde modellemeye zorladığından, verileri modelleme biçiminizde esneklik eksikliği büyük bir dezavantajdır. Örneğin, ilişkisel bir veritabanı kullanarak bir oyunda öğeleri nasıl depolayacağınıza ilişkin bir model oluşturduğunuzu ve aşağıdaki modele karar verdiğinizi düşünün:

weapon_type_id | weapon_type
1 | sharp

weapon_id | weapon| weapon_type_id | damage
1 | Short Sword | 1 | 5

potion_type_id | potion_type
1 | HP
2 | Mana

potion_id | potion| potion_type_id | modifier
1 | Healing Elixer | 1| 5
2 | Mana Drainer | 2| -5

Şimdi aşağıdakileri yapmak için modeli nasıl değiştirmeniz gerektiğini düşünün:

• Yeni bir öğe türü ekle
• Birden fazla silah türüyle bir silah oluşturun
• Silah olarak da kullanılabilecek bir iksir eşyası oluşturun

Kesinlikle tüm bu eylemler yapılabilir, ancak bunları yaparken en mutlu kişi olmayacaksınız ve muhtemelen, "orada yapmak istediğim şey için daha iyi bir çözüm var mı?" ilişkisel olmayan bir veritabanında çok daha esnek bir model tasarlar.

Not: Belge tabanlı veritabanlarının bilgileri nasıl sakladığını bilmiyorsanız, devam etmeden önce lütfen bu bağlantıyı kontrol edin . Aşağıda sunulan model, yukarıda bahsedilen makalede sunulanlara benzer bir mantık kullanmak üzere tasarlanmıştır.

db.itemTypes

name: Weapon
types: Sharp

name: Potion
types: HP, Mana

db.items

name: Short Sword
weapon
    type: Sharp (db.itemTypes reference)
    damage: 5

name: Healing Elixer
potion
    type:  HP (db.itemTypes reference)
    modifier: 5

name: Mana Drainer
potion
    type:  Mana (db.itemTypes reference)
    modifier: -5  

name:  Healing Potion Sword
potion
    type: HP (db.itemTypes reference)
    modifier: 10
weapon
    type: Sharp (db.itemTypes reference)
    damage: 15

NoSQL vs SQL veritabanlarının performansı hakkında birçok iyi makale var, ancak burada kendi testlerinizi yapabilmeniz için uygulama örnekleri sağlayan bir makale var: MongoDB vs. SQL Server 2008 Performance Showdown

MongoDB kullanan kullanıcılar arasında veri tutarlılığını nasıl garanti ederim?

MongoDB, tek veri varlıklarında (belgeler) okuma / yazma atomik işlemlerini destekler, bu nedenle MongoDB'den gelen sorgu sonuçları her zaman veritabanında depolananlarla doğru olmalıdır.

Düzenleme: Öğe veritabanının NoSQL örneği sağlandı

Birkaç kelime SQL veritabanlarını savunur.

1 - SQL veritabanınız varsa, verilerinizle yalnızca birincil anahtarla çalışamazsınız. MMO'daki sorguların çoğu PK tarafından gider, ancak düzey> 30 olan tüm kullanıcıları bulmanız gerektiğinde NoSQL dünyasında ne yapacaksınız?

2 - SQL diliniz varsa bozuk verileri onarmak için "düzeltmeler" oluşturabilirsiniz. Örneğin: "güncelleme player_items set flag = 0 burada item_type_id = 100". Bunu NoSQL'de nasıl düzeltebilirsiniz? Sanırım tüm verilerinizi ayrıştıracak bir komut dosyası yapmanız gerekecek ...

3 - SQL veritabanları düşündüğünüz kadar yavaş değildir. Meslektaşlarım MySQL'de saniyede 5000 işlem yapan web tabanlı MMO oyununu yaratıyor. Senin için yeterli değil mi? Değilse, veritabanınızı ölçeklemek için parçalama kullanabilirsiniz.

4 - SQL'in yabancı anahtar kısıtlamaları ve kodunuzdaki hataları bulmanıza yardımcı olacak iyi şeyler vardır.

NoSQL gümüş bir kurşun değildir. Sadece birkaç problemi çözer ve birçok yeni problem getirir. Bu yüzden tavsiyem - NoSQL'i seçmeden önce iki kez düşünün.

Cevap evet, geçerli bir seçenek ama hayır, muhtemelen harika bir fikir değil .

SQL konusunda, oyun söz konusu olduğunda NoSQL'in ele almaya çalıştığı iki büyük sorun vardır.

Birincisi gecikme veya gecikmedir. Bir anlamda, SQL veritabanları çok hızlıdır ve saniyenin onda birinde binlerce işlem veya daha fazlasını işler. Başka bir deyişle, inanılmaz derecede yavaşlar, çünkü sadece birkaç işlemi işlemek aynı zaman alabilir. Çoğu veritabanı kullanımı için bu önemli değildir, ancak oyunların gerçek zamanlı bir bileşeni vardır, bu yüzden sadece saniyede kaç işlem yapabileceğinizle ilgili değil, aynı zamanda bir veritabanı işlemine yanıt vermek için geçen ortalama süre hakkındadır.

Bu gecikme, gerçek zamanlı oyunlar için büyük bir sorundur. Büyük veritabanlarına (genellikle MMO'lar için) ihtiyaç duyan birçok geliştirici, bu duraklardan kaçınmak için veritabanı ve oyun sunucuları arasında oturan bir önbellek katmanı oluşturur ve ardından önbelleği düzenli olarak temizler. Sorun? Bir veritabanı kullanmanın ana nedenlerini - atomisite, tutarlılık, izolasyon ve dayanıklılık - attınız .

Ancak bu sorun web oyunları için geçerli değildir. Zaten oyuncu ve oyun arasında yüksek gecikmeli bir bağlantınız var, bu nedenle SQL'in sağladığı verimi ve olgun, iyi bilinen yazılımın avantajlarını elde edebilirsiniz.

Ancak ikinci sorun sizin için de geçerlidir ve bu, nesne-ilişkisel empedans uyumsuzluğudur . Oyunlar nesnelerle, veritabanları satırlarla ilgilenir. Şanslıysanız, bir nesne yalnızca alanlarını listeleyerek bir satıra dönüştürülebilir, ancak çoğu zaman nesneler hiyerarşiktir ve bunları satırlara almak için bir şekilde düzleştirmeniz gerekir.

CouchDB ve MongoDB gibi belge tabanlı veritabanları, belgeyi satır yerine en üst düzey nesneye yükselterek bu sorunu çözer (bu durumda "belge", "nesne" ile eşanlamlıdır). Ancak bunu yaparak, SQL veritabanlarının birçok faydasını kaybederler. Verim çok daha düşüktür ve kilitleme algoritmaları çok daha karmaşık hale gelir.

İyi haber şu ki, kullandığınız dil için zaten birçok nesne-ilişkisel haritalama (ORM) aracı var. Hafızadaki nesneler ve veritabanındaki satırlar arasında oldukça şeffaf bir şekilde tercüme etmenizi sağlar. Bu araçlar genellikle büyük ölçekli gerçek zamanlı oyunlar için uygun değildir, çünkü SQL ve NoSQL veritabanlarının en kötü performans özelliklerini sunabilirler. Ama bir web oyunu için iyi - en kötü ihtimalle, performans sorunlarıyla karşılaştığınızda, eski moda bir şekilde işlem yapmaya geri dönebilirsiniz. Gecikme sorunu size zarar vermez ve artan iş hacmi size yardımcı olur.

Son olarak, başka bir yerde bahsettiğim bir noktayı işaretlemek için : Bu, statik oyun verileriyle ilgili değil. Eşya açıklamalarınızdan ya da silah hasarınızdan, spritelarınızdan ya da buradaki herhangi bir şeyden bahsetmiyorum. Bir oyuncunun envanterinde ne olduğu veya istatistiklerinin ne olduğu gibi gerçek, değiştirilebilir oyun verileri demek istiyorum. Statik veriler için ihtiyacınız olan tek şey bir veri deposudur. Belki de en kolay şey, büyük bir ORM'niz olduğu için bunun için veri deposuyla aynı veritabanını kullanmak olduğu ortaya çıkıyor; belki sadece dosya sistemine ihtiyacınız vardır. Bu iki ayrı sorundur ve bir cevap her iki duruma da uymak zorunda değildir (ve muhtemelen uymaz).

• Bir noSQL veri depolama alanı (MongoDB gibi belge tabanlı) web tabanlı bir oyun için uygun olur mu?

Sofadb'ye bir göz atmanızı tavsiye ederim

Arayüzü javascript tabanlıdır, bu nedenle HTML5 / javascript tabanlı oyunlarla oldukça iyi karışacaktır.

Ayrıca 'çevrimdışı' çalışabilir (db'nin yerel bir kopyasını oluşturur) ve daha sonra kendini sunucuyla senkronize edebilir (örneğin, örneklenmiş zindanlar için kullanabilirsiniz)

• MySQL gibi geleneksel bir RDBMS kullanarak ortaya çıkabilecek sorunlar nelerdir?

Asıl mesele, sql olmayan veritabanlarının ilişkisel veritabanlarından oldukça farklı bir şekilde işlemesi olacaktır. Zihinsel geçişi yapmak zor olabilir.

Örneğin, couchdb'de " sorguların " nasıl yapıldığına bir göz atın . Her şey javascript ile yapılır.

• Oyun sırasında veya cron işleri gibi zamanlı etkinliklerde MongoDB kullanıcıları arasında veri tutarlılığı nasıl sigortalanır?

Veritabanlarını 'senkronize etme' sürecine couchdb'nin dilindeki çoğaltma denir . Ayrıca tutarlılık terimini de çok göreceksiniz . Çoğaltma ve tutarlılık ile ilgilenen birkaç yerleşik hizmet vardır. Örneğin, artımlı çoğaltma işlemine bakın.

Oyununuzda ne olduğuna bağlı olarak, her ikisini de kullanarak oyununuzdaki modellere bağlayabilirsiniz. Örnek oyuncusu için ve oyuncu modülü böylece, NoSQL gidebileceğini RDB (giriş bilgisi) ancak oyuncu envanter / değişken depolama olmalıdır olabilir login()RDB kullanarak ve fetchInventory()birincil anahtar ile NoSQL kullanarak.

Haritalar örneğin daha iyi NoSQL (koordinatlar => örneğin farklı nesnelerin dizi) kaydedilecek bir alan RDB (ne bir kısmını okumak için tamamen serileştirmek için gereken seri hale getirilmiş bir dize hariç) ne kaydettiğinizi düşünmüyorum? ve RAM boşa harcanır!) yine de RDB'deki alanları kaydedebilirsiniz, örneğin "şehir X" aşağıdaki kordinatları / bloğu içerir ([3,4], [8,7] ...)

her ikisini de kullanabilir ve muhtemelen kullanmanız ve ihtiyacınız olabilecek memcache veya geçici veriler gibi geçici depolamaya bir göz atmanız gerekir (kesin olarak sabit disk kullanmaktan daha hızlı olurdu! ve size çok fazla CPU kaydeder, ancak RAM'i kurtarmaz)

böylece sonunda>

oyunda ne olmasını istediğinize bağlı! Cheerz