Estructura de la base de datos & amp; Disco duro busca la confusión del tiempo

Question

alguien podría ayudarme a entender cómo funciona la búsqueda de disco duro.

Tengo un pequeño archivo de base de datos binario cuyo rendimiento de lectura es absolutamente esencial. Si necesito omitir algunos bytes en el archivo, ¿es más rápido usar seek () o leer () y luego descartar los datos no deseados?

Si el tiempo promedio de búsqueda de un disco duro es de 10 ms y la velocidad de lectura es de 300 MB / s, calculé que es más rápido leer () que buscar () con un valor inferior a 3 MB. ¿Es verdad? ¿Hay una sobrecarga al realizar una nueva búsqueda, que leer una secuencia existente no tiene?

¿Cuál crees que sea una estructura de archivos más adecuada para un índice?

Entry1:Value:PointerIntoToData
Entry2:Value:PointerIntoToData
Entry3:Value:PointerIntoToData
Data, Data, Data

Or

Entry1:Value:Data
Entry2:Value:Data
Entry3:Value:Data

Al leer una entrada, si el valor no es correcto, se ignorará. Entonces, cuando la transmisión del archivo es más rápido: 1. Cuando no se requiere una entrada, use seek () para omitirla 2. Cuando no se necesita una entrada, léala y luego descarte los datos. 3. o utilice la primera estructura, cuando se requiere una entrada, busque () en un repositorio de datos al final.

La entrada es de 4 bytes, el valor es de 8 bytes & amp; los datos son 12KB

Saludos

Answer 1

Todo lo que hace la llamada al sistema seek es cambiar una posición en el archivo donde estará la próxima lectura. No mueve el cabezal de accionamiento. Los cabezales de la unidad se mueven cuando los datos se leen o escriben y no tiene control directo sobre qué sistema operativo hará a continuación.

La lectura de muchos datos que no va a necesitar tiene un impacto porque todos los datos de lectura necesitan espacio en los buffers del sistema operativo y hacen que los datos más antiguos se descarten. Por lo tanto, el uso de la búsqueda sobre archivos grandes afectará menos la memoria caché del sistema de archivos.

---

Todo lo que escribo debajo asume que no puede guardar toda la base de datos en la memoria. Si puedes, hazlo. Lea todo e intente agregar datos nuevos y modificados al final del archivo. No se preocupe por el espacio desperdiciado, solo haga un poco de compactación de vez en cuando.

---

Si su base de datos es demasiado grande:

Los datos se leen y se escriben en la unidad física en bloques (o páginas). Del mismo modo la unidad básica de disco IO en su sistema operativo es la página. Si el sistema operativo almacena en caché datos del disco, también está en páginas enteras. Por lo tanto, pensar si necesita avanzar unos pocos bytes utilizando buscar o leer tiene poco sentido. Si desea hacerlo más rápido, debe tener en cuenta cómo funciona realmente el IO de disco.

Primero, ya mencionado por nobugz, localidad de referencia. Si los datos que utiliza en cada operación se encuentran juntos en un archivo, su sistema operativo necesitará leer o escribir menos páginas. Por otro lado, si distribuye sus datos, será necesario leer o escribir muchas páginas a la vez, lo que siempre será lento.

En cuanto a la estructura de datos para el índice. Por lo general, se organizan como B-trees . Es una estructura de datos hecha especialmente para la búsqueda efectiva de grandes cantidades de datos almacenados en la memoria con lecturas y escrituras paginadas.

Y ambas estrategias para organizar datos se utilizan en la práctica. Por ejemplo, MS SQL Server almacena por defecto los datos de la primera manera: los datos se almacenan por separado y los índices solo contienen datos de columnas indexadas y direcciones físicas de las filas de datos en los archivos. Pero si define un índice agrupado, todos los datos se almacenarán dentro de este índice. Todos los demás índices apuntarán a los datos a través de la clave de índice agrupado en lugar de la dirección física. La primera forma es más simple, pero la otra puede ser mucho más efectiva si a menudo realiza escaneos de rangos de datos basados ??en índices agrupados.

Answer 2

Cómo " absolutamente esencial " es buscar acceso? ¿Ya probaste tu aplicación con una solución no óptima? Durante esas pruebas, ¿realizó una evaluación comparativa para determinar dónde están los cuellos de botella reales ? Si no lo has hecho, te sorprenderán los resultados.

A continuación, pruebe diferentes métodos y compare los tiempos de ejecución. Pruebe bajo diferentes cargas del sistema (es decir, cuando el sistema está inactivo, excepto para su aplicación, y cuando está ocupado).

Tenga en cuenta que sus optimizaciones basadas en su disco duro actual pueden volverse incorrectas cuando un disco duro nuevo y más rápido tenga diferentes optimizaciones internas que hagan que su trabajo salga por la ventana.

Answer 3

Una lectura secuencial es siempre más rápida que una que requiere una búsqueda de cabeza (no una búsqueda de posición). El rendimiento típico del disco duro para una lectura secuencial es de 50-60 MB / seg. Una vez que se colocan los cabezales de la unidad, esencialmente obtiene los datos en el cilindro de forma gratuita. El caché del sistema de archivos se aprovecha de esto al leer previamente los sectores de un cilindro.

Sin embargo, no tiene control sobre la ubicación de sus datos en los cilindros de disco. Tampoco puedes adivinar la geometría de la unidad. Tenga en cuenta que el rendimiento puede empeorar significativamente con el tiempo cuando el volumen se fragmenta. Tendrá que buscar el rendimiento almacenando datos en la memoria caché. En ese momento, te preocupa la localidad de referencia.

Answer 4

Siempre puede asignar el archivo a la memoria y luego acceder a él a través de punteros y demás. Por lo general, esto debería hacer que sus accesos sean más simples y más rápidos.