He estado leyendo MUCHO sobre las opciones disponibles. También tuve en mis manos la segunda edición de MySQL de alto rendimiento, que recomiendo encarecidamente.
Esto es lo que he logrado reconstruir:
Clustering
La agrupación en clústeres en el sentido general consiste en distribuir la carga entre muchos servidores que a una aplicación externa le parecen un solo servidor.
Clúster MySQL NDB
MySQL NDB Cluster es un motor de almacenamiento distribuido, en memoria, que no comparte nada con replicación síncrona y partición automática de datos (disculpe, tomo prestado literalmente del libro High Performance, pero lo expresaron muy bien allí). Puede ser una solución de alto rendimiento para algunas aplicaciones, pero la aplicación web generalmente no funciona bien en ella.
El principal problema es que más allá de las consultas muy simples (que tocan solo una tabla), el clúster generalmente tendrá que buscar datos en varios nodos, lo que permite que la latencia de la red se filtre y ralentice significativamente el tiempo de finalización de las consultas. Dado que la aplicación trata al clúster como una sola computadora, no puede decirle de qué nodo buscar los datos.
Además, el requisito en memoria no es viable para muchas bases de datos grandes.
Continuent Sequoia
Esta es otra solución de agrupamiento en clústeres para MySQL, que actúa como un middleware sobre el servidor MySQL. Ofrece replicación sincrónica, equilibrio de carga y conmutación por error. También asegura que las solicitudes siempre obtengan los datos de la última copia, eligiendo automáticamente un nodo que tenga los datos nuevos.
He leído algunas cosas buenas sobre él y, en general, suena bastante prometedor.
Federación
La federación es similar a la agrupación, por lo que también lo tiré aquí. MySQL ofrece federación a través del motor de almacenamiento federado. Al igual que la solución de clúster NDB, funciona bien solo con consultas simples, pero peor aún con el clúster para consultas complicadas (ya que la latencia de la red es mucho mayor).
Replicación y equilibrio de carga
MySQL tiene la capacidad incorporada para crear réplicas de una base de datos en diferentes servidores. Esto se puede utilizar para muchas cosas: dividir la carga entre servidores, copias de seguridad en caliente, crear servidores de prueba y conmutación por error.
La configuración básica de la replicación implica que un servidor maestro maneje principalmente las escrituras y uno o más esclavos manejen solo las lecturas. Una variación más avanzada es la de la configuración maestro-maestro , que también permite escalar las escrituras al tener varios servidores escribiendo al mismo tiempo.
Cada configuración tiene sus pros y sus contras, pero un problema que todos comparten es el retraso de la replicación: dado que la replicación de MySQL es asincrónica, no todos los nodos tienen los datos más actualizados en todo momento. Esto requiere que la aplicación sea consciente de la replicación e incorpore consultas compatibles con la replicación para que funcione como se esperaba. Para algunas aplicaciones, esto puede no ser un problema, pero si siempre necesita los datos más recientes, las cosas se complican un poco.
La replicación requiere cierto equilibrio de carga para dividir la carga entre los nodos. Esto puede ser tan simple como algunas modificaciones en el código de la aplicación o usar soluciones de software y hardware dedicadas.
Fragmentación y partición
La fragmentación es un enfoque comúnmente utilizado para escalar soluciones de bases de datos. Divide los datos en fragmentos más pequeños y los distribuye por diferentes nodos del servidor. Esto requiere que la aplicación esté al tanto de la modificación en el almacenamiento de datos para funcionar de manera eficiente, ya que necesita saber dónde encontrar la información que necesita.
Hay marcos de abstracción disponibles para ayudar a lidiar con la fragmentación de datos, como Hibernate Shards , una extensión de Hibernate ORM (que desafortunadamente está en Java. Estoy usando PHP). HiveDB es otra solución de este tipo que también admite el reequilibrio de fragmentos.
Otros
Esfinge
Sphinx es un motor de búsqueda de texto completo que se puede utilizar para mucho más que búsquedas de prueba. Para muchas consultas, es mucho más rápido que MySQL (especialmente para agrupar y ordenar), y puede consultar sistemas remotos en paralelo y agregar los resultados, lo que lo hace muy útil en su uso con fragmentación.
En general, sphinx debe usarse con otras soluciones de escalado para obtener más del hardware y la infraestructura disponibles. La desventaja es que nuevamente necesitas que el código de la aplicación sea consciente de Sphinx para usarlo de manera inteligente.
Resumen
Las soluciones de escalado difieren según las necesidades de la aplicación que las necesita. Para nosotros y para la mayoría de las aplicaciones web, creo que la replicación (probablemente multimaestro) es el camino a seguir con un equilibrador de carga que distribuye la carga. La fragmentación de áreas problemáticas específicas (tablas enormes) también es imprescindible para poder escalar horizontalmente.
También voy a probar Continuent Sequoia y ver si realmente puede hacer lo que promete, ya que implicará la menor cantidad de cambios en el código de la aplicación.