noSQL - È un'opzione valida per i giochi basati sul web? [chiuso]

Per un'opportunità e una noia, un amico e io abbiamo deciso di creare un gioco basato sul web. Questo è il primo "gioco" che farò, dato che di solito programma applicazioni web in django.

Ho scelto di utilizzare lo stesso framework per il gioco, ma non sono completamente sicuro dell'archiviazione dei dati, dal momento che non posso prevedere requisiti futuri e problemi relativi al DB. Ultimamente, il movimento noSQL sta guadagnando forza e vorrei esplorare quell'area.

Pertanto ho le seguenti domande:

• Un datastorage noSQL (basato su documenti, come MongoDB) sarebbe adatto per un gioco basato sul web?
• Quali sono i problemi che potrebbero sorgere utilizzando un RDBMS convenzionale, come MySQL?
• Come assicurare la coerenza dei dati assicurativi tra gli utenti con MongoDB, durante il gioco o in occasione di eventi a tempo, come cron job?

Panoramica del gioco: tipico gioco di avventura, con il giocatore che combatte mostri e guadagna oggetti e simili.

• Alcuni dati sono statici per tutti i giocatori: oggetti, armi, pozioni, mappe, ecc.
• Alcuni dati legati al giocatore: inventario, metriche (statistiche), progressi, ecc.
• Un giocatore potrebbe aver bisogno di conoscere le statistiche e lo stato di un altro giocatore
• Le attività pianificate verranno eseguite a un certo intervallo di tempo

Un database noSQL sarebbe adatto per un gioco basato sul web?

Assolutamente! In generale, i database non relazionali (come MongoDB) sono molto migliori per i giochi, in quanto sono più flessibili nel modo in cui modellano i dati, pur essendo più performanti dei database relazionali (come SQL), rendendoli un "win-win" scelta.

Quali sono i problemi che potrebbero sorgere utilizzando un RDBMS convenzionale?

Esistono due principali svantaggi nell'utilizzo dei database relazionali:

• Mancanza di flessibilità nel modo di modellare i dati
• Prestazione

La mancanza di flessibilità nel modo in cui si modellano i dati è un grosso svantaggio, perché l'uso di un database relazionale ti costringe a modellare i dati per adattarli alle esigenze del database, piuttosto che al database che soddisfa le esigenze del modello. Ad esempio, considera di creare il modello per la modalità di archiviazione degli oggetti in un gioco utilizzando un database relazionale e decidi il modello seguente:

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

Ora considera come dovresti modificare il modello per soddisfare le seguenti esigenze:

• Aggiungi un nuovo tipo di elemento
• Crea un'arma con più tipi di armi
• Crea un oggetto pozione che può essere usato anche come arma

Certamente tutte queste azioni sono realizzabili, ma non sarai la persona più felice mentre le stai facendo, e probabilmente ti chiederai "esiste una soluzione migliore per quello che voglio fare?", Quando puoi progettare un modello molto più flessibile in un database non relazionale.

Nota: se non si ha familiarità con il modo in cui i database basati su documenti archiviano le informazioni, consultare questo collegamento prima di continuare. Il modello presentato di seguito è progettato per utilizzare una logica simile a quella presentata nel suddetto articolo.

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

Ci sono molti buoni articoli sulle prestazioni dei database NoSQL vs SQL, ma eccone uno che fornisce esempi di applicazione in modo da poter eseguire i propri test: MongoDB vs SQL Server 2008 Performance Showdown

Come posso assicurare la coerenza dei dati tra gli utenti con MongoDB?

MongoDB supporta operazioni atomiche di lettura / scrittura su singole entità di dati (documenti), quindi i risultati delle query da MongoDB dovrebbero essere sempre precisi con ciò che è memorizzato nel database.

Modifica: fornito esempio NoSQL del database degli articoli

Un paio di parole difendono i database SQL.

1 - Se si dispone di un database SQL, è possibile lavorare con i dati non solo tramite chiave primaria. La maggior parte delle query in MMO viene eseguita da PK, ma quando devi trovare tutti gli utenti con livello> 30 cosa farai nel mondo NoSQL?

2 - Se si dispone di un linguaggio SQL, è possibile creare "hotfix" per riparare i dati non funzionanti. Ad esempio: "aggiorna player_items set flag = 0 dove item_type_id = 100". Come puoi risolvere questo problema con NoSQL? Penso che dovrai creare uno script che analizzerà tutti i tuoi dati ...

3 - I database SQL non sono così lenti come puoi pensare. I miei colleghi creano il gioco MMO basato sul web, che effettua 5000 transazioni al secondo in MySQL. Non è abbastanza per te? In caso contrario, è possibile utilizzare lo sharding per ridimensionare il database.

4 - SQL ha un vincolo di chiave esterna e cose così buone, che ti aiuteranno a trovare bug nel tuo codice.

NoSQL non è un proiettile d'argento. Risolve solo un paio di problemi e porta molti nuovi problemi. Quindi il mio consiglio: pensaci due volte prima di scegliere NoSQL.

La risposta è sì, è un'opzione valida ma no, probabilmente non è una grande idea .

Esistono due problemi principali con SQL che NoSQL tenta di risolvere quando si tratta di giochi.

Il primo è latenza o ritardo. In un certo senso, i database SQL sono incredibilmente veloci, elaborando migliaia di transazioni o più in decimi di secondo. In un altro senso, sono incredibilmente lenti, perché l'elaborazione di poche transazioni può richiedere lo stesso tempo. Per la maggior parte degli utilizzi del database, questo non ha importanza, ma i giochi hanno un componente in tempo reale, quindi non si tratta solo di quante transazioni puoi fare al secondo, ma del tempo medio impiegato per rispondere a una transazione del database.

Questa latenza è un grosso problema per i giochi in tempo reale. Molti sviluppatori che necessitano di database di grandi dimensioni (in genere per MMO) creano un livello di memorizzazione nella cache che si trova tra il database e i server di gioco per evitare queste bancarelle e quindi svuotare periodicamente la cache. Il problema? Hai appena eliminato i motivi principali per utilizzare un database: atomicità, coerenza, isolamento e durata .

Ma quel problema non si applica ai giochi web. Hai già una connessione ad alta latenza tra il giocatore e il gioco, quindi potresti anche ottenere il throughput fornito da SQL, nonché i vantaggi di un software maturo e ben noto.

Il secondo problema, tuttavia, si applica a te, e questa è la discrepanza di impedenza relazionale oggetto . I giochi si occupano di oggetti, i database si occupano di file. Se sei fortunato, un oggetto può essere trasformato in una riga semplicemente elencando i suoi campi, ma la maggior parte delle volte gli oggetti sono gerarchici e devi appiattirli in qualche modo per metterli in righe.

Database basati su documenti, come CouchDB e MongoDB, risolvono questo problema promuovendo il documento sull'oggetto di livello superiore, anziché sulla riga ("documento" in questo caso è sinonimo di "oggetto"). In questo modo, perdono molti dei vantaggi dei database SQL. Il throughput è molto più basso e gli algoritmi di blocco diventano molto più complicati.

La buona notizia è che ci sono già molti strumenti di mappatura relazionale a oggetti (ORM) disponibili per qualsiasi linguaggio tu stia usando. Ti consentono di tradurre tra oggetti in memoria e righe nel database in modo abbastanza trasparente. Questi strumenti non sono generalmente appropriati per i giochi in tempo reale su larga scala, perché possono presentare gli aspetti peggiori delle prestazioni dei database SQL e NoSQL. Ma va bene per un gioco Web - nel peggiore dei casi, quando si verificano problemi di prestazioni, è possibile tornare a fare transazioni alla vecchia maniera. Il problema di latenza non ti danneggia e la maggiore produttività ti aiuta.

Infine, per sostenere un punto che ho sottolineato altrove : non si tratta di dati di gioco statici. Non sto parlando delle descrizioni dei tuoi oggetti o del danno dell'arma o degli sprite o altro qui. Intendo i dati di gioco reali e mutevoli, come quelli che sono nell'inventario di un giocatore o quali sono le sue statistiche. Tutto ciò che serve per i dati statici è un archivio dati. Forse si scopre che la cosa più semplice da fare è usare lo stesso database dell'archivio dati perché hai un ORM eccezionale; forse avrai solo bisogno del filesystem. Sono due problemi distinti e una risposta non deve (e probabilmente non si adatta) ad entrambi i casi.

• Un datastorage noSQL (basato su documenti, come MongoDB) sarebbe adatto per un gioco basato sul web?

Consiglio di dare un'occhiata a couchdb

La sua interfaccia è basata su javascript, quindi si fonderà abbastanza bene con i giochi basati su HTML5 / javascript.

È anche in grado di funzionare "off-line" (creando una copia locale del db) e quindi sincronizzarsi con il server in un secondo momento (ad esempio, è possibile utilizzarlo per i dungeon istanziati)

• Quali sono i problemi che potrebbero sorgere utilizzando un RDBMS convenzionale, come MySQL?

Il problema principale sarebbe che i database no-sql gestiscono in modo abbastanza diverso dai database relazionali. Fare il passaggio mentale può essere difficile.

Ad esempio, dai un'occhiata a come vengono eseguite le " query " in couchdb. Tutto è fatto in JavaScript.

• Come assicurare la coerenza dei dati assicurativi tra gli utenti con MongoDB, durante il gioco o in occasione di eventi a tempo, come cron job?

Il processo di "sincronizzazione" dei database è chiamato replica nel gergo di couchdb. Vedrai anche il termine coerenza molto. Esistono diversi servizi integrati che si occupano di replica e coerenza. Vedere ad esempio il processo di replica incrementale .

A seconda di ciò che hai nel gioco, potresti finire per usarli entrambi e collegarli attraverso i modelli del gioco. Ad esempio, il lettore potrebbe e dovrebbe trovarsi in RDB (informazioni di accesso) ma l'inventario del giocatore / l'archiviazione variabile potrebbe passare a noSQL, quindi il modulo del lettore potrebbe login()utilizzare RDB e fetchInventory()utilizzare noSQL dalla chiave primaria.

Mappe per esempio migliori per essere salvate in NoSQL (coordinate => array di oggetti diversi per esempio) non immagino di salvare ciò che un'area contiene in RDB (tranne una stringa serializzata che è necessario annullare la serializzazione completa per leggere alcune parti di? Più CPU e RAM sprecata!) bene potresti comunque salvare aree in RDB, ad esempio l'area "città X" contiene i seguenti coordinate / blocco ([3,4], [8,7] ...)

potresti e probabilmente dovresti usare entrambi e dare un'occhiata all'archiviazione volatile come memcache di cui potresti aver bisogno o alcuni dati temporanei (sarebbe sicuramente più veloce dell'uso del disco rigido e ti risparmia molta CPU ma sicuramente non RAM)

così alla fine>

dipende da cosa vuoi avere nel tuo gioco! Cheerz