sql - tabla - tamaño maximo de una base de datos en oracle

Almacenamiento eficiente de 7.300.000.000 filas. (7)

Es posible que desee ver estas preguntas:

Clave principal grande: 1+ mil millones de filas MySQL + InnoDB?

Personalmente, también pienso en calcular el ancho de su fila para darle una idea de qué tan grande será su mesa (según la nota de partición en el primer enlace).

HTH.

¿Cómo abordaría el siguiente problema de almacenamiento y recuperación?

Se agregarán aproximadamente 2.000.000 filas cada día (365 días / año) con la siguiente información por fila:

ID (identificador único de fila)
entity_id (toma valores entre 1 y 2.000.000 inclusive)
date_id (incrementado con uno cada día; tomará valores entre 1 y 3.650 (diez años: 1 * 365 * 10))
value_1 (toma valores entre 1 y 1,000,000 inclusive)
value_2 (toma valores entre 1 y 1,000,000 inclusive)

entity_id combinado con date_id es único. Por lo tanto, como máximo se puede agregar una fila por entidad y fecha a la tabla. La base de datos debe poder contener datos diarios de 10 años (7.300.000.000 de filas (3.650 * 2.000.000)).

Lo que se describe arriba son los patrones de escritura. El patrón de lectura es simple: todas las consultas se realizarán en un entity_id específico. Es decir, recuperar todas las filas que describen entity_id = 12345.

No se necesita soporte transaccional, pero la solución de almacenamiento debe ser de código abierto. Idealmente, me gustaría usar MySQL, pero estoy abierto a sugerencias.

Ahora, ¿cómo abordaría el problema descrito?

Actualización: Me pidieron que explicara los patrones de lectura y escritura. Las escrituras en la tabla se realizarán en un lote por día, donde las nuevas entradas de 2M se agregarán de una sola vez. Las lecturas se harán continuamente con una lectura cada segundo.

Si desea manejar datos enormes con millones de filas, puede considerarse similar a la base de datos de series de tiempo que registra el tiempo y guarda los datos en la base de datos. Algunas de las formas de almacenar los datos son utilizando InfluxDB y MongoDB.

Su descripción de los patrones de lectura no es suficiente. Deberá describir qué cantidades de datos se recuperarán, con qué frecuencia y cuánta desviación habrá en las consultas.

Esto le permitirá considerar la compresión en algunas de las columnas.

También considere archivar y particionar.

Tu aplicación parece tener las mismas características que la mía. Escribí un motor de almacenamiento personalizado MySQL para resolver el problema de manera eficiente. Se describe aqui

Imagine que sus datos se distribuyen en el disco como una matriz de 2 M de entradas de longitud fija (una por entidad), cada una de las cuales contiene 3650 filas (una por día) de 20 bytes (la fila de una entidad por día).

Tu patrón de lectura lee una entidad. Es contiguo en el disco, por lo que toma 1 búsqueda (aproximadamente 8mllisecs) y lee 3650x20 = aproximadamente 80K a unos 100MB / seg ... por lo que se realiza en una fracción de segundo, cumpliendo fácilmente con su lectura de 1 consulta por segundo modelo.

La actualización debe escribir 20 bytes en 2M lugares diferentes en el disco. En el caso más simple, esto requeriría 2M de búsqueda, cada una de las cuales toma aproximadamente 8millisecs, por lo que tomaría 2M * 8ms = 4.5 horas. Si distribuye los datos en 4 discos "raid0", podría llevar 1.125 horas.

Sin embargo, los lugares son sólo 80K aparte. En el sentido, significa que hay 200 lugares dentro de un bloque de 16 MB (tamaño de caché de disco típico), por lo que podría funcionar hasta 200 veces más rápido. (1 minuto) La realidad está en algún lugar entre los dos.

Mi motor de almacenamiento opera con ese tipo de filosofía, aunque es un propósito un poco más general que una matriz de longitud fija.

Podrías codificar exactamente lo que he descrito. Poner el código en un motor de almacenamiento conectable de MySQL significa que puede usar MySQL para consultar los datos con varios generadores de informes, etc.

Por cierto, podría eliminar la fecha y la identificación de la entidad de la fila almacenada (porque son los índices de la matriz) y puede ser la identificación única; si no la necesita realmente ya que (identificación de la entidad, fecha) es única, y almacenar los 2 valores como 3 bytes int. Entonces su fila almacenada es de 6 bytes, y tiene 700 actualizaciones por 16M y, por lo tanto, inserciones más rápidas y un archivo más pequeño.

Editar Comparar con archivos planos

Me doy cuenta de que los comentarios generales favorecen los archivos planos. No olvide que los directorios son solo índices implementados por el sistema de archivos y generalmente están optimizados para un número relativamente pequeño de elementos relativamente grandes. El acceso a los archivos generalmente se optimiza de modo que se espera que se abra un número relativamente pequeño de archivos, y tiene una sobrecarga relativamente alta para abrir y cerrar, y para cada archivo que está abierto. Todos esos "relativamente" son relativos al uso típico de una base de datos.

El uso de nombres de sistemas de archivos como un índice para una entidad-Id que considero que es un número entero no disperso de 1 a 2Million es contraintuitivo. En una programación, usaría una matriz, no una tabla hash, por ejemplo, e inevitablemente incurrirá en una gran cantidad de gastos generales para una vía de acceso costosa que podría ser simplemente una operación independiente de la matriz.

Por lo tanto, si usa archivos sin formato, ¿por qué no usar solo un archivo sin formato e indexarlo?

Editar en el rendimiento

El rendimiento de esta aplicación va a estar dominado por los tiempos de búsqueda del disco. Los cálculos que hice anteriormente determinan lo mejor que puedes hacer (aunque puedes hacer que INSERTAR sea más rápido al ralentizar SELECCIONAR, no puedes hacer que ambos sean mejores). No importa si usa una base de datos, archivos planos o un archivo plano, excepto que puede agregar más búsquedas que realmente no necesita y ralentizarlas aún más. Por ejemplo, la indexación (ya sea el índice del sistema de archivos o el índice de la base de datos) provoca E / S adicionales en comparación con "una búsqueda de matrices", y esto lo hará más lento.

Edición sobre medidas de referencia

Tengo una tabla que se parece mucho a la suya (o casi exactamente a una de sus particiones). Fueron 64K entidades, no 2M (1/32 de las suyas) y 2788 "días". La tabla se creó en el mismo orden de INSERTAR que será el suyo y tiene el mismo índice (entity_id, día). Un SELECT en una entidad demora 20.3 segundos en inspeccionar los 2788 días, lo que representa alrededor de 130 búsquedas por segundo como se esperaba (en discos de tiempo de búsqueda promedio de 8 milisegundos). El tiempo de SELECCIÓN será proporcional al número de días, y no dependerá mucho del número de entidades. (Será más rápido en los discos con tiempos de búsqueda más rápidos. Estoy usando un par de SATA2 en RAID0, pero eso no hace mucha diferencia).

Si reordena la tabla en orden de entidad ALTER TABLE x ORDER BY (ENTITY, DAY) Luego, el mismo SELECT toma 198 milisegundos (porque está leyendo la entidad de orden en un solo acceso de disco). Sin embargo, la operación ALTER TABLE tardó 13,98 DÍAS en completarse (para 182M filas).

Hay algunas otras cosas que las mediciones le dicen 1. Su archivo de índice será tan grande como su archivo de datos. Es 3GB para esta tabla de muestra. Eso significa (en mi sistema) todo el índice a velocidades de disco, no de memoria.

2. Su tasa de INSERCIÓN disminuirá logarítmicamente. El INSERT en el archivo de datos es lineal, pero la inserción de la clave en el índice es log. En los registros de 180M obtuve 153 INSERTOS por segundo, lo que también está muy cerca de la tasa de búsqueda. Muestra que MySQL está actualizando un bloque de índice de hoja para casi todos los INSERT (como es de esperar, ya que está indexado en la entidad pero insertado en orden diario). Por lo tanto, está considerando 2M / 153 segundos = 3.6 horas para realizar su inserción diaria de filas de 2M. (Dividido por cualquier efecto que pueda obtener por partición entre sistemas o discos).

Tuve un problema similar (aunque con una escala mucho mayor, sobre su uso anual todos los días)

El uso de una mesa grande hizo que me detuviera bruscamente: puedes tirar unos meses, pero supongo que finalmente lo dividirás.

No se olvide de indexar la tabla o, de lo contrario, estará jugando con un pequeño goteo de datos en cada consulta; Ah, y si quieres hacer consultas en masa, usa archivos planos

"Ahora, ¿cómo abordaría el problema descrito?"

Con archivos planos simples.

Este es el por qué

"todas las consultas se realizarán en un ID_entidad específico. Es decir, recuperar todas las filas que describan ID_entidad = 12345."

Tienes 2.000.000 entidades. Partición basada en número de entidad:

level1= entity/10000 level2= (entity/100)%100 level3= entity%100

Cada archivo de datos es level1/level2/level3/batch_of_data

Luego puede leer todos los archivos en una parte determinada del directorio para devolver muestras para su procesamiento.

Si alguien quiere una base de datos relacional, entonces cargue los archivos para un entity_id dado en una base de datos para su uso.

Editar en los números del día.

La regla de unicidad de date_id / entity_id no es algo que deba manejarse. Es (a) impuesto de forma trivial sobre los nombres de los archivos y (b) irrelevante para la consulta.
El date_id "rollover" no significa nada; no hay consulta, por lo que no es necesario cambiar el nombre de nada. El date_id simplemente debe crecer sin límite desde la fecha de la época. Si desea purgar datos antiguos, elimine los archivos antiguos.

Como ninguna consulta se basa en date_id , nunca se necesita hacer nada con ella. Puede ser el nombre del archivo para todo lo que importa.

Para incluir el date_id en el conjunto de resultados, escríbalo en el archivo con los otros cuatro atributos que están en cada fila del archivo.

Editar en abrir / cerrar

Para escribir, tienes que dejar los archivos abiertos. Realiza descargas periódicas (o cierra / vuelve a abrir) para garantizar que las cosas realmente se vayan al disco.

Tienes dos opciones para la arquitectura de tu escritor.

Tenga un solo proceso de "escritor" que consolide los datos de las distintas fuentes. Esto es útil si las consultas son relativamente frecuentes. Usted paga por la fusión de los datos en el tiempo de escritura.
Tener varios archivos abiertos al mismo tiempo para escribir. Al realizar consultas, fusione estos archivos en un solo resultado. Esto es útil si las consultas son relativamente raras. Usted paga por la fusión de los datos en el momento de la consulta.

Utilice la partitioning . Con tu patrón de lectura, querrías particionar por hash entity_id .