database - timescale postgres
¿Qué ralentiza el crecimiento del rendimiento de la base de datos? (9)
Estoy creando una base de datos, y creando prototipos y comparando primero. Estoy utilizando H2, una base de datos java relacional, incrustable, comercialmente gratuita. Actualmente no estoy indexando en ninguna columna.
Después de que la base de datos creció a aproximadamente 5 GB, la velocidad de escritura por lotes se duplicó (la velocidad de escritura se redujo 2 veces la velocidad original). Escribía aproximadamente 25 filas por milisegundos con una base de datos nueva y limpia, y ahora, a 7 GB, escribo aproximadamente 7 filas / ms. Mis filas consisten en un short, un int, un float y un byte [5].
No sé mucho sobre las funciones internas de la base de datos o incluso cómo se programó H2. También me gustaría señalar que no estoy hablando mal de H2, ya que este es un problema con otros DBMS que he probado.
¿Qué factores pueden ralentizar la base de datos de esta manera si no hay gastos generales de indexación? ¿Tiene algo que ver principalmente con la estructura del sistema de archivos? A partir de mis resultados, asumo que la forma en que Windows XP y ntfs manejan los archivos hace que sea más lento agregar datos al final de un archivo a medida que crece el archivo.
Esto es muy probablemente causado por campos de ancho variable. No sé si H2 lo permite, pero en MySQL, debe crear su tabla con todos los campos de ancho fijo, y luego declararla explícitamente como una tabla de campo de ancho fijo. Esto permite a MySQL calcular exactamente a dónde debe ir en el archivo de base de datos para hacer la inserción. Si no está utilizando una tabla de ancho fijo, entonces tiene que leer toda la tabla para encontrar el final de la última fila.
Agregar datos (si se hace bien) es una operación O (n), donde n es la longitud de los datos que se escribirán. No depende de la longitud del archivo, hay operaciones de búsqueda para omitirlo fácilmente.
Para la mayoría de las bases de datos, anexar a un archivo de base de datos es definitivamente más lento que precrear el archivo y luego agregar filas. Vea si H2 soporta el pre-crecimiento del archivo.
Un factor que puede complicar las inserciones a medida que crece una base de datos es la cantidad de índices en la tabla y la profundidad de esos índices si son árboles B o similares. Simplemente hay más trabajo por hacer, y es posible que esté causando que los nodos de índice se dividan, o simplemente se haya movido de, digamos, un B-tree de 5 niveles a uno de 6 niveles (o más generalmente, de N a N + 1 niveles).
Otro factor podría ser el uso de espacio en disco, si está utilizando archivos cocinados (ese es el tipo normal para la mayoría de las personas la mayor parte del tiempo; algunos DBMS usan ''archivos sin procesar'' en Unix, pero es poco probable que su sistema integrado lo haga, y sabría si lo hizo porque tendría que decirle que lo haga), es posible que sus tablas más grandes estén ahora fragmentadas en el disco, lo que lleva a un peor rendimiento.
Si el problema estaba en el rendimiento SELECCIONAR, podría haber muchos otros factores que también afectan el rendimiento de su sistema.
Otra causa es si toda la base de datos se guarda en la memoria o si el sistema operativo tiene que hacer una gran cantidad de intercambio de disco para encontrar la ubicación para almacenar el registro.
Yo culparía a E / S, especialmente si está ejecutando su base de datos en una PC normal con un disco duro normal (me refiero a no estar en un servidor con discos duros súper rápidos, etc.).
Esto suena bien. El rendimiento de la base de datos generalmente disminuye significativamente ya que los datos ya no se pueden retener en la memoria y las operaciones se vuelven unidas al disco. Si está utilizando operaciones de inserción normales y desea una mejora significativa del rendimiento, le sugiero que utilice algún tipo de API de carga masiva si H2 lo admite (como Oracle sqlldr, Sybase BCP, Mysql ''load data infile''). Este tipo de API escribe datos directamente en el archivo de datos evitando muchos de los subsistemas de la base de datos.
Muchos motores de base de datos crean una clave primaria entera implícita para cada actualización, por lo que incluso si no ha declarado ningún índice, su tabla todavía está indexada. Esto puede ser un factor.
Usar H2 para archivos de datos 7G es una elección incorrecta desde el punto de vista tecnológico. Como dijiste, incrustable. Qué tipo de aplicación "incrustada" tiene, si necesita almacenar tanta información.
¿Estás realizando commits incrementales? Dado que H2 es una base de datos compatible con ACID, si no realiza confirmaciones incrementales, entonces hay algún tipo de registro de rehacer para que, en el caso de una falla accidental (por ejemplo, un corte de energía) o una reversión, las eliminaciones puedan revertirse.
En ese caso, su registro de rehacer puede estar haciendo crecer grandes y desbordantes búferes de memoria y necesitando escribir su registro de rehacer en el disco, así como también sus datos reales, añadiendo a su sobrecarga de E / S.