Discussion :

[StringBuilder]

Bonjour à tous,

Il n'est pas rare d'être confronté, sur de petits projets, ou des besoins bien spécifiques, à un dilemme : que faire lorsqu'on a quelques données et/ou des besoins de requêtage très basiques ?

En effet, installer un SGBD pour un environnement mono utilisateur et y stocker deux tables de quelques dizaines de lignes qui ne servent qu'à afficher des données dans des combos... c'est un peu le marteau pilon pour ouvrir une noix.
Quant à stocker les données dans un fichier XML ou JSON... c'est pas la panacée en termes de performances, ça oblige à mettre en place des usines à gaz, on réécrit tout le fichier à chaque fois qu'on y fait une modification... Bref, la plaie.

Reste SQLLite, qui, je l'avoue, rend partiellement caduque ce topic, puisqu'il permet de bénéficier de la puissance d'un SGBD et du SQL sans en avoir la lourdeur (ou tout du moins, que partiellement).

Ca fait un bon moment que j'y pense : à l'époque de VB6, tout début année 2000, j'ai été bluffé par les performances d'un programme écrit avec les pieds qui lisait des structures directement dans un fichier.
Depuis cette époque, je me dis qu'il serait pas forcément idiot d'écrire une petite librairie qui permette de faire la même chose, afin de gérer simplement des données dans un fichier.

Depuis quelques temps, je découvre aussi le progiciel de gestion Divalto Infinity.
Même si la majeure partie du programme utilise maintenant SQL Server, certaines parties du programme continuent à utiliser des fichiers séquentiels indexés. D'après l'éditeur, c'est pas vraiment qu'il n'ont pas pris le temps d'effectuer la conversion... c'est avant tout parce que pour certaines partie du logiciel, le SGBD n'apporterait rien, ni en termes de performances, ni en termes de fonctionnalités.

Fort de tout ça, hier je me suis lancé, ça m'a empêché de dormir une partie de la nuit, et maintenant j'ai pondu une version 0.1 de ma librairie.

Alors je vous le dis tout de suite : niveau fonctionnalités, ça ne va pas chercher bien loin, et niveau performances... bah c'est optimisé avec les pieds.

Et pourtant, je suis tout simplement sidéré par les performances de l'outil.

Je vous laisse juger les résultats de mon programme de test qui permet de vérifier le bon fonctionnement de ma librairie...
Il s'agit ici d'insérer en deux fois 5 millions de personnes dans un ordre totalement aléatoire (instances d'une classe Person) dans le fichier "person.dat".
Cela représente un volume de plus de 800 Mo, sur un disque magnétique (vieux disque magnétique de portable recyclé), et ça dure un peu moins de 60 secondes (sisi).
Le programme génère ensuite une liste de 100 000 identifiants aléatoires de personnes à rechercher (il peut y avoir des doublons) puis les charge.
1 sur 2, il le remplace avec un nouveau nom et un nouveau prénom, et 1 sur 2 est tout simplement supprimé.
Et il fait tout ça en... 1,6 secondes !

Open file...
Clear file...
Generate names... (1/2)
Shuffle names... (1/2)
Insert names... (1/2)
5000000 person(s) added
Time to add 5000000 persons : 25896 ms
Average time per record : 51 ticks
Generate names... (2/2)
Shuffle names... (2/2)
Insert names... (2/2)
5000000 person(s) added
Time to add 5000000 persons : 28214 ms
Average time per record : 56 ticks
Insert on person...
Time to add 1 persons : 3636 ticks
There are 10000001 persons in the file
Generate a list of persons to find...
Search those persons and change even to Alfred E. Neuman or delete odd...
99758 person(s) found in 1663 ms
Average time per record : 166 ticks
The file contains 9950113 names

Aussi bien générer 800 Mo de données (10 millions de lignes je vous le rappelle) en moins d'une minute, je suis assez content du résultat, mais pour le coup un SGBD pourrait arriver à suivre...
Autant retrouver près de 100 000 lignes, en modifier la moitié et supprimer l'autre moitié en 1,6 secondes... là, même sur un beau serveur (ce qui n'est pas le cas de mon PC) on va arriver à ces résultats avec un SGBD !

Bon, après, il faut relativiser... c'est du CRUD tout ce qu'il y a de plus basique, avec un seul index sur l'identifiant : pas question de rechercher une personne par son nom par exemple.
Et il n'y a pas de transaction non plus, ni d'accès concurrents possibles.

Mais bon, je me suis dit que tout de même, une lib .NET de moins d'à peine 100 lignes de code et simple d'utilisation pourrait intéresser du monde, comme alternative à un SGBD.

Le code source est accessible ici : https://github.com/SylvainDevidal/MagicFlatIndex

Le programme n'est pas finalisé du tout, et le README.md identifie un certain nombre de lacunes encore présentes (bouchage des trous, réorganisation/tri des données dans le fichier, etc.)

Tout commentaire est le bienvenu.

Edit du 18/04/2020 : Ajout d'une méthode de reconstruction de l'index en cas de perte du fichier ou de reprise après crash

[CinePhil]

Bonjour,

Je ne vais pas commenter sur le fond mais cette discussion va se perdre dans les méandres du forum. Je suis tombé dessus parce que le forum Decision SGBD est dans mon tableau de bord. Pourquoi ne pas faire plutôt un billet de blog ? Tous ceux qui ont la barre d'outils DVP auront connaissance du billet et il se perdra peut-être moins car restera peut-être mieux indexé.

A+

[SQLpro]

Le problème est que en cas de dysfonctionnement toutes tes données sont crashés ! il n'y a pas de journalisation ....

C'est ainsi que mes emails gérés par Mozilla thunderbird qui utilise SQL lite sont devenu une véritable merde irrattrapable avec des millions de lignes doublonnées !!!!!

Pour info, l'ensemble de mes emails représentait environ 16 Go et c'est passé à plus de 40 après crash et tentative de reconstruction... Merci SQLlite !!!



Bref j'ai dû passer en catastrophe à Outlook que je déteste !

A +

[CinePhil]

Quand même quelques trucs sur le fond...

quelques données
...
En effet, installer un SGBD pour un environnement mono utilisateur et y stocker deux tables de quelques dizaines de lignes qui ne servent qu'à afficher des données dans des combos... c'est un peu le marteau pilon pour ouvrir une noix.

Pour ce besoin basique, en effet, un simple fichier du langage applicatif utilisé renvoyant un tableau est largement suffisant. Exemple en PHP :

Code PHP :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
<?pho
// Retourne une liste de trucs
return [
    'Une',
    'Liste',
    'De',
    'Trucs'
];

On peut utiliser ça par exemple pour un fichier de config ; inutile de stocker la config dans le SGBD.

Code PHP :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
<?php
// Fichier de configuration d'accès à la BDD
return [
    'dbname' => 'ma_bdd',
    'user' => 'mon_user_sql',
    'mdp' => 'mon_mdp'
];

Le programme applicatif a ensuite une classe Configuration qui sait lire ce fichier.

Il s'agit ici d'insérer en deux fois 5 millions de personnes dans un ordre totalement aléatoire (instances d'une classe Person) dans le fichier "person.dat".

Là on n'est plus dans "quelques données" !

Le programme génère ensuite une liste de 100 000 identifiants aléatoires de personnes à rechercher (il peut y avoir des doublons) puis les charge.
1 sur 2, il le remplace avec un nouveau nom et un nouveau prénom, et 1 sur 2 est tout simplement supprimé.

OK pour le test de performance du machin mais à quoi ça peut bien correspondre dans la vraie vie ? Dans quel cas aurait-on besoin d'un tel process... à part peut-être pour préparer un génocide ?

Dans un cas réel, ces 5 millions de personnes seraient associées à d'autres données, ce qui nécessiterait un minimum de contraintes d'intégrité. Et là, le SGBD est quand même le mieux équipé pour le faire !

[Waldar]

c'est avant tout parce que pour certaines partie du logiciel, le SGBD n'apporterait rien, ni en termes de performances, ni en termes de fonctionnalités.

Je pense que tout est dit ici.
Sur un traitement intermédiaire sans besoin de persistance avec des opérations difficiles à faire pour un SGBD, ça a tout son sens de le faire là où c'est le plus adapté.

Il faut par contre aller un peu plus loin dans la réflexion et prendre le coût de l'orchestration d'une techno supplémentaire.

Sinon bon boulot Mais oui globalement les programmes qui font une seule chose avec peu de fonctionnalités sont les plus performants.

[StringBuilder]

Le problème est que en cas de dysfonctionnement toutes tes données sont crashés ! il n'y a pas de journalisation...

C'est effectivement ce sur quoi je met en garde : il n'y a pas de mécanisme de sécurité, notamment pas de possibilité de faire des transactions.
Cependant, le cas que tu cites ne devrait pas se produire : la façon dont j'ai fait le truc, au pire, seul le record en cours de modification peut être altéré, et pas de risque de doublons ou de records supprimés qui réapparaissent.
=> En effet, il n'y a aucune recopie (car le fichier de données n'est pas ordonné) et les record supprimés sont marqués physiquement comme tels dans le fichier. Donc la seule chose qu'on risque, c'est un fichier d'index déphasé, et je dois écrire une fonction de reconstruction.

Pour ce besoin basique, en effet, un simple fichier du langage applicatif utilisé renvoyant un tableau est largement suffisant.

On peut utiliser ça par exemple pour un fichier de config ; inutile de stocker la config dans le SGBD.

Le programme applicatif a ensuite une classe Configuration qui sait lire ce fichier.

Oui et non. Pour le coup, l'intérêt du fichier séquentiel indexé, c'est surtout de pouvoir rechercher et modifier les données.
Un fichier PHP qui produit un objet, c'est très compliqué à modifier par programmation... et pour ainsi dire impossible à modifier sans devoir tout charger et tout réenregistrer, ce qui est particulièrement contre-performant en cas de modifications multiples.

Là on n'est plus dans "quelques données" !

OK pour le test de performance du machin mais à quoi ça peut bien correspondre dans la vraie vie ? Dans quel cas aurait-on besoin d'un tel process... à part peut-être pour préparer un génocide ?

Dans un cas réel, ces 5 millions de personnes seraient associées à d'autres données, ce qui nécessiterait un minimum de contraintes d'intégrité. Et là, le SGBD est quand même le mieux équipé pour le faire !

En effet, je me suis amusé à produire 10 millions de lignes, non par pour illustrer un cas réel, mais pour pousser mon bousin dans ses retranchements, car j'étais vraiment surpris des bonnes performances.

Dans la vraie vie, il y a peu de chances qu'un tel besoin se manifeste. Mais pour reprendre un exemple concret d'utilisation, dans Divalto par exemple, c'est tous les menus de l'application qui sont stockés de cette manière.
Ils sont assez "nombreux" (quelques centaines) et sont personnalisables par profil utilisateur. Ainsi, la liste n'est pas figée, il faut que ce soit performant, et chaque utilisateur pouvant avoir sa propre liste de menus, c'est pas ultra pratique à gérer en base (là il suffit de faire un fichier par utilisateur, qu'on peut copier/coller d'un environnement à l'autre, supprimer pour voir ce que ça donne avec les menus standards, etc.)

Ca peut être aussi un fichier de préférences utilisateur, genre stocker des informations de position de fenêtres, valeurs par défaut, etc.
Selon l'application, ces éléments peuvent être nombreux et être modifiés en grand nombre.

Autre application possible, ça peut être un cache d'icônes, à l'image de thumbs.db que Windows génère automatiquement, etc.

Après, pouvoir gérer des relations, ou à minima des index de type "clé étrangère" serait un gros plus. Si un jour j'ai besoin (ou si quelqu'un propose un code, le code est dispo sur github et n'attend qu'à être forké) je l'implémenterai avec plaisir.

[bretus]

Bonjour,

Quel est l'apport de cette bibliothèque par rapport à des bases clé/valeur fichier du type LevelDB (utilisé par chrome, bitcoin,...)?

[StringBuilder]

Bonjour,

Quel est l'apport de cette bibliothèque par rapport à des bases clé/valeur fichier du type LevelDB (utilisé par chrome, bitcoin,...)?

Bonjour,

A priori, aucun rapport.
Le format que je propose se compose en deux fichiers (dont l'un peut être reconstruit à partir du premier) par entité.

Le fichier des données elles-mêmes ne contient que les données. Il s'agit de données structurées, stockées en format binaire, c'est à dire sans notion de balisage ou autre.

Quant au fichier d'index, c'est lui qui pourrait se rapprocher le plus de LevelDB : il s'agit effectivement d'un stockage de données clé/valeur, mais il s'agit de deux entier : la clé correspond à l'identifiant d'un objet du premier fichier, et la valeur correspond à la position de l'objet dans le second fichier. Il ne s'agit donc pas de chaînes.

En ce qui concerne l'ordre/méthode de stockage : pour le fichier de données, les données sont stockées à la suite, sans ordre particulier. Actuellement je n'ai pas implémenté de bouchage de trous ni de réorganisation des données.
Et pour l'index, il s'agit de stocker séquentiellement toutes les entrées du dictionnaire. Ces données sont "mortes", c'est à dire qu'on les charge une fois pour toute au chargement, puis on les réécrit entièrement quand on arrête : on ne charge/modifie ce fichier à aucun moment quand on travaille. On travaille exclusivement en mémoire. A ce moment, c'est l'objet natif .NET SortedDictionnary qui fait le job pour l'optimisation (arbre binaire, clé de hashage, osef du moment que c'est rapide. Si demain j'ai besoin d'un objet plus performant, je me lancerai peut-être dans mieux, mais clairement c'est pas nécessaire pour le moment).

[StringBuilder]

Petite mise à jour : j'ai implémenté la méthode Shrink() qui permet, en fonction du paramètre passé :
- Soit de réduire la taille du fichier simplement en bouchant les trous avec les records situés en fin de fichier
- Soit de réduire la taille du fichier en réorganisant totalement le fichier (tri) en passant par un fichier temporaire

Sauf en cas de vrai besoin de trier les données physiquement, le simple bouchage de trou est largement a privilégier (2 secondes sur un fichier de 820 Mo contre près de 1 minute 30 pour un tri complet sur le même fichier).

Open file...
Clear file...
Generate names... (1/2)
Shuffle names... (1/2)
Insert names... (1/2)
5000000 person(s) added
Time to add 5000000 persons : 30347 ms
Average time per record : 60 ticks
Generate names... (2/2)
Shuffle names... (2/2)
Insert names... (2/2)
5000000 person(s) added
Time to add 5000000 persons : 28475 ms
Average time per record : 56 ticks
Insert on person...
Time to add 1 persons : 4879 ticks
There are 10000001 persons in the file
Rebuild index...
Time to rebuild index : 17364 ms
There are 10000001 persons in the file
Generate a list of persons to find...
Search those persons and change even to Alfred E. Neuman or delete odd...
99744 person(s) found in 1869 ms
Average time per record : 187 ticks
The file contains 9950126 names
Shrink the file (just fill the holes)...
2216 ms
Reorder the whole file...
86160 ms