Xml ou Sqlite, Quand abandonner Xml pour une base de données ?

Question

J'aime beaucoup Xml pour sauvegarder des données, mais quand est-ce que sqlite/base de données devient la meilleure option ? par exemple, quand le xml a plus de x ou est supérieure à y MB ?

Je suis en train de coder un lecteur rss et je crois que j'ai fait le mauvais choix en utilisant xml plutôt qu'une base de données sqlite pour stocker un cache de todos les éléments de l'alimentation. Il y a des flux qui ont un fichier xml de ~1mb après un mois, un autre a plus de 700 éléments, tandis que la plupart n'ont que ~30 éléments et ont une taille de ~50kb après un mois. plusieurs mois.

Pour l'instant, je n'ai pas l'intention de mettre en place un plafond, car j'aime pouvoir effectuer des recherches dans tous les domaines.

Donc, mes questions sont :

1. Quand la surcharge de sqlite/bases de données est-elle justifiée par rapport à l'utilisation de xml ?
2. Est-ce que les quelques gros fichiers xml justification suffisante pour la base de données lorsqu'il y a beaucoup de petits même les plus petites grandiront avec le temps ? (une longue long temps)

actualisé (plus d'infos)

Chaque fois qu'un flux est sélectionné dans l'interface graphique, je recharge tous les éléments du fichier xml de ce flux.

Je dois également modifier l'état de lecture/non-lu, ce qui semble très compliqué lorsque je parcours en boucle tous les nœuds du fichier xml pour trouver l'élément et le mettre en lecture/non-lu.

Answer 1

J'ai de l'expérience dans ce domaine. Je travaille sur un projet où nous avons initialement stocké toutes nos données en utilisant XML, puis nous sommes passés à sqlite. Il y a beaucoup d'avantages et d'inconvénients à chaque technologie, mais c'est la performance qui a provoqué le changement. Voici ce que nous avons observé.

Pour les petites bases de données (quelques mégas ou moins), le XML était beaucoup plus rapide et plus facile à gérer. Nos données étaient naturellement dans un format arborescent, ce qui rendait XML beaucoup plus attrayant, et XPATH nous permettait d'effectuer de nombreuses requêtes en une seule ligne plutôt que de devoir parcourir un arbre généalogique.

Nous programmions dans un environnement Win32, et utilisions la bibliothèque DOM standard de Microsoft. Nous chargions toutes les données en mémoire, les analysions dans un arbre DOM et effectuions des recherches, des ajouts et des modifications sur la copie en mémoire. Nous sauvegardions périodiquement les données, et avions besoin de faire tourner les copies au cas où la machine se planterait au milieu d'une écriture.

Nous avons également dû construire quelques "index" à la main en utilisant des cartes d'arbres C++. Ceci, bien sûr, serait trivial à faire avec sql.

Notez que la taille des données sur le système de fichiers était inférieure d'un facteur 2-4 à celle de l'arbre de dom "en mémoire".

Lorsque les données ont atteint une taille de 10 à 100 millions, nous avons commencé à avoir de vrais problèmes. Il est intéressant de noter qu'à toutes les tailles de données, le traitement XML était beaucoup plus rapide que sqlite (parce qu'il était en mémoire et non sur le disque dur) ! Le problème était en fait double : d'abord, le temps de chargement commençait vraiment à devenir long. Nous devions attendre une minute ou plus avant que les données soient en mémoire et que les cartes soient construites. Bien sûr, une fois chargé, le programme était très rapide. Le deuxième problème était que toute cette mémoire était occupée en permanence. Les systèmes ne disposant que de quelques centaines de mégaoctets ne répondaient pas aux autres applications, même si le programme était très rapide.

Nous envisageons actuellement d'utiliser une base de données xml basée sur un système de fichiers. Il existe quelques bases de données xml en version libre, nous les avons essayées. Je n'ai jamais essayé d'utiliser une base de données xml commerciale, je ne peux donc pas les commenter. Malheureusement, nous n'avons jamais réussi à faire fonctionner correctement les bases de données xml. Même le fait de remplir la base de données avec des centaines de méga de xml prenait des heures..... Peut-être l'utilisions-nous de manière incorrecte. Un autre problème était que ces bases de données étaient assez lourdes. Elles nécessitaient Java et avaient une architecture client-serveur complète. Nous avons abandonné cette idée.

Nous avons trouvé sqlite alors. Il a résolu nos problèmes, mais à un prix. Lorsque nous avons branché sqlite pour la première fois, les problèmes de mémoire et de temps de chargement ont disparu. Malheureusement, comme tous les traitements étaient désormais effectués sur le disque dur, la charge de traitement en arrière-plan a augmenté. Alors qu'auparavant nous n'avions jamais remarqué la charge du processeur, maintenant son utilisation était beaucoup plus importante. Nous avons dû optimiser le code et conserver certaines données en mémoire. Nous avons également dû réécrire de nombreuses requêtes XPATH simples en algorithmes multi-requêtes complexes.

Voici donc un résumé de ce que nous avons appris.

1. Pour les données arborescentes, XML est beaucoup plus facile à interroger et à modifier à l'aide de XPATH.

2. Pour les petits ensembles de données (moins de 10M), XML a surpassé sqlite en termes de performances.

3. Pour les grands ensembles de données (plus de 10M-100M), le temps de chargement XML et l'utilisation de la mémoire sont devenus un gros problème, au point que certains ordinateurs deviennent inutilisables.

4. Nous n'avons pas trouvé de base de données xml opensource pour résoudre les problèmes liés aux grands ensembles de données.

5. SQLITE n'a pas les problèmes de mémoire de XML dom, mais il est généralement plus lent dans le traitement des données (elles sont sur le disque dur, pas en mémoire). (note- les tables sqlite peuvent être stockées en mémoire, peut-être que cela le rendrait aussi rapide..... Nous n'avons pas essayé cela car nous voulions sortir les données de la mémoire).

6. Stocker et interroger des données d'arbres dans une table n'est pas agréable. Cependant, la gestion des transactions et de l'indexation compense partiellement.

Answer 2

Je suis fondamentalement d'accord avec Mitchel que cela peut être très spécifique en fonction de ce que vous allez faire avec XML/sqlite. Dans votre cas (cache), il me semble que l'utilisation de sqlite (ou d'autres bases de données intégrées) est plus logique.

Tout d'abord, je ne pense pas vraiment que sqlite aura besoin de plus de frais généraux que XML. Et je veux dire à la fois les frais de développement et les frais d'exécution. Le seul problème est que vous dépendez de la bibliothèque sqlite. Mais comme vous auriez de toute façon besoin d'une bibliothèque pour XML, cela n'a pas d'importance (je suppose que le projet est en C/C++).

Avantages de sqlite par rapport à xml :

• tout dans un seul fichier,
• La perte de performance est inférieure à celle de XML lorsque le cache devient plus grand,
• vous pouvez conserver les métadonnées des flux séparément du cache lui-même (autre table), mais accessibles de la même manière,
• Pour la plupart des gens, il est probablement plus facile de travailler avec SQL qu'avec XPath.

Inconvénients de sqlite :

• peut être problématique avec plusieurs processus accédant à la même base de données (probablement pas votre cas),
• vous devez connaître au moins le SQL de base. À moins qu'il y ait des centaines de milliers d'éléments dans le cache, je ne pense pas que vous ayez besoin de l'optimiser beaucoup,
• peut-être que d'une certaine manière, il peut être plus dangereux du point de vue de la sécurité (injection SQL). D'un autre côté, vous n'êtes pas en train de coder une application web, donc cela ne devrait pas arriver.

Les autres éléments sont probablement les mêmes pour les deux solutions.

Pour résumer, les réponses à vos questions respectivement :

1. Vous ne le saurez pas, sauf si vous testez votre application spécifique avec les deux backends. Sinon, ce n'est toujours qu'une supposition. Le support de base des deux caches ne devrait pas être un problème à coder. Ensuite, évaluez et comparez.

2. En raison de la façon dont les fichiers XML sont organisés, les recherches sqlite devraient toujours être plus rapides (sauf dans certains cas particuliers où cela n'a pas d'importance parce que c'est incroyablement rapide). Accélérer les recherches en XML nécessiterait une base de données d'indexation de toute façon, dans votre cas cela signifierait avoir un cache pour le cache, pas une idée particulièrement bonne. Mais avec sqlite, l'indexation peut faire partie de la base de données.

Answer 3

N'oubliez pas que vous avez une formidable base de données à portée de main : le système de fichiers !

Beaucoup de programmeurs oublient qu'une structure de fichier répertoire décente est/est :

1. C'est rapide comme l'enfer
2. Il est portable
3. L'empreinte du temps d'exécution est minuscule

Les gens parlent de diviser les fichiers XML en plusieurs fichiers XML... J'envisagerais de diviser votre XML en plusieurs répertoires et plusieurs fichiers en texte clair.

Essayez-le. C'est d'une rapidité rafraîchissante.

Answer 4

1. Utilisez XML pour les données que le application doit connaître - configuration, journalisation et autres.
2. Utiliser des bases de données (Oracle, SQL Server, etc.) pour les données que l'utilisateur utilise. interagit directement ou indirectement - données réelles
3. Utilisez SQLite si les données de l'utilisateur sont plus d'une collection sérialisée - comme une énorme liste de fichiers et leur contenu ou une collection d'éléments de courrier électronique, etc. SQLite est bon pour cela.

Cela dépend du type et de la taille des données.

Answer 5

Quand faut-il utiliser XML pour la persistance des données plutôt qu'une base de données ? Presque jamais. XML est un langage de transport de données. Il est lent à analyser et difficile à interroger. Analysez le XML (ne le détruisez pas !) et convertissez les données résultantes en objets de domaine. Puis faites persister les objets du domaine. L'un des principaux avantages d'une base de données pour la persistance est le SQL, ce qui signifie des requêtes non structurées et l'accès aux outils et techniques d'optimisation courants.