Respuestas:
Lo hicimos, con suerte Ben Z dará una mejor explicación de las razones que yo, ya que en realidad fue el autor original de nuestra base de datos. La versión corta es que las bases de datos relacionales no son muy útiles para los juegos porque no pueden almacenar eficientemente datos jerárquicos muy estructurados, lo que constituye la gran mayoría de los datos que un MMO necesita para el funcionamiento normal. Elegimos construir una base de datos de objetos personalizados y parte de un sistema de procesamiento de transacciones distribuidas, que ahora está en producción y potenciando nuestros dos juegos en vivo.
En cuanto a si deberías hacer lo mismo? Probablemente no, al menos no al principio. Todavía recomendaría evitar SQL, pero ahora hay muchas más opciones en el mundo "NoSQL" que no existían hace unos años.
Dicho esto, la mayoría de los MMO se ejecutan en bases de datos SQL (relacionales). Sé que Eve se ejecuta en una instalación de SQL Server encima de algunos RAMSAN multi-TB (probablemente nunca en mi vida tenga tanto dinero como cuestan esas cosas).
EDITAR: Esperemos que no le importe que publique esto aquí, pero esta es una entrada de blog con algunos enlaces y comentarios sobre la presentación que hicimos en GDC'08 sobre nuestra base de datos.
De acuerdo, esta respuesta es más una observación.
Revelación completa No he trabajado en MMORPG. Trabajé en lo que fue uno de los 10 sitios más visitados en 2009, y trabajé en una compañía de motores de juegos que pensaba que estaban haciendo tecnología MMORPG (no sé si se enviaron).
Si nos fijamos en las compañías que han alcanzado una escala masiva (Google, Facebook, Twitter, etc., sé que no son compañías de juegos, pero vale la pena verlas en este espacio), hay dos cosas que creo que son importantes.
Un gran error es tomar algo costoso llave en mano y esperar que escala mágicamente para ti. No funciona de esa manera. La clave para escalar es lidiar con cada nuevo desafío de manera adecuada. Necesita soluciones flexibles y fáciles de usar que pueda mover hacia adentro y hacia afuera fácilmente.
Entonces, mi consejo para usted sería si está comenzando, solo obtenga lo que parece menos dolor de cabeza para tratar.
Básicamente, hay una amplia gama de enfoques, y creo que se eligen en base más a las experiencias de sus desarrolladores que a las propiedades de la base de datos. En un extremo, muchos MMO están utilizando bases de datos relacionales estándar, por ejemplo. Dark Eges of Camelot usa / usa (¿siguen funcionando?) MySQL , FreeRealms usan un Postgresql modificado , etc.
Avanzando a lo largo de la escala, tienes Guild Wars: usan SQL Server , pero pegan sus datos allí como un solo BLOB. Esto significa que obtienen los beneficios de sus formatos binarios habituales con algunos de los beneficios que proporciona una base de datos. Huelga decir que probablemente también pueda ver algunas desventajas de este enfoque, pero para una empresa acostumbrada a trabajar con archivos planos, probablemente todavía sea un paso adelante.
Luego, probablemente hay algunos lugares que utilizan los diversos enfoques formalizados de NoSQL, aunque todavía es pronto. Farmville usa membase , que hicieron para el propósito, basado en memcached aparentemente. Esto comparte muchas características con MongoDB, CouchDB, etc. Una vez más, con estos enfoques, generalmente implementa sus propios formatos de almacenamiento, pero obtiene los beneficios de distribución, almacenamiento en caché, redundancia, etc.
Algunos están lanzando su propio NoSQL por completo: Cryptic dijo que hicieron algo similar, pero también dijeron que no lo estaban usando en la producción. ( EDITAR : pero vea los comentarios a continuación).
Y luego te encuentras con personas que usan texto plano o archivos binarios; según tengo entendido, los juegos más antiguos como Ultima Online, Everquest, etc., todos siguieron este camino, y para una empresa con experiencia en desarrollo de juegos pero poca experiencia en bases de datos, esto funciona bien también.
Tenga en cuenta también que casi nunca puede escribir su propia base de datos en un sentido laxo del término: en los juegos siempre tendrá datos personalizados que necesita para administrar en la memoria o en el disco de manera que no se presten a sí mismos al software genérico. No puede realizar consultas SQL cada vez que desee algunos datos, por lo que deberá reflejar gran parte de su información en el código, sin importar el back-end que utilice.
En Pirates of the Burning Sea, nos quedamos con MySQL (aunque honestamente hubiera preferido Postgres) y cuando comenzó a caer bajo carga, cambiamos a Microsoft SQL Server. Honestamente, sin embargo, probablemente no volveré a esa ruta en el futuro. La mayoría de los datos de PotBS se serializan previamente antes de que persistan de todos modos, por lo que una gran parte de lo que hay en la base de datos no es más que un almacén de clave / valor demasiado grande. Además de eso, para obtener un mejor rendimiento de nuestra capa de persistencia y un mejor control de cómo se almacenaron los datos en la memoria caché, terminamos escribiendo un servidor de almacenamiento en caché que se encontraba frente a la base de datos.
Así que Kylotan tiene razón, no vas a moverte por ti mismo en algún nivel. Los servidores de bases de datos relacionales SQL no están diseñados para la forma en que los juegos usan datos. En lugar de asumir que los servidores de bases de datos relacionales eran el final de todas las bases de datos, realmente deberíamos haber pensado más sobre los beneficios que estábamos buscando antes de elegir una herramienta.
La próxima vez, analizaría más cosas como BerkleyDB o algunas de las otras bases de datos de estilo NoSQL.
Otra cosa a tener en cuenta es que si tiene un conjunto de datos estáticos (relativamente), ¡no lo almacene en una base de datos! No hay una buena razón para almacenar sus definiciones de hechizos, definiciones de elementos, mapas, etc. en una base de datos. Raramente los consulta excepto por su nombre. Veo a muchas personas saltar al desarrollo del juego almacenando estas cosas junto con los datos persistentes de los jugadores, y es una clase de cosas totalmente diferente.
Necesita un almacén de datos, como un sistema de archivos, para estos. Fuera del desarrollo, no necesita ACID, no necesita CRUD, no necesita una base de datos para ese tipo de datos. Dentro del desarrollo, necesita una base de datos, pero también necesita un VCS de todos modos, y su elección de VCS lo hará por usted.
(Si estás trabajando en un juego en el que los jugadores pueden crear hechizos, objetos o misiones personalizadas, bueno, entonces esos datos son del mismo tipo que los datos del jugador, y necesitas una base de datos nuevamente).
Los MMORPG son aplicaciones intensivas y son una gran empresa. Si está comenzando con el desarrollo del juego, le recomiendo que haga algo más pequeño.
Dicho esto, necesitará dos resultados superiores de su configuración. Obviamente va a necesitar una granja de servidores / colmena. Debido a que la comunicación de red es relativamente costosa (y la mayoría de los MMORPG son en tiempo real) es posible que desee replicar su base de datos central en cada uno de sus servidores de juegos (el equivalente a la replicación de baja latencia en tiempo real en la base de datos de su elección).
Si cada uno de sus servidores está sirviendo a un segmento específico del mundo del juego (como funciona WoW); algo así como vistas particionadas distribuidas . Los DPV le permiten segmentar filas de su base de datos en diferentes servidores; de acuerdo con las restricciones en las columnas de cada servidor. Tanto MSSQL como Oracle son lo suficientemente inteligentes como para hablar solo con el servidor que contiene los datos que se encuentran dentro de su cláusula WHERE u ON. No estoy seguro de si alguna de las ofertas de código abierto tiene DPV.
El resultado neto de todo esto es que no importa qué DB use , solo use uno con un buen nombre: MSSQL, Oracle, MySQL, PostgreSQL. Escriba su base de datos en ANSI SQL y vea qué sistema funciona mejor, esa es la única forma de averiguarlo.
La ruta NoSQL también podría ser una buena idea porque está diseñada para una alta concurrencia. La sugerencia de Pranny podría hacer el truco.
He usado MongoDB (NoSQL), es un almacén de documentos muy rápido al que se puede acceder a través de TCP. ¡Darle una oportunidad! ¡Es impresionante!
Escribir su propio DB es una tarea desalentadora. Le sugiero que primero explore lo que ya existe y, si no puede encontrar nada que coincida con su conjunto específico de criterios, cree el suyo. Ah, y no te olvides de código abierto. :)
Supongo que depende bastante de qué tipo de datos necesita almacenados y bajo qué forma.
Creo que la mayoría de las personas usan bases de datos SQL "estándar" para datos "dinámicos" como información del reproductor, ya sea SQL Server, MySQL, PostgreSQL.
Sin embargo, los datos "internos" (estado del mundo, contenido, ...) pueden almacenarse bajo cualquier forma, y supongo que la mayoría de las empresas escriben sistemas de bases de datos al menos parcialmente personalizados para esa parte, adecuados para sus necesidades específicas .
Esta pregunta es bastante antigua, pero mi idea de cómo manejarla es tan válida como se hizo hoy.
Si está utilizando una base de datos relacional, debe reducir la carga, por lo que esta idea debería ayudar.
Almacene toda la información pública en una base de datos local en cada sistema cliente, así como en la base de datos del servidor.
Almacene todas las tablas con elementos en la base de datos del cliente. En lugar de que el cliente busque en el servidor cuando pasa el mouse sobre esa arma para obtener estadísticas, el cliente solo verifica las estadísticas en la base de datos local. El servidor tiene su propia base de datos para extraer estadísticas al calcular y solo reenvía el daño y la salud restante a los clientes.
El peor caso con esta idea es que todos pueden ver las estadísticas de todas las armas si logran ingresar a la base de datos de los clientes. Sin embargo, no importa porque incluso si cambian los valores, los valores de la base de datos en el servidor son los que calculan en el juego.