Opción NoSql para MMORPGs

Question

Me preguntaba qué tipo de beneficios podría tener una opción nosql en lugar de, o junto con un rdbms para un MMORPG típico. En particular, tengo curiosidad sobre cómo se preserva la integridad de los datos en nosql.

Voy a dar algunos ejemplos en los que estoy un poco confundido en cuanto a cómo operaría la lógica del servidor:

Escenario 1: Digamos B ataque jugador A y C al mismo tiempo. Un player_stats.kill_count se actualiza para cualquier jugador mata a jugador C. Normalmente, se podría manejar esta AttackPlayerRequest de la siguiente manera:

iniciar la transacción { attacker.health = newAttackerHealth

defender.health = newDefenderHealth

si defender.Health == 0 { attacker.stats.kills + = 1 } }

Escenario 2: El jugador A se Envía un artículo a un vendedor de NPC e intenta rápidamente tirar el mismo artículo de su inventario al suelo. (Incluso si su UI no permite esto, pueden poner los eventos en el cable).

Esta lista obviamente continúa y afecta a casi todas las interacciones jugador-jugador jugador-mundo. Una última información es que el servidor está enhebrado ya que no queremos una solicitud particularmente larga para impedir que otros jugadores puedan hacer cosas simples en el juego.

Supongo que mi gran pregunta aquí es: ¿estoy malentendiendo algo sobre nosql en donde este es un problema trivial? Si no, ¿está esto más allá del dominio de lo que las opciones nosql deben resolver? En un MMO típico, ¿dónde podría uno inyectarse opciones de nosql para aumentar el rendimiento del servidor?

Answer 1

Creo que los servidores MMO harían muchas de las cosas que has enumerado en la memoria. No creo que vayan todos a la base de datos. Creo que se guardarán más eventos difíciles como recibir equipo nuevo o cambiar el diseño de tu equipo.

Es una gran cantidad de datos, pero no tanto como en cada interacción de combate.

Answer 2

A mi entender, la tecnología nosql es algo que utilizaría en un contexto de trabajo por lotes, y no en un contexto en tiempo real. Como cuestión de hecho, la implementación de H-base de código abierto se encuentra en la parte superior del sistema de archivos distribuido de hadoop (hdfs), que se utiliza principalmente para situaciones de solo lectura.

La idea es que 'busque' un registro iterando sobre todo el conjunto de datos que mantiene 'en el disco' (en realidad, en un sistema de archivos distribuidos). Para los conjuntos de datos petascale es imposible mantener cosas en la memoria, por lo que utiliza cantidades masivas de lecturas de disco para poder 'buscar' los datos en absoluto. La naturaleza distribuida asegura (o facilita) que esto ocurra de manera oportuna.

El principio es que lleva el procesamiento a los datos distribuidos, en lugar de extraer datos de una base de datos muy grande, enviarlos a través de la red y luego procesarlos en un nodo local. Pig (http://pig.apache.org/) y Hive (http://hive.apache.org/) son interfaces en la parte superior de hdfs, que permiten consultas tipo SQL, pero en el fondo, usan mapreduce trabajos. La interacción es lenta, pero este no es el punto. El punto es que el inmenso conjunto de datos puede procesarse en absoluto.

Para jugar, obviamente este no es el camino a seguir.Por lo tanto, es de esperar que los datos se obtengan del sistema de archivos distribuido, se almacenen en caché en un servidor y se usen durante una sesión. Cuando el juego haya finalizado, todos los datos se confirmarán en el conjunto de datos. (Al menos, así es como me imagino que iría).

Los conjuntos de datos Hdfs se procesan principalmente en un momento dado, después de lo cual los resultados se publican en un lote. Por ejemplo, en un sitio de red social, compilaría todos los datos de conexión a diario, buscaría todas las conexiones nuevas entre personas, y cuando la operación haya finalizado para todas las personas en el conjunto de datos, los resultados se publicarían en el típico 'X ahora está conectado a Y' mensajes. Esto no sucede en tiempo real.

Answer 3

Todo esto depende de cómo funciona su juego.

NoSQL

Farmville en Facebook utiliza NoSQL. Farmville actúa como 1 servidor enorme en el que todos están. Digamos que Farmville usa 3 computadoras en su cluster de base de datos. Computadora 1 en San Diego. Computadora 2 en Nueva York. Computadora 3 en Moscú. Me conecto a Facebook desde San Diego para que yo me conecte a la base de datos aquí. Subo de nivel y cierro sesión. Eventualmente la Computadora 1 le dirá a la computadora 2 y 3 sobre cómo nivelé pero podría pasar hasta una hora antes de que alguien en Rusia vea esos cambios en mi cuenta.

NoSQL escalar es tan simple como agregar otra computadora al clúster y decirle al sitio web de esa región que use esa computadora.

SQL

Hay varios métodos de fabricación de SQL trabajo, pero voy a explicar una manera para que sea similar a NoSQL

Cada centro de datos tendrá 10 servidores de juego, cada uno con su propio SQL Base de datos de base de datos + 1 base de datos. La base de datos Sub Master compartió la información entre los 10 servidores, por lo que si inicia sesión en el servidor 1 y crea el carácter John Doe, entonces cierre la sesión, el servidor 10 tendrá su carácter si ingresa a ese servidor a continuación.

Sub Master comparte su información con el servidor maestro en su HQ. El servidor maestro luego compartirá John Doe con cada otro submaster en todos los demás centros de datos, y esos submaestros actualizarán sus servidores de juegos. Esta configuración le permitiría iniciar sesión en el servidor Weed en San Francisco, reproducir su personaje, cerrar la sesión, iniciar sesión en el servidor Vodka en Moscú, y aún así ver a su personaje.

Los juegos como World of Warcraft usan SQL pero solo se comparten ciertas partes de la base de datos. Esto permite reducir el tamaño de la base de datos en cada computadora y también reducir los requisitos de hardware.

En una situación de la vida real, cada Submaster tendría un Submaster de respaldo, y su servidor Master tendría unos pocos servidores de respaldo en el caso de que un servidor caiga, toda la red no se cerraría.

Answer 4

Los MMORPG preocupados por la latencia normalmente se ejecutan en un único servidor y almacenan todo excepto la información del modelo de objeto en la RAM. Cualquier cosa con entornos de batalla está preocupado por la latencia.

Cualquier cosa que use HDD, ya sea un RDBMS o NoSQL, es una mala idea en entornos de batalla. Actualizar y compartir la personalización de objetos, la posición, el vector de movimiento, el vector de orientación, la salud, la potencia, etc. Los datos entre 10,000 usuarios en un solo servidor a través de cualquier mecanismo que use HHD son simplemente tontos si te preocupa la latencia. Incluso si tienes 2 personas peleando en un campo simple, la latencia sigue siendo un problema y debes correr en un solo servidor y tener todo en la memoria.Todo lo que se renderizará debe estar en su PC o en la memoria de su PC también.

MMORPG que no están preocupados acerca de la latencia puede ejecutarse en múltiples servidores y cualquier base de datos que desea (NoSQL, MySQL, etc ...)

Si estás haciendo un juego como FarmVille o neopets, entonces sí, NoSQL o MySQL se convierten en opciones válidas.