Quel SGBD convient aux lectures ultra-rapides et à une structure de données simple?

Je développe un produit qui, dans le cadre de son fonctionnement, doit suivre un grand nombre de fichiers / répertoires. L'idée est de stocker les informations statistiques dans une base de données puis, au démarrage, de créer des montres pour chaque fichier. Les fichiers modifiés seront mis en file d'attente (dans la base de données) pour une synchronisation de groupe avec une base de données distante. Ils seront synchronisés par ordre de priorité, un nombre compris entre 1 et 10.

Informations sur la base de données:

• <100 000 entrées d'informations statistiques
• Base de données entière lue au démarrage, seul le chemin du fichier est nécessaire
• Les fichiers en file d'attente auront un champ prioritaire (rien d'autre ne doit être recherché par)
• Les insertions peuvent être lentes

J'ai trouvé quelques bases de données qui, je pense, fonctionneront, mais je ne sais pas laquelle serait la meilleure:

• Redis - stocke le chemin du fichier comme clé, les données statistiques comme valeur; la file d'attente serait une liste
• MongoDB - plus d'options de requête que Redis, mais toujours rapide

Je pense qu'une base de données NoSQL serait la meilleure solution ici, car il n'y a pas trop de logique relationnelle en cours et la taille totale des données n'est pas trop grande (quelque chose comme <100 Mo, plus proche de <30 Mo). J'ai regardé SQLite car il semble assez simple pour être intégré dans une application installable.

Comme il s'agit d'une application distribuée pour les utilisateurs finaux et non d'un serveur à charge élevée, la base de données n'a pas à prendre en charge de nombreux utilisateurs simultanés. La priorité principale ici est de trouver une base de données dont le modèle a le plus de sens.

Donc la question, quelle base de données serait la plus applicable à cette situation?

Existe-t-il également d'autres bases de données qui auraient plus de sens pour une application comme celle-ci?

La première chose qui me vient à l'esprit est un SGBDR particulier que je connais. Je reconnais cependant que ce n'est peut-être pas le meilleur pour cette application.

Donc, mon conseil est d'aller avec une base de données qui vous est familière. Si vous connaissez Redis ou MongoDB, optez pour l'un d'entre eux. Si vous connaissez mieux SQLite, choisissez-le.

Sur une base de données de cette taille, tout va être assez rapide. Même les bases de données qui sont plus gourmandes en disque utiliseront une sorte de mise en cache afin que la vitesse du disque ne soit pas trop un problème.

Si vous n'êtes pas concerné par la logique relationnelle, souhaitez une vitesse de lecture très rapide et que vous êtes prêt à travailler avec un SGBDR, je me risquerais à dire MySQL. Pourquoi ???

Le moteur de stockage MyISAM dispose d'une option qui permet d'augmenter la structure physique de la table pour de meilleures performances. Quelle est cette option? L'option ALTER TABLE ROW_FORMAT.

Par exemple, le livre MySQL Database Design and Tuning recommande d'utiliser ROW_FORMAT = FIXED aux pages 72,73. Cela convertira en interne tous les champs VARCHAR en CHAR. Cela rendra la table MyISAM plus grande, mais les SELECT exécutés par rapport à elle seront beaucoup plus rapides. Je peux personnellement témoigner de cela. J'ai eu une fois une table de 1,9 Go. J'ai changé le format avec ALTER TABLE tblname ROW_FORMAT = FIXED. Le tableau a fini par 3,7 Go. La vitesse des SELECTs par rapport à elle était 20-25% plus rapide sans amélioration ou changement d'autre chose.

Que faire si vous avez déjà une table MyISAM remplie de données? Vous pouvez obtenir des métriques pour les définitions de colonne recommandées en fonction des données présentes dans la table MyISAM. Quelle requête présente ces mesures?

SELECT * FROM tblname PROCEDURE ANALYSE();

PROCEDURE ANALYZE () Ceci n'affichera pas les données. Il lira la valeur de chaque colonne et recommandera des définitions de colonne. Par exemple, si vous avez une colonne de type dont les valeurs sont 1-4, cela suggérerait d'utiliser un ENUM de ces 4 valeurs. Vous pouvez alors choisir d'utiliser TINYINT ou CHAR (1) car ils prennent la même quantité d'espace (1 octet).

Voici autre chose à considérer: puisque vous envisagiez d'utiliser une base de données NoSQL, avez-vous déjà pensé à utiliser MyISAM de manière NoSQL? C'est tout à fait possible. La page 175 du même livre que j'ai mentionné suggère d'utiliser des structures HANDLER pour lire un tableau sans les bagages relationnels . En fait, la page 175 donne cet exemple:

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;

Ce tableau contient des millions de lignes. Supposons que vous devez créer une application d'analyse de données répondant aux exigences suivantes:

• Il doit récupérer des blocs d'informations le plus rapidement possible.
• En fonction de la saisie de l'utilisateur ou d'autres facteurs, il est probable qu'il "saute" dans le tableau.
• Il ne concerne pas la concurrence ou d'autres problèmes d'intégrité des données.
• Le verrouillage de table multi-applications n'est pas requis.

Ces commandes permettent des lectures rapides et sales à partir du tableau:

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;

J'espère que cela donnera matière à réflexion. Veuillez l'examiner.

CAVEAT

Ce qui est très ironique au sujet de moi écrivant ce post particulier, c'est que j'ai écrit un post précédent sur HANDLER utilisé dans les binaires Percona Server et pensant que son utilisation était obsolète . Depuis ce poste plus ancien, je n'ai jamais pensé que j'écrirais quelque chose à l'appui des structures HANDLER. Je me tiens maintenant corrigé.