Arquitectura de base de datos para millones de nuevas filas por día

Question

Necesito implementar un servicio analítico web desarrollado a medida para una gran cantidad de sitios web. Las entidades claves aquí son:

• sitio web
• Visitante

cada visitante único tendrá que tienen una sola fila en la base de datos con información como página de destino, la hora del día, sistema operativo, navegador, referente , IP, etc.

necesitaré hacer consultas agregadas en esta base de datos como 'contar todos los visitantes que tienen Windows como sistema operativo y venían de Bing.com'

Tengo cientos de sitios web para rastrear y el número de visitantes para esos sitios web varía de unos pocos cientos por día a pocos millones por día. En total, espero que esta base de datos crezca en aproximadamente un millón de filas por día.

Mis preguntas son:

1) ¿Es una buena base de datos MySQL para este fin?

2) ¿Qué podría ser una buena arquitectura? Estoy pensando en crear una nueva tabla para cada sitio web. O tal vez comenzar con una sola tabla y luego generar una nueva tabla (a diario) si el número de filas en una tabla existente supera el millón (es mi suposición correcta). Mi única preocupación es que si una tabla crece demasiado, las consultas SQL pueden ser dramáticamente lentas. Entonces, ¿cuál es la cantidad máxima de filas que debo almacenar por mesa? Además, hay un límite en la cantidad de tablas que MySQL puede manejar.

3) ¿Es aconsejable hacer consultas agregadas sobre millones de filas? Estoy listo para esperar unos segundos para obtener resultados de tales consultas. ¿Es una buena práctica o hay alguna otra manera de hacer consultas agregadas?

En pocas palabras, Estoy tratando de diseñar un tipo de configuración de depósito de datos a gran escala que será escribir pesado. Si conoce algún estudio de caso o informe publicados, ¡será genial!

Answer 1

Algunas sugerencias en una base de datos de manera independiente.

El más simple racional es distinguir entre tablas intensivas de lectura y de escritura intensiva. Probablemente sea una buena idea crear dos esquemas paralelos diarios/semanales y un esquema de historial. La partición se puede hacer de manera apropiada. Uno puede pensar en un trabajo por lotes para actualizar el esquema del historial con datos del esquema diario/semanal. En el esquema de historial nuevamente, puede crear tablas de datos separadas por sitio web (según el volumen de datos).

Si todo lo que está interesado es en la agregación estadísticas sola (que puede no ser verdad). Es una buena idea tener tablas de resumen (mensuales, diarias) en las que el resumen se almacene como visitantes únicos totales, visitantes repetidos, etc .; y estas tablas resumen se actualizarán al final del día. Esto permite el cálculo instantáneo de estadísticas sin esperar a que se actualice la base de datos de historial.

Answer 2

Si habla volúmenes de datos más grandes, mire MySQL partitioning. Para estas tablas, una partición por datos/tiempo sin duda ayudaría al rendimiento. Hay un artículo decente sobre la partición here.

Mire en la creación de dos bases de datos separadas: una para todos los datos en bruto para las escrituras con una indexación mínima; un segundo para informar usando los valores agregados; ya sea con un proceso por lotes para actualizar la base de datos de informes desde la base de datos de datos en bruto, o use la replicación para hacer eso por usted.

EDITAR

Si quieres ser realmente inteligente con sus informes de agregación, crear un conjunto de tablas de agregación ("hoy", "semana hasta la fecha", "mes hasta la fecha", "por año") Agregado de datos brutos a "hoy" ya sea diariamente o en "tiempo real"; agregado de "por día" a "semana a fecha" en una base nocturna; de "semanas hasta la fecha" a "meses hasta la fecha" sobre una base semanal, etc. Cuando la ejecución de consultas, join (UNION) las tablas apropiadas para los periodos de tiempo que le interesa.

editar # 2

En lugar de una tabla por cliente, trabajamos con un esquema de base de datos por cliente. Dependiendo del tamaño del cliente, podríamos tener varios esquemas en una única instancia de base de datos, o una instancia de base de datos dedicada por cliente. Usamos esquemas separados para la recopilación de datos en bruto, y para la agregación/informe para cada cliente. Ejecutamos múltiples servidores de bases de datos, restringiendo cada servidor a una sola instancia de base de datos. Para lograr resiliencia, las bases de datos se replican en varios servidores y se equilibran en la carga para un mejor rendimiento.

Answer 3

Realmente debe probar que su manera de proceder simulará los entornos lo más cerca posible del entorno en vivo, con datos "reales falsos" (formato correcto & de longitud). Consultas de referencia y variantes de estructuras de tablas. Como parece que conoce MySQL, comience allí. No debería demorar tanto en configurar algunas secuencias de comandos que bombardean su base de datos con consultas. Estudiando los resultados de su base de datos con su tipo de datos le ayudará a darse cuenta de dónde ocurrirán los cuellos de botella.

No es una solución, pero es de esperar un poco de ayuda en el camino, buena suerte :)

Answer 4

Definitivamente debe considerar dividir los datos por el sitio a través de bases de datos o esquemas - esto no sólo hace que sea mucho más fácil de copia de seguridad, la caída de un etc sitio/cliente individual pero también elimina gran parte de la molestia de asegurarse de que ningún cliente pueda ver los datos de otros clientes por accidente o pobre codificación, etc. También significa que es más fácil tomar decisiones sobre la división, más allá de la tabulación del nivel de tabla de databae para hora o cliente, etc.

También dijiste que el volumen de datos es de 1 millón de filas por día (eso no es particularmente pesado y no requiere un gran poder de sonido para registrar/store, ni de hecho para informar (aunque si estuvieras generando 500 informes a medianoche, podrías hacer un logjam). Sin embargo, también dijiste que algunos sitios tenían 1 millón de visitantes diariamente, ¿quizás crees que es demasiado conservador?

Por último, no dijo si desea informar en tiempo real a la chartbeat/opentracker etc. o una actualización cíclica como Google Analytics: esto tendrá una gran influencia en el modelo de almacenamiento desde el primer día.

M