Compila aplicaciones escalables con Firestore

En este documento, se describe cuándo usar Firestore para compilar aplicaciones de gran tamaño. En este documento, se proporcionan soluciones para administradores de infraestructura que administran sistemas de base de datos de aplicaciones de gran tamaño. Usar Firestore junto con otros productos en Google Cloud simplifica el aprovisionamiento y el mantenimiento de una base de datos para que puedas enfocarte en desarrollar tu app en lugar de planificar la capacidad.

Funciones y limitaciones de Firestore

Firestore se diseñó para aplicaciones web y para dispositivos móviles con el fin de almacenar datos transaccionales jerárquicos con un esquema flexible y no relacional. Cuando evalúes Firestore como una posible solución de base de datos, asegúrate de que sus cuotas y límites sean adecuados para tus casos de uso. Firestore es versátil y aplicable en muchas instancias, pero otros productos de bases de datos de Google Cloud pueden ser mejores para determinadas situaciones. Al momento de decidir si usar Firestore o una solución diferente, ten en cuenta los siguientes factores.

Almacenamiento

Firestore puede alojar cualquier cantidad de almacenamiento de datos. Controla desde kilobytes hasta petabytes de datos de la misma manera sin que el rendimiento se vea afectado.

Actualizaciones en tiempo real

Firestore proporciona actualizaciones en tiempo real y permite que los clientes detecten un documento y usen consultas para obtener actualizaciones en tiempo real. Proporcionas una devolución de llamada que crea de inmediato una instantánea del documento con el contenido actual de un solo documento. Cada vez que se cambia el contenido del documento, otra llamada actualiza la instantánea del documento.

Persistencia de datos sin conexión

Firestore proporciona persistencia de datos sin conexión con soporte sin conexión total para clientes web y móviles. Puedes acceder y actualizar tus datos mientras estés sin conexión y, luego, sincronizar los cambios en la nube de forma automática cuando vuelvas a conectarte. El soporte sin conexión integrado usa una caché local para entregar y almacenar datos, por lo que la app se mantiene ágil sin importar la latencia de la red ni la conectividad a Internet.

Transacciones

Firestore admite transacciones de varios documentos que cumplen con ACID. El término ACID es el acrónimo en inglés de atomicidad, coherencia, aislamiento y durabilidad.

Consultas

Firestore ofrece consultas con coherencia sólida en toda la base de datos. Junto con los índices principales, Firestore admite índices secundarios y compuestos para buscar con rapidez las ubicaciones de los elementos que solicitas en una consulta.

Las consultas de Firestore están limitadas de las siguientes maneras:

  • Firestore es una base de datos no relacional, por lo que no admite esquemas relacionales o consultas que usen la semántica de SQL. En particular, Firestore no admite operaciones de unión, el filtrado de desigualdad en varias propiedades ni el filtrado de datos basado en los resultados de una subconsulta.
    • Si la app requiere compatibilidad con SQL para escalamientos no horizontales, usa Cloud SQL.
    • Si la app requiere compatibilidad con SQL para escalamientos horizontales y globales más grandes, usa Cloud Spanner.
  • Datastore está optimizado para el procesamiento de transacciones en línea (OLTP).

Seguridad

Firestore encripta todos los datos de forma automática antes de escribirlos en el disco. Firestore ofrece autenticación y administración de acceso sólidos mediante los siguientes métodos, según las bibliotecas cliente que uses:

Ajuste de escala automático

Firestore escala verticalmente de forma automática, sin tiempo de inactividad. Este mecanismo de escalamiento permite que Firestore entregue miles de solicitudes por segundo y millones de conexiones simultáneas. Solo pagas por el uso real en función del tamaño de almacenamiento y la cantidad de operaciones. Para obtener más información, consulta los precios de Firestore.

El ajuste de escala automático de Firestore se limita de las siguientes maneras:

  • El modo nativo de Firestore puede escalar las operaciones de actualización de documentos a un máximo de 10,000 operaciones de escritura por segundo y más de un millón de conexiones. Si tu app supera estos límites de frecuencia de escritura, te recomendamos usar el modo Datastore, que escala verticalmente hasta millones de operaciones de escritura por segundo. Para obtener más información sobre las diferencias entre estos modos, consulta Elige entre el modo nativo y el modo Datastore.
  • Firestore puede controlar operaciones a escala masiva. Sin embargo, para admitir funciones complejas, como la replicación y las transacciones, Firestore realiza algunas compensaciones que pueden disminuir el rendimiento de las apps que se espera que admitan cargas extremas.
    • Si tu app tiene muchas operaciones de escritura, considera usar Cloud Bigtable a fin de obtener mayor capacidad de transferencia de datos a expensas de las transacciones y los índices secundarios.
    • Si tu app suele mostrar la misma información a los usuarios, como una tabla de clasificación de jugadores en los videojuegos, considera el almacenamiento en caché del lado del cliente para reducir la carga y evitar solicitudes innecesarias al servidor.

Latencia

Firestore prioriza la durabilidad y la disponibilidad sobre la latencia mediante escrituras síncronas entre regiones o zonas. Si la app requiere una latencia coherente inferior a 10 milésimas de segundo para leer o escribir datos, considera usar una base de datos en la memoria como Memorystore para Redis.

Redundancia y disponibilidad

Firestore ofrece los siguientes niveles de redundancia de varias ubicaciones que se basan en diferentes mecanismos de replicación:

  • La replicación regional es la mejor opción si tu prioridad es lograr una latencia de escritura baja. Cuando usas la replicación regional, los datos se replican dentro de la misma región. Para garantizar la latencia más baja, te recomendamos que coloques la app en la misma región.
  • La replicación multirregional es la mejor opción si tu prioridad es garantizar la disponibilidad. Cuando usas la replicación multirregional, los datos se replican en varias zonas en al menos dos regiones diferentes, por lo que la base de datos es resistente a las interrupciones por región. La replicación multirregional proporciona mayor disponibilidad y redundancia, pero tiene una latencia de escritura más alta. Un nodo testigo se implementa en una tercera región para que actúe como tiebreaker entre las dos regiones replicadas, como se ilustra en la figura 1.

Esquema de replicación de una base de datos multirregional

Figura 1. Diagrama de una base de datos multirregional en Firestore.

Bibliotecas cliente

Los clientes web y móviles pueden acceder directamente a Firestore mediante las bibliotecas cliente para Android, iOS y la Web. Firestore también se integra sin problemas en la plataforma de Firebase que proporciona funciones como Crash Reporting, autenticación de usuarios, entrega de mensajes y estadísticas de eventos de los usuarios.

Cuándo usar Firestore

Las funciones de Firestore son una buena opción para una amplia gama de casos de uso, incluidos los siguientes:

  • Perfiles de usuario: Administra perfiles de usuarios a fin de personalizar la experiencia del usuario según sus actividades y preferencias anteriores. Puedes usar el esquema flexible de Firestore para evolucionar la estructura de los perfiles de usuario. Por ejemplo, puedes agregar propiedades nuevas para admitir funciones nuevas en tu app. Los cambios en el esquema ocurren sin tiempo de inactividad y el rendimiento no disminuye incluso a medida que aumenta la cantidad de usuarios.
  • Inventarios en tiempo real: Usa los objetos enriquecidos y anidados de Firestore para almacenar grandes cantidades de datos dispersos y no homogéneos de diversos productos sin especializar demasiado la estructura. Por ejemplo, puedes crear un catálogo de productos para un minorista.
  • Administración de las sesiones de usuario: La compatibilidad de Firestore con las transacciones ACID garantiza que los usuarios puedan bloquear uno o más documentos hasta que se complete su transacción. Por ejemplo, puedes crear carritos de compras de transacciones minoristas o un formulario de procesamiento de varias partes para eventos de reserva.
  • Mutaciones de estado: Usa las transacciones ACID de Firestore para propagar las mutaciones en una gran cantidad de usuarios simultáneos. Por ejemplo, puedes mantener un estado coherente para todos los jugadores en una app de videojuegos.
  • Caché persistente de escritura inmediata: La alta disponibilidad y durabilidad de Firestore proporcionan un estado persistente y evitan la posible pérdida de datos causada por una falla de la app. Firestore ofrece características como un almacén de clave-valor fácil de usar. Sin embargo, Firestore no tiene un mecanismo de tiempo de vida (TTL) ni un mecanismo de vencimiento de caché integrados.
  • Sincronización de datos en varios dispositivos: Las actualizaciones en tiempo real de Firestore garantizan que todos los dispositivos conectados siempre muestren el estado más reciente. Por ejemplo, Firestore proporciona un estado coherente de las apps para dispositivos móviles, multiusuario y de colaboración y las apps a las que te conectas desde varios dispositivos.
  • Administración de IoT y seguimiento de recursos: La persistencia de datos sin conexión de Firestore te permite registrar datos incluso cuando los dispositivos pierden la conectividad de red. Por ejemplo, puedes configurar el seguimiento por GPS en tiempo real de dispositivos móviles y vehículos.
  • Funciones en tiempo real: Las actualizaciones en tiempo real de Firestore te permiten configurar estadísticas y mensajes en tiempo real. Puedes mantener actualizados grafos visuales y gráficos, como paneles visuales interactivos y configurar foros de debate en vivo y salas de chat.
  • Contadores distribuidos: Configura contadores distribuidos para mostrar interacciones de documentos, como un recuento de Me gusta en una publicación o favoritos en un elemento específico.

Arquitecturas de referencia

En esta sección, se proporcionan arquitecturas de referencia para compilar aplicaciones web de gran tamaño que combinan Firestore con otros productos de Google Cloud, como los siguientes:

  • Exportaciones diarias
  • Almacenamiento en caché
  • Procesamiento de datos
  • Modelos de entrenamiento para el aprendizaje automático

Estas arquitecturas no son prescriptivas. En cambio, destacan la variedad de usos posibles de Firestore en la compilación aplicaciones web escalables. Puedes reorganizar y adaptar las arquitecturas para compilar tu propia aplicación web que cumpla con tus requisitos.

Videojuegos

Una plataforma de videojuegos admite el acceso simultáneo de decenas de miles de jugadores. Los servicios de frontend del juego usan Firestore para almacenar miles de millones de documentos con datos jerárquicos del estado del mundo. Firestore también contiene los datos del usuario, como la configuración del usuario, las membresías de un grupo, los gremios, las listas de amigos y los datos de presencia. En este caso de uso, se incorporan otros productos de Google Cloud:

  • Spanner proporciona una base de datos con coherencia global que puede mantener el inventario o el historial de partidas para cantidades masivas de jugadores en cualquier lugar del mundo.
  • En Memorystore para Redis, se implementa una caché regional en memoria a fin de acelerar el acceso a los datos que se usan con frecuencia.
  • Los eventos se registran en Bigtable, donde los desarrolladores o el personal de asistencia pueden acceder a ellos para solucionar problemas.
  • Los datos de las bases de datos de frontend y backend se importan con frecuencia a BigQuery para ejecutar canalizaciones de análisis de datos. Estas canalizaciones ayudan a descubrir vulnerabilidades o mecánicas de juego que necesitan una actualización antes de que afecten a la comunidad del juego y alejen a los jugadores.

En la figura 2, se muestra la arquitectura del caso de uso de los videojuegos:

Arquitectura del caso de uso de los videojuegos.

Figura 2. Ejemplo de la arquitectura de una plataforma de videojuegos.

Internet de las cosas

Una aplicación web interactiva muestra información de telemetría en tiempo real generada por dispositivos de la Internet de las cosas (IoT). Los dispositivos miden y recopilan la temperatura y el ritmo cardíaco del usuario con regularidad y, luego, procesan los datos de la siguiente manera:

  1. Cada medición se envía de inmediato a IoT Core a través de puentes MQTT y HTTP.
  2. IoT Core publica cada medición como un mensaje individual en Pub/Sub.
  3. El mensaje de Pub/Sub activa Cloud Functions que extrae información relevante de los mensajes sin procesar y guarda los resultados en Firestore para el almacenamiento a largo plazo.
  4. Una interfaz de usuario web interactiva alojada en Firebase Hosting y con la tecnología de Angular detecta las actualizaciones directamente desde Firestore. Cada actualización se envía de forma automática a la interfaz de usuario web para visualizar la información más reciente en tiempo real.

En la figura 3, se muestra la canalización de datos para la información de telemetría en esta situación:

Arquitectura del caso de uso de la app de la IoT.

Figura 3. Ejemplo de la arquitectura de una app de la IoT

Venta minorista

Una plataforma de venta minorista proporciona recomendaciones de productos a los compradores de primera vez a través de diferentes medios. Una aplicación web registra datos en vivo sobre los usuarios en línea, como la referencia, la región geográfica y el tipo de dispositivo, y, luego, escribe los datos recopilados en Firestore de la siguiente manera:

  1. Cada creación de un registro nuevo activa una canalización de datos en Cloud Functions que copia los datos del usuario en BigQuery.
  2. Un motor de recomendaciones implementado con Spark MLlib e implementado en Dataproc, se entrena con los datos del usuario activo almacenados en BigQuery y con los metadatos del producto almacenados en Cloud SQL.
  3. El motor de recomendaciones proporciona las siguientes predicciones para los productos recomendados:
    • Predicciones en tiempo real que se escriben en Firestore y se envían de forma automática a los dispositivos de los usuarios en línea
    • Predicciones por lotes que se envían a los usuarios sin conexión mediante un servicio de correo electrónico

En la figura 4, se muestra el flujo de datos para la situación de la plataforma de venta minorista:

Arquitectura del caso de uso de la plataforma de venta minorista

Figura 4. Ejemplo de arquitectura de la plataforma de venta minorista.

Captura de cambios de datos en tiempo real

Una app recibe entradas del usuario en tiempo real que cambian el estado global. Un panel en Data Studio realiza un seguimiento de los eventos en tiempo real para comprender mejor el comportamiento y las interacciones de los usuarios. Cuando una acción del usuario actualiza un valor de estado, se producen los siguientes eventos:

  1. Firestore activa una función de Cloud Functions que escribe el cambio en BigQuery, incluidos los valores de estado antiguos y los nuevos.
  2. El panel de Data Studio ejecuta consultas de agregación en tiempo real en los datos de eventos en BigQuery.
  3. Las consultas generan métricas, como la proporción de cambios de eventos agregados a depósitos diferentes, el tipo único de eventos por depósito de tiempo y la latencia de la transferencia de eventos.

Para obtener una presentación y demostración detallada de esta arquitectura, consulta el video de Cloud Next '19 Building amazing apps With Firestore (Compila apps increíbles con Firestore).

En la figura 5, se muestra la arquitectura para capturar cambios en los datos en tiempo real:

Arquitectura del caso de uso de la captura de datos

Figura 5. Ejemplo de una arquitectura de captura de datos simples.

Edición de contenido colaborativo

Un sistema de administración de contenido (CMS) colaborativo permite que varios editores trabajen al mismo tiempo en el mismo artículo. Cada vez que un editor realiza un cambio, por ejemplo, agregar o borrar un carácter, el cliente del editor envía el cambio directamente a Firestore.

Si varios editores envían cambios al mismo tiempo, se genera el siguiente proceso de resolución:

  1. Las transacciones de Firestore garantizan que solo el primer cambio recibido se escriba en la base de datos. Se rechazan otros cambios.
  2. Firestore envía de forma automática el contenido actualizado a todos los editores.
  3. Los editores que se rechazaron en un principio vuelven a aplicar sus propios cambios sobre el contenido actualizado y, luego, vuelven a enviar los cambios a Firestore.
  4. El mismo proceso de resolución de conflictos se repite hasta que todos los cambios de todos los clientes se aceptan y se escriben en la base de datos.

Una canalización de la etapa de pruebas permite que los editores obtengan una vista previa del contenido de la siguiente manera:

  1. Un trabajo cron alojado en Cloud Scheduler activa Cloud Functions cada segundo.
  2. La función copia el contenido más reciente de Firestore en la base de datos de etapa de pruebas alojada en Cloud SQL.
  3. Los editores obtienen una vista previa del contenido publicado en etapa de pruebas en el servidor de etapa de pruebas alojado en App Engine.

Cuando se completa el contenido, un editor hace clic en el botón Publicar en el CMS. Esta acción activa una función de Cloud Functions que copia el contenido más reciente de Firestore a la base de datos de producción alojada en Cloud SQL. Luego, los lectores pueden consumir el contenido recién publicado en el sitio web de producción. Si deseas ver un ejemplo real similar de esta arquitectura, consulta el artículo del The New York Times We Built Collaborative Editing for Our Newsroom's CMS (Creamos la edición colaborativa del CMS para nuestra sala de prensa).

En la figura 6, se muestra la canalización para la edición, la etapa de pruebas y la publicación de contenido en el caso de uso de edición de contenido colaborativo:

Arquitectura del caso de uso de edición de contenido.

Figura 6. Ejemplo de una arquitectura de plataforma de edición colaborativa.

Próximos pasos