¿Demasiadas lecturas en Firestore? Cómo saber qué está leyendo

Abre la página de Uso de tu base de datos, en la consola de Firebase (Firestore > Uso) o en la de Google Cloud. Muestra lecturas, escrituras y borrados a lo largo del tiempo. Busca el día, y si puedes la hora, en que cambió la curva, y compáralo con tus despliegues: la mayoría de los picos de lecturas empiezan con una versión nueva.

Dos cosas sobre este panel. Es una estimación: Google dice "the dashboard is not an exact view of billed operations. Billed usage is likely higher." (el panel no es una vista exacta de las operaciones facturadas; lo facturado probablemente sea mayor) (Supervisar el uso de Firestore). Y va un poco por detrás: "updates may take up to 4 minutes to show up in your dashboards." (las actualizaciones pueden tardar hasta 4 minutos en aparecer en los paneles).

En Cloud Monitoring, abre el Explorador de métricas y dibuja la métrica de Firestore Document Reads. Puedes desglosarla por tipo: LOOKUP para documentos sueltos leídos por su ruta, QUERY para documentos devueltos por consultas y listeners. Otras dos métricas ayudan: Snapshot Listeners y Active Connections.

• Sobre todo QUERY: una consulta lee demasiados documentos, o un listener vuelve a leer sus resultados una y otra vez.
• Sobre todo LOOKUP: algo pide documentos uno a uno, a menudo en un bucle o dentro de tus Security Rules.
• Listeners que crecen más rápido que los usuarios: tu app abre listeners y nunca los cierra, o abre uno nuevo en cada render.

• Consultas sin límite. Una página que carga una colección entera para enseñar los 20 primeros lee todos sus documentos en cada visita. Añade limit() y pagina con cursores. Así ocurrieron 30.356 $ en 72 horas.
• Listeners que se vuelven a suscribir. En React, un onSnapshot dentro de un useEffect cuyas dependencias cambian en cada render abre un listener nuevo cada vez, y cada listener nuevo vuelve a leer todo su resultado. En la web, la persistencia offline está desactivada por defecto, y la página de precios de Firestore deja claro lo que cuesta: "If offline persistence is disabled, you will be charged for documents and index entries read as if you had issued a brand-new query whenever the listener disconnects and reconnects." (sin persistencia offline, se te cobran los documentos y entradas de índice leídos como si hicieras una consulta nueva cada vez que el listener se desconecta y se reconecta).
• Lecturas dentro de las Security Rules. Cada get() o exists() de tus reglas lee un documento. "You are charged for reads that are necessary to evaluate your Cloud Firestore Security Rules" (se te cobran las lecturas necesarias para evaluar tus Security Rules de Cloud Firestore) (precios de Firestore). Una regla que consulta el perfil del usuario en cada petición duplica las lecturas de una pantalla con mucho tráfico.
• Contar leyendo. Cargar una colección para mostrar cuántos elementos tiene lee todos sus documentos. Una agregación count() se cobra por entradas de índice: "count() operations that read between 0 and 1000 index entries are billed for one document read." (las operaciones count() que leen entre 0 y 1000 entradas de índice se cobran como una lectura de documento).
• Polling. Un temporizador que lanza una consulta cada pocos segundos la paga cada vez, haya resultados o no, porque Firestore cobra "a minimum charge of one document read for each query that you perform, even if the query returns no results" (un mínimo de una lectura de documento por cada consulta, aunque no devuelva resultados). Usa un listener, o consulta mucho menos a menudo.
• Funciones que leen en cada escritura. Una Cloud Function que salta con cada escritura y luego lee una colección multiplica tu tráfico. Si además escribe en los documentos que la disparan, puede entrar en bucle.
• Alguien de fuera. Si tus reglas dejan que cualquiera, o cualquier usuario con sesión, lea una colección, un script con tu configuración pública puede leerla todo el día. La consola de Firebase muestra cuántas peticiones evalúan tus reglas, Cloud Monitoring puede avisarte cuando se disparan las denegadas y App Check frena las peticiones que no vienen de tu app.

El primer efecto se vuelve a suscribir cada vez que filters es un objeto nuevo, que en muchos componentes es en cada render. El segundo depende de un valor simple y limita el resultado:

// Subscribes again every time `filters` is a new object
useEffect(() => {
  const q = query(collection(db, "orders"), where("status", "==", filters.status));
  return onSnapshot(q, (snap) => setOrders(snap.docs));
}, [filters]);

// Subscribes once per status, and reads at most 50 documents
const status = filters.status;
useEffect(() => {
  const q = query(collection(db, "orders"), where("status", "==", status), limit(50));
  return onSnapshot(q, (snap) => setOrders(snap.docs));
}, [status]);

Cuando sospeches de una consulta, ejecútala con Query Explain. Te dice las operaciones de lectura que se le cobraron y el índice que usó, así que puedes comprobar un arreglo antes de desplegarlo (Query Explain).

Una alerta de presupuesto te llega horas después de las lecturas, así que vigila las lecturas en sí. En Cloud Monitoring, crea una política de alertas sobre Document Reads con un umbral un poco por encima de tu pico normal.

O deja que lo haga FireShield. En Pro lee el uso de cada servicio cada pocos minutos, compara la última hora con la hora normal de ese servicio durante la última semana y te avisa, o apaga la parte cara, cuando se disparan las lecturas de Firestore.