La raíz no es lo suficientemente específica como para dar una sugerencia firme, pero la lista completa de lo que se podría hacer es la siguiente:
- Clúster de base de datos :adecuado para situaciones en las que no desea cambiar su capa de aplicación y la base de datos es todo lo que toca. Hay un límite de cuánto puede obtener de un clúster de base de datos. Si su volumen de solicitudes sigue creciendo, esta solución también fallará eventualmente. Pero la buena noticia es que tiene toda la funcionalidad que ya tenía en un MySQL ordinario de instancia única.
- fragmentación :Dado que su pregunta está etiquetada con MySQL y no admite la fragmentación por sí sola, si desea utilizar esta solución, debe implementarla en su capa de aplicación. En esta solución, distribuirá sus datos en varias bases de datos (preferiblemente en varias instancias de MySQL en hardware separado) de forma lógica. Será su responsabilidad encontrar la base de datos adecuada que contenga sus datos designados. Es una de las soluciones más efectivas que existen, pero no siempre es factible. Su mayor defecto es que los datos dispersos entre dos o más bases de datos no pueden incluirse dentro de una transacción.
- Replicación :Dependiendo de su escenario, es posible que pueda incorporar la replicación de la base de datos y tener copias de sus datos en ellos. De esta manera, puede conectarse a ellos en lugar de a la base de datos maestra y reducir la carga en ella. La definición de replicación predeterminada es el escenario maestro/esclavo en el que el flujo de datos es unidireccional, del maestro al esclavo. Entonces, los cambios que pueda hacer en el esclavo mientras se aplicarán en el bálsamo, no afectarán al maestro. Pero también existe una configuración de replicación maestro/maestro en la que el flujo de datos es en ambos sentidos. Sin embargo, no puede asumir la integridad atómica de los cambios de datos simultáneos entre ambos maestros. Al final, esta solución es más efectiva si planea usarla en modo maestro/esclavo y usar esclavos para acceso de solo lectura.
- Almacenamiento en caché :Tal vez esta solución no debería incluirse aquí, pero dado que su vástago no la rechaza, aquí va. Una de las formas de reducir la carga de la base de datos es almacenar en caché sus datos una vez extraídos. Esta solución puede ser beneficiosa especialmente si la extracción de datos es costosa. Hay muchos servidores de caché, como memcached o redis . De esta manera, puede omitir muchas de las conexiones de la base de datos, pero solo para la extracción de datos.
- Otros motores de almacenamiento :Siempre puede cambiar a motores de mayor rendimiento si el actual no le proporciona lo que necesita. Por supuesto, esto solo es factible si tus necesidades te lo permiten. Hoy en día existen motores NoSQL, mucho más eficaces que RDBMS, que admiten la fragmentación de forma nativa y se pueden escalar linealmente con el mínimo esfuerzo. También existen soluciones basadas en Lucene con potentes capacidades de búsqueda de texto completo que le brindan la misma fragmentación automática. De hecho, la única razón por la que debería utilizar un RDBMS tradicional es el comportamiento atómico de las transacciones. Pero si las transacciones no son obligatorias, existen soluciones mucho mejores que RDBMS.
