¿Qué DBMS es bueno para lecturas súper rápidas y una estructura de datos simple?

Estoy desarrollando un producto que, como parte de su operación, debe rastrear una gran cantidad de archivos / directorios. La idea es almacenar información estadística en una base de datos y luego, al arrancar, crear relojes para cada archivo. Los archivos que cambian se pondrán en cola (en la base de datos) para una sincronización de grupo a una base de datos remota. Se sincronizarán en orden de prioridad, un número entre 1-10.

Información sobre la base de datos:

• <100,000 entradas de información estadística
• Toda la base de datos leída en el arranque, solo es necesaria la ruta del archivo
• Los archivos en cola tendrán un campo de prioridad (no es necesario buscar nada más)
• Las inserciones pueden ser lentas

He encontrado un par de bases de datos que creo que funcionarán, pero no estoy seguro de cuál sería el mejor:

• Redis : almacena la ruta del archivo como clave, los datos estadísticos como valor; la cola sería una lista
• MongoDB : más opciones de consulta que Redis, pero aún así rápido

Estoy pensando que una base de datos NoSQL sería la mejor solución aquí, ya que no hay demasiada lógica relacional y el tamaño total de los datos no es demasiado grande (algo así como <100 mb, más cercano a <30 mb). Observé SQLite porque parece ser lo suficientemente simple como para incrustarlo en una aplicación instalable.

Dado que esta es una aplicación distribuida para usuarios finales y no un servidor de alta carga, la base de datos no tiene que soportar muchos usuarios simultáneos. La principal prioridad aquí es encontrar una base de datos cuyo modelo tenga más sentido.

Entonces, la pregunta, ¿qué base de datos sería más aplicable para esta situación?

Además, ¿hay otras bases de datos que tengan más sentido para una aplicación como esta?

Lo primero que me viene a la mente es un RDBMS particular que me resulta familiar. Sin embargo, reconozco que puede no ser el mejor para esta aplicación.

Por lo tanto, mi consejo es ir con una base de datos que le sea familiar. Si está familiarizado con Redis o MongoDB, vaya con uno de esos. Si está más familiarizado con SQLite, elija eso.

En una base de datos de este tamaño, todo será bastante rápido. Incluso las bases de datos que son más pesadas en disco utilizarán algún tipo de almacenamiento en caché para que la velocidad del disco no sea una gran preocupación.

Si no le preocupa tanto la lógica relacional, desea una velocidad de lectura realmente rápida y está dispuesto a trabajar con un RDBMS, me aventuraría perjudicialmente a decir MySQL. Por qué ???

El motor de almacenamiento MyISAM tiene una opción que permite aumentar la estructura física de la tabla para un mejor rendimiento. ¿Cuál es esa opción? La opción ALTER TABLE ROW_FORMAT.

Por ejemplo, el libro MySQL Database Design and Tuning recomienda usar ROW_FORMAT = FIXED en las páginas 72,73. Esto convertirá internamente todos los campos VARCHAR a CHAR. Hará que la tabla MyISAM sea más grande, pero los SELECT ejecutados contra ella serán mucho más rápidos. Personalmente puedo dar fe de esto. Una vez tuve una mesa de 1.9GB. Cambié el formato con ALTER TABLE tblname ROW_FORMAT = FIXED. La mesa terminó 3.7GB. La velocidad de los SELECT contra él fue 20-25% más rápida sin mejorar ni cambiar nada más.

¿Qué sucede si ya tiene una tabla MyISAM que se llena con datos? Puede obtener métricas para las definiciones de columna recomendadas basadas en los datos presentes en la tabla MyISAM. ¿Qué consulta presenta esas métricas?

SELECT * FROM tblname PROCEDURE ANALYSE();

ANÁLISIS DE PROCEDIMIENTO () Esto no mostrará datos. Leerá el valor de cada columna y recomendará definiciones de columna. Ejemplo, si tiene una columna de tipo cuyos valores son 1-4, sugeriría usar un ENUM de esos 4 valores. A continuación, puede optar por utilizar TINYINT o CHAR (1), ya que ocupan la misma cantidad de espacio (1 byte).

Aquí hay algo más a tener en cuenta: dado que estaba pensando en usar un DB NoSQL, ¿alguna vez pensó en usar MyISAM de una manera NoSQL? Esto es muy posible. La página 175 del mismo libro que mencioné sugiere usar estructuras HANDLER para leer una tabla sin el equipaje relacional . De hecho, la página 175 da este ejemplo:

CREATE TABLE customer_mileage_details
(
    customer_id INT NOT NULL,
    ff_number CHAR(10) NOT NULL,
    transaction_date DATE NOT NULL,
    mileage SMALLINT NOT NULL,
    INSERT(customer_id),
    INSERT (ff_number,transaction_date)
) ENGINE = MYISAM;

Esta tabla contiene millones de filas. Suponga que necesita crear una aplicación de análisis de datos que tenga los siguientes requisitos:

• Necesita recuperar bloques de información lo más rápido posible.
• Según la entrada del usuario u otros factores, es probable que "salte" en la tabla.
• No le preocupa la concurrencia u otros problemas de integridad de datos.
• No se requiere el bloqueo de la mesa de aplicaciones cruzadas.

Estos comandos permiten lecturas rápidas y sucias de la tabla:

HANDLER customer_mileage_details OPEN;
HANDLER customer_mileage_details READ ff_number FIRST WHERE ff_number=('aaetm-4441');
HANDLER customer_mileage_details READ NEXT LIMT 10;
HANDLER customer_mileage_details CLOSE;

Espero que esto dé pie a la reflexión. Por favor, míralo.

CONSIDERACIÓN

Lo que es muy irónico acerca de mí al escribir esta publicación en particular es que escribí una publicación anterior sobre el uso de HANDLER en los binarios del Servidor Percona y pensando que su uso estaba desactualizado . Desde esa publicación anterior, nunca pensé que alguna vez escribiría algo en apoyo de las estructuras HANDLER. Ahora estoy corregido.