Recomendaciones para el uso de Cloud Spanner como base de datos de videojuegos

En este documento se describen las prácticas recomendadas para el uso de Cloud Spanner como la base de datos de backend principal para el almacenamiento del estado de un videojuego. Puedes usar Cloud Spanner en lugar de bases de datos comunes para almacenar los datos de autenticación de un jugador y los datos de inventario. Este documento se dirige a ingenieros de backend de videojuegos que trabajan en el almacenamiento de estado a largo plazo, así como administradores y operadores de infraestructura de videojuegos que brindan asistencia a esos sistemas y están interesados en alojar sus bases de datos de backend en Google Cloud Platform (GCP).

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 autorizaciones, estados e inventario 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 fragmentación o agrupación en clústeres. El seguimiento de artículos valiosos dentro del juego o del progreso de los jugadores, generalmente, requiere transacciones. Además, trabajar con muchos tipos de bases de datos distribuidas resulta desafiante.

Cloud Spanner es el primer servicio de base de datos escalable, de nivel empresarial, distribuido en todo el mundo y con coherencia sólida, creado específicamente para la nube, y que combina los beneficios de la estructura de las bases de datos relacionales con el escalamiento horizontal no relacional. Para muchas empresas de videojuegos ofrece 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 GCP Console para agregar nodos. Cloud Spanner puede manejar de manera transparente la replicación global con coherencia sólida y, al mismo tiempo, eliminar la necesidad de administrar réplicas regionales.

En este documento sobre recomendaciones, se abordan los siguientes temas:

  • Conceptos importantes sobre Cloud Spanner y diferencias con las bases de datos que se suelen utilizar en los videojuegos
  • Cuándo es Cloud Spanner la base de datos adecuada para tu videojuego
  • Patrones que deben evitarse cuando se utiliza Cloud Spanner para videojuegos
  • Diseño de las operaciones de base de datos con Cloud Spanner como la base de datos del videojuego
  • Modelado de los datos y creación de un esquema para obtener el mejor rendimiento con Cloud 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 número de la tarjeta de crédito y 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 almacenan el progreso del jugador y el inventario dentro del videojuego.
Base de datos de autenticación
Es una base de datos que incluye las autorizaciones del jugador y la PII que los jugadores utilizan cuando realizan una compra. La base de datos de autenticación también se conoce como base de datos de la cuenta o 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 con diversos 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 única instancia en el backend del videojuego.
Nodo
A los fines de este documento, es una máquina única que ejecuta una copia del software de base de datos.
Réplica
Es una segunda copia de una base de datos. Las réplicas se suelen utilizar para recuperación de datos y alta disponibilidad, o para ayudar a aumentar el rendimiento de lectura.
Clúster
Son varias copias del software que se ejecutan en muchas máquinas, las cuales aparecen como una sola instancia para el backend del videojuego. La agrupación en clústeres se utiliza 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 se conoce como un fragmento. La fragmentación, generalmente, se realiza por cuestiones de rendimiento o escalabilidad; se sacrifica la eficiencia de la administración y se aumenta la complejidad de la aplicación.
Hotspot
Es cuando un solo fragmento en una base de datos distribuida, como Cloud 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 se degrada el rendimiento.

Cómo usar Cloud Spanner para videojuegos

En la mayoría de los casos en los que consideres un RDBMS para tu videojuego, Cloud Spanner será una opción adecuada, porque puede reemplazar efectivamente la base de datos del videojuego, la base de datos de autenticación o, en muchos casos, ambas.

Bases de datos de videojuegos

Cloud Spanner puede operar como una única autoridad transaccional a nivel mundial, lo que lo hace que resulte sumamente idónea para los sistemas de inventario de los juegos. 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.

Cloud Spanner puede simplificar el enfoque para las transacciones de monedas y de inventario. Incluso si se utiliza Cloud Spanner para contener todos los datos del juego a nivel mundial, esta solución ofrece transacciones de lectura y escritura con niveles de atomicidad, coherencia, aislamiento y durabilidad (ACID) aún más sólidos que con los métodos tradicionales. La escalabilidad de Cloud Spanner significa que no es necesario fragmentar los datos en instancias de bases de datos separadas cuando se requiere más rendimiento o almacenamiento; en su lugar, simplemente agregas más nodos. Además, Cloud Spanner maneja con transparencia la alta disponibilidad y resiliencia de datos para las cuales los videojuegos a menudo agrupan sus bases de datos en clústeres. Por lo tanto, no requiere configuración o administración adicional.

Bases de datos de autenticación

Cloud Spanner también puede utilizarse para las bases de datos de autenticación, en especial si deseas estandarizar en un solo RDBMS a nivel de estudio o publicador. Si bien las bases de datos de autenticación para juegos a menudo no requieren la escala de Cloud Spanner, sus garantías transaccionales y la alta disponibilidad de los datos la convierten en una alternativa atractiva. La replicación de datos en Cloud Spanner es transparente, integrada y síncrona. Cloud Spanner tiene configuraciones que ofrecen 99.99% ("cuatro nueves") o 99.999% ("cinco nueves") de disponibilidad. Los "cinco nueves" corresponden a menos de cinco minutos y medio de no disponibilidad al año. Gracias a este tipo de disponibilidad, es una buena opción para la ruta 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 Cloud Spanner en el diseño de videojuegos. Es importante modelar los datos del juego con el fin de beneficiarse de las características únicas que ofrece Cloud Spanner. Si bien puedes acceder a Cloud 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. La documentación de Cloud Spanner contiene recomendaciones detalladas para el diseño de esquemas que puedes revisar, pero las siguientes secciones incluyen algunas prácticas recomendadas para las bases de datos de videojuegos.

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 fragmentos de la base de datos y puede ayudar a obtener un mayor rendimiento con Cloud Spanner.

Utiliza 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 Cloud 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 identificador del jugador que es el propietario actual. Esta columna es la clave primaria de una tabla de base de datos separada. En Cloud Spanner, puedes utilizar la intercalación, que almacena las filas del inventario cerca de la fila asociada de la tabla del jugador para un mejor rendimiento. Cuando utilices tablas intercaladas, recuerda lo siguiente:

  • Debes mantener todos los datos en la fila del jugador y todas las filas de inventario descendientes deben tener ~2 GiB. Esta restricción no suele representar un problema si cuentas con un diseño adecuado para el modelo de datos.
  • 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 Cloud Spanner, la creación o actualización de una fila con datos en ese índice genera una carga de escritura adicional proporcional al número de columnas indexadas. Puedes mejorar el rendimiento de Cloud Spanner si eliminas 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 identificador 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 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 rápidamente.

Si desea obtener una clasificación para este modo de juego, el índice solo escanea las filas que contienen GameMode=1 y proporciona una latencia de lectura baja. Sin embargo, si todos juegan el mismo modo de juego, este índice crea un hotspot.

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). En el momento de redacción de este documento, el número máximo de tablas por base de datos en Cloud Spanner es 2048, lo cual es más que suficiente para la mayoría de los juegos.

Bases de datos separadas por instancia

A diferencia de otras cargas de trabajo, para las que recomendamos diseñar para varias latencias en Cloud Spanner mediante el uso de diferentes valores de clave primaria, para los datos de videojuegos, recomendamos el enfoque más convencional de usar bases de datos separadas para cada instancia. Los cambios de esquema son comunes con el lanzamiento de nuevas características de los juegos de servicio en vivo, y el aislamiento de las instancias a nivel de la base de datos puede simplificar las actualizaciones del esquema. Esta estrategia también permite optimizar el tiempo que lleva crear copias de seguridad o restablecer los datos de la instancia, ya que estas operaciones se realizan en toda la base de datos completa a la vez.

Evita actualizaciones de esquema incrementales

A diferencia de algunas bases de datos relacionales convencionales, Cloud Spanner permanece operativa durante las actualizaciones de esquema. Se muestran todas las consultas sobre el esquema anterior (aunque pueden devolverse con menor velocidad de lo habitual), y las consultas sobre el esquema nuevo se muestran a medida que están disponibles. Puedes diseñar tu proceso de actualización para que el juego continúe en ejecución durante las actualizaciones de esquema cuando se ejecuta en Cloud 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 pone en cola y no tendrá lugar hasta que todas las actualizaciones de esquema anteriores se hayan completado. 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. Si deseas obtener más información sobre las actualizaciones de esquema, incluso cómo realizar una actualización de esquema que requiere validación de datos, consulta Actualizaciones de esquema de Cloud.

Considera el acceso y el tamaño de la base de datos

Cuando desarrolles el servidor del juego y los servicios de plataforma para usar Cloud Spanner, considera cómo accede el juego a la base de datos y qué dimensiones dar a la base de datos a fin de evitar costos innecesarios.

Utiliza bibliotecas y controladores nativos

Cuando desarrolles con Cloud Spanner, considera cómo se relaciona el código con la base de datos. Cloud Spanner ofrece bibliotecas cliente nativas para diversos 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 utiliza Cloud Spanner para desarrollos nuevos, recomendamos el uso de las bibliotecas clientes de Cloud para Cloud Spanner. Aunque las integraciones de los motores de juegos típicas no cuentan con mucha flexibilidad en la selección de lenguajes, para los servicios de plataforma que acceden a Cloud Spanner, hay casos de clientes de videojuegos que utilizan Java o Go. En aplicaciones de alto rendimiento, selecciona una biblioteca en la que puedas usar el mismo cliente de Cloud Spanner para múltiples solicitudes secuenciales.

Adapta el tamaño de la base de datos de acuerdo con las necesidades de prueba y producción

Durante el desarrollo, una instancia de Cloud Spanner de un solo nodo probablemente sea suficiente para la mayoría de las actividades, incluidas las pruebas funcionales.

Evalúa las necesidades de Cloud Spanner para la producción

Cuando pasas del desarrollo a la prueba y, luego, a la producción, es importante que vuelvas a evaluar tus necesidades de Cloud Spanner para asegurarte de 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

Ejecutar 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 parezca 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 Cloud Spanner. Nada es mejor que ejecutar una prueba Beta (abierta o cerrada) con jugadores reales para verificar cómo se comporta Cloud Spanner con datos reales.

El siguiente diagrama es un ejemplo de un estudio de videojuegos que ilustra la importancia de usar pruebas Beta para analizar las cargas.

Lista de nombres de jugadores y su clasificación para pruebas de carga

El estudio preparó algunos datos representativos basados en las tendencias que tenían de un juego anterior que habían operado durante un par de años. Esta tabla contiene ejemplos de nombres de jugadores y su clasificación.

Sobre la base de esta información, el modelo de datos para Cloud Spanner indexa los jugadores según su clasificación. En las pruebas de carga, este modelo hace un trabajo aceptable para distribuir los datos en varios fragmentos, como se ilustra en el siguiente diagrama.

Jugadores distribuidos en los servidores de Cloud Spanner según su clasificación

Los datos sintéticos utilizados en la prueba de carga son similares al estado constante final del juego (en que las clasificaciones de los jugadores están bien distribuidas). Los jugadores se distribuyen en varios servidores de Cloud Spanner según su clasificación.

Sin embargo, el diseño del juego determina que todos los jugadores comenzaron en la posición 1. En el siguiente diagrama, se muestran todos los jugadores en el lanzamiento en el mismo servidor de Cloud Spanner, mientras que los otros servidores de Cloud Spanner no están en uso.

Los jugadores con la misma clasificación en el lanzamiento crean un hotspot en una sola instancia de Cloud Spanner.

Esto crea un hotspot durante la ventana de lanzamiento debido a la incorporación masiva de jugadores nuevos que utilizan el mismo fragmento en lugar de distribuirse entre los distintos fragmentos, lo que afecta la disponibilidad del juego.

Después del lanzamiento, el problema del hotspot se resuelve en el siguiente diagrama, porque los jugadores se distribuyen de modo uniforme entre los fragmentos.

La incorporación de una columna de fragmentos al esquema distribuye de modo uniforme a los jugadores en el lanzamiento por fragmento en lugar de por clasificación.

Tras la incorporación de una columna ShardID en el esquema y la indexación de la columna nueva, los jugadores se distribuyen de manera uniforme en los servidores de Cloud Spanner disponibles.

Debido a que no se ejecutó una prueba Beta, el estudio no se dio cuenta de que estaban realizando pruebas con datos supuestos incorrectos. Si bien las pruebas de carga sintética constituyen una buena manera de validar la cantidad de consultas por segundo que puede manejar la instancia, se requiere una prueba Beta con jugadores reales para validar el 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. La creación de un backend escalable se aplica no solo a los servicios de plataforma y servidores de juegos dedicados, sino también a las bases de datos. Mediante el uso de soluciones de GCP, como App Engine, puedes crear servicios de API de frontend que pueden escalarse rápidamente. Aunque Cloud 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 pico 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 %.

Precalienta la base de datos antes del lanzamiento

Otro paso importante de la preparación previa al lanzamiento es el calentamiento de la base de datos.

Cloud Spanner en estado frío no puede proporcionarte los nodos que necesitas para el lanzamiento sin un calentamiento previo.

Cloud Spanner es una base de datos distribuida, lo que significa que a medida que la base de datos crece, Cloud Spanner divide los datos en fragmentos llamados divisiones. Las divisiones individuales pueden moverse de manera independiente respecto de las otras y asignarse a distintos servidores, que pueden estar en diferentes ubicaciones físicas. Si deseas obtener más información, consulta Divisiones de bases de datos.

Una división se define como un rango de filas. En otras palabras, contiene un subconjunto de tu tabla. Cloud Spanner divide los datos en función de la carga y el tamaño. De esa manera, las divisiones se pueden mover de forma dinámica a través de los nodos de Cloud Spanner para balancear la carga total en la base de datos. Cuantos más datos ingreses en Cloud Spanner, más divisiones se generan.

En el siguiente diagrama, hay cuatro nodos.

Datos en un nodo cuando Cloud Spanner está frío

Debido a que no hay datos en Cloud Spanner, cuando comienzas a escribir datos, escribes en un solo nodo. En este momento, Cloud Spanner se encuentra en estado frío.

En el siguiente diagrama, se ilustra la división para los otros nodos.

Los datos se dividen entre distintos nodos cuando Cloud Spanner está caliente.

A medida que se ingresan datos en el sistema, Cloud Spanner comienza a dividirlos para volver a balancear la carga en los cuatro nodos aprovisionados. Ahora Cloud Spanner se encuentra en estado caliente.

Es aconsejable que inicies el juego cuando Cloud Spanner está en estado caliente, con las divisiones ya equilibradas en todos los nodos. Sigue estos pasos para calentar la base de datos:

  1. Asegúrate de que las claves primarias de la tabla que generes para tu prueba de carga estén en el mismo espacio de claves (tengan las mismas propiedades estadísticas) que las claves que estás usando para el tráfico de producción real.
  2. Ejecuta una prueba de carga dos días antes del lanzamiento. Ejecuta la prueba de carga durante al menos una hora a la carga máxima esperada. La prueba de carga hace que Cloud Spanner cree más divisiones debido a la división basada en la carga.
  3. Una vez finalizada la prueba de carga, puedes borrar de tus tablas las filas generadas por la prueba de carga, pero no borres las tablas. Así mantendrás las divisiones disponibles para la ventana de lanzamiento.

Supervisa y entiende el rendimiento

Cualquier base de datos de producción requiere una supervisión completa y métricas de rendimiento. Cloud Spanner incluye métricas incorporadas en Stackdriver. Siempre que sea posible, recomendamos incorporar las bibliotecas gRPC proporcionadas en el proceso de backend del juego, ya que estas bibliotecas incluyen el seguimiento de OpenCensus. El seguimiento de OpenCensus te permite ver registros de consultas en Stackdriver, además de otras herramientas de seguimiento de código abierto compatibles.

En Stackdriver, puedes ver detalles sobre el uso de Cloud Spanner, incluido el almacenamiento de datos y el uso de la CPU. Para la mayoría de los casos, recomendamos basar las decisiones de escalamiento de Cloud Spanner en esta métrica de uso de la CPU o la latencia observada. Si deseas obtener más información sobre el uso de CPU sugerido para un rendimiento optimizado, consulta Recomendaciones para las instancias.

Cloud Spanner ofrece planes de ejecución de consultas. Puedes revisar estos planes en GCP Console y comunicarte con el equipo de asistencia si necesitas ayuda para comprender el rendimiento de tus consultas.

Cuando evalúes el rendimiento, reduce al mínimo las pruebas de ciclo corto, ya que Cloud 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 Cloud Spanner, las tablas recién creadas aún no han tenido la oportunidad de someterse a la división basada en la carga o el tamaño para mejorar el rendimiento. Cuando borras datos mediante la eliminación de una tabla y su posterior creación, Cloud 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 provista, 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 videojuegos deben cumplir leyes de localidad de datos, como GDPR, cuando se juegan en todo el mundo. Para satisfacer las necesidades del GDPR, consulta el documento técnico de GCP y GDPR, y selecciona la configuración regional de Cloud Spanner correcta.

Pasos siguientes

¿Te ha resultado útil esta página? Enviar comentarios:

Enviar comentarios sobre...