Quali DBMS sono abbastanza veloci per un gioco online (poche migliaia di giocatori)? [chiuso]

Attualmente sto realizzando un gioco MMORPG, che potrebbe avere alcune migliaia di giocatori online contemporaneamente (probabilmente no; solo un pio desiderio). Prima di tutto volevamo usare MySQL, ma ho sentito che non è abbastanza veloce per questa scala.

Quale DBMS è abbastanza veloce? Quanto è SQL Server (come ho imparato SQL Server a scuola)?

Questa è una domanda davvero difficile a cui rispondere. Puoi prendere la piattaforma di database più veloce al mondo, progettare uno schema orribile, scrivere un'applicazione schifosa attorno ad essa e quindi essere tentato di incolpare la piattaforma di database. Allo stesso tempo, è possibile utilizzare SQL Server Express gratuito e, con il giusto design, la logica dell'applicazione e un approccio con ragionevole scalabilità (ad esempio ridimensionamento delle letture mediante memorizzazione nella cache dei dati, ecc.), È possibile scrivere un'applicazione che gestisce migliaia di utenti nessun problema.

Credo che SQL Server sia in grado di gestire migliaia di utenti? Assolutamente. Credo che Oracle e DB2 possano fare altrettanto? Certamente. MySQL? Non sono sicuro, non abbastanza esperienza lì. Accesso? Probabilmente non è affatto una scelta saggia. Se hai familiarità con SQL Server, allora suggerisco che è la strada che prendi in considerazione, tieni presente che la tua scelta di RDBMS non determinerà di per sé successo o fallimento.

Lasciami dire così, ricordi GameSpy Arcade dall'inizio della metà degli anni 2000? Funzionava con migliaia di giochi ed era tutto in esecuzione su SQL Server e supportava decine di migliaia di utenti contemporaneamente (sì, avevamo diversi server SQL lì dentro che facevano varie cose). Riguarda la progettazione del database e il modo in cui usi il sistema. Fallo correttamente e il tuo progetto avrà successo, fallo in modo errato e il tuo progetto fallirà, malamente.

La risposta giusta dipende molto dalla piattaforma per cui stai programmando.

Accade così che qualcuno abbia posto questa domanda per una piattaforma specifica in StackOverflow circa 1,5 anni fa.

Che si tratti di MySQL, SQL Server, Oracle, PostgreSQL o qualche altro RDBMS, devi essere molto creativo con l'infrastruttura del database. Se hai un libretto degli assegni aperto per l'hardware e un DBMS di livello industriale, Oracle è per te (in realtà, Oracle RAC sarebbe più desiderabile). Se stai sviluppando utilizzando IIS e un ambiente Microsoft, allora è SQL Server fino in fondo. Se hai problemi di budget e desideri un aspetto grafico di Oracle, PostgreSQL in soccorso. Se hai problemi di budget, una fervida immaginazione e desideri micromanage di Storage Engine a tuo piacimento per soddisfare la conformità ACID, letture ad alta velocità e una varietà di architetture di replica, direi pregiudizialmente MySQL.

Il DBMS dovrebbe essere l'ultimo dei tuoi problemi con MMORPG. I problemi di programmazione presentano sempre pesci più grandi da friggere. Quindi, prendi la tua decisione con prudenza e saggezza, perché qualunque DBMS tu scelga, devi conviverci ( allo stesso modo in cui FaceBook deve convivere con MySQL ).

Questa non è la domanda giusta. Le prestazioni del tuo gioco dipenderanno dall'architettura completa e dallo stack tecnologico che scegli e da come viene implementato. Il DBMS è solo un componente dello stack. Immagino che è improbabile che il DBMS sia un fattore limitante per le prestazioni, a meno che non si progettino cose molto male. Il livello del dominio, la memorizzazione nella cache e il modo in cui distribuisci e ridimensiona il sito sembrano essere preoccupazioni molto più importanti.

Qualsiasi RDBMS cadrà con la scala a seconda di come è configurato, ridimensionato e come l'applicazione lo utilizza.

Me pensa, hai due domande in una. Il primo, "ciò che i DBMS sono in grado di mantenere in modo efficiente i dati di gioco". (soggettivo, imho) Il secondo "come scalare quel DBMS per esibirmi con migliaia di utenti?"

Molti servizi online hanno trovato la combinazione di MySQL e Memcached per fornire prestazioni e scalabilità eccellenti. Tuttavia, arriva un punto in cui anche quella soluzione cade. Tuttavia, potrebbe essere esattamente quello che ti serve.

Sempre più servizi online inseriscono una soluzione NoSQL nella loro architettura. Ho una certa esperienza con CouchBase e lo trovo utile.

Codice, design e i tuoi dischi (per le scritture) determinano le prestazioni in generale. Non la piattaforma.

Puoi dare un'occhiata a CUBRID . È un RDBMS open source che è molto "caldo" in Corea del Sud in questo momento. Supponiamo che funzioni meglio / molto velocemente per le applicazioni web con un alto numero di utenti (dicono 50k o qualcosa del genere).

Penso che uno qualsiasi dei principali database sia in grado di gestire il carico se progettato bene. Purtroppo, stimerei che meno dell'1% di tutti i database sia ben progettato. (Ho trattato personalmente i dati di letteralmente migliaia di database diversi che svolgono una vasta gamma di funzioni, quindi penso di avere una buona idea della mancanza di qualità che esiste nel mondo reale.)

Suggerirei caldamente di ottenere alcuni libri sull'ottimizzazione delle prestazioni per il database scelto e di leggerli attentamente prima di iniziare a progettare. Ci sono molte cose che aiuteranno il tuo database a funzionare meglio che dovrebbe essere progettato dall'inizio. Sapere come scrivere query performanti e indici di progettazione è fondamentale per ottenere un buon design. Questo tipo di studio e le prestazioni progettate non sono ottimizzazioni premature. Non vi è alcun motivo di utilizzare tecniche di uccisione delle prestazioni conosciute nella progettazione. I database devono essere progettati per le prestazioni sin dall'inizio.

Abbiamo giochi mobili con migliaia di giocatori e abbiamo visto un enorme calo di carico andando ai pool di connessioni mysql IIS / .NET persistenti. mysql 5.1

Pensa a conservare i dati di "sola scrittura" da qualche altra parte per ridurre il carico su qualunque db tu scelga Cassandra o syslog. Pensa a mantenere dati in rapida evoluzione, altamente transitori ma ricostruibili in un db nosql come memcache, riak, ecc.