noSQL: ¿es una opción válida para un juego basado en web? [cerrado]

20

Debido a una oportunidad y al aburrimiento, un amigo y yo decidimos hacer un juego basado en la web. Este es el primer 'juego' que haré, ya que generalmente programo aplicaciones web en django.

Opté por usar el mismo marco para el juego, pero no estoy totalmente seguro sobre el almacenamiento de datos, ya que no puedo prever requisitos futuros y problemas relacionados con la base de datos. Últimamente, el movimiento noSQL está ganando fuerza y ​​me gustaría explorar esa área.

Por lo tanto, tengo las siguientes preguntas:

  • ¿Sería adecuado un almacenamiento de datos noSQL (basado en documentos, como MongoDB) para un juego basado en la web?
  • ¿Cuáles son los problemas que pueden surgir al usar un RDBMS convencional, como MySQL?
  • ¿Cómo asegurar la consistencia de datos entre los usuarios con MongoDB, durante el juego o en eventos cronometrados, como trabajos cron?

Descripción general del juego: juego de aventura típico, con el jugador luchando contra monstruos y ganando objetos y demás.

  • Algunos datos son estáticos en todos los jugadores: artículos, armas, pociones, mapas, etc.
  • Algunos datos vinculados al jugador: inventario, métricas (estadísticas), progreso, etc.
  • Un jugador puede necesitar conocer las estadísticas y el estado de otro jugador
  • Las tareas programadas se ejecutarán en cierto intervalo de tiempo
Pran
fuente
1
Un problema con algunas bases de datos noSQL es que no pueden realizar consultas imprevistas en el "diseño" de manera rápida en grandes conjuntos de datos como registros de eventos: gamedev.stackexchange.com/q/4465/450 Tenga en cuenta que las bases de datos noSQL requieren lo mismo técnicas contra la inyección de consultas normales que las bases de datos normales.
Hendrik Brummermann el
1
@nhnb: Una buena manera de reafirmar su punto es "usar una base de datos relacional para datos de relación y usar una base de datos de objetos / documentos para datos de objetos / documentos". Desafortunadamente, no creo que la mayoría de las personas tengan experiencia o pasen mucho tiempo pensando en el modelado, lo que conduce a malos diseños sin importar cuál elijan.
2
En respuesta a su pregunta "¿Es NoSQL una opción válida para juegos basados ​​en la web?" Creo que la respuesta es si. Las bases de datos NoSQL se han utilizado antes para juegos basados ​​en la web (como FarmVille) y ofrecen mucha flexibilidad. El principal punto de discusión para esta pregunta parece ser "¿cuál es mejor (NoSQL o SQL)?". Cada sistema tiene ventajas y desventajas, pero ambas son opciones perfectamente legítimas. Si está buscando una lista detallada de las ventajas de un sistema sobre el otro, puede pagar una visita a los Programadores StackExchange. :)
Ari Patrick

Respuestas:

21

¿Sería adecuada una base de datos noSQL para un juego basado en la web?

¡Absolutamente! En términos generales, las bases de datos no relacionales (como MongoDB) son mucho mejores para los juegos, ya que son más flexibles en la forma en que modelan los datos, a la vez que son más eficaces que las bases de datos relacionales (como SQL), lo que las convierte en un "ganar-ganar". elección.

¿Cuáles son los problemas que pueden surgir al usar un RDBMS convencional?

Existen dos inconvenientes principales para usar bases de datos relacionales:

  • Falta de flexibilidad en la forma de modelar datos
  • Actuación

La falta de flexibilidad en la forma en que modela los datos es un inconveniente importante, porque el uso de una base de datos relacional lo obliga a modelar los datos para que se ajusten a las necesidades de la base de datos, en lugar de que la base de datos se adapte a las necesidades del modelo. Por ejemplo, considere que está creando el modelo de cómo almacenará los elementos en un juego usando una base de datos relacional y decide el siguiente modelo:

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

Ahora considere cómo necesitaría modificar el modelo para cumplir, haga lo siguiente:

  • Agregar un nuevo tipo de elemento
  • Crea un arma con múltiples tipos de armas
  • Crea un objeto de poción que también se pueda usar como arma

Ciertamente, todas estas acciones son factibles, pero no serás la persona más feliz mientras las haces, y probablemente te preguntarás, "¿hay una mejor solución para lo que quiero hacer?", Cuando puedas diseñar un modelo mucho más flexible en una base de datos no relacional.

Nota: Si no está familiarizado con la forma en que las bases de datos basadas en documentos almacenan información, consulte este enlace antes de continuar. El modelo presentado a continuación está diseñado para usar una lógica similar a la que se presenta en el artículo mencionado anteriormente.

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

Hay muchos buenos artículos sobre el rendimiento de NoSQL vs bases de datos SQL, pero aquí hay uno que proporciona ejemplos de aplicaciones para que pueda realizar sus propias pruebas: MongoDB vs. SQL Server 2008 Performance Showdown

¿Cómo aseguro la consistencia de los datos entre los usuarios con MongoDB?

MongoDB admite operaciones atómicas de lectura / escritura en entidades de datos individuales (documentos), por lo que los resultados de consultas de MongoDB siempre deben ser precisos con lo que está almacenado en la base de datos.

Editar: ejemplo NoSQL proporcionado de la base de datos de elementos

Ari Patrick
fuente
En el ejemplo que escribiste usando sql, ¿cómo lo modelarías a alto nivel usando nosql?
Pran el
44
-1, su respuesta muestra solo datos estáticos. Todo el debate sobre SQL vs. NoSQL para bases de datos de juegos involucra datos altamente dinámicos. Lo mejor sería mostrar una transacción NoSQL que intercambie algo entre dos jugadores, una ocurrencia muy común, y la mayoría de los juegos se equivocan independientemente del tipo que elijan.
3
@Ari: hay muchos más datos estáticos, pero a nadie le importa el rendimiento de las escrituras, porque nadie escribe en él: no escribe, no hay transacciones, no ACID, no hay una pregunta real de la base de datos, incluso si lo almacena. en uno. Esa pregunta es fácil de responder, solo manténgala en la memoria. Ciertamente "¿Cómo podemos cargar datos estáticos más rápido?" es una pregunta interesante, pero no creo que esté relacionada con las preguntas de SQL vs. NoSQL. - En cuanto a las operaciones de documentos múltiples, ¿significa esto que su base de datos tendría un documento con, por ejemplo, todos los jugadores?
2
@Ari: No confunda NoSQL, que es una idea, y MongoDB, que es una base de datos particular. En mi último trabajo enviamos dos juegos en una base de datos NoSQL y obtuvimos una excelente concurrencia con baja latencia. Pero nuestra base de datos NoSQL también admitía transacciones de documentos múltiples con bloqueo de nivel de campo. NoSQL no es una sola "cosa" como SQL, solo se refiere a cualquier base de datos que no usa SQL (y generalmente no usa esquemas relacionales).
55
Solo mis $ .02, pero "no funciona" no es un inconveniente de RDBMS. Es un inconveniente almacenar datos no relacionales en un RDBMS, no ajustar su RDBMS, no entender lo que está haciendo su SQL, no indexar, etc. etc. etc. Si tiene datos relacionales, encontrará que los RDBMS están increíblemente optimizados.
Robbie
19

Un par de palabras defienden las bases de datos SQL.

1 - Si tiene una base de datos SQL, puede trabajar con sus datos no solo por clave primaria. La mayoría de las consultas en MMO se realiza por PK, pero cuando necesite encontrar a todos los usuarios con nivel> 30, ¿qué hará en el mundo NoSQL?

2 - Si tiene lenguaje SQL, puede crear "revisiones" para reparar datos dañados. Por ejemplo: "actualizar player_items set flag = 0 donde item_type_id = 100". ¿Cómo puedes solucionar esto en NoSQL? Creo que tendrá que hacer un script que analizará todos sus datos ...

3 - Las bases de datos SQL no son tan lentas como puedes pensar. Mis colegas crean el juego MMO basado en la web, que realiza 5000 transacciones por segundo en MySQL. ¿No es suficiente para ti? De lo contrario, puede usar el fragmentación para escalar su base de datos.

4 - SQL tiene restricciones de clave externa y cosas tan buenas que te ayudarán a encontrar errores en tu código.

NoSQL no es una bala de plata. Solo resuelve un par de problemas y trae muchos problemas nuevos. Así que mi consejo: piénselo dos veces antes de elegir NoSQL.

Andrey Frolov
fuente
1
Estas son todas buenas razones para evitar NoSQL hasta que realmente lo necesite. Especialmente # 3. A menos que ya tenga millones de usuarios (y se niegue a compartir nada), probablemente sea mucho más productivo con MySQL.
Ojrac
55
1. Usarías: "for x en db.user.find ({" level ": {" $ gt ": 30}})" 2. Técnicamente, lo que escribiste es un script también, así que estoy No estoy muy seguro de cuál es tu punto. 3. Es MUY posible hacer un MMO usando SQL, y de hecho, muchos MMO han sido desarrollados usando la tecnología. La tecnología NoSQL es bastante nueva y ya ha sido adoptada por servicios como Amazon, Google y Facebook por su rendimiento y flexibilidad. 4. En NoSQL necesitaría escribir sus propias restricciones, pero eso es simplemente el costo de una mayor flexibilidad.
Ari Patrick
2
Estoy de acuerdo con tu afirmación de pensar dos veces. Eso es parcialmente lo que estoy haciendo aquí con esta pregunta :)
Pran el
10
SQL no es una viñeta astillada. NoSQL no es una bala de plata. Piénselo dos veces antes de usar cualquier tecnología.
stonemetal
55
En cuanto a 3, el problema no es tanto que SQL es lento , pero que SQL es lag . En términos generales, las bases de datos SQL obtienen un rendimiento excelente a expensas de la latencia. Para un juego basado en la web, ¡eso es probablemente lo que quieres! Para un juego en red en tiempo real, probablemente no lo sea, y la mayoría de los MMO "similares a WoW" que usan SQL usan una capa de almacenamiento en caché que elimina la mayoría de los beneficios de SQL, por lo que NoSQL es un gran paso adelante para ellos.
18

La respuesta es sí, es una opción válida, pero no, probablemente no sea una gran idea .

Hay dos problemas principales con SQL que NoSQL intenta abordar cuando se trata de juegos.

El primero es la latencia o retraso. En cierto sentido, las bases de datos SQL son increíblemente rápidas y procesan miles de transacciones o más en décimas de segundo. En otro sentido, son increíblemente lentos, porque procesar solo unas pocas transacciones puede llevar la misma cantidad de tiempo. Para la mayoría de los usos de la base de datos, esto no importa, pero los juegos tienen un componente en tiempo real, por lo que no se trata solo de cuántas transacciones puede hacer por segundo, sino también del tiempo promedio que se tarda en responder a una transacción de la base de datos.

Esta latencia es un problema importante para los juegos en tiempo real. Muchos desarrolladores que necesitan grandes bases de datos (generalmente para MMO) construyen una capa de almacenamiento en caché que se encuentra entre la base de datos y los servidores del juego para evitar estos bloqueos, y luego vacían el caché periódicamente. ¿El problema? Acaba de descartar las razones principales para usar una base de datos: atomicidad, consistencia, aislamiento y durabilidad .

Pero ese problema no se aplica a los juegos web.Ya tienes una conexión de alta latencia entre el jugador y el juego, por lo que también podrías obtener el rendimiento que proporciona SQL, así como los beneficios de un software maduro y conocido.

Sin embargo, el segundo problema se aplica a usted, y ese es el desajuste de impedancia relacional del objeto . Los juegos tratan con objetos, las bases de datos tratan con filas. Si tiene suerte, un objeto puede convertirse en una fila simplemente enumerando sus campos, pero la mayoría de las veces los objetos son jerárquicos, y debe aplanarlos de alguna manera para colocarlos en filas.

Las bases de datos basadas en documentos, como CouchDB y MongoDB, resuelven este problema promoviendo el documento al objeto de nivel superior, en lugar de la fila ("documento" en este caso es sinónimo de "objeto"). Pero al hacer esto, pierden muchos de los beneficios de las bases de datos SQL. El rendimiento es mucho menor y los algoritmos de bloqueo se vuelven mucho más complicados.

La buena noticia es que ya hay una gran cantidad de mapeo relacional de objetos (ORM) herramientas de disponibles para cualquier lenguaje que esté utilizando. Le permiten traducir entre objetos en la memoria y filas en la base de datos de manera bastante transparente. Estas herramientas generalmente no son apropiadas para juegos en tiempo real a gran escala, ya que pueden presentar los peores aspectos de rendimiento de las bases de datos SQL y NoSQL. Pero está bien para un juego web: en el peor de los casos, cuando te encuentras con problemas de rendimiento, puedes volver a hacer transacciones a la antigua. El problema de la latencia no le hace daño, y el aumento del rendimiento lo ayuda.

Finalmente, para aclarar un punto que he hecho en otra parte : no se trata de datos estáticos del juego. No estoy hablando de las descripciones de tus artículos o del daño de tu arma o los sprites o cualquier cosa aquí. Me refiero a los datos reales y mutables del juego, como lo que hay en el inventario de un jugador o cuáles son sus estadísticas. Todo lo que necesita para los datos estáticos es un almacén de datos. Tal vez resulta que lo más fácil de hacer es usar la misma base de datos que el almacén de datos porque tiene un gran ORM; tal vez solo necesites el sistema de archivos. Son dos problemas separados, y una respuesta no necesita (y probablemente no) encajar en ambos casos.

Comunidad
fuente
1
+1 Gracias por la comparación de ambas opciones. Además, hace un buen punto al decir que los datos estáticos no deben estar en la base de datos.
Pran
1
+1 Sin embargo, creo que no menciona uno de los principales profesionales (bueno, pro o contra dependiendo de la perspectiva) de No SQL, que es que no tiene esquema, lo que permite el almacenamiento de datos altamente dinámicos. De hecho, voy a utilizar una combinación de ambos para mi proyecto actual con PostgreSQL para cosas que encajan bien en el modelo relacional, y Mongo para cosas semiestáticas que no. (por ejemplo, un registro que se puede usar para generar una repetición, donde relacionalmente tendría que tener una columna que almacene un PK de una de muchas otras tablas, o una tabla con nombres de columna genéricos, por ejemplo, param1 param2)
Davy8
1
@ Davy88: noSQL no es necesariamente sin esquema, y ​​tener una base de datos "altamente dinámica" no es realmente una ventaja. Si todo lo que tiene es sopa de datos, no puede hacer indexación, no puede hacer bloqueo de nivel de campo, e incluso las consultas simples se llenan de preguntas sobre qué sucede si no existe una clave.
@ user744, ¿qué logran esas cosas que mencionas?
expiredninja
5
  • ¿Sería adecuado un almacenamiento de datos noSQL (basado en documentos, como MongoDB) para un juego basado en la web?

Aconsejaría echar un vistazo a couchdb

Su interfaz está basada en JavaScript, por lo que se combinará bastante bien con los juegos basados ​​en HTML5 / JavaScript.

También puede trabajar 'fuera de línea' (hacer una copia local de la base de datos) y luego sincronizarse con el servidor más adelante (puede usar esto para mazmorras instantaneas, por ejemplo)

  • ¿Cuáles son los problemas que pueden surgir al usar un RDBMS convencional, como MySQL?

El problema principal sería que las bases de datos sin sql se manejan de manera bastante diferente a las bases de datos relacionales. Hacer el cambio mental puede ser difícil.

Por ejemplo, eche un vistazo a cómo se realizan las " consultas " en couchdb. Todo se hace en javascript.

  • ¿Cómo asegurar la consistencia de datos entre los usuarios con MongoDB, durante el juego o en eventos cronometrados, como trabajos cron?

El proceso de 'sincronización' de bases de datos se llama replicación en la jerga de couchdb. También verá mucho el término consistencia . Existen varios servicios integrados que se ocupan de la replicación y la coherencia. Vea, por ejemplo, el proceso de replicación incremental .

egarcia
fuente
Sí, también he oído hablar de couchdb, de hecho, incluso en el sitio web de mongodb, comúnmente lo comparan. Creo que necesito investigar sobre couchdb vs mongodb.
Pran el
2

Dependiendo de lo que tengas en tu juego, podrías terminar usando ambos y conectándolos a través de los modelos de tu juego. Por ejemplo, el reproductor podría y debería estar en RDB (información de inicio de sesión), pero el inventario del reproductor / almacenamiento variable podría ir a noSQL, por lo que su módulo de reproductor podría login()usar RDB y fetchInventory()noSQL por la clave principal.

Los mapas, por ejemplo, es mejor guardarlos en NoSQL (coordenadas => matriz de diferentes objetos, por ejemplo). No me imagino guardar lo que contiene un área en RDB (excepto una cadena serializada que necesita serserializar completamente para leer alguna parte de más CPU). y RAM desperdiciada!) bueno, aún podría guardar áreas en RDB, por ejemplo, el área "ciudad X" contiene los siguientes cordinates / bloque ([3,4], [8,7] ...)

podrías y probablemente deberías usar ambos, y echar un vistazo al almacenamiento volátil como memcache que podrías necesitar o algunos datos temporales (¡seguro que sería más rápido que usar el disco duro! y te ahorra mucha CPU pero no RAM)

así que al final>

¡depende de lo que quieras tener en tu juego! cheerz

Ronan Dejhero
fuente
¿Qué características crees que te arrastrarían más a NoSQL o la capa de persistencia como me gusta pensar en ello?
expiredninja
1
quizás un sistema de coordenadas si tu juego está basado en gps, algo que podría necesitar una búsqueda avanzada Básicamente, si eres bueno con MySQL, entonces cúmplelo, ¿es posible usarlo también como un nosql?
Ronan Dejhero