De: http://sigt.net/archivo/digg-mejora-del-rendimiento-un-4000-por-ordenar-con-php-en-lugar-de-mysql.xhtml

 

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:

 

  1. 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.
  2. 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.
  3. 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.
  4. 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?.
  5. 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.
  6. Escalar equivale a especialización. Para escalar a  menudo se requiere construir de forma personalizada grandes soluciones a  problemas específicos.
  7. 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.