Almacenamiento de cientos de millones de registros

Almacenamiento de cientos de millones de registros

Mi empresa tomará posesión de un conjunto de datos que constará de aproximadamente entre 200 y 300 millones de registros. El material fuente es csv y ocupa aproximadamente 150 GB sin comprimir. Necesitaríamos realizar una carga inicial de los datos y luego actualizar aproximadamente el 1% de los registros diariamente. También nos encantaría poder mantener el historial de cada registro.

Actualmente usamos MySQL y parece que algunas personas están usando MySQL y PostgreSQL para bases de datos de este tamaño, pero no veo mucha información concreta sobre sus experiencias.

Definitivamente podríamos salirnos con la nuestra sin normalizar los datos y puedo imaginar distribuir la información entre muchos servidores. ¿Qué tal MongoDB o algún otro almacén de datos no tradicional?

¿Alguien tiene alguna idea sobre la viabilidad de este tipo de esfuerzo? Agradezco cualquier ayuda que puedas brindar.

Respuesta1

Mi experiencia en conjuntos de datos de ese tamaño se limita a MSSQL, pero definitivamente puede manejar datos de ese tamaño.

Mi primera preocupación es el tamaño de los datos. 300 millones de registros a 150 Gb son aproximadamente 500 Kb por fila, y esa es una fila grande. Una pelea muy, muy grande. Si puede normalizar a la tercera forma normal, esto podría ser de gran ayuda (suponiendo que haya datos que puedan normalizarse). Si no va a normalizar (y solo tiene una tabla única y masiva), entonces un motor que admita ISAM será más rápido que un RDBMS, por lo que MySQL en modo ISAM es la opción obvia sobre MSSQL (lo siento, no No tengo ninguna experiencia con Postgre o Mongo)

Dicho esto, MSSQL puede manejar una tabla de ese tamaño sin preocupaciones. Puede particionar los datos para que diferentes partes vivan en discos diferentes, por lo que podría mantener el 1% de los datos actualizados en un disco rápido y mantener el resto en un disco más lento si el presupuesto es una preocupación. Si su DBMS de elección admite esto, entonces podría ser una buena manera de hacerlo.

Solo como referencia, una vez administré una base de datos que tenía alrededor de 200 millones de filas en una sola tabla (pero la tabla tenía solo 20 Gb de tamaño) y con algunos tiempos de consulta de indexación inteligentes todavía se medían en milisegundos. Eso se normalizó a la tercera forma normal, por lo que también hubo muchos LOJ para recuperar datos asociados.

Respuesta2

La mayoría de las bases de datos pueden administrar fácilmente el almacenamiento de cantidades tan grandes; realmente depende de lo que desee hacer con los datos una vez que los haya cargado. ¿Es transaccional, por lo que será consultado y actualizado con frecuencia? ¿O es más para generar informes con información nueva que ingresa todos los días desde el sistema transaccional?

información relacionada