En este documento se describen las prácticas recomendadas para usar Spanner como la base de datos de backend principal de almacenamiento del estado de los videojuegos. Puedes usar Spanner en lugar de bases de datos comunes para almacenar datos de autenticación de jugadores y datos de inventario. Este documento está dirigido a ingenieros de backend de videojuegos que trabajan en el almacenamiento de estados a largo plazo, así como a operadores y administradores de infraestructuras de videojuegos que admiten esos sistemas y están interesados en alojar su base de datos de backend enGoogle Cloud.
Los juegos multijugador y online han evolucionado hasta requerir estructuras de bases de datos cada vez más complejas para monitorizar los derechos, el estado y los datos de inventario de los jugadores. El aumento de las bases de jugadores y la creciente complejidad de los juegos han llevado a soluciones de bases de datos que son difíciles de escalar y gestionar, y que suelen requerir el uso de fragmentación o clustering. El seguimiento de objetos valiosos del juego o del progreso crítico de los jugadores suele requerir transacciones y es difícil de eludir en muchos tipos de bases de datos distribuidas.
Spanner es el primer servicio de base de datos escalable de categoría empresarial con coherencia inmediata y distribuido por todo el mundo que se ha creado específicamente para la nube. Así, combina las ventajas de la estructura de las bases de datos relacionales con la escalabilidad horizontal de las no relacionales. Muchas empresas de videojuegos han descubierto que es una solución adecuada para sustituir las bases de datos de autenticación y de estado de los juegos en sistemas a escala de producción. Puedes aumentar el rendimiento o el almacenamiento añadiendo nodos mediante laGoogle Cloud consola. Spanner puede gestionar de forma transparente la replicación global con una coherencia sólida, lo que elimina la necesidad de gestionar réplicas regionales.
En este documento de prácticas recomendadas se tratan los siguientes temas:
- Conceptos importantes de Spanner y diferencias con las bases de datos que se suelen usar en los juegos.
- Cuándo es Spanner la base de datos adecuada para tu juego.
- Patrones que se deben evitar al usar Spanner en juegos.
- Diseñar las operaciones de la base de datos con Spanner como base de datos de tu juego.
- Modelizar los datos y crear un esquema para obtener el mejor rendimiento con Spanner.
Terminología
- Derechos
- Juegos, expansiones o compras en la aplicación que pertenezcan a un jugador.
- Información de identificación personal (IIP)
- En los juegos, la información suele incluir la dirección de correo electrónico y los datos de la cuenta de pago, como el número de la tarjeta de crédito y la dirección de facturación. En algunos mercados, esta información puede incluir un número de identificación nacional.
- Base de datos de juegos
- Una base de datos que contiene el progreso y el inventario de los jugadores de un juego.
- Base de datos de autenticación (base de datos de autenticación)
- Una base de datos que incluye los derechos de los jugadores y la información personal identificable que utilizan los jugadores al hacer una compra. La base de datos de autenticación también se conoce como base de datos de cuentas o base de datos de jugadores. Esta base de datos a veces se combina con la base de datos del juego, pero se suele separar en estudios o editores que tienen varios títulos.
- Transacción
- Una transacción de base de datos: un conjunto de operaciones de escritura que tienen un efecto de todo o nada. O bien la transacción se realiza correctamente y se aplican todas las actualizaciones, o bien la base de datos vuelve a un estado que no incluye ninguna de las actualizaciones de la transacción. En los juegos, las transacciones de bases de datos son cruciales cuando se procesan pagos y cuando se asigna la propiedad de inventario o moneda valiosos del juego.
- Sistema de gestión de bases de datos relacionales (RDBMS)
- Un sistema de base de datos basado en tablas y filas que se referencian entre sí. SQL Server, MySQL y (con menos frecuencia) Oracle® son ejemplos de bases de datos relacionales que se usan en juegos. Se usan con frecuencia porque pueden proporcionar metodologías conocidas y garantías sólidas sobre las transacciones.
- Base de datos NoSQL
- Bases de datos que no están estructuradas de forma relacional. Estas bases de datos son cada vez más populares en los juegos porque ofrecen mucha flexibilidad cuando cambia el modelo de datos. Entre las bases de datos NoSQL se incluyen MongoDB y Cassandra.
- Clave principal
- Normalmente, es la columna que contiene el ID único de los artículos del inventario, las cuentas de jugador y las transacciones de compra.
- Instancia
- Una sola base de datos. Por ejemplo, un clúster ejecuta varias copias del software de la base de datos, pero aparece como una sola instancia en el backend del juego.
- Node
- En este documento, se refiere a una sola máquina que ejecuta una copia del software de la base de datos.
- Réplica
- Una segunda copia de una base de datos. Las réplicas se usan con frecuencia para la recuperación de datos y la alta disponibilidad, o para aumentar el rendimiento de lectura.
- Clúster
- Varias copias del software que se ejecutan en muchos equipos que, en conjunto, parecen una sola instancia para el backend del juego. La agrupación en clústeres se usa para la escalabilidad y la disponibilidad.
- Fragmentación
- Una instancia de una base de datos. Muchos estudios de videojuegos ejecutan varias instancias de bases de datos homogéneas, cada una de las cuales contiene un subconjunto de los datos del juego. Cada una de estas instancias se denomina fragmento. El particionado se suele hacer para mejorar el rendimiento o la escalabilidad, lo que implica sacrificar la eficiencia de la gestión y aumentar la complejidad de la aplicación. La fragmentación en Spanner se implementa mediante divisiones.
- Dividir
- Spanner divide los datos en fragmentos denominados divisiones, donde las divisiones individuales pueden moverse de forma independiente entre sí y asignarse a diferentes servidores. Una división se define como un intervalo de filas de una tabla de nivel superior (es decir, no intercalada), donde las filas se ordenan por clave principal. Las claves de inicio y fin de este intervalo se denominan "límites de división". Spanner añade y elimina automáticamente límites de divisiones, lo que cambia el número de divisiones de la base de datos. Spanner divide los datos en función de la carga: añade límites de división automáticamente cuando detecta una carga de lectura o escritura alta repartida entre muchas claves de una división.
- Punto de acceso
- Cuando una sola división de una base de datos distribuida, como Spanner, contiene registros que reciben una gran parte de todas las consultas que se dirigen a la base de datos. Este escenario no es deseable porque reduce el rendimiento.
Usar Spanner en videojuegos
En la mayoría de los casos en los que te planteas usar un RDBMS para tu juego, Spanner es una opción adecuada porque puede sustituir de forma eficaz la base de datos del juego, la base de datos de autenticación o, en muchos casos, ambas.
Bases de datos de juegos
Spanner puede funcionar como una única autoridad transaccional en todo el mundo, lo que la convierte en una opción excelente para los sistemas de inventario de juegos. Cualquier moneda u objeto del juego que se pueda intercambiar, vender, regalar o transferir de otro modo de un jugador a otro supone un reto para los back-ends de juegos a gran escala. A menudo, la popularidad de un juego puede superar la capacidad de una base de datos tradicional para gestionar todo en una base de datos de un solo nodo. En función del tipo de juego, la base de datos puede tener problemas con el número de operaciones necesarias para gestionar la carga de los jugadores, así como con la cantidad de datos almacenados. Esto suele llevar a los desarrolladores de juegos a fragmentar su base de datos para mejorar el rendimiento o a almacenar tablas que no paran de crecer. Este tipo de solución conlleva una complejidad operativa y una sobrecarga de mantenimiento elevadas.
Para mitigar esta complejidad, una estrategia habitual es ejecutar regiones de juego completamente independientes sin forma de mover datos entre ellas. En este caso, los jugadores de diferentes regiones de juego no pueden intercambiar objetos ni moneda, ya que los inventarios de cada región se almacenan en bases de datos independientes. Sin embargo, esta configuración sacrifica la experiencia de juego preferida en favor de la simplicidad operativa y de desarrollo.
Por otro lado, puedes permitir las transacciones entre regiones en una base de datos fragmentada geográficamente, pero a menudo con un coste de complejidad elevado. Esta configuración requiere que las transacciones abarquen varias instancias de la base de datos, lo que da lugar a una lógica compleja y propensa a errores en el lado de la aplicación. Intentar obtener bloqueos de transacciones en varias bases de datos puede tener un impacto significativo en el rendimiento. Además, no poder confiar en las transacciones atómicas puede provocar que los jugadores aprovechen vulnerabilidades, como la duplicación de monedas u objetos del juego, lo que perjudica el ecosistema y la comunidad del juego.
Spanner puede simplificar tu enfoque de las transacciones de inventario y de moneda. Incluso cuando se usa Spanner para almacenar todos los datos de tu juego en todo el mundo, ofrece transacciones de lectura y escritura con propiedades ACID (atomicidad, coherencia, aislamiento y durabilidad) aún más sólidas que las convencionales. Gracias a la escalabilidad de Spanner, los datos no tienen que fragmentarse en instancias de base de datos independientes cuando se necesita más rendimiento o almacenamiento. En su lugar, puedes añadir más nodos. Además, Spanner gestiona de forma transparente la alta disponibilidad y la resiliencia de los datos por las que los juegos suelen agrupar sus bases de datos, sin necesidad de configuración ni gestión adicionales.
Bases de datos de autenticación
Spanner también es una buena opción para las bases de datos de autenticación, sobre todo si quieres estandarizar un único RDBMS en tu estudio o a nivel de editor. Aunque las bases de datos de autenticación de los juegos no suelen requerir la escala de Spanner, las garantías transaccionales y la alta disponibilidad de datos pueden hacer que sea una opción atractiva. La replicación de datos en Spanner es transparente, síncrona e integrada. Spanner tiene configuraciones que ofrecen una disponibilidad del 99,99% ("cuatro nueves") o del 99,999% ("cinco nueves"), con "cinco nueves" correspondiente a menos de cinco minutos y medio de inactividad al año. Este tipo de disponibilidad hace que sea una buena opción para la ruta de autenticación crítica que se requiere al principio de cada sesión del jugador.
Prácticas recomendadas
En esta sección se ofrecen recomendaciones sobre cómo usar Spanner en el diseño de juegos. Es importante modelar los datos de tu juego para aprovechar las funciones únicas que ofrece Spanner. Aunque puedes acceder a Spanner usando la semántica de las bases de datos relacionales, algunos puntos de diseño de esquemas pueden ayudarte a mejorar el rendimiento. En la documentación de Spanner se incluyen recomendaciones detalladas sobre el diseño de esquemas que puedes consultar, pero en las siguientes secciones se describen algunas prácticas recomendadas para las bases de datos de juegos.
Las prácticas que se describen en este documento se basan en las experiencias de los clientes y en casos prácticos.
Usar UUIDs como IDs de jugador y de personaje
La tabla de jugadores suele tener una fila por cada jugador y su moneda del juego, su progreso u otros datos que no se asignan fácilmente a filas discretas de la tabla de inventario. Si tu juego permite que los jugadores tengan partidas guardadas independientes para varios personajes, como muchos juegos multijugador masivos persistentes de gran tamaño, esta tabla suele contener una fila por cada personaje. El patrón es el mismo.
Te recomendamos que uses un identificador de personaje o jugador único a nivel mundial (ID de personaje) como clave principal de la tabla de personajes. También te recomendamos que uses el identificador único universal (UUID) versión 4, ya que distribuye los datos de los jugadores entre los nodos de la base de datos y puede ayudarte a mejorar el rendimiento de Spanner.
Usar el entrelazado en tablas de inventario
La tabla de inventario suele contener elementos del juego, como el equipo de los personajes, cartas o unidades. Normalmente, un jugador tiene muchos objetos en su inventario. Cada elemento se representa mediante una sola fila en la tabla.
Al igual que otras bases de datos relacionales, una tabla de inventario de Spanner tiene una clave principal que es un identificador único global del elemento, tal como se muestra en la siguiente tabla.
itemID
|
type
|
playerID
|
|---|---|---|
7c14887e-8d45 |
1 |
6f1ede3b-25e2 |
8ca83609-bb93 |
40 |
6f1ede3b-25e2 |
33fedada-3400 |
1 |
5fa0aa7d-16da |
e4714487-075e |
23 |
5fa0aa7d-16da |
d4fbfb92-a8bd |
14 |
5fa0aa7d-16da |
31b7067b-42ec |
3 |
26a38c2c-123a |
En la tabla de inventario de ejemplo, itemID y playerID se han truncado para que sean más fáciles de leer. Una tabla de inventario real también contendría muchas otras columnas que no se incluyen en el ejemplo.
Una estrategia habitual en un RDBMS para hacer un seguimiento de la propiedad de los elementos es usar una columna como clave externa que contenga el ID del jugador propietario actual. Esta columna es la clave principal de una tabla de base de datos independiente. En Spanner, puedes usar el entrelazado, que almacena las filas de inventario cerca de la fila de la tabla de jugadores asociada para mejorar el rendimiento. Cuando uses tablas intercaladas, ten en cuenta lo siguiente:
- No puedes generar un objeto sin un propietario. Puedes evitar objetos sin propietario en el diseño del juego si conoces la limitación con antelación.
Diseñar la indexación para evitar los puntos de acceso
Muchos desarrolladores de juegos implementan índices en muchos de los campos de inventario para optimizar determinadas consultas. En Spanner, al crear o actualizar una fila con datos en ese índice, se genera una carga de escritura adicional proporcional al número de columnas indexadas. Puedes mejorar el rendimiento de Spanner eliminando los índices que no se usen con frecuencia o implementando estos índices de otras formas que no afecten al rendimiento de la base de datos.
En el siguiente ejemplo, se muestra una tabla de registros de puntuaciones altas de jugadores a largo plazo:
CREATE TABLE Ranking (
PlayerID STRING(36) NOT NULL,
GameMode INT64 NOT NULL,
Score INT64 NOT NULL
) PRIMARY KEY (PlayerID, GameMode)
Esta tabla contiene el ID del jugador (UUIDv4), un número que representa un modo de juego, una fase o una temporada, y la puntuación del jugador.
Para acelerar las consultas que filtran por el modo de juego, considera el siguiente índice:
CREATE INDEX idx_score_ranking ON Ranking (
GameMode,
Score DESC
)
Si todos los jugadores juegan al mismo modo de juego llamado 1, este índice crea un punto de acceso donde GameMode=1. Si quieres obtener una clasificación para este modo de juego, el índice solo analiza las filas que contienen GameMode=1, lo que permite devolver la clasificación rápidamente.
Si cambias el orden del índice anterior, puedes solucionar este problema del punto de acceso:
CREATE INDEX idx_score_ranking ON Ranking (
Score DESC,
GameMode
)
Este índice no creará un punto de acceso significativo a partir de los jugadores que compitan en el mismo modo de juego, siempre que sus puntuaciones se distribuyan en el intervalo posible. Sin embargo, obtener puntuaciones no será tan rápido como con el índice anterior, ya que la consulta analiza todas las puntuaciones de todos los modos para determinar si GameMode=1.
Por lo tanto, el índice reordenado resuelve el problema anterior del modo Juego, pero aún se puede mejorar, como se muestra en el siguiente diseño.
CREATE TABLE GameMode1Ranking (
PlayerID STRING(36) NOT NULL,
Score INT64 NOT NULL
) PRIMARY KEY (PlayerID)
CREATE INDEX idx_score_ranking ON Ranking (
Score DESC
)
Te recomendamos que saques el modo de juego del esquema de la tabla y que uses una tabla por modo, si es posible. Si usas este método, cuando obtengas las puntuaciones de un modo, solo consultarás una tabla con las puntuaciones de ese modo. Esta tabla se puede indexar por puntuación para recuperar rápidamente intervalos de puntuación sin un riesgo significativo de puntos de acceso (siempre que las puntuaciones estén bien distribuidas). En el momento de redactar este documento, el número máximo de tablas por base de datos en Spanner es de 2560, lo que es más que suficiente para la mayoría de los juegos.
Bases de datos independientes por inquilino
A diferencia de otras cargas de trabajo, en las que recomendamos diseñar para multitenancy en Spanner mediante el uso de diferentes valores de clave principal, en el caso de los datos de videojuegos, recomendamos el enfoque más convencional de bases de datos independientes por inquilino. Los cambios de esquema son habituales cuando se lanzan nuevas funciones de juego en juegos de servicio activo, y el aislamiento de los inquilinos a nivel de base de datos puede simplificar las actualizaciones de esquemas. Esta estrategia también puede optimizar el tiempo que se tarda en crear una copia de seguridad o restaurar los datos de un arrendatario, ya que estas operaciones se realizan en toda la base de datos a la vez.
Evita las actualizaciones incrementales del esquema
A diferencia de algunas bases de datos relacionales convencionales, Spanner sigue funcionando durante las actualizaciones de esquemas. Se devuelven todas las consultas de esquema antiguo (aunque pueden tardar más de lo habitual) y las consultas de esquema nuevo se devuelven a medida que están disponibles. Puedes diseñar tu proceso de actualización para que el juego siga funcionando durante las actualizaciones del esquema cuando se ejecute en Spanner, siempre que tengas en cuenta las restricciones anteriores.
Sin embargo, si solicitas otro cambio de esquema mientras se está procesando uno, la nueva actualización se pondrá en cola y no se llevará a cabo hasta que se hayan completado todas las actualizaciones de esquema anteriores. Para evitar esta situación, planifica actualizaciones de esquemas más grandes en lugar de emitir muchas actualizaciones de esquemas incrementales en un periodo breve. Para obtener más información sobre las actualizaciones de esquemas, incluido cómo realizar una actualización de esquema que requiera validación de datos, consulta la documentación sobre actualizaciones de esquemas de Spanner.
Tener en cuenta el acceso y el tamaño de la base de datos
Cuando desarrolles tu servidor de juego y tus servicios de plataforma para usar Spanner, ten en cuenta cómo accede tu juego a la base de datos y cómo dimensionarla para evitar costes innecesarios.
Usar controladores y bibliotecas integrados
Cuando desarrolles con Spanner, ten en cuenta cómo interactúa tu código con la base de datos. Spanner ofrece bibliotecas de cliente integradas para muchos lenguajes populares, que suelen tener muchas funciones y un buen rendimiento. También hay controladores JDBC disponibles, que admiten instrucciones de lenguaje de manipulación de datos (DML) y de lenguaje de definición de datos (DDL). En los casos en los que se usa Spanner en un nuevo desarrollo, recomendamos usar las bibliotecas de cliente de Cloud para Spanner. Aunque las integraciones típicas de motores de juegos no tienen mucha flexibilidad en la selección de idiomas, en el caso de los servicios de plataforma que acceden a Spanner, hay clientes de juegos que usan Java o Go. En las aplicaciones de alto rendimiento, selecciona una biblioteca en la que puedas usar el mismo cliente de Spanner para varias solicitudes secuenciales.
Ajustar el tamaño de la base de datos a las necesidades de pruebas y producción
Durante el desarrollo, es probable que una instancia de Spanner de un solo nodo sea suficiente para la mayoría de las actividades, incluidas las pruebas funcionales.
Evaluar las necesidades de Spanner para la producción
Cuando pases de la fase de desarrollo a la de pruebas y, después, a la de producción, es importante que vuelvas a evaluar tus necesidades de Spanner para asegurarte de que tu juego pueda gestionar el tráfico de jugadores reales.
Antes de pasar a producción, es fundamental realizar pruebas de carga para verificar que tu backend pueda gestionar la carga durante la producción. Te recomendamos que hagas pruebas de carga con el doble de la carga que esperas en producción para estar preparado ante picos de uso y casos en los que tu juego sea más popular de lo previsto.
Realizar pruebas de carga con datos reales
No basta con hacer una prueba de carga con datos sintéticos. También debes realizar pruebas de carga con datos y patrones de acceso lo más parecidos posible a los que se esperan en producción. Es posible que los datos sintéticos no detecten posibles puntos de acceso en el diseño de tu esquema de Spanner. No hay nada mejor que hacer una prueba beta (abierta o cerrada) con jugadores reales para verificar cómo se comporta Spanner con datos reales.
El siguiente diagrama es un ejemplo de esquema de tabla de jugadores de un estudio de videojuegos que ilustra la importancia de usar pruebas beta para realizar pruebas de carga.
El estudio preparó estos datos basándose en las tendencias de un juego anterior que había gestionado durante un par de años. La empresa esperaba que el esquema representara bien los datos de este nuevo juego.
Cada registro de jugador tiene asociados algunos atributos numéricos que hacen un seguimiento del progreso del jugador en el juego (como el rango y el tiempo de juego). En el caso del atributo de ejemplo utilizado en la tabla anterior, los nuevos jugadores reciben un valor inicial de 50, que luego cambia a un valor entre 1 y 100 a medida que el jugador avanza.
El estudio quiere indexar este atributo para acelerar las consultas importantes durante la partida.
A partir de estos datos, el estudio creó la siguiente tabla de Spanner, con una clave principal que usa PlayerID y un índice secundario en Attribute.
CREATE TABLE Player (
PlayerID STRING(36) NOT NULL,
Attribute INT64 NOT NULL
) PRIMARY KEY (PlayerID)
CREATE INDEX idx_attribute ON Player(Attribute)
Se ha consultado el índice para encontrar hasta diez jugadores con Attribute=23,
de esta forma:
SELECT PlayerID
FROM Player@{force_index=idx_attribute}
WHERE Attribute = 23
LIMIT 10
Según la documentación sobre la optimización del diseño del esquema, Spanner almacena los datos de índice de la misma forma que las tablas, con una fila por entrada de índice. En las pruebas de carga, este modelo distribuye de forma aceptable la carga de lectura y escritura del índice secundario en varias divisiones de Spanner, tal como se muestra en el siguiente diagrama:
Aunque los datos sintéticos que se usan en la prueba de carga son similares al estado estable final del juego, en el que los valores de Attribute están bien distribuidos, el diseño del juego determina que todos los jugadores empiecen con Attribute=50. Como cada jugador nuevo empieza con Attribute=50, cuando se unen nuevos jugadores, se insertan en la misma parte del índice secundario idx_attribute. Esto significa que las actualizaciones se dirigen a la misma división de Spanner, lo que provoca un punto de acceso durante el periodo de lanzamiento del juego. Se trata de un uso ineficiente de Spanner.
En el siguiente diagrama, al añadir una columna IndexPartition al esquema después del lanzamiento, se resuelve el problema del hotspot y los jugadores se distribuyen de forma uniforme entre las divisiones de Spanner disponibles. El comando actualizado para crear la tabla y el índice es el siguiente:
CREATE TABLE Player (
PlayerID STRING(36) NOT NULL,
IndexPartition INT64 NOT NULL
Attribute INT64 NOT NULL
) PRIMARY KEY (PlayerID)
CREATE INDEX idx_attribute ON Player(IndexPartition,Attribute)
El valor de IndexPartition debe tener un intervalo limitado para que las consultas sean eficientes, pero también debe tener un intervalo que sea al menos el doble del número de divisiones para que la distribución sea eficiente.
En este caso, el estudio asignó manualmente a cada jugador un valor IndexPartition
entre 1 y 6 en la aplicación del juego.
Otra opción sería asignar un número aleatorio a cada jugador o asignar un valor derivado de un hash en el valor PlayerID.
Consulta Lo que deben saber los administradores de bases de datos sobre Spanner (parte 1): claves e índices
para obtener más información sobre las estrategias de fragmentación a nivel de aplicación.
La consulta anterior actualizada para usar este índice mejorado sería la siguiente:
SELECT PlayerID
FROM Player@{force_index=idx_attribute}
WHERE IndexPartition BETWEEN 1 and 6
AND Attribute = 23
LIMIT 10
Como no se llevó a cabo ninguna prueba beta, el estudio no se dio cuenta de que estaba probando con datos que tenían supuestos incorrectos. Aunque las pruebas de carga sintéticas son una buena forma de validar cuántas consultas por segundo (CPS) puede gestionar tu instancia, es necesario realizar una prueba beta con jugadores reales para validar tu esquema y preparar un lanzamiento exitoso.
Dimensionar el entorno de producción para anticipar los picos de demanda
Los juegos importantes suelen alcanzar el pico de tráfico en el momento del lanzamiento. Crear un backend escalable no solo se aplica a los servicios de plataforma y a los servidores de juegos dedicados, sino también a las bases de datos. Con soluciones como Google Cloud App Engine, puedes crear servicios de API de frontend que se puedan ampliar rápidamente. Aunque Spanner ofrece la flexibilidad de añadir y quitar nodos online, no es una base de datos de autoescalado. Debes aprovisionar suficientes nodos para gestionar el pico de tráfico en el lanzamiento.
Según los datos que hayas recogido durante las pruebas de carga o de cualquier prueba beta pública, puedes estimar el número de nodos necesarios para gestionar las solicitudes en el momento del lanzamiento. Es una buena práctica añadir algunos nodos como margen por si consigues más jugadores de lo esperado. Siempre debes dimensionar la base de datos de forma que no se supere el 65 % de uso medio de la CPU.
Calentar la base de datos antes del lanzamiento del juego
Antes de lanzar tu juego, te recomendamos que calientes tu base de datos para aprovechar las funciones de paralelización de Spanner. Para obtener más información, consulta Calentar la base de datos antes de lanzar la aplicación.
Monitorizar e interpretar el rendimiento
Cualquier base de datos de producción requiere una monitorización exhaustiva y métricas de rendimiento. Spanner incluye métricas en Cloud Monitoring. Cuando sea posible, te recomendamos que incorpores las bibliotecas gRPC proporcionadas en el proceso backend de tu juego, ya que incluyen seguimiento de OpenCensus. El seguimiento de OpenCensus te permite ver trazas de consultas en Cloud Trace, así como en otras herramientas de seguimiento de código abierto compatibles.
En Cloud Monitoring, puedes ver detalles sobre el uso de Spanner, como el almacenamiento de datos y el uso de la CPU. En la mayoría de los casos, te recomendamos que bases tus decisiones de escalado de Spanner en esta métrica de uso de CPU o en la latencia observada. Para obtener más información sobre el uso de CPU sugerido para optimizar el rendimiento, consulta las prácticas recomendadas.
Spanner ofrece planes de ejecución de consultas. Puedes consultar estos planes en la Google Cloud consola y ponerte en contacto con el equipo de Asistencia si necesitas ayuda para entender el rendimiento de tus consultas.
Cuando evalúes el rendimiento, haz pruebas de ciclo corto lo menos posible, ya que Spanner divide tus datos de forma transparente en segundo plano para optimizar el rendimiento en función de tus patrones de acceso a los datos. Debes evaluar el rendimiento con cargas de consultas sostenidas y realistas.
Al eliminar datos, elimina filas en lugar de volver a crear tablas
Cuando trabajas con Spanner, las tablas recién creadas aún no han tenido la oportunidad de someterse a una división basada en la carga o en el tamaño para mejorar el rendimiento. Cuando eliminas datos eliminando una tabla y, a continuación, la vuelves a crear, Spanner necesita datos, consultas y tiempo para determinar las divisiones correctas de la tabla. Si tienes previsto volver a rellenar una tabla con el mismo tipo de datos (por ejemplo, al realizar pruebas de rendimiento consecutivas), puedes ejecutar una consulta DELETE en las filas que contengan datos que ya no necesites. Por el mismo motivo, las actualizaciones de esquemas deben usar la API de Cloud Spanner proporcionada y no deben seguir una estrategia manual, como crear una tabla y copiar los datos de otra tabla o de un archivo de copia de seguridad.
Seleccionar una ubicación de datos para cumplir los requisitos
Muchos juegos deben cumplir las leyes de localización de datos, como el RGPD, cuando se juega en todo el mundo. Para ayudarte a cumplir los requisitos del RGPD, consulta el Google Cloud y el informe técnico sobre el RGPD y selecciona la configuración regional de Spanner correcta.
Siguientes pasos
- Consulta cómo usó Bandai Namco Entertainment Spanner en el lanzamiento de Dragon Ball Legends.
- Consulta la sesión de Cloud Next '18 sobre optimización de aplicaciones, esquemas y diseño de consultas en Spanner.
- Consulta nuestra guía sobre cómo migrar de DynamoDB a Spanner.