Afortunadamente, Facebook y Twitter son bastante abiertos acerca de cómo realizan el almacenamiento en caché: a través de una combinación de cachés apartados (Memcache, Redis), replicación asíncrona de centros de datos cruzados, Redes de entrega de contenido (por ejemplo, Akamai para fotos de Facebook) y el lado subestimado del cliente caché de navegador.
TAO [1], un artículo publicado por Facebook en USENIX ATC 2013 describe el sistema que almacena su gráfico social de múltiples petabytes. Los datos se almacenan en un MySQL fragmentado que se replica de forma asíncrona en los centros de datos. El almacenamiento en caché se realiza en dos niveles de niveles de caché . El nivel de caché líder se encuentra directamente frente a MySQL y se le permite realizar escrituras en él. Múltiples niveles de caché de seguidores atienden solicitudes a sus servidores de aplicaciones más cercanos y reenvían solicitudes al líder si es necesario. Cada nivel consta de muchos servidores Memcache modificados con asignación de memoria personalizada y esquemas de desalojo de caché LRU. Los niveles se fragmentan mediante un hash constante para evitar la reorganización de datos en caso de fallas. Para mitigar los puntos calientes de Justin-Bieber, cada fragmento dentro de un nivel también se puede clonar (replicar). Los niveles se comportan como cachés de escritura síncrona, es decir , cuando una solicitud de escritura llega al fragmento de memoria caché de los niveles de seguidor, se reenvía al fragmento de líder respectivo. Si el centro de datos actual es el maestro para ese elemento de datos, la escritura se realiza en el fragmento de MySQL correspondiente. De lo contrario, se reenvía al nivel líder del centro de datos maestro. Cuando se completa la escritura, se emiten mensajes de invalidación a cada caché que contiene ese elemento de datos. La coherencia de la memoria caché es, por lo tanto, “eventual”, es decir, no hay garantías de coherencia, pero anecdóticamente el retraso es del orden de un segundo. TAO maneja aproximadamente 1 billón (!) De lecturas por segundo y todo esto es posible gracias a la arquitectura de almacenamiento en caché en capas y su carga de trabajo de lectura pesada (más del 99% de lecturas).
En un artículo reciente de SOSP 2013 [2] Facebook también detalla cómo se almacena en caché el contenido estático, en particular las imágenes. La conclusión es:
- ¿Qué es un diagrama de arquitectura del sistema para aplicaciones web?
- ¿Existe una forma "correcta" de implementar aplicaciones web?
- ¿Qué lleva más tiempo construir un sitio web o una aplicación móvil?
- Como desarrollador web, ¿cómo le pide a un contratista su pago?
- Al referirse al desarrollo web, ¿cuál diría que es mejor o mejor trabajar para empezar? ¿Por qué?
Nuestros resultados (1) cuantifican los porcentajes de tráfico generales atendidos por diferentes capas: 65.5% de caché del navegador, 20.0% de caché de borde, 4.6% de caché de origen y 9.9% de almacenamiento de fondo , (2) revelan que una parte significativa de las solicitudes de fotos se enrutan a Los PoP remotos y los centros de datos como consecuencia tanto de la política de equilibrio de carga como de emparejamiento, (3) demuestran los beneficios potenciales de rendimiento de coordinar los cachés de borde y adoptar los algoritmos de desalojo S4LRU en las capas de borde y origen, y (4) muestran que la popularidad de las fotos dependen en gran medida de la edad del contenido y dependen condicionalmente de las métricas de redes sociales que consideramos.
Twitter utiliza técnicas similares, como se muestra en esta gran charla [3]. La línea de tiempo de cada usuario se almacena en caché en instancias de Redis . Cuando llega un tweet, se despliega en la línea de tiempo de todos los seguidores (una lista nativa de Redis de identificadores de tweets e identificadores de usuario) usando RPUSHX para agregar solo a las líneas de tiempo en caché. Por lo tanto, cada lectura de línea de tiempo se puede servir cómodamente desde una lista de Redis en caché.
Ver que el almacenamiento en caché se realiza de manera muy similar pero hecha a mano en la mayoría de las infraestructuras lleva a la pregunta natural: ¿por qué no abstraer y automatizar el proceso de una manera ajustable por consistencia? Este es un tema central de investigación en nuestro grupo de bases de datos y también la base de una startup recientemente fundada para una Base de Datos como Servicio de baja latencia muy almacenada en caché llamada Baqend [4].
[1] Página en dl.frz.ir
[2] Página en cornell.edu
[3] Arquitectura de entrega en tiempo real en Twitter
[4] Baqend
