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.