Capacidades máximas de MySQL

Question

¿Cómo sé si un proyecto es demasiado grande para MySQL y debería usar algo con una mejor reputación de escalabilidad?

¿Hay un tamaño de base de datos máximo para MySQL antes de que se produzca la degradación del rendimiento? ¿Qué factores contribuyen a que MySQL no sea una opción viable en comparación con un SGBD comercial como Oracle o SQL Server?

Answer 1

Principalmente es el tamaño de la tabla.

Supongo que utilizará el complemento de Oracle innoDB para mysql como motor. Si no lo hace, eso probablemente signifique que está utilizando un motor comercial como infiniDB, InfoBright para Tokutek, en cuyo caso debe enviar sus preguntas.

InnoDB se pone un poco desagradable con tablas muy grandes. Se aconseja dividir sus tablas si es posible con instancias muy grandes. Esencialmente, si sus índices (frecuentemente usados) no encajan todos en el ram, los insertos serán muy lentos ya que necesitan tocar muchas páginas que no están en ram. Esto no se puede solucionar.

Puede utilizar la característica de partición de MySQL 5.1 si hace lo que desea, o particionar sus tablas en el nivel de aplicación si no lo hace. Si puede obtener los índices de sus tablas para que quepan en ram, y solo cargue una tabla a la vez, entonces obtendrá un ganador.

Puede utilizar la compresión del complemento para hacer que su memoria RAM vaya un poco más lejos (ya que las páginas se comprimen tanto en el RAM como en el disco) pero no puede superar la limitación fundamental.

Si los índices de su tabla no son todos (o al menos MAYORMENTE - si tiene algunos índices que son NULL en 99.99% de los casos, puede escaparse sin tenerlos) encajan en ram, la velocidad de inserción será mala.

El tamaño de la base de datos no es un problema importante, siempre que sus tablas encajen individualmente en ram mientras realiza la carga masiva (y, por supuesto, solo carga una a la vez).

Estas limitaciones realmente suceden con la mayoría de las bases de datos basadas en filas. Si necesita más, considere una columna de base de datos.

Infobright e Infinidb ambos usan un núcleo basado en mysql y son motores basados ​​en columnas que pueden manejar tablas muy grandes.

Tokutek es bastante interesante también - es posible que desee ponerse en contacto con ellos para una evaluación.

Cuando evalúa la idoneidad del motor, asegúrese de cargarlo con datos muy grandes en hardware de grado de producción. No tiene sentido probarlo con una base de datos 10G (por ejemplo), que no probará nada.

Answer 2

Google utiliza MySQL. ¿Tu proyecto es más grande que Google?

Comentarios de Smart-alec aparte, MySQL es una aplicación de base de datos profesional. Si su aplicación pone a prueba MySQL, apuesto a que hará lo mismo con casi cualquier otra base de datos.

Answer 3

Si usted está buscando un par de ejemplos:

• Facebook se trasladó a Cassandra sólo después de que estaba almacenando más de 7 terabytes de datos de buzón de entrada. (Fuente: Lakshman, Malik: Cassandra - A Decentralized Structured Storage System.) (... A pesar de que estaban teniendo bastantes problemas en esa etapa.)

• Wikipedia también handles hundreds of Gigabytes de datos de texto en MySQL.

Answer 4

MySQL es un DBMS comerciales, sólo tiene la option para obtener el apoyo/monitorización que es ofrecido por Oracle o Microsoft. O puede usar el soporte de la comunidad o el software de monitoreo provisto por la comunidad.

Answer 5

Lo que debe tener en cuenta no solo es el tamaño en las operaciones. Crítico también:

• ¿Scenaros para copia de seguridad y restauración?
• Mantenimiento. Ejemplo: SQL Server Enterprise puede reconstruir un índice MIENTRAS EL ANTIGUO ESTÁ DISPONIBLE - de forma transparente. Esto significa que no hay tiempo de inactividad para una reconstrucción de índice.
• Disponibilidad (básicamente no desea tener que restablecer una base de datos de 5000gb si un servidor se muere) - duplicación preferida, la replicación "apesta" (técnicamente).

Sea lo que sea que vaya, tenga cuidado con Oracle RAC (su clúster): se sabe que es "problemático" (por decirlo de forma precisa). Se sabe que SQL Server es mucho más barato, escala mucho peor (sin la opción "RAC") pero básicamente funciona sin hacer que los administradores quieran suicidarse cada hora (la opción "RAC" parece hacer eso). La escalabilidad "mucho peor" sigue siendo suficiente para Terra Server (http://msdn.microsoft.com/en-us/library/aa226316(SQL.70).aspx)

Aquí hay algunas preguntas recientes sobre personas que tienen problemas para reconstruir índices en una base de datos de 10 gb o algo así.

Mucho por mis 2 centavos. Estoy seguro de que algunos especialistas de MySQL se meterán en problemas allí.

Answer 6

Trabajo para una gran empresa de Internet. MySQL puede escalar muy, muy grande con muy buen rendimiento, con un par de advertencias.

Un problema con el que puede encontrarse es que un índice de más de 4 gigabytes no puede entrar en la memoria. Una vez que intenté mejorar el rendimiento del texto completo de MySQL, pasé mucho tiempo jugando con algunos parámetros de índice, pero no se puede evitar el problema fundamental de que si su consulta da en el disco por un índice, se vuelve lento.

Puede encontrar algunas aplicaciones de ayuda que pueden ayudar a resolver su problema. Para el problema de texto completo, hay Sphinx: http://www.sphinxsearch.com/

Jeremy Zawodny, que ahora trabaja en la lista de Craig, tiene un blog en el que de vez en cuando se analiza el comportamiento de grandes bases de datos: http://blog.zawodny.com/

En resumen, el proyecto probablemente no sea demasiado grande para MySQL. Puede que sea demasiado grande para algunas de las formas en que ha usado MySQL anteriormente, y es posible que deba adaptarlas.