En este documento, se describen las prácticas recomendadas a fin de usar Spanner como la base de datos de backend principal para el almacenamiento del estado de un videojuego. Puedes usar Spanner en lugar de bases de datos comunes para almacenar inventarios y datos de autenticación de jugadores de datos no estructurados. Este documento está destinado a ingenieros de backend de videojuegos que trabajan en el almacenamiento de estado a largo plazo, y a administradores y operadores de infraestructura de videojuegos que brindan asistencia a esos sistemas y están interesados en alojar las bases de datos de backend en Google Cloud.
Los juegos multijugador y en línea han evolucionado. Ahora requieren estructuras de bases de datos cada vez más complejas para llevar un seguimiento de los datos de inventario, autorizaciones y estados de los jugadores. Debido al crecimiento de las bases de jugadores y la complejidad de los juegos, la administración y el escalamiento de las soluciones de bases de datos representan un desafío. Por lo tanto, con frecuencia requieren el uso de la fragmentación o la agrupación en clústeres. El seguimiento de artículos valiosos dentro del juego o del progreso de los jugadores, por lo general, requiere transacciones. Además, trabajar con muchos tipos de bases de datos distribuidas resulta desafiante.
Spanner es el primer servicio de base de datos escalable, de nivel empresarial, distribuido en todo el mundo y con coherencia sólida, compilado para la nube a fin de combinar los beneficios de la estructura de las bases de datos relacionales con el escalamiento horizontal no relacional. Muchas empresas de videojuegos lo ven como una opción adecuada para reemplazar las bases de datos tanto del estado del juego como de autenticación en los sistemas a escala de producción. Puedes realizar ajustes destinados a lograr un mayor almacenamiento o rendimiento mediante el uso de la consola de Cloud para agregar nodos. Spanner puede manejar con transparencia la replicación global con coherencia sólida y, al mismo tiempo, quitar la necesidad de administrar réplicas regionales.
En este documento sobre prácticas recomendadas, se abordan los siguientes temas:
- Conceptos importantes sobre Spanner y diferencias con las bases de datos que se suelen usar en los videojuegos
- Cuándo Spanner es la base de datos adecuada para un videojuego
- Patrones que deben evitarse cuando se usa Spanner para videojuegos
- Diseño de las operaciones de base de datos con Spanner como la base de datos del videojuego
- Modelado de los datos y creación de un esquema para obtener el mejor rendimiento con Spanner
Terminología
- Autorizaciones
- Son los juegos, expansiones o compras directas desde la aplicación que pertenecen al jugador.
- Información de identificación personal (PII)
- En los videojuegos, es información que suele incluir la dirección de correo electrónico y los datos de la cuenta de pagos, como el número de la tarjeta de crédito y la dirección de facturación. En algunos mercados, esta información podría incluir un número de identificación nacional.
- Base de datos del videojuego
- Es una base de datos donde se almacena el progreso del jugador y el inventario del videojuego.
- Base de datos de autenticación
- Es una base de datos que incluye las autorizaciones del jugador y la PII que usan los jugadores cuando realizan una compra. La base de datos de autenticación también se conoce como base de datos de la cuenta o base de datos del jugador. A veces, esta se combina con la base de datos del videojuego, pero, en general, se encuentran separadas en el caso de estudios o publicadores que tienen varios títulos.
- Transacción
- Una transacción de base de datos es 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 la base de datos regresa a un estado que no incluye ninguna de las actualizaciones de la transacción. En los videojuegos, las transacciones de base de datos son más importantes cuando se procesan pagos y cuando se asigna la propiedad de monedas o inventario de valor dentro del juego.
- Sistema de administración de bases de datos relacionales (RDBMS)
- Es un sistema de base de datos basado en tablas y filas que hacen referencia unas a otras. SQL Server, MySQL y (con menos frecuencia) Oracle® son ejemplos de bases de datos relacionales que se utilizan en los videojuegos. Estas se suelen usar porque permiten proporcionar metodologías familiares y garantías sólidas en torno a las transacciones.
- Base de datos NoSQL
- Son bases de datos que no tienen una estructura relacional. Estas bases de datos son cada vez más populares en los videojuegos, porque ofrecen una gran flexibilidad cuando cambia el modelo de datos. Las bases de datos NoSQL incluyen MongoDB y Cassandra.
- Clave primaria
- Por lo general, es la columna que contiene el ID único para los artículos del inventario, las cuentas del jugador y las transacciones de compra.
- Instancia
- Es una base de datos única. Por ejemplo, un clúster ejecuta varias copias del software de base de datos, pero aparece como una sola instancia en el backend del videojuego.
- Nodo
- A los fines de este documento, es una sola máquina que ejecuta una copia del software de base de datos.
- Réplica
- Es una segunda copia de la base de datos. Las réplicas se suelen usar para la recuperación de datos y la alta disponibilidad, o para ayudar a aumentar la capacidad de procesamiento de lectura.
- Clúster
- Son varias copias del software que se ejecutan en muchas máquinas, las que aparecen como una sola instancia para el backend del videojuego. La agrupación en clústeres se usa para la escalabilidad y la disponibilidad.
- Fragmentación
- Es 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 suele denominarse fragmento. Por lo general, la fragmentación se realiza por cuestiones de rendimiento o escalabilidad; se sacrifica la eficiencia de la administración y se aumenta la complejidad de la app. La fragmentación en Spanner se implementa mediante divisiones.
- Dividir
- Spanner divide los datos en fragmentos llamados divisiones. Las divisiones individuales pueden moverse de forma independiente unas de otras y asignarse a diferentes servidores. Una división es un rango de filas de una tabla de nivel superior (en otras palabras, no intercalada), en la que las filas se ordenan según la clave primaria. Las claves de inicio y fin de este rango se denominan “límites de división”. Spanner agrega y quita de forma automática estos límites de división, lo que cambia la cantidad de divisiones de la base de datos. Spanner divide los datos en función de la carga, es decir, agrega límites de división de forma automática cuando detecta una gran cantidad de operaciones de lectura o escritura en muchas claves de una división.
- Hotspot
- Es cuando una sola división en 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. Esta situación no es deseable, porque disminuye el rendimiento.
Usa Spanner para videojuegos
En la mayoría de los casos en los que consideres usar un RDBMS para un videojuego, Spanner será una opción adecuada, porque puede reemplazar de forma efectiva la base de datos del videojuego, la base de datos de autenticación o, en muchos casos, ambas.
Bases de datos de videojuegos
Spanner puede operar como una única autoridad transaccional a nivel mundial, por lo que resulta idóneo para los sistemas de inventario de los videojuegos. Cualquier moneda o artículo dentro del juego que se pueda intercambiar, vender, regalar o transferir de un jugador a otro presenta un desafío en los backends de videojuegos a gran escala. A menudo, la popularidad de un juego puede superar la capacidad de una base de datos tradicional para controlar todo en una base de datos de un solo nodo. Según el tipo de videojuego, se pueden presentar dificultades debido a la cantidad de operaciones que debe controlar la base de datos para manejar la carga del jugador, así como la cantidad de datos almacenados. A menudo, esto lleva a los desarrolladores de videojuegos a fragmentar sus bases de datos para obtener un rendimiento adicional o para almacenar tablas que crecen constantemente. Este tipo de solución trae como resultado un aumento de la complejidad operativa y de las necesidades de mantenimiento.
A fin de mitigar esta complejidad, una estrategia común es ejecutar regiones de juego completamente separadas sin una manera de mover los datos entre ellas. En este caso, los artículos y las monedas no se pueden intercambiar entre jugadores en diferentes regiones del juego, porque los inventarios de cada región se segregan en bases de datos separadas. Sin embargo, esta configuración sacrifica la experiencia del jugador, en favor de la simplicidad operativa y para el desarrollador.
Por otro lado, puedes permitir intercambios entre regiones en una base de datos fragmentada geográficamente, pero esto suele conllevar una gran complejidad. Esta configuración requiere que las transacciones abarquen varias instancias de base de datos, lo que conlleva a una lógica compleja y propensa a errores en el lado de la aplicación. Intentar obtener bloqueos de transacción en varias bases de datos puede tener un impacto significativo en el rendimiento. Además, el hecho de no poder confiar en transacciones atómicas puede dar lugar a vulnerabilidades para los jugadores, como la duplicación de monedas o artículos, que dañan el ecosistema y la comunidad del juego.
Spanner puede simplificar el enfoque para las transacciones de monedas y de inventario. Incluso cuando usas Spanner para conservar todo de datos de todo el mundo, ofrece transacciones de lectura y escritura con son más resistentes que la atomicidad, la coherencia, el aislamiento y la durabilidad tradicionales (ACID) propiedades. Con la escalabilidad de Spanner, significa que los datos no necesita ser fragmentada en instancias de bases de datos separadas cuando hay más se necesite el rendimiento o almacenamiento; en su lugar, puedes agregar más nodos. Además, Spanner maneja con transparencia la alta disponibilidad y resiliencia de datos, que a menudo son la razón de la agrupación de las bases de datos en clústeres en los videojuegos, y no requiere configuración ni administración adicional.
Bases de datos de autenticación
Spanner también puede usarse para las bases de datos de autenticación, en especial si deseas estandarizar en un solo RDBMS a nivel de estudio o publicador. Aunque las bases de datos de autenticación para videojuegos a menudo no requieren el escalamiento de Spanner, las garantías transaccionales y la alta disponibilidad de datos lo hacen una alternativa atractiva. La replicación de datos en Spanner es transparente, integrada y síncrona. Spanner tiene parámetros de configuración que ofrecen el 99.99% (“cuatro nueves”) o el 99.999% (“cinco nueves”) de disponibilidad. Los “cinco nueves” corresponden a menos de cinco minutos y medio de falta de disponibilidad al año. Gracias a este tipo de disponibilidad, es una buena opción para la ruta de acceso de autenticación crítica que se requiere al comienzo de cada sesión del jugador.
Recomendaciones
En esta sección, se proporcionan recomendaciones sobre cómo usar Spanner en el diseño de videojuegos. Es importante modelar los datos del videojuego para aprovechar las funciones únicas que ofrece Spanner. Si bien puedes acceder a Spanner mediante el uso de la semántica de la base de datos relacional, algunos puntos de diseño de esquemas pueden ayudarte a aumentar el rendimiento. Spanner documentación tiene recomendaciones detalladas para el diseño de esquemas que puedes revisar, pero las siguientes secciones son algunas prácticas recomendadas BD.
Las recomendaciones de este documento se basan en experiencias de uso de clientes y casos de éxito.
Usa los UUID como ID de jugador y de personaje
La tabla de jugadores suele tener una fila para cada jugador, su moneda del juego, progreso y otros datos que no se representan fácilmente en filas discretas de la tabla de inventario. Si el juego permite a los jugadores guardar progresos separados para varios personajes, como muchos videojuegos multijugador masivos, esta tabla generalmente contiene una fila para cada personaje. En ambos casos, el patrón es el mismo.
Recomendamos usar un identificador único de personaje o jugador a nivel global (ID de personaje) como clave primaria de la tabla de personajes. También recomendamos el uso del identificador universal único (UUID) v4, ya que distribuye los datos del jugador por los nodos de la base de datos y puede ayudar a obtener un mayor rendimiento de Spanner.
Usa la intercalación para tablas de inventario
Las tablas de inventario a menudo contienen artículos del juego, como equipos del personaje, tarjetas o unidades. Normalmente, un jugador tiene muchos artículos en su inventario. Cada artículo está representado por una sola fila en la tabla.
Como sucede con otras bases de datos relacionales, una tabla de inventario en Spanner tiene una clave primaria que es un identificador único global para el artículo, como se ilustra 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 truncan para mejorar la lectura. Una tabla de inventario real también contendría muchas otras columnas que no están incluidas en el ejemplo.
Un enfoque típico en un RDBMS para llevar un seguimiento de la propiedad de un artículo es usar una columna como una clave externa que contiene el ID del jugador que es el propietario actual. Esta columna es la clave primaria de una tabla de base de datos separada. En Spanner, puedes usar la intercalación, que almacena las filas del inventario cerca de la fila asociada de la tabla del jugador para un mejor rendimiento. Cuando uses tablas intercaladas, recuerda lo siguiente:
- No puedes generar un objeto sin propietario. Puedes evitar los objetos sin propietario en el diseño del juego, siempre que conozcas la limitación con anticipación.
Diseña índices para evitar la generación de hotspots
Muchos desarrolladores de videojuegos implementan índices en muchos de sus campos de inventario con el propósito de optimizar ciertas consultas. En Spanner, la creación o actualización de una fila con datos en ese índice genera una carga de escritura adicional que es proporcional a la cantidad de columnas indexadas. Puedes mejorar el rendimiento de Spanner si quitas los índices que no se usan con frecuencia o si implementas estos índices de otras maneras que no afecten el rendimiento de la base de datos.
En el siguiente ejemplo, hay una tabla para los registros de las puntuaciones más altas del jugador 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 el modo de juego, la etapa o la temporada, y la puntuación del jugador.
A fin de acelerar las consultas que filtran el modo de juego, considera el siguiente índice:
CREATE INDEX idx_score_ranking ON Ranking (
GameMode,
Score DESC
)
Si todos juegan el mismo modo de juego llamado 1, este índice crea un hotspot en el que GameMode=1. Si deseas obtener una clasificación para este modo de juego, el índice solo escanea las filas que contienen GameMode=1 y muestra la clasificación con rapidez.
Si cambias el orden del índice anterior, puedes resolver este problema del hotspot:
CREATE INDEX idx_score_ranking ON Ranking (
Score DESC,
GameMode
)
Este índice no creará un hotspot significativo de los jugadores que compiten en el mismo modo de juego, siempre que sus puntuaciones se distribuyan en el rango posible. Sin embargo, la obtención de las puntuaciones no será tan rápida como con el índice anterior, porque la consulta escanea todas las puntuaciones de todos los modos para determinar si GameMode=1.
Como resultado, el índice reordenado resuelve el hotspot anterior del modo de juego, pero se puede mejorar aún más, como se ilustra 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
)
Recomendamos mover el modo de juego fuera del esquema de la tabla y usar una tabla por modo si es posible. Con este método, cuando recuperas las puntuaciones de un modo, solo consultas una tabla con puntuaciones de ese modo. Esta tabla se puede indexar por puntuación para una recuperación rápida de los rangos de puntuaciones sin riesgo significativo de hotspots (siempre que las puntuaciones estén bien distribuidas). Al momento de la redacción de este documento, la cantidad máxima de tablas por base de datos en Spanner es de 2,560, que es más que suficiente para la mayoría de los videojuegos.
Bases de datos separadas por usuario
A diferencia de otras cargas de trabajo, en las que recomendar el diseño para multiusuarios en Spanner Si usa diferentes valores de clave primaria, para datos de videojuegos, Enfoque convencional de bases de datos independientes para cada usuario. Los cambios de esquema son comunes con el lanzamiento de características nuevas de los juegos de servicio en vivo, y el aislamiento de los usuarios a nivel de la base de datos puede simplificar las actualizaciones del esquema. Esta estrategia también permite optimizar el tiempo que lleva crear una copia de seguridad o restablecer los datos del usuario, ya que estas operaciones se realizan en una base de datos completa en una vez.
Evita las actualizaciones de esquema incrementales
A diferencia de algunas bases de datos relacionales convencionales, Spanner permanece operacional durante las actualizaciones de esquema. Se muestran todas las consultas sobre el esquema anterior (aunque pueden devolverse con menor velocidad que lo habitual), y las consultas sobre el esquema nuevo se muestran a medida que estén disponibles. Puedes diseñar el proceso de actualización para que el videojuego continúe en ejecución durante las actualizaciones de esquema cuando se ejecuta en Spanner, siempre que tengas en cuenta las restricciones anteriores.
Sin embargo, si solicitas otro cambio de esquema mientras hay uno en curso, procesada, la nueva actualización se pone en cola y no tendrá lugar hasta todas las se completaron las actualizaciones del esquema. Para evitar esta situación, planea actualizaciones de esquema más grandes, en lugar de emitir muchas actualizaciones de esquema incrementales en un período corto. Para obtener más información sobre las actualizaciones de esquema, incluido cómo realizar una actualización de esquema que requiere validación de datos, consulta la documentación de actualizaciones de esquema de Spanner.
Considera el acceso y el tamaño de la base de datos
Cuando desarrolles el servidor del videojuego y los servicios de plataforma para usar Spanner, considera cómo accede el videojuego a la base de datos y qué dimensiones dar a la base de datos a fin de evitar costos innecesarios.
Cómo usar bibliotecas y controladores integrados
Cuando desarrolles con Spanner, considera cómo se relaciona el código con la base de datos. Spanner ofrece bibliotecas cliente integradas para muchos lenguajes populares, que suelen tener muchas funciones y un gran rendimiento. También están disponibles los controladores JDBC, que admiten lenguaje de manipulación de datos (DML) y lenguaje de definición de datos (DDL). En los casos en que se usa Spanner para desarrollos nuevos, recomendamos usar las bibliotecas cliente de Cloud para Spanner. Aunque las integraciones típicas de los motores de videojuegos no tienen mucha flexibilidad en la selección de lenguajes, para los servicios de plataforma que acceden a Spanner, hay casos de clientes de videojuegos que usan Java o Go. En aplicaciones de alta capacidad de procesamiento, selecciona una biblioteca en la que puedas usar el mismo cliente de Spanner para varias solicitudes secuenciales.
Adapta el tamaño de la base de datos de acuerdo con las necesidades de prueba y producción
Durante el desarrollo, es probable que una instancia de Spanner de nodo único sea suficiente para la mayoría de las actividades, incluidas las pruebas funcionales.
Evalúa las necesidades de Spanner para la producción
Cuando pasas de la etapa de desarrollo a la de prueba y, luego, a la de producción, es importante que vuelvas a evaluar las necesidades de Spanner para garantizar que el videojuego pueda manejar el tráfico de jugadores en vivo.
Antes de pasar a la producción, las pruebas de carga son fundamentales para verificar que el backend pueda manejar la carga durante la producción. Recomendamos realizar pruebas de carga con el doble de la carga que esperas en la producción a fin de estar preparado para los picos de uso y casos en los que el juego sea más popular de lo esperado.
Ejecuta pruebas de carga con datos reales
Ejecuta una prueba de carga con datos sintéticos no es suficiente. También debes ejecutar pruebas de carga con datos y patrones de acceso que se parezcan todo lo posible a lo que se espera en la producción. Es posible que los datos sintéticos no detecten hotspots potenciales en el diseño del esquema de Spanner. Nada es mejor que ejecutar 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 probar las cargas.
El estudio preparó estos datos en función de las tendencias de un juego anterior que habían operado durante un par de años. La empresa esperaba que el esquema representara bien los datos de este juego nuevo.
Cada registro de jugador tiene algunos atributos numéricos asociados que hacen un seguimiento del progreso del jugador en el juego (como la clasificación y el tiempo de juego). Para el atributo de ejemplo usado en la tabla anterior, los jugadores nuevos reciben un valor inicial de 50, que luego cambia a un valor entre 1 y 100 a medida que el jugador avanza.
El estudio desea indexar este atributo para acelerar las consultas importantes durante el juego.
En función de estos datos, el estudio creó la siguiente tabla de Spanner, con una clave primaria que usa el 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)
Y el índice se consultó para encontrar hasta diez jugadores con Attribute=23, de la siguiente manera:
SELECT PlayerID
FROM Player@{force_index=idx_attribute}
WHERE Attribute = 23
LIMIT 10
Según la documentación en Optimiza el diseño de esquemas, Spanner almacena los datos de índices de la misma manera que las tablas, con una fila por cada entrada de índice. En las pruebas de carga, este modelo hace un trabajo aceptable para distribuir la carga de lectura y escritura del índice secundario en varias divisiones de Spanner, como se muestra en el siguiente diagrama:
Aunque los datos sintéticos que se usaron en la prueba de carga son similares al estado constante final del juego en el que los valores Attribute están bien distribuidos, el diseño del juego determina que todos los jugadores comienzan con Attribute=50. Debido a que cada jugador nuevo comienza con Attribute=50, cuando se unen jugadores nuevos, se insertan en la misma parte del índice secundario idx_attribute. Esto significa que las actualizaciones se enrutan a la misma división de Spanner, lo que genera un hotspot durante la ventana de lanzamiento del videojuego. Este es un uso ineficiente de Spanner.
En el siguiente diagrama, cuando se agrega una columna IndexPartition al esquema después del lanzamiento, se resuelve el problema del hotspot, y los jugadores se distribuyen de manera uniforme en las divisiones disponibles de Spanner. El comando actualizado para crear la tabla y el índice tiene el siguiente aspecto:
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 IndexPartition debe tener un rango limitado para realizar consultas eficientes.
pero también debería tener un rango que sea al menos el doble del número de divisiones para
distribución eficiente.
En este caso, el estudio asignó a cada jugador un IndexPartition entre 1 y 6 en la aplicación del videojuego de forma manual.
Los métodos alternativos pueden ser la asignación de un número aleatorio a cada jugador o la asignación de un valor derivado de un hash en el valor PlayerID.
Consulta What DBA need to know about Spanner, part 1: Keys and indexes (Qué deben saber los DBA sobre Spanner, parte 1: índices y claves).
para ver más estrategias de fragmentación
a nivel de la aplicación.
La actualización de la consulta anterior para usar este índice mejorado tiene el siguiente aspecto:
SELECT PlayerID
FROM Player@{force_index=idx_attribute}
WHERE IndexPartition BETWEEN 1 and 6
AND Attribute = 23
LIMIT 10
Debido a que no se ejecutó una prueba Beta, el estudio no se dio cuenta de que estaban realizando pruebas con datos supuestos incorrectos. Aunque las pruebas de carga sintética son una buena manera de validar cuántas consultas por segundo (QPS) que puede manejar tu instancia, se necesita una prueba beta con jugadores reales para validar tu esquema y preparar un lanzamiento exitoso.
Ajusta el tamaño del entorno de producción para anticipar la demanda máxima
Los juegos principales a menudo experimentan picos de tráfico en el lanzamiento. Crear un de backend escalable se aplica no solo a los servicios de plataforma y a las sino también a las bases de datos. Usar soluciones de Google Cloud, como App Engine puede crear servicios de API de frontend que pueden escalar verticalmente con rapidez. Aunque Spanner ofrece la flexibilidad de agregar y quitar nodos en línea, no es una base de datos de ajuste de escala automático. Debes aprovisionar suficientes nodos para manejar el aumento drástico de tráfico en el lanzamiento.
En función de los datos que hayas recopilado durante las pruebas de carga o cualquier prueba Beta pública, puedes estimar la cantidad de nodos necesarios para manejar las solicitudes en el inicio. Una buena práctica es agregar algunos nodos como respaldo en caso de que se sumen más jugadores de lo esperado. Siempre debes ajustar el tamaño de la base de datos de modo que no supere un uso de CPU promedio del 65 %.
Prepara la base de datos antes del lanzamiento del juego
Antes de iniciar el juego, te recomendamos calentar la base de datos para aprovechar las funciones de paralelización de Spanner. Para obtener más información, consulta Preparación de la base de datos antes del lanzamiento de la aplicación.
Supervisa y entiende el rendimiento
Cualquier base de datos de producción requiere una supervisión completa y métricas de rendimiento. Spanner cuenta con métricas integradas en Cloud Monitoring. Siempre que sea posible, recomendamos incorporar las bibliotecas gRPC proporcionadas en el proceso de backend del videojuego, ya que estas bibliotecas incluyen el seguimiento de OpenCensus. El seguimiento de OpenCensus te permite ver registros de consultas en Cloud Trace y otras herramientas de seguimiento de código abierto compatibles.
En Cloud Monitoring, puedes ver detalles sobre el uso de Spanner, incluido el almacenamiento de datos y el uso de CPU. Para la mayoría de los casos, recomendamos basar las decisiones de escalamiento de Spanner en esta métrica de uso de la CPU o en la latencia observada. Para obtener más información uso sugerido de la CPU para un rendimiento optimizado, consulta Prácticas recomendadas.
Spanner ofrece planes de ejecución de consultas. Puedes revisar estos planes en la consola de Cloud y comunicarte con el equipo de asistencia si necesitas ayuda para comprender el rendimiento de las consultas.
Cuando evalúes el rendimiento, reduce al mínimo las pruebas de ciclo corto, ya que Spanner divide los datos con transparencia en segundo plano para optimizar el rendimiento en función de los patrones de acceso a los datos. Debes evaluar el rendimiento mediante el uso de cargas de consultas continuas y realistas.
A la hora de quitar datos, borra filas en lugar de volver a crear tablas
Cuando trabajas con Spanner, las tablas recién creadas aún no tuvieron la oportunidad de dividirse en función de la carga o el tamaño para mejorar el rendimiento. Cuando borras datos mediante la eliminación de una tabla y la vuelves a crear, Spanner necesita datos, consultas y tiempo para determinar las divisiones correctas de la tabla. Si planeas volver a completar una tabla con el mismo tipo de datos (por ejemplo, cuando ejecutas pruebas de rendimiento consecutivas), puedes ejecutar una consulta DELETE en las filas que contienen datos que ya no necesitas. Por el mismo motivo, las actualizaciones de esquema deben usar la API de Cloud Spanner proporcionada, y se debe evitar el uso de una estrategia manual, como crear una tabla nueva y copiar los datos desde otra tabla o un archivo de copia de seguridad.
Selecciona una localidad de datos para satisfacer los requisitos de cumplimiento
Muchos juegos deben cumplir leyes de localidad de datos, como el RGPD cuando se juega en todo el mundo. Para satisfacer tus necesidades relacionadas con el GDPR, consulta el Informe de Google Cloud y el GDPR y seleccionar la opción Configuración regional de Spanner.
¿Qué sigue?
- Descubre cómo Bandai Namco Entertainment usó Spanner para el lanzamiento exitoso de Dragon Ball Legends.
- Mira la sesión Cloud Next '18 sobre la optimización de aplicaciones, esquemas y diseño de consultas en Spanner.
- Lee nuestra guía Migra de DynamoDB a Spanner.