¿Qué base de datos (RDBMS vs NoSQL vs BOTH) usar para un juego multijugador en tiempo real?

12

Estoy trabajando en un juego multijugador en tiempo real que requerirá una base de datos (para funciones como perfiles de jugadores, amigos, desbloqueos, noticias, etc.). Es un juego estándar para PC (no basado en navegador) y utilizará un servidor cliente. arquitectura. Soy nuevo en el uso de bases de datos, y he investigado durante los últimos días cuando me topé con el acalorado debate: RDBMS vs NoSQL. Actualmente me estoy inclinando hacia NoSQL pero después de leer sobre los usos de cada uno (RDBMS y NoSQL), estoy tentado a usar ambos. Sé que puede parecer extraño, pero déjame explicarte mi situación:

Mi equipo tiene un paquete de alojamiento web compartido que ofrece almacenamiento ilimitado de mySQL y ancho de banda, la única advertencia es que solo podemos tener 25 conexiones abiertas al mismo tiempo (regla de alojamiento compartido). Tengo la intención de usar esto para mi sitio web (un uso típico sin duda) para publicar actualizaciones de noticias, funciones de soporte de la comunidad (como comentarios, subir fan art, etc.) y similares. Eso está bien y bien, ¡pero! Aquí es donde las cosas se ponen interesantes ... Quiero mostrar esta misma información que está publicada en mi sitio web, en el juego. Esto significa usar mySQL tanto para mi sitio web como para mi juego. Además de las publicaciones de noticias y similares, planeo usarlo en el juego para cosas como el chat y una lista de servidores. Me preocupa sobre todo esa regla de 25 conexiones.

Lo que me lleva a hacer la Pregunta # 1: ¿Funcionará y hay una mejor alternativa?

Ahora, además de esto, he leído sobre qué tan bien funciona NoSQL y es adecuado para juegos en tiempo real (podría estar equivocado, he atravesado una gran guerra de llamas RDBMS vs NoSQL para llegar aquí y probablemente estoy quemado). Básicamente, me gustaría usar MongoDB para todos mis datos de objetos de juego.

And again, it will be helpful if I provide some context: I have found a host (MongoLab) which offers a 240MB MongoDB package for free, which I intend on using until it's necessary to upgrade. Given 240MB, I've calculated that I will be able to store roughly 60,000 players (if each player is roughly 4KB and we ignore other things that might be stored). The storage space, and having to pay for more in the future (should our game be successful) is not a problem. The only reason I currently intend on using MongoDB for all of my game object data is because of how often this game object data will be accessed (such as whenever a player is killed, picks up an item, fires a gun, etc.) I also like the straight forward schema-free documents (which make it easier to map game object data). I should note that, at one time, there will only ever be one server writing to a player's profile in the database (the server the player is in).

Tengo la intención de usar el mismo MongoDB en mi sitio web, para mostrar la información del perfil del jugador (no me preocupa la consistencia completa, está bien algún retraso por las actualizaciones en el juego). Lo que me lleva a mi segunda pregunta, Pregunta # 2: ¿Es una buena idea o hay algo mejor que debería hacer?

El juego tendrá una experiencia de inicio similar a esta:

  1. El cliente inicia sesión (MongoDB)
  2. El cliente está en la página de inicio del juego con salas de chat (MySQL)
  3. El cliente va a la lista de servidores (MySQL)
  4. El cliente se conecta a un servidor y juega en él

  5. El servidor comunica actualizaciones para todos los jugadores (MongoDB)

Así es como me imaginaba que funcionaría. ¿Le parece bien o tiene sugerencias sobre cómo se puede mejorar este plan?

Andrés
fuente
99
A menos que usted ha proporcionado un montón de información , a diferencia de algunas personas que no dan suficiente información.
Cíclope
77
Puedo estar malinterpretando lo que está sugiriendo, pero como cuestión de seguridad, su juego no debería conectarse directamente a su base de datos de todos modos, por lo que el recuento de conexiones no debería importar. Si tu juego puede conectarse, entonces cualquiera puede hacerlo. Probablemente tampoco debas abrir una nueva conexión desde tu servidor de juegos a la base de datos para cada jugador que se conecte.
Matthew Scharley
1
¿Qué idioma / herramientas planea usar para la programación de back-end?
aaaaaaaaaaaa
44
Si elige un DB alojado, tendrá un viaje de ida y vuelta desde su juego a su servidor y desde allí al servidor de DB. Esto va a ser más lento que desde el juego a su servidor (que abre una conexión de base de datos local) y anulará la ganancia de rendimiento supuesta de usar NoSQL.
bummzack
"el equipo tiene un paquete de alojamiento web compartido que ofrece almacenamiento ilimitado de mySQL y ancho de banda" ... Lo que le dicen y lo que obtiene son dos cosas diferentes. Puede "tener" todo el espacio del mundo, pero si está accediendo a él a través de una pajilla virtual en lugar de una tubería gruesa, entonces es inútil.
Ken

Respuestas:

11

Mi sugerencia es que su juego se comunique con un servicio web que creó que se ocupa de consultar la base de datos. En ese punto, es muy simple probar diferentes tipos de bases de datos al "cambiar" las implementaciones de servicios web (la interfaz de su servicio web siempre permanece igual para que su juego no se rompa) y decidir cuál es el adecuado para usted.

También es mucho más seguro no exponer su base de datos a Internet directamente.

pwny
fuente
Esa es una gran idea, gracias, definitivamente lo haré. Soy nuevo en el uso de bases de datos, por lo que estas cosas no se me han ocurrido.
Andrew
2
Hacer que el cliente se comunique directamente con DB es un agujero de seguridad del calibre goatse.cx.
importa
6

solo podemos tener 25 conexiones abiertas a la vez (regla de alojamiento compartido).

Eso es más que suficiente para tu juego. El problema es que si su sitio web utiliza múltiples conexiones, podría quedarse sin él. Debes configurar tu servidor web para usar solo un pequeño número de ellos, dejando el resto para tu servidor de juegos. Su servidor de juegos realmente no necesita más de 1 conexión, pero podría beneficiarse de tener un puñado.

Ahora, además de esto, he leído sobre qué tan bien funciona NoSQL y es adecuado para juegos en tiempo real (podría estar equivocado, he atravesado una gran guerra de llamas RDBMS vs NoSQL para llegar aquí y probablemente estoy quemado). Básicamente, me gustaría usar MongoDB para todos mis datos de objetos de juego.

Es un argumento un poco falso, porque ninguno de los sistemas es lo suficientemente rápido como para usarlo como la tienda principal para un juego en tiempo real de ritmo rápido; realmente necesitas mantener y manipular los valores en la memoria. Por lo tanto, solo accede a la base de datos cuando es absolutamente necesario, lo que podría ser guardar el personaje completo de vez en cuando (por ejemplo, una vez por minuto), momento en el que las diferencias de velocidad se vuelven insignificantes.

Lo curioso es que si ajusta MongoDB para obtener la máxima velocidad, puede llegar a un punto en el que sería lo suficientemente rápido como para realizar escrituras sincrónicas desde un juego de ritmo razonablemente rápido, pero esto sería a costa de integridad de datos porque las escrituras están almacenadas en búfer. Esto significa que pierde esos datos en el caso de un bloqueo, por lo que no tenía sentido realizar la escritura, y todavía es más lento que si solo realizara la edición en la memoria y la guardara más tarde, por lo que obtiene lo peor de ambos mundos .

La única razón por la que tengo la intención de usar MongoDB para todos mis datos de objetos del juego es debido a la frecuencia con la que se accederá a estos datos del objeto del juego (como cuando un jugador muere, recoge un objeto, dispara un arma, etc.)

Pregúntese por qué necesita escribir en la base de datos cuando un jugador dispara un arma. ¿Por qué no se puede manejar eso en memoria en el servidor del juego? Si su juego falla y luego se reinicia, y el jugador descubre que tiene 3 balas más de lo que esperaban, ¿es un problema comercial crítico?

También me gustan los documentos sencillos y libres de esquemas (que facilitan el mapeo de datos de objetos de juego).

Esta es una razón mucho mejor para elegir un enfoque NOSQL que el problema de rendimiento.

Tengo la intención de usar el mismo MongoDB en mi sitio web, para mostrar la información del perfil del jugador (no me preocupa la consistencia completa, está bien algún retraso por las actualizaciones en el juego).

Eso está bien y es sensato. Más adelante, es posible que desee utilizar una instancia separada, para que las lecturas web no compitan con las lecturas y escrituras de juegos, pero ese problema es trivial de resolver en comparación con el problema de hacerse lo suficientemente popular como para que esto sea un problema.

Personalmente, solo elegiría una de las dos bases de datos, en función de cuál sería menos trabajo para mí, y estandarizaría eso, pero no hay ninguna razón por la que no pueda quedarse con dos si lo desea.

Kylotan
fuente
¿Puedes sugerir algún marco para esto? "Realmente necesitas mantener y manipular los valores en la memoria". He oído hablar de redis, pero es solo una relación de valor clave, ¿hay algo que podamos manipular?
user1735921
No, cuando digo "mantener y manipular valores en la memoria", estoy literalmente diciendo "el juego se ejecuta como un programa normal con los datos almacenados en variables", no como una especie de capa o marco de base de datos especial.
Kylotan
4

Todos los datos en tiempo real deben mantenerse en la memoria de la aplicación, cualquier otra cosa sería una tontería.

Mantener los datos de inicio de sesión de los usuarios, las estadísticas, etc. es una tarea bastante ligera, por lo que seré valiente y diré que puedes usar casi lo que quieras. Aunque es posible que desee tener cuidado con el sitio web, cosas como las listas de usuarios podrían absorber mucho rendimiento de la base de datos si no crea un sistema de almacenamiento en caché adecuado.

Y como dijo bummzack, debes mantener todo en la misma red. Además de eso, tenga cuidado con las cosas gratis, 240 MB de almacenamiento gratuito de la base de datos suena bien, pero dado que la máquina probablemente se divide entre una gran cantidad de usuarios gratuitos, el servicio podría ser bastante lento.

aaaaaaaaaaaa
fuente
Estoy de acuerdo, desea ot mantener los datos del juego en la memoria, y que así pueda mantener entrada de datos en la memoria, así (teniendo en cuenta que son mucho más pequeñas)
MarkR
La razón para no mantener algunos datos en la memoria (o dejar que una base de datos maneje que está tanto en la memoria como en el disco) es que desea que los datos sean persistentes si el servidor falla. La forma más fácil de asegurarlo es almacenarlo en una base de datos.
aaaaaaaaaaaa
Todavía puede usar una base de datos para la persistencia, pero aún conserva los datos en la memoria, de esa manera tiene un almacenamiento robusto a prueba de choques, pero el acceso es lo suficientemente rápido como para no bloquear el servidor (de otras actividades) si necesita verificar inicios de sesión, etc. .
MarkR
2

¿Confía en sus 60,000 usuarios por base de datos? De lo contrario, debe rechazar la idea de "acceso a la base de datos del cliente", a menos que su nivel de experiencia en la seguridad del software de la base de datos sea de primera categoría y esté seguro de que puede resolver cualquier problema que pueda surgir.

Andy Finkenstadt
fuente
99
Y si está seguro de eso, entonces ipso facto su nivel de experiencia en seguridad de bases de datos no es de primera categoría.
jhocking