Precomputing: lo bueno, lo malo y lo feo de cachar datos

Precomputing es una técnica que se usa para obtener datos antes de que el usuario entre a consultar. Estos datos son peculiares ya que pueden ser el resultado de una o muchas consultas a la base de datos. También tiene la característica de que para muchos usuarios esta información es relevante y es por eso que los cachamos.

Se pueden utilizar diferentes tipos de tecnología para hacer precomputing o cachear los datos como mongodb, redis, memcache. Estas técnicas son usadas por grandes empresas como Facebook, Twitter y Reddit.

Facebook usa un sistema de precomputing TAO, Twitter hace precomputing a todos los timelines y los mezcla para poder mostrar el timeline de amigos; Reddit es más simple ya que solo precarga los contenidos de las páginas de diferentes formas basado en las consultas (como por ejemplo los votos).

Queremos mostrarte las ventajas y desventajas de las técnicas al momento de cachar datos y a la vez ponerte al tanto de lo necesarias e inevitables que serán en el futuro.

Lo bueno

  • El precomputing es más rápido.
  • Bases de datos más pequeñas.
  • Querys no tan complejos, realtime en memoria y listo para ser servido.
  • Poca latencia al eliminar la base de datos de la consulta query.

Lo malo

Uno de los problemas al programar el sistema que ya tiene los datos precomputados puede ser que se repita demasiado el código si, por ejemplo, dentro de un equipo cada uno toma la solución por su lado y escribe su propio código para esta tarea. Entonces se hace muy difícil de mantener.

Claro que esto depende de la forma en cómo se implementen desde el principio el query y el caché. Hay cosas que no podemos cachar y hay cosas que tienen que sumarse al caché, estas técnicas pueden evitar una sobrecarga.

Estas técnicas de optimización se ven en Twitter, por ejemplo: con solo cachar todos los timelines se reduce el código repetido. Cuando le haces unfollow a un usuario simplemente dejas de consultar el caché de su timeline. También pasa cuando borras un tweet de tu timeline, que no significa borrarlo de todos los timelines de tus amigos, es muy simple.

Lo peor

La pregunta que todos nos hacemos es ¿por qué no sólo usamos la base de datos?, ya que es el camino más fácil de tomar, y la respuesta es:

  • porque se centraliza el proceso de los datos en un solo lugar (que es la base de datos) con queries gigantes y es mucho trabajo para la base de datos, para cada proceso se usa una gran cantidad de memoria extra, y es mucho más complicado controlar todo esto junto en un solo lugar.
  • porque es difícil explotar aplicaciones semánticas, así como sucede en Facebook: los resultados de las consultas están basados en la vida social y son el resultado de las consultas a las bases de datos, entonces se precomputan.

    Facebook :

    as efficient as MYSQL is at managing data on disk, the assumption built into the InnoDB buffer pool algorithms dont match the request pattern of serving the social graph
  • porque cuando más trabajo hay por parte de los clientes (celulares, navegadores, tabletas) necesitamos ayuda del caché.

Es por todo esto que tenemos que evitar usar proyectos disponibles libres para cachar datos, tenemos que hacer nuestro propio sistema de caché para optimizar y que encaje perfectamente en nuestra aplicación. Hay que pensar en cachar datos computados, no cachar bases de datos.

¿Cómo optimizar el caché de ahora en más?

Mientras más somos y más dispositivos consumen nuestros datos, más tenemos que tener los datos listos.

Más celulares y más tabletas significan, desde una perspectiva técnica, que las bases de datos van a trabajar demasiado. Los clientes solo verán vistas de datos precomputados ya que gran parte del procesamiento del entorno (front) se hará del lado del cliente.

En el futuro encontraremos tres niveles de caché: el navegador o el celular, el caché en memoria y, por último, la base de datos. Cada nivel decide cómo mantener los datos listos para ser servidos al cliente.

¿A que le hacemos caché? ¿cachamos en memoria o en el cliente? ¿a mano o usamos un framework? ¿qué tenemos que mantener al día? para responder todas estas preguntas tienes que saber usar estas técnicas y ceñirte a las necesidades de tus usarios. Debemos ver cómo vamos a usar las diferentes tecnologías, y el conjunto de técnicas que serán el futuro que vamos a afrontar.

Aquí les dejo el video para entender mejor qué tan bueno puede ser trabajar el caché antes que la base de datos.

Enviar comentario

via Cristalab http://ift.tt/1h5SU5o

Advertisements

Tags:

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: