YouTube

Got a YouTube account?

New: enable viewer-created translations and captions on your YouTube channel!

Spanish, Mexican subtitles

← 07-14 Scaling

Get Embed Code
4 Languages

Showing Revision 2 created 09/09/2013 by Nidia Cortés.

  1. Tenemos estos servidores de aplicaciones,
    y cada uno estä ejecutando su propio caché,
  2. y también tenemos algunas bases de datos,
    que son réplicas de sí mismas.
  3. Aquí agregamos un equilibrador de carga,
    el cual probablemente fue ejecutado.
  4. Seguramente fue un programa ejecutado
    en una de estas máquinas de aplicaciones,
  5. y esta gente estaban manteniendo su caché sincronizado,
    interactuando directamente con bases de datos.
  6. Hay un límite de cuántos servidores de aplicaciones podemos tener, porque tenemos este complicado
  7. "caching spread". Luego, agregamos
    la capa memcache.
  8. Entonces, en vez de que estos servidores de
    aplicaciones almacenen su memoria caché,
  9. pueden comunicarse a través de memcache.
  10. En vez de tener que mantener el caché sincronizado,
    tenemos sólo un caché compartido entre todos nuestros
  11. servidores de aplicaciones. Me da pena que nos haya tomado tanto tiempo darnos cuenta de esto, porque
  12. memcache existía cuando comenzamos "reddit",
    y lo deberíamos haber usado desde el principio.
  13. Esto es lo que nos permitió obtener todo ese estado, todo ese caché, desde las aplicaciones a memcache,
  14. y nos permitió añadir
    aplicaciones arbitrariamente.
  15. Una vez que esto funcionó, nos permitió
    reproducir nuestras aplicaciones a mayor escala,
  16. y mantenerlas sincronizadas, entonces podíamos agregar una aplicación, o perder una aplicación. No teníamos que
  17. preocuparnos. El siguiente problema del que debíamos ocuparnos es la carga de la base de datos.
  18. Ya estamos replicando por durabilidad
    y por razones de desempeño,
  19. así que podemos distribuir nuestras lecturas por varias
    máquinas, al empezar a segmentar por tipo.
  20. Tenemos una base de datos sólo para links; luego tenemos
    comentarios separados en sus propias bases de datos.
  21. Entonces estos serían réplicas de sí mismos.
    Pero si sólo estás enviando un link,
  22. solo tienes que tocar esta base de datos,
    y si sólo estás leyendo un comentario,
  23. por ejemplo, sólo tienes que
    tocar esta base de datos.
  24. Esta es, básicamente, la configuración básica que reddit
    tiene hoy en día, en lo que respecta a la escala de su
  25. base de datos. Nunca creamos un proceso de fragmentación al principio y me arrepiento de eso.
  26. Cuando yo reescribí la segunda versión de
    ThingDB, pensé, para mis adentros,
  27. que debería añadir fragmentación
    porque lo necesitaríamos algún día.
  28. Y después, quise simplemente poner la maldita cosa
    en funcionamiento, entonces abandoné esa idea.
  29. La gran lección que he aprendido es que cuando
    estás creando un sistema grande, como ese,
  30. si no te ocupas de las partes difíciles al comenzar,
    tal vez nunca tengas otra oportunidad de hacerlo,
  31. porque ahora la base de datos es tan grande, que si
    quisiéramos comenzar el proceso de fragmentación, sería
  32. un proyecto enorme. Ahora es más fácil agregar
    máquinas más grandes, y más caché.
  33. No va a poder ser así para siempre, y alguien va a tener
    que abordar esa situación y resolverla algún día.
  34. Y habría sido mucho más fácil
    ocuparse de esto cuando comenzamos.
  35. Debido a todos nuestros pedidos, dejamos de usar
    "joins" cuando nos cambiamos a ThingDB,
  36. Sharding es bastante simple si
    lo haces desde el principio.
  37. Al pasar el tiempo, parte del software en estos sesrvidores de aplicaciones ha cambiado. Siempre hemos
  38. usado Python. No recuerdo qué servidor de
    aplicaciones usábamos, originalmente.
  39. Cambiamos de lo que usábamos originalmente a web.py,
    que es un marco de trabajo que creamos en reddit.
  40. Aaron es el autor principal, y aún
    está en algún lugar en internet.
  41. Y esta es la primera vez que recuerdo haber visto
    un marco de trabajo con esta noción,
  42. de una clase de handler, y
    funciones de "get" y "post",
  43. y nos hemos vuelto un poco adictos a pensar
    en aplicaciones web de esta manera.
  44. De hecho, el motor de aplicaciones de Google,
    el marco de trabajo webapp2,
  45. heredó mucho de su diseño
    de web.py, lo cual es bueno.
  46. Bueno para mí, al menos, ya que esa decisión de
    diseño ha permanecido estable por algún tiempo,
  47. así que creo que eso significa
    que el diseño es bueno.
  48. Ahora Python usa un enmarcador web llamado Pylons,
    pero es una versión muy vieja de Pylons.
  49. Y básicamente, cuando nos cambiamos a Pylons,
    Aaron había dejado de mantener web.py.
  50. No quería mantenerlo. Nos cambiamos a algo
    distinto, mantenido por otra persona.
  51. Y básicamente destruimos la mayor parte,
    e hicimos que funcionara igual que web.py.
  52. En retrospectiva, probablemente deberíamos haber
    escrito nuestro propio enmarcador, porque eso es en
  53. efecto lo que terminamos haciendo. Pero
    lo construimos usando Pylons como base.
  54. Si quieres usar la versión de Pylons de reddit,
    es de fuente abierta, y está disponible online.
  55. Pero, para este entonces, no se parece en
    nada al verdadero marco de trabajo Pylons.
  56. Por lo que yo sé, eso es lo que aún usan hoy
    en día, esa versión "hackeada" de Pylons.