Risposte:
Abbiamo fatto, speriamo che Ben Z fornirà una spiegazione migliore delle ragioni di me, dato che era in realtà l'autore originale del nostro database. La versione breve è che i DB relazionali non sono molto utili per i giochi in quanto non sono in grado di archiviare in modo efficiente dati gerarchici fortemente strutturati, il che costituisce la stragrande maggioranza dei dati necessari a un MMO per il normale funzionamento. Scegliamo di costruire un database di oggetti personalizzati e parte di un sistema di elaborazione delle transazioni distribuito, che è ora in produzione e alimenta i nostri due giochi dal vivo.
E se dovessi fare lo stesso? Probabilmente no, almeno non all'inizio. Continuerei a raccomandare di evitare SQL, ma ora ci sono molte più opzioni nel mondo "NoSQL" che non esistevano alcuni anni fa.
Detto questo, la maggior parte degli MMO viene eseguita su database SQL (relazionali). So che Eva gira su un'installazione di SQL Server in cima ad alcuni RAMSAN multi-TB (probabilmente non avrò mai nella mia vita tanti soldi quanto costano quelle cose).
EDIT: Spero che non gli dispiaccia che pubblichi questo qui, ma questo è un post sul blog con alcuni link e commenti sulla presentazione che abbiamo fatto a GDC'08 sul nostro database.
Va bene, questa risposta è più di un'osservazione.
Informativa completa Non ho lavorato su MMORPG. Ho lavorato in quello che era uno dei primi 10 siti più visitati nel 2009 e ho lavorato presso la società di motori di gioco che pensava che stessero realizzando la tecnologia MMORPG (non so se spedito).
Se guardi alle aziende che hanno raggiunto dimensioni enormi (Google, Facebook, Twitter, ecc., So che non sono società di giochi, ma vale la pena guardare in questo spazio) ci sono due cose che penso siano importanti.
Un grosso errore è quello di afferrare qualcosa di costoso chiavi in mano e aspettarsi che si riduca magicamente per te. Non funziona così. La chiave per scalare è affrontare ogni nuova sfida in modo appropriato. Hai bisogno di soluzioni flessibili e facili da usare che puoi spostare facilmente dentro e fuori.
Quindi il mio consiglio per te sarebbe se tu iniziassi, prendi solo quello che sembra meno mal di testa da affrontare.
Fondamentalmente, esiste un'intera gamma di approcci e penso che siano stati scelti in base più alle esperienze dei loro sviluppatori che alle proprietà del database. Da un lato, molti MMO utilizzano database relazionali standard, ad es. Dark Ages of Camelot ha usato / usa (stanno ancora andando?) MySQL , FreeRealms usano Postgresql modificato , ecc.
Muovendosi lungo la scala, hai Guild Wars: usano SQL Server , ma inseriscono i loro dati come un singolo BLOB. Ciò significa che ottengono i vantaggi dei loro soliti formati binari con alcuni dei vantaggi offerti da un database. Inutile dire che probabilmente vedrai anche alcuni svantaggi di questo approccio, ma per un'azienda abituata a lavorare con file flat, è probabilmente ancora un passo avanti.
Quindi ci sono probabilmente alcuni posti che usano i vari approcci NoSQL formalizzati, anche se è ancora agli inizi. Farmville usa membase , che hanno creato allo scopo, apparentemente basato su memcached. Questo condivide molte caratteristiche con MongoDB, CouchDB, ecc. Ancora una volta con questi approcci si rotolano in genere i propri formati di archiviazione ma si ottengono i vantaggi della distribuzione, memorizzazione nella cache, ridondanza, ecc.
Alcuni stanno lanciando interamente il proprio NoSQL: Cryptic ha detto di aver fatto qualcosa di simile ma ha anche detto che non lo stavano usando in produzione. ( EDIT : ma vedi i commenti qui sotto.)
E poi vieni da persone che usano file flat o binari - a quanto ho capito, i vecchi giochi come Ultima Online, Everquest, ecc. Sono andati tutti su questa strada, e per un'azienda con esperienza di sviluppo di giochi ma poca esperienza di database funziona bene pure.
Nota anche che non ti metti quasi mai in giro a scrivere il tuo database in un certo senso del termine: nei giochi avrai sempre dati su misura che devi gestire sia in memoria che su disco in modi che non si prestano al software generico. Non è possibile eseguire query SQL ogni volta che si desidera disporre di alcuni dati, quindi sarà necessario eseguire il mirroring di molte informazioni nel codice, indipendentemente dal back-end utilizzato.
Su Pirates of the Burning Sea, abbiamo iniziato con MySQL (anche se onestamente avrei preferito Postgres) e quando ha iniziato a cadere sotto carico, siamo passati a Microsoft SQL Server. Onestamente, però, probabilmente non seguirò più quella strada in futuro. La maggior parte dei dati di PotBS è pre-serializzata prima che venga comunque mantenuta, quindi gran parte di ciò che è nel DB non è altro che un archivio di chiavi / valori troppo cresciuto. Inoltre, per ottenere prestazioni migliori dal nostro livello di persistenza e un migliore controllo del modo in cui i dati sono stati memorizzati nella cache, abbiamo finito per scrivere un server di cache che si trovava davanti al database.
Quindi Kylotan ha perfettamente ragione, non hai intenzione di andare in giro a un certo livello. I server di database relazionali SQL non sono progettati per il modo in cui i giochi utilizzano i dati. Invece di supporre che i server DB relazionali rappresentassero la fine di tutti i database, avremmo davvero dovuto pensare di più ai vantaggi che stavamo cercando prima di scegliere uno strumento.
La prossima volta, analizzerei di più cose come BerkleyDB o alcuni altri DB in stile NoSQL.
Un'altra cosa da notare è che se si dispone di un set di dati (relativamente) statico, non memorizzarlo in un database! Non c'è davvero un buon motivo per archiviare le definizioni degli incantesimi, le definizioni degli oggetti, le mappe, ecc. In un database. Raramente li stai interrogando tranne che per nome. Vedo molte persone saltare nello sviluppo del gioco archiviando queste cose insieme ai dati persistenti dei giocatori, ed è una classe completamente diversa di cose.
Per questi è necessario un archivio dati, come un filesystem. Al di fuori dello sviluppo, non è necessario ACID, non è necessario CRUD, non è necessario un database per quel tipo di dati. All'interno dello sviluppo, hai bisogno di un database, ma hai anche bisogno di un VCS e la tua scelta di VCS farà quella scelta di database per te.
(Se stai lavorando a un gioco in cui i giocatori possono creare incantesimi o oggetti o missioni personalizzati, beh, allora quei dati sono dello stesso tipo dei dati dei giocatori e hai di nuovo bisogno di un database.)
I MMORPG sono app ad alta intensità e sono un'impresa enorme. Se stai iniziando con lo sviluppo del gioco, ti consiglio vivamente di fare qualcosa di più piccolo.
Detto questo, avrai bisogno di due massime prestazioni dalla tua configurazione. Ovviamente avrai bisogno di una server farm / hive. Poiché la comunicazione di rete è relativamente costosa (e la maggior parte dei MMORPG sono in tempo reale), potresti voler replicare il tuo database centrale su ciascuno dei tuoi server di gioco (l'equivalente della replica in tempo reale a bassa latenza nel tuo database preferito).
Se ciascuno dei tuoi server sta servendo un segmento specifico del mondo di gioco (come funziona WoW); qualcosa come le viste partizionate distribuite . I DPV ti consentono di segmentare le file del tuo database su server diversi; in base ai vincoli sulle colonne di ciascun server. Sia MSSQL che Oracle sono abbastanza intelligenti da comunicare solo con il server che contiene i dati che rientrano nella clausola WHERE o ON. Non sono sicuro se una delle offerte open source abbia DPV.
Il risultato netto di tutto ciò è che non importa quale DB usi , basta usarne uno con un buon nome: MSSQL, Oracle, MySQL, PostgreSQL. Scrivi il tuo database in ANSI SQL e vedi quale sistema funziona meglio: è l'unico modo per scoprirlo.
La route NoSQL potrebbe anche essere una buona idea perché è progettata per una concorrenza elevata. Il suggerimento di Pranny potrebbe fare il trucco.
Ho usato MongoDB (NoSQL), è un archivio documenti molto veloce a cui è possibile accedere tramite TCP. Provaci! È meraviglioso!
Scrivere il proprio DB è un compito scoraggiante. Ti suggerisco di esplorare prima cosa c'è già là fuori e se non riesci a trovare qualcosa che corrisponda al tuo set di criteri specifico, costruisci il tuo. Oh, e non dimenticare di open source. :)
Immagino che dipenda molto dal tipo di dati che è necessario archiviare e da quale forma.
Penso che la maggior parte delle persone là fuori utilizzino database SQL "standard" per dati "dinamici" come le informazioni dei giocatori, siano essi SQL Server, MySQL, PostgreSQL.
Tuttavia, i dati "interni" (stato del mondo, contenuto, ...) possono essere archiviati in qualsiasi forma, e la mia ipotesi sarebbe che la maggior parte delle aziende scriva almeno parzialmente sistemi di database personalizzati per quella parte, adatti alle loro esigenze specifiche .
Questa domanda è piuttosto vecchia, ma la mia idea di come gestirla è valida come è stata posta come lo è oggi.
Se stai usando un database relazionale devi ridurre il carico su di esso, quindi questa idea dovrebbe aiutare.
Memorizzare tutte le informazioni pubbliche su un DB locale su ciascun sistema client e nel DB dei server.
Memorizzare tutte le tabelle con elementi nel database client. Invece del client che guarda al server quando si passa il mouse su quell'arma per le statistiche, il client controlla solo le statistiche nel database locale. Il server ha un proprio database per estrarre le statistiche durante il calcolo e inoltrare ai client solo danni e integrità.
Il caso peggiore di questa idea è che tutti possono vedere le statistiche di tutte le armi se riescono ad accedere al database dei clienti. non importa se causa anche se cambiano i valori, i valori del database sul server sono ciò che fa il calcolo nel gioco.