Te recomendamos que revises esta respuesta en un ambiente controlado antes de enviarlo a producción, saludos.
Solución:
Costo.
Firestore en modo Datastore admite key-Solo y consultas de proyección como 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 efectivamente multiplicaría 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 añadida, esperábamos que tuviera menos rendimiento que en el almacén de datos original, pero en nuestras pruebas no fue así. Firestore en modo de almacén de datos se desempeñó consistentemente aproximadamente el doble de rápido para nuestra aplicación en todos los tipos de operaciones.
Hay ventajas de usar el “modo de almacenamiento de datos”, incluso para un nuevo proyecto.
Estoy evaluando los dos modos de Firestore “Modo Datastore” y “Modo nativo” para un proyecto de migración de 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
- Consulta y ordena varias propiedades a la vez
- Modelo de datos estructurados con un tipo raíz y algunos tipos de segundo nivel
- Mucha escritura con requisito de transacción limitado, gran cantidad de lectura con proyección dentro de un grupo de entidades
Por otro lado, el “modo nativo” parece cumplir con 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 ocasionalmente conectados
- Pocos objetos polimórficos grandes para sincronizar y persistir
- Mayormente consulta simple en una propiedad (objeto principal)
Sin embargo, hay una razón que aboga por el modo Datastore para el segundo proyecto.
- Multiusuario 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 Datastore, que no son posibles en el modo nativo. Los elementos 6 a 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 usa tanto el modo Firestore (nativo) como el modo Datastore.
-
2 proyectos basados en Firestore. Estamos utilizando mucho los conceptos de colección, subcolección y documentos y la segregación permanente de datos. También implementamos 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 de ellos, estamos usando mucho los conceptos de espacio de nombres y tipo. También utilizamos la indexación global de las propiedades de tipo 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 un 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 características de la biblioteca de clientes móviles y web no lo son.
Cloud Firestore en modo Datastore usa el comportamiento del sistema 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 desactiva las funciones de Cloud Firestore que no son compatibles con Cloud Datastore:
- El proyecto aceptará solicitudes de API de Cloud Datastore y rechazará solicitudes de API de Cloud Firestore.
- El proyecto utilizará índices de Cloud Datastore en lugar de índices de Cloud Firestore.
- Puede usar las bibliotecas cliente de Cloud Datastore con este proyecto, pero no las 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 utilizará el visor de Cloud Datastore.
Aquí puedes ver las reseñas y valoraciones de los usuarios
Si piensas que te ha resultado provechoso este artículo, te agradeceríamos que lo compartas con otros seniors de esta manera nos ayudas a difundir este contenido.