Est-il plus rapide d'accéder aux données à partir de fichiers ou d'un serveur de base de données?
Si j'ai une base de données statique composée de dossiers et de fichiers, l'accès et la manipulation seraient-ils plus rapides que les bases de données de type serveur SQL, étant donné que cela serait utilisé dans un script CGI?
Lorsque vous travaillez avec des fichiers et des dossiers, quelles sont les astuces pour améliorer les performances?
Je vais ajouter à la foule ça dépend.
C’est le genre de question qui n’a pas de réponse générique, mais qui dépend fortement de la situation. J'ai même récemment déplacé certaines données d'une base de données SQL vers un système de fichiers à plat, car la surcharge de la base de données, combinée à certains problèmes de fiabilité de la connexion à la base de données, rendait l'utilisation de fichiers à plat un meilleur choix.
Voici quelques questions que je me poserais lors du choix:
Comment est-ce que je consomme les données? Par exemple, vais-je simplement lire les lignes du début à la fin dans l'ordre indiqué? Ou vais-je rechercher des lignes qui correspondent à plusieurs critères?
À quelle fréquence vais-je accéder aux données lors de l'exécution d'un programme? Vais-je aller une fois chercher tous les livres avec Salinger comme auteur ou vais-je aller plusieurs fois chercher plusieurs auteurs? Vais-je y aller plus d'une fois pour plusieurs critères différents?
Comment vais-je ajouter des données? Puis-je simplement ajouter une ligne à la fin et c'est parfait pour ma récupération ou faut-il y avoir recours?
Quelle sera la logique du code dans six mois? J'insiste sur ce point car je pense que cela est trop souvent oublié dans la conception d'objets (pas seulement du code, ce cheval de passe-temps appartient en fait à mon époque de mécanicien de la Marine maudissant les ingénieurs mécaniciens). Dans six mois, lorsque je devrai gérer votre code (ou ce que vous faites après avoir travaillé sur un autre projet), quelle méthode de stockage et de récupération de données aura plus de sens. Si le passage de fichiers plats à une base de données entraîne une amélioration de l'efficacité de 1%, mais ajoute une semaine de travail pour déterminer les éléments à mettre à jour lorsque vous devez mettre à jour le code.
Cela dépend de la nature de vos informations et de la structure et de la structure de vos accès. Les deux principaux avantages des bases de données relationnelles sont les suivants:
Caching. Sauf si vous êtes très intelligent, vous ne pouvez pas écrire un cache aussi bon que celui d'un serveur de base de données
Optimiseur.
Cependant, pour certaines applications spécialisées, aucun de ces 2 avantages ne se manifeste par rapport aux fichiers + dossier de stockage de données - la réponse est donc une "dépend" retentissante.
En ce qui concerne les fichiers/dossiers, les astuces sont les suivantes:
- Cache le contenu des fichiers fréquemment demandés
- Ayez des petits répertoires (l'accès aux fichiers dans des petits répertoires profondément imbriqués est beaucoup plus rapide que dans une structure plus plate, en raison du temps nécessaire pour lire le contenu d'un grand répertoire).
- Il existe d'autres optimisations plus avancées (découpage sur plusieurs disques, placement à différents endroits d'un disque ou d'une partition, etc.) - mais si vous avez besoin de CE niveau, vous avez tout intérêt à utiliser une base de données.
En règle générale, les bases de données sont plus lentes que les fichiers.
Si vous avez besoin d'indexer vos fichiers, un chemin d'accès codé en dur sur des structures d'indexation personnalisées aura toujours le potentiel d'être plus rapide si vous le faites correctement.
Mais la «performance» n’est pas l’objectif lors du choix d’une base de données sur une solution basée sur des fichiers.
Vous devriez vous demander si votre système a besoin des avantages d'une base de données. Si tel est le cas, la petite surcharge de performances est tout à fait acceptable.
Alors:
- Avez-vous besoin de gérer plusieurs utilisateurs et mises à jour simultanées? (Eh bien, vous avez dit que c'était statique.)
- Avez-vous besoin de flexibilité pour pouvoir facilement interroger les données sous différents angles?
- Avez-vous plusieurs utilisateurs et pourriez-vous tirer parti d'un modèle de sécurité existant?
Fondamentalement, la question est plus qui serait plus facile à développer. La différence de performance entre les deux ne vaut pas la peine de perdre du temps de développement.
D'après mon expérience, les bases de données sur serveur (même celles servies sur la machine locale) ont tendance à avoir un débit très lent comparé aux systèmes de fichiers locaux. Toutefois, cela dépend de certaines choses, dont la complexité asymptotique. En comparant l'analyse d'une grande liste de fichiers avec l'utilisation d'une base de données avec un index pour rechercher un élément, la base de données l'emporte.
Mon peu d'expérience est avec PostgreSQL. J'avais une table avec trois millions de lignes et je suis allé mettre à jour seulement 8 000 enregistrements. Cela a pris 8 secondes.
Pour ce qui est de la citation "L’optimisation prématurée est la racine de tout mal", je prendrais cela avec un grain de sel. Si vous écrivez votre application en utilisant une base de données, puis que vous la trouvez lente, le passage à une approche basée sur un système de fichiers ou autre (par exemple, SQLite) peut prendre un temps considérable. Je dirais que votre meilleur pari est de créer un prototype très simple de votre charge de travail et de le tester avec les deux approches. Je crois qu'il est important de savoir lequel est le plus rapide dans ce cas.
Comme d'autres l'ont souligné: ça dépend!
Si vous vraiment avez besoin de savoir ce qui sera le plus performant, vous pouvez générer des exemples de données à stocker dans chaque format, puis exécuter des tests de performance. Le module Benchmark.pm est fourni avec Perl et permet de faire une comparaison côte à côte avec quelque chose comme ceci:
use Benchmark qw(:all) ;
my $count = 1000; # Some large-ish number of trials is recommended.
cmpthese($count, {
'File System' => sub { ...your filesystem code... },
'Database' => sub { ...your database code... }
});
Vous pouvez taper perldoc Benchmark pour obtenir une documentation plus complète.
Il est très utile d’utiliser des fichiers au lieu de db quand il s’agit d’images, si la structure du site le permet. Créez des dossiers représentant vos données correspondantes et placez des images à l'intérieur. Par exemple, vous avez un site d'articles, vous stockez vos articles dans db. Vous ne devez pas placer vos chemins d’image sur la base de données, nommer les dossiers avec vos clés primaires comme 1,2,3 .. et y mettre des images. Livres électroniques, fichiers musicaux, vidéos, cette approche peut être utilisée dans tous les fichiers multimédias. Même logique fonctionne avec les fichiers XML si vous ne cherchez pas quelque chose.
Comme d'autres l'ont dit, cela dépend: de la taille et de la nature des données et des opérations que vous prévoyez d'y exécuter.
En particulier pour un script CGI, vous vous exposerez à des problèmes de performances si vous vous connectez à un serveur de base de données à chaque affichage de page. Cependant, si vous créez une approche naïve à base de fichiers, vous risquez de créer des problèmes de performances encore plus graves ;-)
Outre une solution Berkeley DB File, vous pouvez également utiliser SQLite. Cela crée une interface SQL avec une base de données stockée dans un fichier local. Vous pouvez y accéder avec DBI et SQL, mais il n’existe pas de serveur, de configuration ou de protocole réseau. Cela pourrait permettre une migration plus facile si un serveur de base de données était nécessaire à l'avenir (exemple: si vous décidez de disposer de plusieurs serveurs frontaux, mais que vous devez partager l'état).
Sans connaître les détails, je suggérerais en utilisant une solution SQLite/DBI puis en examinant les performances}. Cela donnera de la flexibilité avec un démarrage relativement simple et des performances décentes.
Pour accéder rapidement aux fichiers, en fonction de ce que vous faites, un mmap peut être très pratique. Je viens d’écrire à ce sujet dans Effective Perl blog en tant que Les fichiers de mappage de mémoire au lieu de les slurping .
Cependant, je pense qu’un serveur de base de données serait beaucoup plus rapide. Il est difficile de dire ce qui serait plus rapide pour vous quand nous n'avons aucune idée de ce que vous faites, du type de données auquel vous avez besoin d'accéder, etc.
Cela dépend du profil des données et de la logique que vous allez utiliser pour y accéder. Si vous devez simplement sauvegarder et récupérer des nœuds nommés, une base de données basée sur un système de fichiers peut être plus rapide et plus efficace. (Vous pouvez également consulter Berkeley DB à cette fin.) Si vous devez effectuer des recherches basées sur des index, et en particulier si vous devez associer différents ensembles de données en fonction de clés, une base de données SQL est votre meilleur choix.
Je voudrais simplement aller avec la solution qui semble la plus naturelle pour votre application.
Je vais vous donner la même réponse que tout le monde vous a donnée, Ça dépend
Dans un scénario simple avec un seul serveur qui renvoie des données (READ Only), le système de fichiers Yes sera formidable et facile à gérer.
Toutefois, lorsque vous avez plusieurs serveurs, vous devez gérer un système de fichiers distribué tel que glusterfs , ceph , etc.
Une base de données est un outil pour tout gérer pour vous, système de fichiers distribués, compression, lecture/écriture, verrous, etc.
j'espère que c'est utile.