Solución:
Costo.
Firestore en el modo Datastore admite consultas de proyección y de solo clave, al igual que el almacén de datos original. Eso significa que el conjunto de resultados de esas consultas cuenta para las “Operaciones pequeñas de Cloud Firestore”, que son gratuitas. Acumulamos miles de millones de esas pequeñas operaciones por día y no tener consultas de proyección multiplicaría efectivamente por 10 el costo de nuestro almacén de datos, lo que sería insoportable.
Como esta función no está disponible en el modo nativo de Firestore, y también con la fuerte consistencia agregada, esperábamos que tuviera un rendimiento menor que en el almacén de datos original, pero en nuestras pruebas este no fue el caso. Firestore en el modo de almacén de datos se desempeñó de manera constante aproximadamente el doble de rápido para nuestra aplicación en todo tipo de operaciones.
Existen ventajas de utilizar el “modo de almacén de datos”, incluso para un proyecto nuevo.
Estoy evaluando los dos modos de firestore “modo Datastore” y “modo nativo” para un proyecto de migración desde MySQL.
Por un lado, considero usar el “modo Datastore” para un repositorio global de back-end porque:
- Solo del lado del servidor
- Fuerte expectativa de rendimiento en las consultas de búsqueda en todas las entidades
- Consultar y ordenar varias propiedades en total
- Modelo de datos estructurado con un tipo de raíz y pocos tipos de segundo nivel
- Mucha escritura con requisitos de transacción limitados, una gran cantidad de lectura con proyección dentro de un grupo de entidades
Por otro lado, el “modo nativo” parece cumplir algunos requisitos para un usuario que se enfrenta a una aplicación específica porque:
- Web, iOS, Android, interfaz API con sincronización bidireccional
- Varios casos de uso conectados ocasionalmente
- Pocos objetos polimórficos grandes para sincronizar y persistir
- Consulta principalmente simple en una propiedad (objeto principal)
Sin embargo, hay una razón que aboga por el modo Datastore para el segundo proyecto
- Multi-tenancy con espacio de nombres
También hay necesidades comunes satisfechas por ambos modos, que respaldan la decisión de migrar a tecnologías NoSQL.
- Escalabilidad
- Sin administrador
- Disponibilidad
- Velocidad de desarrollo
Los elementos 2 a 5 y 10 se basan en funciones específicas para el modo de almacén de datos, que no son posibles en el modo nativo. Los elementos del 6 al 9 son específicos del modo nativo.
Actualización: 21 de marzo de 2019
Seis meses después de la evaluación descrita en mi primera respuesta, mi equipo está usando el modo Firestore (nativo) y el modo Datastore.
-
2 proyectos basados en Firestore. Estamos utilizando mucho los conceptos de recopilación, subcolección y documentos y la segregación implícita de datos. También hemos implementado oyentes en aplicaciones de iOS y Android para subcolecciones seleccionadas de acuerdo con sólidas reglas comerciales y de seguridad, lo que no es posible con Datastore.
-
9 proyectos basados en Datastore. Para tres 3 de ellos, estamos usando mucho los conceptos de espacio de nombres y tipo. También utilizamos la indexación global de las propiedades de kind y la proyección de propiedades del lado del servidor, lo que no es posible con Firestore.
PD: estamos considerando abrir nuestra biblioteca de Python para el desarrollo rápido de una API común que se ejecute en Firestore y en Datastore.
Según la documentación oficial, aunque Cloud Firestore es compatible con versiones anteriores de Cloud Datastore, el nuevo modelo de datos, las actualizaciones en tiempo real y las funciones de biblioteca de cliente web y móvil no lo son.
Cloud Firestore en modo Datastore usa el comportamiento del sistema de Cloud Datastore, pero accede a la capa de almacenamiento de Cloud Firestore, lo que elimina las siguientes limitaciones de Cloud Datastore:
- Consistencia eventual, todas las consultas de Cloud Datastore se vuelven muy consistentes.
- Las transacciones ya no se limitan a 25 grupos de entidades.
- Las escrituras en un grupo de entidades ya no están limitadas a 1 por segundo.
El modo Datastore inhabilita las funciones de Cloud Firestore que no son compatibles con Cloud Datastore:
- El proyecto aceptará solicitudes de la API de Cloud Datastore y rechazará las solicitudes de la API de Cloud Firestore.
- El proyecto usará índices de Cloud Datastore en lugar de índices de Cloud Firestore.
- Puedes usar bibliotecas cliente de Cloud Datastore con este proyecto, pero no bibliotecas cliente de Cloud Firestore.
- Las capacidades en tiempo real de Cloud Firestore no estarán disponibles.
- En la consola de GCP, la base de datos usará el visor de Cloud Datastore.