Conclusiones finales mysql 2007

Esto son algunas ideas que están dando vuelta por mi cabeza a medida que absorbo todo lo que escuché y vi en la conferencia.

Escalamiento

El particionar los datos por tipo de uso fue una buena idea, podríamos llevar aún más tablas a alternate. El motor Federated nos permitiría manejar mucho más fácilmente los problemas de join que pudéramos tener, está como hecho para eso. Por ejemplo, para OUM 2.0 fue necesario replicar la tabla TM_pros. Sería mucho más lógico que esta tabla se siga manejando en uno de los dos servidores (o shards como sería el nombre correcto) y la otra vea la misma copia a través de una tabla proxy de tipo federated. Hay dudas que aún tengo sobre este engine como por ejemplo si es posible escribir en él, pero es algo que vale la pena investigar.

Creo que debiéramos activar los “lazy master” que tenemos para fail-over. Una forma que se me ocurre para manejar posibles colisiones de datos es mantener a los clientes siempre conectados a un mismo master a través de un hash de su IP por ejemplo. Sería Basic_Services quien manejaría esta distribución de carga, a no ser que se pueda hacer por Iron. Hay que tener cuidado en los casos de que un server esté abajo. Pero la idea es que los cgi y pl no tengan idea de esta separación.

Por último, todos los programas que se escriban de ahora en adelante (y ojalá ir cambiando los actuales también) debiesen estar preparados para manejar por separado conexiones de read/write con las de sólo read. Esa es la forma más simple y efectiva de escalar en el futuro según la experiencia de los grandes. Para muchos de los programas más antiguos esto es relativamente fácil gracias a que separaban la conexión local de la central, pero siempre hay que tener cuidado. En devel podríamos tener las 2 conexiones configuradas apuntando al mismo servidor, pero hacer enforce de que la read no pueda escribir para ver cómo se comportan los programas.

Optimización

Hay algunos parámetros con los que podríamos jugar un poco, pero veo mucho más productivo
dedicarse a optimizar los query y los schemas. Por ejemplo los id de todas las tablas innodb debiesen ser unsigned int auto_increment. Preocuparse de no tener campos más grandes de lo que realmente se use, etc. Quizás valdría la pena en producción pasar todo a innodb para manejar los caches de forma centralizada. Ojo con optimizar los query para el query_cache, analizar si se está utilizando de manera correcta. Es tanto lo que se puede hacer en este punto que no se me ocurren ideas puntuales, pero por esto se puede partir. También sería interesante tener sesiones de tutorial con todo desarrollo para compartir y aprender buenas prácticas.

Content Delivery

La idea ya me había cruzado la cabeza, pero ahora estoy convencido. El approach que usamos para el problema del contenido estático es errado. Lo que hay que hacer no es precompilar todo, sino CACHE. No sé qué facilidades entregue Akamai para eso, pero hay otras soluciones locales que podemos usar también, debajo de Akamai. Squid, memcached, etc. Usados de manera inteligente haría mucho más simple la resolución del problema y mucho más rápida la generación de html.

Ideas random

Para los log: analizar realmente cuanto log es necesario guardar. Si es tanto lo que necesitamos, tener discos más grandes y baratos en un servidor dedicado y formas inteligentes de buscar en ellos usando indexación en mysql.

Hay varias herramientas que creo valdría la pena analizar. Está la de profiling, innotop, la de capacity planning, mysql benchmark, etc etc.

Por último, ojo con las cosas nuevas que vienen en camino, varias novedades de 5.1, pero especialmente con el motor Falcon.

3er (4to) y último día de la conferencia.

La mañana partió con interesantes discursos keynote del creador de php, el dba de youtube, y otro no tanto del CEO de Zmanda.
- PHP on Hormones: Rasmus Lerdorf nos habló un poco de la historia de php, y algunos tips para pensar en la web 2.0. Los sitios de ahora los construyen los usuarios, y eso es lo que los hace volver de la forma más barata. Hay que pensar en performance, y la clave de eso es el CACHE (no dejo de escuchar eso). Mencionó una interesante herramienta de profiling Callgrind. No sé si nos servirá pero se ve muy buena. Hay que pensar en seguridad, y habló de varias formas de crackear un sitio con javascript x-scripting. No es una vulnerabilidad que afecte directamente, pero puede significar una fuente de desconfianza para una víctima.

- Scaling MySQL at YouTube: Youtube muestra más de 100 millones de videos al día, y ellos si que manejan todos sus datos con MySQL. Fue interesante ver que partieron con un Master read/write y varios slaves read y esa es su forma de escalar. El problema de ellos era conseguir que los datos del master llegasen lo más rápido posible al slave. Mostró un montón de técnicas y dificultades para hacer la replicación lo más rápida posible. No creo que esto sea hoy un problema para nosotros, pero es bueno tenerlo en cuenta. Además volvió a mencionar que lo más importante es la memoria. 16GB por server es la opción, aunque haya menos cpus. Y después de eso la velocidad de los discos. Y eso lo obtienen con un RAID gigantesco. Lamentablemente no alcanzó a terminar su presentación, me hubiera gustado ver como lograron escalar los masters.

- De la sesión de Zmanda me salí en la mitad porque estaban vendiendo el producto y estaba más interesante la conversación afuera con el tipo de Youtube.

Sesiones:

- The innotop Workshop: El autor (tiene un blog bien completo de las sesiones que va a complementar con el audio en el futuro) de esta herramienta hizo un walkthrough de sus opciones y posibilidades. No la conocía y me pareció muy útil, llegando le voy a hechar una mirada. Es como lo que el mytop nunca logró ser y está hecha entera en PERL. Algunos tips: ^abre el editor de tablas. El mismo autor tiene otras herramientas interesantes, como una para sincronizar tablas de un master a un slave eficientemente.

- What Happens After You're Scalable: Capacity Planning for LAMP: Otra charla de la gente de flickr, ahora desde otro punto de vista. Algunas cosas que anoté:

• Capacity planning != tuning: no confundirse. Según el tipo es mucho más efectivo concentrarse en la capacidad, ya que con el tuning uno se puede perder en los detalles.
• Olvidarse de los temas de universidad (redes de markov, modelos estocásticos, etc) y planear con datos de verdad (ojalá de producción)
• Conocer los techos: cuanto throughput podemos tener con niveles aceptables de respuesta, en esto los gráficos son imprescindible (up.time quizás). Ellos usan Ganglia.
• Familiarizarse con el "Application Usage"
• Monitorearlo todo, hacer predicciones, y usar herramientas automáticas de deployment (install_procedure.txt no creo que cumpla con lo de automática :)). Alguien del público nombró Puppet, me parece que vale la pena un vistazo.

Sólo falta una sesión. Estaba entre SQL Kitchen: Spicing Up Everyday SQL y InnoDB Performance Optimization, porque puede ser más útil la segunda, pero Heikki habla tan mal que mejor me quedo con los slides y voy a la primera no más. Finalmente fui a las 2. :)

Al principio entré a la de SQL. Ahora el presentador era un franchute orgulloso de sus “hacks”con sql. Mostró varios bien simpáticos, algunos con enum, formas de guardar datos más compactos, varios usos para una tabla de integers. Es la segunda persona que habla de guardar las direcciones IP como integers para optimizar espacio y búsquedas, creo que debemos hacerles caso (la forma de manipularlos es con las funciones INET_NTOA() / INET_ATON(). En la mitad hubo un receso (era una sesión extra larga) así que aproveché de ver qué estaba pasando en la otra sala. (Siempre se puede ver los slides para aprender nuevos trucos).

En la otra sesión, Heikki esta vez estaba acompañado lo que hizo las cosas bastante más dinámicas y entendibles. Llegué justo cuando estaban terminando de hablar de optimización y consideraciones para los query y se pusieron a hablar de los parámetros de servidor. En este contexto, analizaron las diferentes variables innodb_% dando una explicación y consideraciones de cada una. Volvieron a repetir la importancia del buffer_pool_size, ojalá toda la memoria disponible que no use el SO. Ojo con la variable log_file_size, se supone que hace todos los write mucho más rápidos a medida que sea más grande, a costa de tener un mayor tiempo de recovery en caso de caída. (En un modelo como el nuestro que tenemos backup en caso de caída, creo que vale la pena aumentarle el tamaño). Otros comentarios: conviene aumentar el tamaño del auto_extend para evitar fragmentación, se puede tener el espacio innodb en archivos separados por tabla (por ejemplo para tener tablas en diferentes particiones), conviene apagar el xa si no lo usamos, para obtener ganancias de hasta 5% en uso de cpu. Hablaron de hartas cosas más, pero no alcanzaron a terminar así que dejaron harto pendiente. Todos los detalles están en el powerpoint que espero publiquen pronto.

Y eso fueron todas las sesiones de la conferencia. Finalmente un programador de Yahoo! Mostró un nuevo programa que estaba desarrollando, pipes.yahoo.com. Encontré que la interfaz del programa está increíble, aunque fue raro haber terminado la conferencia con eso que como que no tenía nada que ver.

Debo decir que estos 4 días fueron bastante intensos. Al principio era tanta la información que me saturó un poco, pero a medida que fui absorbiendo los conceptos y el “espíritu”, creo que el provecho que fui sacando es invaluable. Ahora sólo falta poder transmitir lo mejor posible esta experiencia para que todo el equipo se vea beneficiado (para lo que espero este blog ayude), y poder aplicar lo aprendido con éxito. Se me ocurren algunas cosas que sería bueno aplicar que voy a poner en el siguiente artículo.

2do día de la conferencia.

Segundo día de conferencias, 3ero en general. Hoy el día estuvo más relajado, hubo puntos altos y bajos. Las sesiones a las que fui fueron las siguientes:

- Federation at Flickr: doing Billions of Queries per Day: Creo que fue la sesión más interesante del día. El DBA de Flicker nos mostró cómo pueden atender + de 30k queries/sec (más de 10 veces lo que nosotros atendemos) usando mysql distribuido o "federado". La gracia es que separan los datos por usuario en shards (fragmentos), y cada uno de estos shards es independiente. Tienen más de 20 shards y pueden migrar usuarios entre 1 y otro con simples scripts para mantener estos shards balanceados. Cada shard son 2 servidores funcionando en modelo Active Master/Master, y para evitar problemas con el lag de replicacion, se mantiene a cada usuario siempre conectado al mismo master. He escuchado mucho de este modelo de replicación en toda la conferencia como la panacea, así que habrá que echarle un vistazo. Un detalle importante es que he escuchado más de una vez, es que cada Master debe ser capaz de manejar toda la carga por si solo, en el caso de que haya que bajar los otros para mantención, etc. Es decir si es un cluster de 2 master, cada uno no puede tener más de 50% de carga en régimen normal.
Con este esquema pueden manejar más de 12 TB(!) de datos (no de fotos, eso es otro cuento), sin tener más de 500GB en cada cluster.
Otro aspecto simpático de la solución es que tienen un par de "Ticket Servers". Éstos son 2 máquinas básicas balanceadas corriendo mysql que lo único que tienen es una bd con una tabla con 1 fila auto_increment, y los usan para generar ids que pueden usar en cualquier tabla de la federación. Para mantener la consistencia entre las 2 máqs usan el offset de mysql 5. Así se aseguran de que todos los ids son únicos en toda la federación de servidores.

- Running a Top 500 Web Site with LAMP Stack and Commodity Hardware: Aprendimos cómo manejan las máqs que albergan los sitios de MySQL (la compañía). La configuración es bastante básica y no aprendí nada muy nuevo. Un dato: siempre usar números IP para configurar hosts en mysql, nunca nombres por temas de desempeño (creo que alguna vez tuvimos problemas por algo así). Si pasó algo más interesante, la verdad no me acuerdo, se podrá ver en los slides...

- Optimizing Performance for Dynamic, High Volume Web Pages: Lejos el punto bajo del día. Por el título tenía altas espectativas de esta sesión, pero resultó ser un fiasco. Se trató de un caso para nada replicable y de 0 interés.

- Inside Falcon: MySQL's Newest Storage Engine: Cansado de sesiones prometedoras y de escuchar por n-ésima vez lo mismo, quise escuchar algo un poco más del estado del arte. La sesión fue una introducción al nuevo engine de mysql que aún está en alfa, dada por su mismísimo arquitecto. Se ve MUY interesante, tipo InnoDB pero orientado al performance. La idea básica de diseño es que el hardware está para usarlo, y que todo es cada vez más rápido excepto los discos. Por lo tanto a pesar de ser un engine de DD, la idea es ir al disco lo menos posible, ojalá nunca, y tener el desempeño de una BD de memoria. El costo de mantener todo en memoria de manera inteligente es mayor uso de CPU, el cuál todos sabemos es cada vez más barato y en servidores de BD es subutilizado. El lema es "Trade single thread performance for multi-CPU scalability" (Cuando el presentador lo dijo sacó aplausos de algunos fanáticos)

- MySQL Performance Cookbook: Un montón de tips rápidos que podrían ser útiles en ciertas situaciones. Todos los desarrolladores mysql debiesen ver los slides para aprender un par de trucos de desempeño y buenas prácticas, o poner el blog en sus favoritos (ahí van a publicar la presentación algún día).
Algunos datos que anoté:

• Existe una aplicación para analizar el slow log: mysqlsla
• Usamos la peor forma que existe para seleccionar datos random (lo he visto en algunas partes de nuestro código). Pero tiene solución: http://jan.kneschke.de/projects/mysql/order-by-rand
• Algo que había escuchado en el tutorial: los subqueries son malos, pero ahora aprendí que en el FROM no hay problema. El problema es en el WHERE.

- For Ticketmaster, MySQL Replication is the Ticket!: Una confusión me llevó a estar sorprendido la mayor parte de la presentación. Ticketmaster puede vender un estadio completo de tickets en pocos minutos (o segundos) y todo usando mysql 4.0 y la replicación más básica. Escalando simplemente con una pirámide de 3 niveles, con algo así como 200 máqs en la base para los read de los clientes. La mayor parte de la presentación fue explicar esta topología pero de un punto de vista bien básico, más bien introductorio. Y yo pensando para mis adentros cómo no habíamos hecho algo así antes, si lo hemos pensado tantas veces, separando las conexiones de read con las de write y escalando como loco. Y pensar que hay (o había) gente que le echa la culpa de la lentitud del sitio a usar una BD gratis. Pero todas las piezas calzaron cuando en la conversación del final me enteré que esa pirámide era sólo para mostrar información de los eventos a los usuarios (los clientes nunca escriben en esa BD). Todo los temas de sesión, compra, etc, se manejan con cuatro clusters Oracle replicados con software propietario. Y todos los presentes estaban de acuerdo en que eso era lo lógico... Faltó alguien de mysql o algún fanático que defendiera su producto, pero nadie dijo nada...

Aproveché también un momento en la mañana en que no me interesó nada en particular para recorrer la exposición de los sponsor. Conseguí 2 poleras, como 8 lápices, un llavero con linterna y un paquetito de tictacs pero marca mysql. Y participé en un concurso para ganar $200 dólares en libros O'reily que me imagino muy poca gente participó, así que las probabilidades son altas.
Entre los expositores, la niña de Google era bien simpática, la de Redhat aún más. Y de los productos, había algunas soluciones de backup que Marchant podrá analizar en su momento (llevo folletos de todo), un engine para mysql muy rápido para sacar estadísticas, un software de desarrollo rápido de aplicaciones basadas en query-by-example que se veía demasiado bueno para ser cierto.

1er día de conferencia

Después del día de tutoriales, hoy empezamos con las sesiones de la conferencia en sí. (Esto lo estoy escribiendo un día después de los acontecimientos, así que puede que no me acuerde de algunos detalles.) En la mañana, comenzando, hubo algunos discursos o keynotes bastante interesantes:

- Primero, Marten Mickos, CEO de MySQL AB (S.A. en Finlandia o alguno de esos países), nos dio la bienvenida y una introducción a la empresa y su particular estilo. 70% de los empleados de mysql trabaja desde sus casas, en muchos países diferentes, por lo que mantener un espíritu de empresa es una tarea no menor. Dio algunos punteros para lograrlo, de los que lo que más me llamó la atención fue que cuando se juntan, no tienen meetings, sino reunions. Para discutir temas de trabajo es mucho más práctico usar la tecnología, entonces los pocos momentos en que se ven, aprovechan de estrechar los lazos y de divertirse juntos. Todos se juntan una vez al año en algún lugar del mundo (no son muchos empleados, no sé el número exacto pero deben de ser algo así como 100), y me pareció que la empresa es un verdadero ejemplo de una comunidad global.

- Después un tipo del que nunca había escuchado, Guy Kawasaki, dio una presentación bastante entretenida y dinámica sobre la innovación. Parece que es famoso por estos lados en discursos motivacionales, y por algo es porque me motivó :). Espero que ponga el powerpoint en su blog, aunque el contenido no es tan interesante como haberlo escuchado.

- Finalmente, un tipo de Redhat a cargo del proyecto OLPC (un notebook por niño), mostró el proyecto, las motivaciones y mostró un video de los desarrolladores. Me dieron ganas de tener uno de los aparatitos; están casi listos y tienen hartas cosas simpáticas. (El objetivo de la charla era mostrar cómo la comunidad opensource puede entregar a la sociedad)

Después estuve todo el día en sesiones. Las sesiones a las que asistí hoy fueron las siguientes:

- Tips and Tricks for MySQL Replication: Una sucesión vertiginosa de 25 tips relativos a la replicación, demasiado rápido como para absorber mucho. Se pueden analizar los slides posteriormente. Me llamaron la atención algunos trucos para simular la replicación multi-master, y un uso que para las tablas BLACKHOLE (primera vez que las escuchaba). Hay otra sesión sobre Blackhole y Federated que no pude ir, pero sería bueno conseguirse el powerpoint, ya que se ven muy interesantes. La presentación la dio el Lead Developer de la replicación, Lars Thalmann, así que los consejos son de buena fuente.

-A Real-world MySQL Watch Dog: Step-by-Step Usage of the MySQL Monitoring and Advisory Service: Nada nuevo, el objetivo era vender el servicio que ya tenemos. Aprendí que las variables XA de innodb si no se usan mejor apagarlas (las usamos?) ya que afectan el rendimiento. Debi haber ido a la presentación de Digg en vez (habrá que conseguir los slides).

- SQL AntiPatterns: Consejos básicos de cosas que No hay que hacer en mysql:

1. Por ningún motivo usar campos de valores separados por comas (los tenemos en varias partes)
2. No confiar en campos que no aparecen en el GROUP BY pero si en el SELECT (mejor usar GROUP_CONCAT en esos casos) Ej: Select a,b from c group by a: b puede ser un valor al azar en cada fila. Bastante obvio y no creo que nos afecte en algo
3. Tablas EAV - Entity-Attribute-Value, tablas de valores "flexibles" del tipo entity_id, atributo, valor. Evitarlas.
4. Nunca dar acceso a usuarios a ejecutar sql directamente a ninguna maquina (desarrollo es una excepcion para nosotros obviamente) Ej: select * from table, table, ...., table. Con solo 10 filas tenemos 10^n resultados que matarian al servidor.
5. Nunca reusar primary keys. Y a esto agrego algo del tutorial de ayer: Siempre tener un primary key int unsigned auto_increment, aunque la tabla tenga un pk natural. Tiene montones de consecuencias positivas, especialmente con InnoDB (debiese cambiar todas las tablas de cache)

- Intro to MySQL Cluster: Después del tutorial de 5.1 quise aprender un poco más de mysql cluster. Interesante, pero demasiado complejo en nuestra situación, no sé si valga la pena.

- Real-world MySQL Tuning: La presentación la dio un indio de una consultora relacionada con tuning de bases de datos. (El tipo tiene un buen blog de la conferencia, y sus slides). Interesante y se ve que sabía harto, entendí mejor las diferentes variables del my.cnf y para qué sirven y un poco como ajustarlas. Todo el detalle está en el powerpoint. Recordatorio: revisar las variables qcache, me tinca que hay harto que optimizar con respecto a eso.

- InnoDB: Status, Architecture, and New Features: La presentación la dio Heikki Tuuri, el autor y programador de InnoDB, Oracle. El tipo podrá ser un genio, pero fue la presentación más fome e insípida que quizás he visto en mi vida. Realmente la nórdica es una cultura diferente a cualquiera y bastante especial. Buen material powerpoint que sirve para entender Innodb por debajo.

Finalmente, me hubiese gustado ir a Scaling the World’s Largest Photo Blogging Community, pero aproveché la ocasión para tomar un examen de certificación que dieron gratis por ser beta. Así que si todo sale bien, en unas semanas seré un Asociado MySQL Certificado (CMA).

En la noche hubo una recepción con cóctel y cervezas. Conversé con unos rusos autores de un proyecto, Sphinx, que se me ocurrió podría servir para nuestro problema de logs. Aunque no sé si me entendieron bien, habrá que darle una vuelta.