He estado leyendo MUCHO sobre las opciones disponibles. También tengo en mis manos la 2.ª edición de MySQL de alto rendimiento, que recomiendo encarecidamente.
Esto es lo que he logrado reconstruir:
Agrupación
La agrupación en clúster en el sentido general es distribuir la carga entre muchos servidores que aparecen en una aplicación externa como un solo servidor.
Clúster NDB de MySQL
MySQL NDB Cluster es un motor de almacenamiento distribuido, en memoria, no compartido, con replicación síncrona y partición automática de datos (disculpe, lo tomé prestado literalmente del libro de alto rendimiento, pero lo explican muy bien allí). Puede ser una solución de alto rendimiento para algunas aplicaciones, pero las aplicaciones web generalmente no funcionan bien en ellas.
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 infiltre y ralentice significativamente el tiempo de finalización de las consultas. Dado que la aplicación trata el clúster como una sola computadora, no puede decirle de qué nodo obtener los datos.
Además, el requisito de memoria interna no funciona para muchas bases de datos grandes.
Secuoya continua
Esta es otra solución de agrupación en clústeres para MySQL, que actúa como un middleware sobre el servidor MySQL. Ofrece replicación síncrona, equilibrio de carga y conmutación por error. También garantiza 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 en él, y en general suena bastante prometedor.
Federación
La federación es similar a la agrupación en clústeres, así que también la arrastré aquí. MySQL ofrece federación a través del motor de almacenamiento federado. Similar a la solución de clúster NDB, funciona bien solo con consultas simples, pero aún peor que 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 replicaciones de una base de datos en diferentes servidores. Esto se puede usar para muchas cosas:dividir la carga entre servidores, copias de seguridad activas, 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 escrituras y uno o más esclavos solo manejen lecturas. Una variación más avanzada es la del master-master configuración, 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 asíncrona, 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 conscientes de la replicación para funcionar como se espera. Para algunas aplicaciones, esto podría no ser un problema, pero si siempre necesita los datos más actualizados, las cosas se complican un poco.
La replicación requiere algo de 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 el uso de 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 en diferentes nodos de servidor. Esto requiere que la aplicación sea consciente de la modificación del 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 del ORM de Hibernate (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
Esfinge 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 para usar con fragmentación.
En general, Sphinx debe usarse con otras soluciones de escalado para obtener más hardware e infraestructura disponibles. La desventaja es que nuevamente necesita el código de la aplicación para estar al tanto 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 balanceador de carga que distribuye la carga. La fragmentación de áreas problemáticas específicas (mesas enormes) también es imprescindible para poder escalar horizontalmente.
También le daré una oportunidad a 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.
