Descripción general de las interfaces de consulta
En esta página, se explican las diferentes interfaces disponibles para acceder a los datos en una base de datos de Firestore en modo nativo.
Interfaces de operación
El modo nativo admite dos interfaces para acceder a los datos:
Operaciones de canalización
Es la interfaz de consultas más reciente para Firestore. Las operaciones de canalización admiten una sintaxis componible basada en etapas. Para construir una operación, debes definir una serie de etapas secuenciales que se ejecutan en orden. Esto permite realizar operaciones complejas, como filtrar el resultado de una agregación, lo que antes no era posible en la interfaz original (operaciones principales).
Las operaciones de canalización solo están disponibles en la edición Enterprise de Firestore.
Operaciones principales
Las operaciones principales son la interfaz original de Firestore.
Las operaciones de Core usan una sintaxis de encadenamiento de métodos (.where(), .orderBy(), .get()) en las referencias de documentos o colecciones para recuperar documentos. El orden de las etapas de la consulta está implícito y la compatibilidad con la agregación es limitada.
Las operaciones principales están disponibles en las ediciones Enterprise y Standard, pero los valores predeterminados de los índices son muy diferentes entre las ediciones. Consulta la siguiente sección para obtener más detalles.
Diferencias de la interfaz entre las ediciones
Con la introducción de la compatibilidad con el modo nativo en la edición Enterprise, están disponibles las operaciones de Core y de canalización de Firestore. Cuando se usan las operaciones de Core en la edición Enterprise, el nuevo comportamiento del índice y el modelo de precios eliminan muchas de las restricciones de la edición Standard.
| Función | Edición Standard | Edición Enterprise |
| Operaciones admitidas | Se limita a las operaciones de Firestore Core. | Admite operaciones de Firestore Core y Pipeline, y operaciones de compatibilidad con MongoDB de Firestore. |
| Requisito de indexación | Todas las consultas requieren índices. | Los índices no son obligatorios para las consultas. |
| Creación de índices | Los índices automáticos se crean para campos únicos. Puedes crear índices compuestos de forma manual. | No se crean índices automáticos. Los índices deben administrarse de forma manual. |
| Campos indexados | Si aún no está presente, se agrega automáticamente un campo __name__ adicional a los campos indexados. | __name__ no se agrega automáticamente a los campos indexados. Debes especificar de forma explícita __name__ en los campos indexados si es importante para tu aplicación. |
| Index Sparsity | Todos los índices son dispersos. Una entrada de índice solo existe si todos los campos definidos en el índice están presentes en el documento. | El valor predeterminado es dense, en el que existe una entrada de índice incluso si no hay campos definidos en el índice presentes en el documento.
Además, se pueden habilitar índices dispersos, en los que existe una entrada de índice si al menos un campo del índice está presente en el documento. |
| Normalización del orden | La cláusula order by de la consulta se normaliza agregando campos de desigualdad y el campo __name__ al final (si aún no está presente). Esto garantiza un orden único y determinístico de los resultados, independientemente de qué otros campos se incluyan en la cláusula ORDER BY. | No se normaliza el orden de clasificación. Un orden de clasificación como sort a ASC solo garantiza que los resultados se ordenen por el campo a. Firestore usará tus índices existentes para devolver resultados en el orden más eficiente posible. Por lo tanto, si a no es único entre el conjunto de resultados, el orden de los resultados puede variar de una consulta a otra según la configuración del índice, las estrategias de ejecución, etcétera. Para garantizar un orden único y determinístico de los resultados, debes agregar un campo único, como __name__, al orden de clasificación. |
| Rendimiento y costo de las consultas | En general, las consultas son eficientes debido a los requisitos de indexación. | Crea índices para optimizar el rendimiento y los costos de las consultas. Puedes identificar los índices faltantes con la Explicación de las consultas y las Estadísticas de consultas.
Las consultas sin índices pueden correr el riesgo de ser costosas y de bajo rendimiento a medida que crece el conjunto de datos, lo que requiere supervisión y ajuste. |
| Costo de indexación | No se aplican cargos por las escrituras de índices, ya que los índices son automáticos. | La escritura de entradas de índice consume unidades de escritura cuando se escribe un documento asociado (1 unidad de escritura por cada 1 KiB de tamaño de entrada de índice). Ahorras en costos de almacenamiento porque no creas entradas de índice para cada campo. |
| Modelo de facturación (lecturas, escrituras y eliminaciones) | Se cobra por cada operación de lectura, escritura y eliminación de documentos. | Se cobra por cada lectura y escritura (tramo). Las lecturas se cobran en unidades de lectura (tramos de 4 KiB). Las escrituras y las eliminaciones se combinan en unidades de escritura (tramos de 1 KiB). |
| Precios básicos (por millón)
Los precios que se muestran son para la región us-central1. |
Lecturas: $0.03 por 100,000 documentos (o $0.30 por millón)
Escrituras: $0.09 por 100,000 documentos (o $0.90 por millón) Eliminaciones: $0.01 por 100,000 documentos (o $0.10 por millón) |
Unidades de lectura: $0.05 por cada 1 millón de unidades de lectura
Unidades de escritura: $0.26 por 1 millón de unidades de escritura En general, los precios son más bajos si los documentos tienen menos de 4 KiB en comparación con el costo de lectura estándar. |
| Actualizaciones en tiempo real
Los precios que se muestran son para la región us-central1. |
Las actualizaciones en tiempo real se incluyen en la facturación como lecturas a $0.03 por 100,000 documentos. | Las actualizaciones en tiempo real tienen un nuevo SKU independiente (unidades de actualización en tiempo real) que se cobra por tramo de 4 KiB. Las actualizaciones en tiempo real cuestan $0.30 por millón de unidades de lectura. |