Prácticas recomendadas, PHP, seguimiento de millones de impresiones por día

Question

¿Qué debo hacer para hacer 20k insertos mysql por segundo posibles (durante las horas pico alrededor de 1k/seg durante tiempos más lentos)? He estado investigando un poco y he visto la sugerencia "INSERT DELAYED", escribiendo en un archivo plano, "fopen (file, 'a')", y luego ejecutando un trabajo crónico para volcar los datos "necesarios" en mysql, etc. También he escuchado que necesita varios servidores y "balanceadores de carga" de los que nunca he oído hablar, para hacer que algo así funcione. También he estado mirando estos thing-a-ma-jigs de "servidor en la nube" y su escalabilidad automática, pero no estoy seguro de qué es realmente escalable.

La aplicación es solo un script de seguimiento, por lo que si tengo 100 sitios web que obtienen 3 millones de páginas cargadas al día, habrá alrededor de 300 millones de inserts por día. Los datos se ejecutarán a través de un script que se ejecutará cada 15-30 minutos, lo que normalizará los datos e insertará en otra tabla mysql.

¿Cómo lo hacen los perros grandes? ¿Cómo lo hacen los perritos? No puedo permitirme un servidor enorme, así que de forma intuitiva, si hay varias maneras de hacerlo, la gente inteligente puede pensar ... por favor, hágamelo saber :)

Answer 1

Eso es impresionante. La mayoría de mis datos provienen de inserciones masivas a la vez. Una cosa que encuentro es que los insertos a granel son mucho mejores que los insertos individuales. Además, el diseño de sus tablas, índices, etc. tiene mucho que ver con la velocidad de inserción. El problema con el uso de cron y la inserción masiva son los casos límite. (Cuando va a hacer los insertos).

Además con archivos flatfiles. Puede encontrar fácilmente problemas con la concurrencia al escribir las inserciones en el archivo. Si escribe 1k + inserta una s, se encontrará rápidamente con muchos conflictos y pérdidas cuando haya problemas con la escritura del archivo.

Answer 2

¿Cómo lo hacen los perros grandes?

Varios servidores. Balanceo de carga.

¿Cómo lo hacen los perros pequeños?

Varios servidores. Balanceo de carga.

Realmente desea guardar inserciones y enviarlas a la base de datos de forma masiva. 20k inserta un segundo por segundo y simplifica eso hasta una gran inserción cada segundo, elimina la mayor parte.

Answer 3

Este no es un problema que pueda manejar solo en PHP.

Si usted tiene 20 000 solicitudes de un golpear a su "bajo presupuesto" (como se entendía por el tono de su pregunta) servidor, entonces alcanzará su límite antes de la mayoría de ellos llegan al procesador de PHP segundo (y , eventualmente, MySQL).

Si tiene un script de seguimiento de tráfico, es muy probable que cause problemas para todos los sitios que rastrea.

Answer 4

Un par de maneras:

En primer lugar, se llega a un punto donde es necesario particionar o fragmentar los datos que dividirlo entre varios servidores. Esto podría ser tan simple como A-C en el servidor 1, D-F en el servidor 2 y así sucesivamente.

En segundo lugar, difiera la escritura en la base de datos. En su lugar, escriba en una tienda de memoria rápida utilizando beanstalkd o memcached directamente.Haga que otro proceso recopile esos estados y escriba datos agregados en la base de datos. Periódicamente amalgame esos registros en datos resumidos.

Answer 5

PHP no es muy adecuado para el tráfico web de alto volumen en mi humilde opinión. Sin embargo, es probable que la base de datos lo empantane antes del rendimiento de PHP, especialmente con el modelo de conexión de PHP (abre una nueva conexión para cada necesidad).

Tengo dos sugerencias para usted:

1. Dale SQL Relay un vistazo: http://sqlrelay.sourceforge.net/
2. la salida algunos aceleradores de PHP: http://en.wikipedia.org/wiki/List_of_PHP_accelerators

SQL Relay permite efectivamente PHP para aprovechar TKE de conexión agrupación y que proporcionará un rendimiento mucho mejor para una aplicación de base de datos de gran volumen.

Acceleradores de PHP (en general) almacenan en caché los códigos de operación PHP, lo que ahorra la sobrecarga de interpretar el código PHP con cada solicitud.

¡Buena suerte!

Answer 6

Escribir en un archivo es excelente, pero igual necesita sincronizar las escrituras de sus archivos, lo que lo coloca nuevamente en el punto de partida.

Sugerencias:

• sistema MQ, aunque a veces la base de datos puede ser más rápido,
• Sobre la idea de MQ: cola en memoria. Sé que dijiste PHP, pero he visto esto bastante bien en Java/Servlets,
• Dependiendo de lo que estés rastreando, puedes implementar un archivo estático en una CDN (la nube de la que hablaste) y agregue los registros de acceso en lote. Le permite alquilar la ampliación,
• INSERTAR RETRASADA buena idea, pero no sé cuál es el tamaño de la cola/retraso para eso en MySQL? (cualquiera)

Answer 7

Recomendaría también el almacenamiento en memoria caché.

Escriba sus datos en un Memcache y haga que un trabajo que se ejecuta periódicamente lo agregue y haga las inserciones.

Escribir en un archivo real probablemente REDUCIRÁ su rendimiento ya que el acceso al sistema de archivos es en su mayoría más lento que hablar con una base de datos que puede manejar el acceso de escritura de manera mucho más eficiente.

Answer 8

Dado que realiza un seguimiento de las impresiones, ¿qué ocurre si intenta guardar solo, por ejemplo, una de cada 5. Entonces, todavía tiene una muestra completamente "aleatoria" y puede aplicar los porcentajes al conjunto de datos más grande.