2012-08-16 14 views
14

Estoy creando una aplicación web usando Firebase que toma los mismos datos y los presenta de dos maneras diferentes: en una lista y como marcadores en un mapa de Google.Firebase: ¿el almacenamiento en caché mejora el rendimiento?

Ahora mismo, en cada vista, mapa o lista, tengo código para consultar los datos de firebase, fusionarlos y mostrarlos. En cambio, estoy considerando este plan: al inicio, consultar los datos, fusionarlos y guardarlos en una matriz que paso de vista a vista.

En cierto sentido, estoy "almacenando en caché" los datos de firebase en una matriz. Esto no es ideal en un sentido: los datos en caché no están tan actualizados como para consultar directamente a Firebase. Por otro lado, solo llamo a Firebase una vez.

¿Tiene esto sentido de la interpretación? ¿Los datos de lectura de una base de Firebase se toman en el mismo orden de magnitud que la lectura de datos de una matriz?

Respuesta

21

En general, los datos de almacenamiento en caché para limitar el uso de Firebase no son necesarios. Firebase mantiene su propia memoria caché de datos "activos" en el cliente. "Activo" se define como datos para los que una llamada "activada" está pendiente. Por lo tanto, para cualquier dato activo, cualquier llamada adicional "on" o "once" no requerirá tráfico de red ya que los datos ya se han cargado.

No estoy del todo seguro de lo que quiere decir con "querying firebase". Firebase no tiene consultas en el sentido tradicional. Simplemente tiene métodos para adjuntar devoluciones de llamada. ¿Estás usando la función "once()" para obtener datos periódicamente de Firebase? Si es así, esto podría ser muy ineficiente. Una vez es un método de conveniencia y, en general, solo se debe utilizar para datos a los que se accede con muy poca frecuencia o que, por alguna razón, el desarrollador no desea actualizar en tiempo real. Si no hay llamadas activas "activadas" pendientes cuando finaliza una vez(), Firebase vaciará el caché de esos datos, y cualquier llamada posterior a una vez() requerirá una ida y vuelta al servidor.

Si lo que desea es una forma de acceder de forma sincrónica una copia local de la versión más reciente de los datos de una manera eficiente, recomiendo este método:

var savedSnapshot = null; 
dataRef.on("value", function(snapshot) { 
    savedSnapshot = snapshot; 
}); 

//and then when you need to read the data 
var theData = savedSnapshot.val() 

Al mantener una sola en() llamada, Firebase puede mantener tus datos actualizados solo enviando deltas por cable cuando cambian las cosas, en lugar de volver a cargar todos los datos cada vez que los necesites.

+1

Gran explicación. Los documentos, por cierto, dan esta impresión pero no entran en detalles tan grandes (esto podría ser un gran apéndice para los documentos) – Kato

+1

Estamos planeando agregar algunas secciones sobre el rendimiento a los documentos en el futuro cercano. –

+0

@AndrewLee ¿Alguna vez se escribirá esta sección de rendimiento? He estado usando Firebase durante 2 años y no hice "clic" exactamente como lo hizo cuando esta respuesta (de 5 años) explicó cómo podía almacenar una captura de datos para su uso posterior. Ahora me doy cuenta de que he estado codificando bastante a la defensiva, por miedo a no saber qué hace Firebase y qué no "almacena en caché" internamente. Ahora veo que una DataSnapshot es solo un cursor navegable para una estructura de datos interna inmutable, y que 'val()' clona sus datos en un POJO. ¡Este es un diseño tan elegante! Felicitaciones :-) – skrebbel

Cuestiones relacionadas