database - top - ¿Cómo es la compresión de datos más efectiva que la indexación para el rendimiento de búsqueda?
sql server slow performance (2)
Esto me hizo preguntarme si el impacto en el rendimiento de la E / S de disco es en realidad mucho más pesado de lo que pensaba.
Seguro. Si tiene que ir al disco, el golpe de rendimiento es muchos órdenes de magnitud mayor que la memoria. Esto me recuerda el clásico de Jim Gray, Distributed Computing Economics :
La economía informática está cambiando. Hoy existe una paridad de precios aproximada entre (1) acceso a una base de datos, (2) diez bytes de tráfico de red, (3) 100.000 instrucciones, (4) 10 bytes de almacenamiento en disco y (5) un megabyte de ancho de banda de disco. Esto tiene implicaciones sobre cómo se estructura la informática distribuida a escala de Internet: uno pone la informática lo más cerca posible de los datos para evitar el tráfico caro de la red.
La pregunta, entonces, es ¿cuántos datos tienes y cuánta memoria puedes permitirte?
Y si la base de datos se pone realmente grande, como en el caso de que nadie pueda permitirse esa cantidad de memoria, incluso en 20 años, necesita sistemas inteligentes de bases de datos distribuidas como BigTable o Hadoop de Google.
Para nuestra aplicación, mantenemos grandes cantidades de datos indexados por tres columnas enteras (fuente, tipo y hora). Cargar pedazos significativos de esos datos puede llevar algo de tiempo y hemos implementado varias medidas para reducir la cantidad de datos que se deben buscar y cargar para consultas más grandes, como el almacenamiento de granularidades más grandes para consultas que no requieren una alta resolución (tiempo -sabio).
Cuando buscamos datos en nuestros archivos de respaldo, donde los datos están almacenados en archivos de texto bzip, pero básicamente tienen la misma estructura, noté que es mucho más rápido desacoplar a stdout y canalizarlo a través de grep que desencajarlo en disco y grep Los archivos. De hecho, el untar-to-pipe fue incluso notablemente más rápido que el simple almacenamiento de los archivos descomprimidos (es decir, descontando el disco-a-disco).
Esto me hizo preguntarme si el impacto en el rendimiento de la E / S de disco es en realidad mucho más pesado de lo que pensaba. Así que aquí está mi pregunta:
¿Crees que poner los datos de múltiples filas en un campo blob (comprimido) de una sola fila y buscar filas individuales sobre la marcha durante la extracción podría ser más rápido que buscar las mismas filas a través del índice de la tabla?
Por ejemplo, en lugar de tener esta tabla
CREATE TABLE data ( `source` INT, `type` INT, `timestamp` INT, `value` DOUBLE);
Quisiera
CREATE TABLE quickdata ( `source` INT, `type` INT, `day` INT, `dayvalues` BLOB );
con aproximadamente 100-300 filas de datos para cada fila en datos rápidos y buscando las marcas de tiempo deseadas sobre la marcha durante la descompresión y la decodificación del campo blob.
¿Tiene sentido esto para ti? ¿Qué parámetros debo investigar? ¿Qué cuerdas se pueden unir? ¿Qué características de DB (cualquier DBMS) existen para lograr efectos similares?
Hice un descubrimiento similar cuando trabajo en Python en una base de datos: el costo de acceder a un disco es muy, muy alto. Resultó ser mucho más rápido (es decir, casi dos órdenes de magnitud) para solicitar una gran cantidad de datos e iterar a través de ella en Python de lo que era crear siete consultas que eran más estrechas. (Uno por día en cuestión para los datos)
Se apagó aún más cuando recibía datos por hora. 24x7 ¡muchas consultas!