¿Cuántas selecciones por segundo puede ejecutar un servidor mysql?

Estoy escribiendo un plan de negocios y tengo que simular el costo cuando mi sitio web llegará a 500,000 visitantes únicos.

• visitantes: 500.000
• páginas vistas: 1,500,000
• páginas vistas de araña: 500,000
• total de páginas vistas: 2,000,000

Cada página hace 50 consultas + -

• consultas por día: 100 millones
• por hora: 4 millones
• por minuto: 70,000
• por segundo: 1,200
• pico: 3.000

Al hacer este cálculo, necesito 3.000 consultas en segundo lugar ... ¿qué tipo de servidor puede manejarlo?

El problema es: en realidad mi sitio está realizando 2.000 visitas al día y tiene - + 150/200 consultas / segundo ... a partir de este punto, esperaré 50.000 consultas / segundo.

¿Cuántos servidores necesito en clúster o replicación gestionan este trabajo?

Solía ​​trabajar para una empresa de comercio electrónico con un sitio web que tenía varios millones de visitas por día. Teníamos un solo DELL PE 1750 con 2 CPU de un solo núcleo y 2 GB de RAM, tamaño de base de datos aprox. 4 GB. En las horas punta, este servidor maneja más de 50k consultas por segundo.

Dicho esto: la base de datos estaba bien estructurada, todas las consultas se ajustaban con precisión (teníamos sesiones semanales que analizaban los registros de consultas lentas y corrigían consultas e índices) y la configuración del servidor también se ajustaba. El almacenamiento en caché es definitivamente una buena idea, pero MySQL lo hace de todos modos, solo tiene que analizar el rendimiento y luego ajustar cómo se usa su memoria (consultar caché frente a otras opciones).

A partir de esa experiencia, puedo decirle que el mayor impacto es causado por la falta de índices, índices incorrectos y mal diseño de la base de datos (por ejemplo, campos de cadena largos como claves primarias y tonterías similares).

Todo depende de la complejidad de la consulta, la cantidad de memoria que tengan los servidores y la rapidez de los discos.

Si las consultas son muy simples o están muy bien ajustadas, un solo servidor de base de datos grande puede manejar eso. Sin embargo, si las consultas son muy complejas (o simples pero mal ajustadas), necesitará varios servidores.

Esto realmente no se puede estimar sin saber nada sobre las consultas específicas que está ejecutando, el esquema de la base de datos y su tamaño.

Un SELECT simple en una columna indexada es una bestia bastante diferente de un par de JOINs basadas en no indexadas ... y, por supuesto, las cosas cambian mucho si las tablas involucradas contienen registros 1K o 1M.

También:

• ¿Cuál es su configuración de hardware actual?
• ¿Cuánto de su potencia (CPU, RAM, E / S de disco) está utilizando su servidor bajo la carga actual?

Como comentó Ignacio, es posible que desee considerar el almacenamiento en caché. En el cms o tal vez incluso en frente de la pila. Más de 50 consultas para cada (¡cada!) Página realmente es mucho.

A juzgar por sus comentarios, el factor más importante será el tamaño de su conjunto de datos, o al menos el tamaño del conjunto de datos "en caliente". 3,000qps o incluso 8,000qps en un servidor de 16 núcleos no es un problema en absoluto, siempre y cuando el servidor rara vez tenga que ir al disco para satisfacer la consulta. Una vez que el conjunto de datos activo excede la cantidad de memoria que InnoDB está utilizando para almacenarlo en caché, su rendimiento disminuirá rápidamente.

Para grandes conjuntos de datos "activos", probablemente valga la pena invertir tiempo en convertirlos en un esquema de "grandes datos", para eso están destinados. Por ejemplo, si tiene una gran cantidad de datos para recuperar, pero nunca reescribe, sino que solo agrega datos nuevos, mire Apache Hive. Examine, generalmente es un sabor que puede interactuar fácilmente con el código existente, lo que también evitará que se agote el espacio del caché.

Hay demasiadas cosas que pueden afectar sus consultas por segundo, no confíe en mis datos sin probarse usted mismo. Publico el resultado de mi prueba de velocidad aquí para ayudar a alguien a estimar el qps con la base de datos y la máquina mysql actual (2018-09). En mi prueba, el tamaño de los datos es menor que la memoria del servidor (eso reduce drásticamente la E / S y mejora mucho el rendimiento).

Uso una memoria de una cpu 3.75GB, 100GB ssd, instancia de servidor mysql en la nube gcp y obtengo:

• 1 cliente, un sql, una fila leída: 799 sql / segundo.
• 50 clientes, un sql, una fila leída: 6403 sql / segundo.
• 50 clientes, un sql una fila de escritura: 4341 filas escritas, qps. 4341 sql / segundo.
• 1 cliente, 30k filas escritas por sql: 92109 filas escritas / s.