Join FlipAndroid.COM Telegram Group: https://t.me/joinchat/F_aqThGkhwcLzmI49vKAiw


Firebase Database – la técnica "Fan Out"

Estaba investigando la base de datos Firebase para Android y me di cuenta de que almacena sus datos de la siguiente manera:

Introduzca aquí la descripción de la imagen

No estoy muy familiarizado con las técnicas de NoSQL y tratando de entender por qué tenemos que persistir cada entidad de post dos veces – en los posts y user_posts correspondiente. La documentación dice que este enfoque se llama "Fan Out" y estoy totalmente de acuerdo en que podría ser útil para acceder a las publicaciones de los usuarios a través de la construcción simple como databaseReference.child("user-posts").child("<user_uid>") . Pero, ¿por qué necesitamos el nodo posts entonces? ¿Qué pasa si necesitamos actualizar algunos post – ¿tenemos que hacerlo dos veces?

 // [START write_fan_out] private void writeNewPost(String userId, String username, String title, String body) { // Create new post at /user-posts/$userid/$postid and at // /posts/$postid simultaneously String key = mDatabase.child("posts").push().getKey(); Post post = new Post(userId, username, title, body); Map<String, Object> postValues = post.toMap(); Map<String, Object> childUpdates = new HashMap<>(); childUpdates.put("/posts/" + key, postValues); childUpdates.put("/user-posts/" + userId + "/" + key, postValues); mDatabase.updateChildren(childUpdates); } // [END write_fan_out] 

Así que me pregunto … cuando este enfoque podría ser útil y cuando no? ¿Firebase SDK proporciona herramientas para mantener sincronizados todos los duplicados al actualizar o eliminar datos?


UPDATE: Aquí está la explicación recibida del equipo de Firebase:

La razón por la que los mensajes se duplican es porque queremos ser capaces de obtener rápidamente todos los mensajes pertenecientes a un usuario (como usted sugiere) y el filtrado de la lista de todos los puestos de siempre para obtener los puestos de un usuario puede ser bastante caro como el Número de puestos se expande.

Esto significa que tenemos que actualizar la publicación en dos ubicaciones siempre que lo actualicemos. Hace que el código sea un poco más feo, pero como las consultas son más comunes que las escritas, es mejor optimizar la lectura de los datos.

Sospecho que este enfoque podría parecer no muy elegante, pero es probablemente la opción más rápida para grandes conjuntos de datos, siempre y cuando se realiza SELECT más a menudo que UPDATE. Sin embargo, para algunos casos prefiero seguir otras soluciones recomendadas aquí.

  • Parse.com equivalente a las combinaciones de SQL
  • Cómo consultar desde la base de datos realm con resultados distintos java
  • NoSQL para aplicaciones móviles?
  • 2 Solutions collect form web for “Firebase Database – la técnica "Fan Out"”

    Data Fan Out es una gran técnica para manejar cantidades masivas de datos . Si no utiliza este patrón, podría tener serios problemas de escala en el futuro.

    Lo que veo de su estructura de base de datos, es que usted está almacenando toda la información de la publicación dos veces , y eso no es una buena práctica. Desea almacenar sólo una referencia a la publicación bajo otro nodo en su lugar. Por lo tanto, tendrás un nodo denominado users-posts que consistirá en claves de usuario, y cada una de esas claves tendrá un conjunto de claves con valor de true . Para dejarlo más claro:

    Introduzca aquí la descripción de la imagen

    De esta forma, está rastreando qué publicaciones el usuario ha escrito bajo el nodo users-posts ; Y también el usuario que ha escrito cada post bajo el nodo posts . Ahora, puede que necesite obtener una lista de las publicaciones de todos los usuarios. Lo que tendrías que hacer es sincronizar en los users-posts/USER_KEY/ node para obtener las claves de todas las entradas que el usuario ha escrito, y luego obtener más información de la publicación con la clave de correo que acaba de recibir .

    ¿Por qué se recomienda este diseño de base de datos? Debido a que está recibiendo mucha menos información para cada sincronización (con Firebase no estamos emitiendo peticiones por sí, por lo que llamo a la lectura una sincronización). En su ejemplo, si adjunta un oyente a las user-posts/USER_KEY/ para obtener una lista de todas las publicaciones, también solicitará TODA la información de CADA Y CADA publicación que haya escrito. Con el ventilador de datos hacia fuera acercamiento usted puede apenas pedir la información del poste que usted necesita porque usted tiene ya la llave de los postes.

    En mi opinión, este no es un buen enfoque, ya que es necesario mantener en sincronía los datos y Firebase no proporciona ninguna herramienta para mantener duplicados en sincronía. Un buen enfoque sería almacenar sólo la clave en user-posts .

    Sugiero leer esto, es muy interesante entender cómo estructurar datos: https://www.firebase.com/docs/web/guide/structuring-data.html

    FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.