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.
¿Sabes SQL? ¿No-SQL? Aprende MySQL, PostgreSQL, MongoDB, Redis y más con el Curso Profesional de Bases de Datos que empieza el martes, en vivo.
alessandro15 :
Claro que si, y me gustaría que pienses en como lo estarías haciendo si fueras Gmail:
Cargar lo mas rápido posible el javascript y todo el front para manejar tus mensajes, si fuera yo usaría Backbone, luego te colocaría una barra de pre carga, mientras cargo los mensajes en cache de tu ultima consulta con los cambios nuevos como puede ser un correo nuevo, una respuesta, tus correos enviados, esto lo hago consultando el caché de otros usuarios y comparándolos con el tullo, ademas tengo que tener en cuenta que millones de personas me consultan, entonces tengo que hacer esto lo mas rápido posible, esto es un ejemplo.
Te invito a aprender técnicas para hacer cache, en tu cache guarda datos que no encuentras en la base de datos, si no que son el resultado de una consulta.