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.