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

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

¿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

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.

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.

• ¿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 .

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