Mysql: Trabajando con 192 trillones de registros ... (Sí, 192 trillones)

Aquí está la pregunta ...

Considerando 192 trillones de registros, ¿cuáles deberían ser mis consideraciones?

Mi principal preocupación es la velocidad.

Aquí está la mesa ...

    CREATE TABLE `ref` (
  `id` INTEGER(13) AUTO_INCREMENT DEFAULT NOT NULL,
  `rel_id` INTEGER(13) NOT NULL,
  `p1` INTEGER(13) NOT NULL,
  `p2` INTEGER(13) DEFAULT NULL,
  `p3` INTEGER(13) DEFAULT NULL,
  `s` INTEGER(13) NOT NULL,
  `p4` INTEGER(13) DEFAULT NULL,
  `p5` INTEGER(13) DEFAULT NULL,
  `p6` INTEGER(13) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY (`s`),
  KEY (`rel_id`),
  KEY (`p3`),
  KEY (`p4`)
    );

Aquí están las consultas ...

SELECT id, s FROM ref WHERE red_id="$rel_id" AND p3="$p3" AND p4="$p4"

SELECT rel_id, p1, p2, p3, p4, p5, p6 FROM ref WHERE id="$id"

INSERT INTO rel (rel_id, p1, p2, p3, s, p4, p5, p6)
VALUES ("$rel_id", "$p1", "$p2", "$p3", "$s", "$p4", "$p5", "$p6")

Aquí hay algunas notas ...

• Los SELECT se realizarán con mucha más frecuencia que el INSERT. Sin embargo, ocasionalmente quiero agregar algunos cientos de registros a la vez.
• En cuanto a la carga, no habrá nada durante horas, entonces tal vez algunos miles de consultas a la vez.
• No creo que pueda normalizar más (necesito los valores de p en una combinación)
• La base de datos en su conjunto es muy relacional.
• Esta será la mesa más grande con diferencia (la siguiente más grande es de aproximadamente 900k)

ACTUALIZACIÓN (08/11/2010)

Curiosamente, me dieron una segunda opción ...

En lugar de 192 billones, podría almacenar 2.6 * 10 ^ 16 (15 ceros, lo que significa 26 billones) ...

Pero en esta segunda opción solo necesitaría almacenar un bigint (18) como índice en una tabla. Eso es todo, solo una columna. Así que solo estaría comprobando la existencia de un valor. Ocasionalmente agrega registros, nunca los elimina.

Eso me hace pensar que debe haber una solución mejor que mysql para simplemente almacenar números ...

Dada esta segunda opción, ¿debería tomarla o seguir con la primera ...

[editar] Acabo de recibir noticias de algunas pruebas que se han realizado: 100 millones de filas con esta configuración devuelven la consulta en 0.0004 segundos [/ editar]

La estimación de pQd de 7 PB parece razonable, y esa es una gran cantidad de datos para un RDBMS. No estoy seguro de haber oído hablar de alguien haciendo 7PB con cualquier sistema de disco compartido, y mucho menos MySQL. Consultar este volumen de datos con cualquier sistema de disco compartido será inusualmente lento. El hardware SAN más rápido alcanza un máximo de 20 GB / seg incluso cuando está sintonizado para grandes consultas de transmisión. Si puede permitirse el hardware SAN de esta especificación, puede usar algo que se adapte mejor al trabajo que MySQL.

De hecho, estoy luchando por concebir un escenario en el que pueda tener un presupuesto para un subsistema de disco de esta especificación, pero no para una mejor plataforma DBMS. Incluso utilizando discos de 600GB (la unidad de '' empresa '' más grande de 15K actualmente en el mercado) tiene alrededor de 12,000 unidades de disco físico para almacenar 7PB. Los discos SATA serían más baratos (y con discos de 2TB necesitarías alrededor de 1/3 del número), pero un poco más lento.

Una SAN de esta especificación de un proveedor importante como EMC o Hitachi costaría muchos millones de dólares. La última vez que trabajé con equipos SAN de un proveedor importante, el costo de transferencia de espacio en un IBM DS8000 fue de más de £ 10k / TB, sin incluir ninguna asignación de capital para los controladores.

Realmente necesita un sistema de nada compartido como Teradata o Netezza para esta cantidad de datos. Es posible que particionar una base de datos MySQL, pero recomendaría una plataforma VLDB especialmente diseñada. Un sistema de nada compartido también le permite usar un disco de conexión directa mucho más barato en los nodos: eche un vistazo a la plataforma Sun X4550 (thumper) para una posibilidad.

También debe pensar en sus requisitos de rendimiento.

• ¿Qué es un tiempo de ejecución aceptable para una consulta?
• ¿Con qué frecuencia consultará su conjunto de datos?
• ¿Se pueden resolver la mayoría de las consultas utilizando un índice (es decir, van a ver una pequeña fracción, digamos: menos del 1%, de los datos) o necesitan hacer un análisis completo de la tabla?
• ¿Qué tan rápido se cargarán los datos en la base de datos?
• ¿Sus consultas necesitan datos actualizados o podría vivir con una tabla de informes actualizada periódicamente?

En resumen, el argumento más fuerte contra MySQL es que estaría haciendo backflips para obtener un rendimiento de consulta decente sobre 7PB de datos, si es posible. Este volumen de datos realmente lo coloca en un territorio de nada compartido para hacer algo que lo consultará razonablemente rápido, y probablemente necesitará una plataforma diseñada desde el principio para una operación de nada compartido. Los discos por sí solos reducirán el costo de cualquier plataforma DBMS razonable.

Nota: Si divide sus bases de datos operativas y de informes, no necesariamente tiene que usar la misma plataforma DBMS para ambas. Obtener inserciones rápidas e informes de menos de un segundo de la misma tabla de 7 PB será un desafío técnico al menos.

Debido a sus comentarios de que puede vivir con cierta latencia en los informes, puede considerar sistemas de captura e informes separados, y es posible que no necesite mantener todos los 7 PB de datos en su sistema de captura operacional. Considere una plataforma operativa como Oracle (MySQL puede hacer esto con InnoDB) para la captura de datos (nuevamente, el costo de los discos solo reducirá el costo del DBMS a menos que tenga muchos usuarios) y una plataforma VLDB como Teradata, Sybase IQ, RedBrick, Netezza (nota: hardware propietario) o Greenplum para informes

fragmentarlo En este tamaño, tener una instancia grande es un suicidio: piense en posibles restauraciones de copias de seguridad, daños en el espacio de tablas, agregando nuevas columnas o cualquier otro proceso de 'mantenimiento de la casa'; todo eso es imposible de hacer en un tiempo razonable a esta escala.

cálculos simples del reverso de la envolvente: suponiendo enteros de 32 bits para todas las columnas, excepto la identificación de 64 bits; sin índices incluidos:

8 * 4B + 8B = 40B por fila [y esto es muy optimista]

192 trillones de filas 40B cada uno nos da casi 7 PB

tal vez pueda repensar todo el asunto, resumir información para informes rápidos y almacenar registros comprimidos para intervalos de tiempo determinados cuando alguien necesita profundizar en detalles más profundos.

preguntas para responder:

• ¿Cuál es el tiempo de inactividad aceptable en caso de que el sistema se bloquee / reinicie?
• cuál es el tiempo de inactividad accesible cuando necesita recuperar una copia de seguridad o sacar el servidor de producción para el mantenimiento planificado.
• ¿con qué frecuencia y dónde desea hacer una copia de seguridad?

enlaces aleatorios - velocidad de las inserciones:

• http://highscalability.com/blog/2010/5/20/strategy-scale-writes-to-734-million-records-per-day-using-t.html
• https://stackoverflow.com/questions/654594/

Llama a Percona . No pase "Ir". No recoja $ 200.

Puede haber otra forma, en lugar de almacenar miles de millones de números si todo lo que quiere hacer es ver si están en el conjunto. Los filtros de Bloom son un método probabilístico, mediante hashing de múltiples maneras. Además, los falsos positivos son posibles, pero los falsos negativos no lo son. (Entonces, podría decir que el número está en el conjunto, y estar equivocado, pero no dirá que no está allí, si realmente estaba). También existe el problema de la gran cantidad de artículos para almacenar, pero al menos podría reducir un poco el tamaño del conjunto de datos de trabajo.

Editar: en realidad, si es solo la existencia o no de un "registro" en la ubicación X en un rango de enteros, podría eliminar el almacén de datos y simplemente usar el mapa de bits ... Entonces, aproximadamente 10 máquinas con 100 TB de espacio en disco (por lo que tiene 10 copias de su mapa de bits para el rendimiento y la copia de seguridad) y si hiciera 128 GB de RAM por servidor, podría ajustar un índice de grupo de bloques de nivel superior de alta resolución en la memoria para hacer una primera comprobación antes de golpear el disco para el bit X de 26 Quadrillion .

Iría por la opción # 2 si tomas:

375 máquinas con 64TB (32 unidades de 2TB) cada una (en realidad 400 máquinas para fallas) luego simplemente mapean los registros en ZVOL que son 2TB cada uno. Luego, en uno o más servidores de índice, almacene en una matriz Judy o matriz critbit o simplemente en un mapa de bits simple, una asignación de si ha agregado un registro a esa 1 de 26 ubicaciones de Quadrillion. El índice estaría entre 50 y 100TB e incluso podría tener un índice de segundo nivel que indicara si hay registros escritos en un determinado bloque de direcciones de 64k que cabría en menos de 64 GB de RAM y proporcionaría un nivel rápido de verificación inicial si cierto "barrio" estaba vacío o no.

Luego, para leer ese registro, primero verificará si hay un registro para buscar mirando el índice. Si lo hay, vaya a la máquina # (X) / ZOL # (Y) en esa máquina / registre la ubicación # (Z) dentro de ese blob de 2TB basado en el cálculo de índice simple. Las búsquedas de registros individuales serían extremadamente rápidas y podría probar cargar algunas partes del almacén de datos en diferentes bases de datos (mientras usa el almacén de datos para un trabajo real) y realizar pruebas de rendimiento para ver si son capaces de admitir toda su base de datos, o no, solo usa el almacén de datos de esa manera.

Un ZOL es una cosa de ZFS que podría pensarse en un archivo disperso en otros sistemas de archivos, por lo que se aplicarían cosas similares. O simplemente puede indexar a un cierto número de bytes en un disco, pero esto se vuelve complicado si los discos son de diferentes tamaños si no limita el número de bytes utilizados por disco en un nivel que funcione para todos los discos, es decir, 1.75TB por disco de 2TB . O cree metadispositivos de tamaño fijo, etc.

Además de ajustar sus parámetros de base de datos como locos (use mysqltuner para ayudar) para tratar de mantener sus SELECT almacenados en caché tanto como sea humanamente posible, una cosa que podría investigar es INICIAR TRANSACCIÓN / COMMIT (suponiendo InnoDB) al insertar sus cientos de registros para evitar fila por fila se bloquea por encima y reduce el tiempo de inserción por un factor enorme. También crearía la tabla como MyISAM e InnoDB y realizaría pruebas en ella para ver cuál es realmente más rápido una vez que apriete el almacenamiento en caché; no siempre es que MyISAM sea más rápido para las lecturas.

http://www.mysqlperformanceblog.com/2007/01/08/innodb-vs-myisam-vs-falcon-benchmarks-part-1/

Durante la prueba, la cantidad de subprocesos concurrentes también debe variar de arriba a abajo hasta que encuentre el punto óptimo para la cantidad de RAM que puede permitirse en el servidor para dedicar a ajustar las cachés; es posible que, si bien puede admitir más subprocesos por las matemáticas, el DB en sí mismo puede funcionar peor si el recuento de subprocesos es demasiado alto.

Además, si usa MyISAM y / o InnoDB archivo por tabla, podría investigar la creación de un punto de montaje de sistema de archivos diferente para / var / lib / mysql que se ajustó a un tamaño de bloque más pequeño y ajustó los parámetros de tipo fs, es decir, ext3 / ext4 / resiserfs puede usar data = writeback para el diario y deshabilitar la actualización de los tiempos de acceso en el sistema de archivos para la velocidad de E / S.

Para la segunda opción, ¿cuántos números se pueden colocar realmente?

Si solo habrá uno en mil, o 10K, 100K, etc., el almacenamiento de rangos de números usados ​​(o no usados) podría ahorrar billones de entradas. por ejemplo: almacenamiento ('libre', 0,100000), ('tomado', 100000,100003), ('libre', 100004,584234): división de filas en dos o tres filas según sea necesario e indexación en el primer número, buscando x <= {aguja} para ver si el rango que contiene el número buscado es tomado o libre.

Es posible que ni siquiera necesite ambos estados. Simplemente almacene el estado que sea menos probable.