database - script - ¿Opción de base de datos para el gran volumen de datos?
pasos para crear una base de datos en sql (6)
Estoy a punto de comenzar un nuevo proyecto que debería tener una base de datos bastante grande.
El número de tablas no será grande (<15), la mayoría de los datos (99%) se incluirán en una tabla grande, que es casi solo de inserción / lectura (sin actualizaciones).
La cantidad estimada de datos en esa tabla aumentará a 500,000 registros por día , y deberíamos mantener al menos 1 año de ellos para poder hacer varios informes.
Es necesario que haya una base de datos replicada (de solo lectura) como copia de seguridad / conmutación por error, y tal vez para descargar los informes en las horas punta.
No tengo experiencia de primera mano con esas grandes bases de datos, así que les pregunto a las que tienen qué base de datos es la mejor opción en esta situación. Sé que Oracle es la apuesta segura, pero estoy más interesado si alguien tiene experiencia con Postgresql o Mysql con una configuración similar.
¿Tiene una copia de " The Data Warehouse Toolkit "?
La sugerencia es hacer lo siguiente.
Separe los valores de los hechos (medibles, numéricos) de las dimensiones que califican u organizan esos hechos. Una gran mesa no es realmente la mejor idea. Es una tabla de hechos que domina el diseño, más una serie de tablas de dimensiones pequeñas para permitir "cortar y cortar" los hechos.
Mantenga los hechos en archivos planos simples hasta que desee realizar informes de estilo SQL. No cree ni realice una copia de seguridad de una base de datos. Crear y respaldar archivos; cargue una base de datos solo para los informes que debe hacer desde SQL.
Donde sea posible, crear un resumen o datos adicionales para el análisis. En algunos casos, es posible que deba cargar todo en una base de datos. Si sus archivos reflejan el diseño de su tabla, todas las bases de datos tienen herramientas de carga masiva que pueden llenar e indexar las tablas SQL de los archivos.
Algunos puntos interesantes con respecto a Google BigTable en que hay ...
Bigtable Vs DBMS
- Tasa de consulta rápida
- Sin combinaciones, sin soporte de SQL , base de datos orientada a columnas
- Utiliza un Bigtable en lugar de tener muchas tablas normalizadas.
- Ni siquiera está en 1NF en una vista tradicional
- Diseñado para admitir el campo de marca de tiempo de las consultas históricas => ¿qué aspecto tuvo esta página web ayer?
- La compresión de datos es más fácil, las filas son escasas
Resalté las Uniones y Sin Soporte SQL como mencionaste, necesitarás ejecutar una serie de informes. No sé cuánto (si alguno) no tiene la capacidad de hacer esto tendrá en sus informes de ejecución si se utiliza este.
He usado PostgreSQL en un entorno donde estamos viendo 100K-2M de nuevas filas por día, la mayoría agregadas a una sola tabla. Sin embargo, esas filas tienden a reducirse a muestras y luego a eliminarse en unos pocos días, por lo que no puedo hablar sobre el rendimiento a largo plazo con más de ~ 100 millones de filas.
Descubrí que el rendimiento del inserto es bastante razonable, especialmente si utiliza la COPIA a granel. El rendimiento de las consultas está bien, aunque las elecciones que hace el planificador a veces me confunden; Particularmente cuando se hace JOINs / EXISTS. Nuestra base de datos requiere un mantenimiento bastante regular (VACÍO / ANÁLISIS) para que funcione sin problemas. Podría evitar algo de esto optimizando con más cuidado el vacío automático y otras configuraciones, y no es un gran problema si no hace muchos BORRAR. En general, hay algunas áreas donde creo que es más difícil de configurar y mantener de lo que debería ser.
No he usado Oracle y MySQL solo para conjuntos de datos pequeños, por lo que no puedo comparar el rendimiento. Pero PostgreSQL funciona bien para grandes conjuntos de datos.
La base de datos BigTable de Google y Hadoop son dos motores de base de datos que pueden manejar una gran cantidad de datos.
La cantidad de datos (200 millones de registros por año) no es realmente grande y debería ir con cualquier motor de base de datos estándar.
El caso es aún más fácil si no necesita informes en vivo sobre él. Me gustaría reflejar y precargar datos en algún otro servidor, por ejemplo, en lotes diarios. Como sugirió S.Lott, le gustaría leer sobre el almacenamiento de datos.
Usamos Firebird para una base de datos realmente enorme (manteniendo los datos por más de 30 años) y se adapta muy bien.
Lo mejor de todo es que tiene propiedades para configurar, pero a diferencia de Oracle, lo instala y funciona muy bien sin la necesidad de comenzar a configurar antes de poder usarlo.