Tenía en la cola de pendientes un apunte la mar de interesante publicado en High Scalability y titulado Digg: 4000% Performance Increase by Sorting in PHP Rather than MySQL (del cual sale el titular de esta entrada). Casi toda la entrada es traducción de la original en inglés aunque un poco "liberal". Cualquier error en la misma, ya sabéis ;).
En la entrada original comentan y enlazan una entrevista de James Turner hecha a Joe Stump CTO de SimpleGeo y anterior líder de arquitectura de Digg.
En ella Joe habla de su experiencia en el uso de Cassandra (una base de datos NoSQL) vs MySQL. Y de cómo Digg empezó con una arquitectura orientada a MySQL para actualmente estar moviéndose a Cassandra.
Sus observaciones sobre algunas de las lecciones aprendidas y las motivaciones detrás de este cambio son especialmente valiosas. A continuación algunos de los puntos claves que pueden resultar útiles:
-
Precalcular al escribir, hacer las lecturas rápidas. Esto es una vieja táctica a la hora de escalar pero es valioso ver cómo SimpleGeo está aplicándolo a sus problemas de encontrar entidades en ciertas regiones geográficas. Usando Cassandra han construido dos clusters: uno para los índices y otro para los documentos. El cluster para documentos, como podrás imaginar, es un simple buscador de datos. El cluster para índices está cuidadosamente construido para tener una respuesta a cada escenario de búsqueda. Los índices están calculados al escribir, por lo que las lecturas son muy rápidas. Como las lecturas son predominantes, este planteamiento tiene mucho sentido. Las peticiones basadas en la hora también son precalculadas. Joe menciona algoritmos especiales para desplegar los datos, con tendencia a concentrarse alrededor de las zonas geográficas, pero no menciona cuáles son éstos.
-
Restringe lo que el usuario puede hacer. El sistema se mantiene simple no permitiendo consultas de duración indefinida. Los usuarios tienen permitidas realizar una serie de operaciones bien definidas que terminan en búsquedas altamente optimizadas. No tienen intención de ser una base de datos genérica, su única intención es ser capaces de servir datos geográficos... de forma óptima.
-
El conjunto de herramientas relaciones han fallado cuando se requiere tiempo real. El conjunto de herramientas de las bases de datos relaciones no han evolucionado. Han fracasado para entornos en tiempo real a gran escala. Hacer sistemas escalables en una base de datos relacional requiere hacer "[sharding](http://en.wikipedia.org/wiki/Shard_(database_architecture)", balanceo de carga, "resharding", administración de clusters, preocuparse de la consistencia, implementar peticiones distribuidas y hacer otras capas por ti mismo. Entonces ¿para qué molestarse?. Cassandra hace todo esto de serie. Apaga un servidor y Cassandra gestionará todo el re-mapeado y re-enrutado de forma automática.
-
Las técnicas para escalar convierten una base de datos relacional en una no relacional. Para escalar Digg ellos han seguido un conjunto de técnicas muy similares a las usadas por eBay. Nada de "joins" (uniones), nada de "foreign key constraints" (restricciones de claves foráneas - para escalar las escrituras), sólo "primary key look-ups" (búsquedas de clave primaria), peticiones de rango limitado y las uniones se hacen en memoria. Cuando se implementaron los comentarios se consiguió una mejora del rendimiento de un 4000% al ordenar (sorting) usando PHP en lugar de MySQL. Todo este esfuerzo requerido para hacer escalar una base de datos relacional básicamente quiere decir que vas a usar una base de datos no relacional de todas formas. Entonces ¿Por qué no utilizar una base de datos no relacional desde un principio?.
-
Adopta y extiende productos existentes en lugar de hacer los tuyos propios. Cassandra ha permitido a SimpleGeo crear políticas personalizadas de particionamiento de datos y extender éstos datos mejor. Esto significa que no hay que crear una base de datos, una base de datos existente puede ser creada y mejorada para adquirir esa funcionalidad extra que requieres mientras sigues beneficiándote de una bien soportada y altamente funcional base de datos. Ésto es también una lección aprendida en Justin.tv y es probable que se convierta en una estrategia mucho más importante a medida que la complejidad aumenta.
-
Escalar equivale a especialización. Para escalar a menudo se requiere construir de forma personalizada grandes soluciones a problemas específicos.
-
MySQL funciona bien para un cierto conjunto de problemas. Típicamente para datos relativamente estáticos, volúmenes de peticiones relativamente pequeños y requerimientos de latencia relativamente altos.
Comentarios