Quale database (RDBMS vs NoSQL vs ENTRAMBI) utilizzare per un gioco multiplayer in tempo reale?

Sto lavorando a un gioco multiplayer in tempo reale che richiederà un database (per funzionalità come profili dei giocatori, amici, sblocchi, notizie, ecc.) Questo è un gioco per PC standard (non basato su browser) e utilizzerà un client-server architettura. Sono nuovo nell'uso dei database e ho fatto qualche ricerca negli ultimi giorni quando mi sono imbattuto nel dibattito acceso: RDBMS vs NoSQL. Attualmente mi sto avvicinando a NoSQL ma dopo aver letto degli usi per ciascuno (RDBMS e NoSQL), sono tentato di usare entrambi. So che può sembrare strano, ma lasciami spiegare la mia situazione:

Il mio team ha un pacchetto di web hosting condiviso che offre memoria e larghezza di banda mySQL illimitate, l'unico avvertimento è che possiamo avere solo 25 connessioni aperte contemporaneamente (regola di hosting condiviso). Ho intenzione di utilizzare questo per il mio sito Web (un uso tipico senza dubbio) al fine di pubblicare aggiornamenti di notizie, supportare funzionalità della community (come commenti, caricamento di fan art, ecc.) E simili. Va tutto bene e bene - ma! è qui che le cose si fanno interessanti ... Voglio mostrare queste stesse informazioni che sono pubblicate sul mio sito web, nel gioco. Questo significa usare mySQL sia per il mio sito web che per il mio gioco. Oltre ai post di notizie e simili, ho intenzione di usarlo nel gioco per cose come la chat e un elenco di server. Sono principalmente preoccupato per quella regola delle 25 connessioni.

Il che mi porta a porre la domanda n. 1: funzionerà e c'è un'alternativa migliore?

Ora oltre a questo, ho letto quanto bene funziona NoSQL ed è adatto ai giochi in tempo reale (potrei sbagliarmi, ho attraversato un'enorme guerra di fiamma RDBMS vs NoSQL per arrivare qui e probabilmente sono bruciato). Fondamentalmente, vorrei usare MongoDB per tutti i miei dati sugli oggetti di gioco.

E di nuovo, sarà utile se fornirò un contesto: ho trovato un host (MongoLab) che offre gratuitamente un pacchetto MongoDB da 240 MB, che intendo utilizzare fino a quando non sarà necessario aggiornarlo. Dato 240 MB, ho calcolato che sarò in grado di memorizzare circa 60.000 giocatori (se ogni giocatore ha circa 4KB e ignoriamo altre cose che potrebbero essere memorizzate). Lo spazio di archiviazione e dover pagare di più in futuro (se il nostro gioco avrà successo) non è un problema. L'unico motivo per cui intendo attualmente utilizzare MongoDB per tutti i miei dati sugli oggetti di gioco è a causa della frequenza con cui accederai a questi dati degli oggetti di gioco (come ogni volta che un giocatore viene ucciso, raccoglie un oggetto, spara una pistola, ecc.) I come i semplici documenti privi di schemi (che semplificano la mappatura dei dati degli oggetti di gioco). Dovrei notare che, una volta,

Intendo utilizzare lo stesso MongoDB nel mio sito Web, per visualizzare le informazioni sul profilo del giocatore (non mi preoccupo della coerenza completa, va bene qualche ritardo dagli aggiornamenti in-game). Il che mi porta alla mia seconda domanda, domanda n. 2: è una buona idea o c'è qualcosa di meglio che dovrei fare?

Il gioco avrà un'esperienza di avvio simile a questa:

1. Accesso client (MongoDB)
2. Il client è nella home page del gioco con chat room (MySQL)
3. Il client passa all'elenco dei server (MySQL)

4. Il client si connette a un server e ci gioca

5. Il server comunica gli aggiornamenti per tutti i giocatori (MongoDB)

Questo è solo il modo in cui immaginavo che avrebbe funzionato. Ti sembra buono o hai suggerimenti su come migliorare questo piano?

Il mio suggerimento è di far comunicare il tuo gioco a un servizio web creato da te che si occupa di interrogare il database. A quel punto, è molto semplice provare diversi tipi di database "cambiando" le implementazioni del servizio Web (l'interfaccia del servizio Web rimane sempre la stessa in modo che il gioco non si interrompa) e decidere quale è giusto per te.

È anche molto più sicuro non esporre direttamente il tuo database a Internet.

possiamo avere solo 25 connessioni aperte contemporaneamente (regola di hosting condiviso).

È più che sufficiente per il tuo gioco. Il problema è che se il tuo sito Web utilizza più connessioni, potresti esaurire. Devi configurare il tuo server web per usarne solo un piccolo numero, lasciando il resto al tuo server di gioco. Il tuo server di gioco non ha davvero bisogno di più di 1 connessione, ma potrebbe trarre vantaggio dall'avere una manciata.

Ora oltre a questo, ho letto di come si comporta NoSQL ed è adatto per i giochi in tempo reale (potrei sbagliarmi, ho attraversato un'enorme guerra di fiamma RDBMS vs NoSQL per arrivare qui e probabilmente sono bruciato). Fondamentalmente, vorrei usare MongoDB per tutti i miei dati sugli oggetti di gioco.

È un po 'un falso argomento, perché nessuno dei due sistemi è abbastanza veloce da usare come archivio principale per un gioco in tempo reale frenetico: devi davvero conservare e manipolare i valori in memoria. Quindi colpisci il database solo quando devi assolutamente, il che potrebbe essere solo per salvare l'intero personaggio ogni tanto (ad es. Una volta al minuto), a quel punto le differenze di velocità diventano trascurabili.

La cosa divertente è che se modifichi MongoDB per la massima velocità, puoi quasi arrivare a un punto in cui sarebbe abbastanza veloce per eseguire scritture sincrone all'interno di un gioco ragionevolmente veloce, ma questo sarebbe a costo di integrità dei dati perché le scritture sono memorizzate nel buffer. Ciò significa che perdi quei dati in caso di arresto anomalo, quindi era inutile eseguire la scrittura, ed è ancora più lento rispetto a quando hai appena eseguito la modifica in memoria e l'hai salvata in seguito, in modo da ottenere il peggio di entrambi i mondi .

L'unico motivo per cui al momento intendo usare MongoDB per tutti i dati dei miei oggetti di gioco è a causa della frequenza con cui si accederà a questi dati degli oggetti di gioco (come ogni volta che un giocatore viene ucciso, raccoglie un oggetto, spara una pistola, ecc.)

Chiediti perché devi scrivere nel database quando un giocatore spara una pistola. Perché non può essere semplicemente gestito in memoria sul server di gioco? Se il gioco si interrompe e successivamente si riavvia e il giocatore scopre di avere 3 proiettili in più di quanto si aspettasse, è un problema aziendale critico?

Mi piacciono anche i documenti privi di schemi (che semplificano la mappatura dei dati degli oggetti di gioco).

Questo è un motivo molto migliore per scegliere un approccio NOSQL rispetto al problema delle prestazioni.

Intendo utilizzare lo stesso MongoDB nel mio sito Web, per visualizzare le informazioni sul profilo del giocatore (non mi preoccupo della coerenza completa, va bene qualche ritardo dagli aggiornamenti in-game).

Va bene e ragionevole. In seguito potresti voler usare un'istanza separata, in modo che le letture sul web non siano in conflitto con le letture e le scritture di giochi, ma quel problema è banale da risolvere rispetto al problema di diventare abbastanza popolare da essere un problema.

Personalmente sceglierei solo uno dei due database, in base al quale uno sarebbe meno lavoro per me, e standardizzerei su quello - ma non c'è motivo per cui non puoi tenerne due se vuoi.

Tutti i dati in tempo reale devono essere conservati nella memoria dell'applicazione, qualsiasi altra cosa sarebbe sciocca.

Mantenere i dati di accesso degli utenti, statistiche ecc. È un compito piuttosto leggero, quindi sarò audace e dirò che puoi usare praticamente tutto ciò che vuoi. Anche se potresti voler stare attento con il sito web, cose come gli elenchi di utenti potrebbero risucchiare molte prestazioni del database se non crei un sistema di cache adeguato.

E come ha detto bummzack, dovresti tenere tutto nella stessa rete. Inoltre, attenzione alle cose gratuite, 240 MB di spazio di archiviazione gratuito per il database sembrano buoni, ma poiché la macchina è probabilmente suddivisa tra un gran numero di utenti gratuiti, il servizio potrebbe essere piuttosto lento.

Ti fidi dei tuoi 60.000 utenti per database? In caso contrario, dovresti eliminare l'idea di "accesso al database dal client", a meno che il tuo livello di esperienza nella sicurezza del software del database non sia di prim'ordine e sei sicuro di poter affrontare qualsiasi problema risultante.