Digg: mejora del rendimiento un 4000% por ordenar con PHP en lugar de MySQL
Publicado el Monday 29 de March del 2010 @ 9:00 por Armonth.
- 9
- 7
Comentar
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 CTO1 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 “sharding2“, 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.
Notas de traducción
9 Comentarios
-
Jaime:
Si pero a la que añadas a esa web unas cuantas de mas busquedas con filtros y demas por lo que sea tienes que volver a programarlo todo. Mientras en Sql con una simple peticion ya esta.
Mejor combinar los 2 metodos. -
Clbustos:
Lo que me preocupa de esta moda del “No-Sql” es que los programadores de pequeñas aplicaciones empezaran a usar sistemas no relacionales cuando no es pertinente. Como bien dice Jaime, en sistemas típicos los sistemas relacionales ofrecen un balance adecuado entre eficiencia en la implementación y en el desarrollo.
Y creo que sería mejor traducir los términos relacionados con claves de datos más usados, como restricciones de claves foráneas o búsquedas de clave primaria, ya que para algo tenemos nuestro idioma.
-
mmolina:
Yo, como Clbustos también creo que esta moda puede desencadenar en que gente que no necesita meterse en problemas, se meta :)
Este tipo de cosas son necesarias si tienes sitios como los de “esta gente”: millones de visitas al día. Pero para el resto de gente (me incluyo, con sitios de 300k usuarios/día) no hace falta ser tan extremos: sharding, memcache y sphinx te salvan la papeleta sin necesidad de subirte al carro “no-SQL”.
-
fer:
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡El mundo se ha vuelto loco!!!!!!!!!!!!!!!!!!!!!!!!!!!
Como mucha gente, yo empecé en banca (cobol). Tuve que trabajar con ambos tipos de BBDD, y es una locura pensar en bases no relacionales para propositos generales (tal vez haya unos casos donde esté justificado, pero no es lo normal. En especial porque desde hace unos años se migraron todas las BBDD de “no relacionales” a “relaciones” (y os aseguro que si el banco hace algo es para ahorrar en CPU)
Para no ser adecuadas en grandes volúmenes de datos, se usa en los sistemas que manejan mayor volumen de información, a día de hoy.
Lo que no cabe duda es que hay simplicar la programación para hacer búsquedas mas sencillas, o crear un buen diseño de las bases que optimice el proceso
Saludos
-
wladimir:
Debemos considerar que un motor de datos es una herramienta, solo eso, y como cualquier herramienta, se debe saber para que sirve. Si lo unico que conoces es un martillo, todo tiene cara de clavo. si usas una BD Relacional para datos estructurados, organizados y conocidos, es ideal, pero cuando quieres a manejar datos sin estructura o de estructura cambiante, comienzan los problemas.
-
Marxchante:
Hola, hace 2 años mas o menos tuve que hacer un cubo de desición, es decir usar una inmensa cantidad de datos, aprovechando la ocasión, ingrese algunos datos que tenia yo en postgresql a una base de mysql. Y si bien se supone que el fuerte de mysql es la velocidad solo es en bases de tamaño moderado, ya que para este ejercicio, postgresql se tardo en la consulta 10 segundos, mysql en 2 horas. El problema no es lo relacional, sino el manejador que se usa para un caso no adecuado.
Saludos
-
Pedro Fortuny:
Estamos en lo de siempre: un buen ingeniero conoce VARIAS soluciones al problema planteado y -supuestamente- toma una decisión optimal en el sentido en que le parece más oportuno. No hay dicotomía, solo hay un problema de diseño y optimización.
Los F1 no tienen varios asientos porque están optimizados para una cosa. Las furgonetas son tan grandes porque están optimizadas para otra. ¿Cuál es tu problema? Antes de escoger un coche por la marca (SQL, noSQL, relacional pero no estático…) plantéate el problema.
Cheers
-
Antonio J.:
Una de las tareas a realizar cada vez que se aborda un proyecto es estudiar y seleccionar la tecnología más adecuada, y según sea necesario, nos decantaremos por una base de datos realcional o no-relacional.
Como dice Pedro, es un problema de diseño y optimización.
Ahora ocurrirá como otras tantas veces, que llega el jefe de turno que ha oído que con una base de datos no-relacional vamos a ganar rendimiento y….a cambiarlo todo ;)