Pourquoi utiliser une base de données au lieu de simplement enregistrer vos données sur disque?


193

Au lieu d'une base de données, je sérialise simplement mes données sur JSON, les enregistre et les charge sur le disque si nécessaire. Toute la gestion des données est faite sur le programme lui-même, ce qui est plus rapide ET plus facile que d'utiliser des requêtes SQL. Pour cette raison, je n'ai jamais compris pourquoi des bases de données sont nécessaires.

Pourquoi utiliser une base de données au lieu de simplement enregistrer les données sur disque?


61
Si la gestion des relations entre vos données dans votre application est en réalité plus rapide que dans une base de données (ce que je trouve extrêmement difficile à croire), vous devez lire la suite sur la normalisation SQL et la base de données. Ce que vous vivez est probablement l’effet secondaire d’une base de données terriblement conçue.
Yannis

68
Vous n'avez pas besoin d'une base de données dans le scénario que vous décrivez, car votre jeu de données est trivial. Les bases de données sont conçues pour des ensembles de données plus complexes. Si vous ne faites que lire et afficher une liste, votre approche fonctionne.
Yannis

16
Quelles conditions de course pourriez-vous rencontrer et êtes-vous prêt pour cela? Souhaitez-vous vouloir dépasser un seul serveur Web? Quel est votre plan de sauvegarde en cas de panne de votre serveur? Votre réponse à toutes ces questions sera probablement meilleure si vous avez une base de données que si vous n'en avez pas. De même, si vous avez déjà appris à utiliser des bases de données, je suppose que vous trouverez votre "plus facile que d'utiliser des requêtes SQL" devrait être modifiée en "plus facile que d'utiliser des requêtes SQL si vous ne comprenez pas SQL."
btilly

37
La base de données stocke quand même les données sur le disque. C'est le résultat final d'une évolution naturelle des systèmes de stockage de données structurées dans un fichier. Si vous envisagez d'utiliser des fichiers pour stocker vos données structurées, il est fort probable que vous réinventiez des fonctionnalités déjà développées dans des bases de données. Alors pourquoi ne pas utiliser une base de données dès le début?
Benoît

13
En fonction de l'évolution de votre projet, vous devrez peut-être gérer des problèmes tels que l'accès simultané et les restaurations. Ils semblent banaux, mais ne le sont pas. Au moment où vous avez fini de les résoudre, vous constaterez que vous avez essentiellement écrit une base de données. Voulez-vous vraiment être dans le secteur des bases de données ou dans un autre secteur?
Jwernerny

Réponses:


280
  1. Vous pouvez interroger des données dans une base de données (posez-lui des questions).
  2. Vous pouvez rechercher des données dans une base de données relativement rapidement.
  3. Vous pouvez associer des données de deux tables différentes à l'aide de JOIN.
  4. Vous pouvez créer des rapports significatifs à partir des données d'une base de données.
  5. Vos données ont une structure intégrée.
  6. Les informations d'un type donné sont toujours stockées une seule fois.
  7. Les bases de données sont ACID .
  8. Les bases de données sont tolérantes aux pannes.
  9. Les bases de données peuvent gérer de très grands ensembles de données.
  10. Les bases de données sont concurrentes; plusieurs utilisateurs peuvent les utiliser en même temps sans corrompre les données.
  11. Les bases de données évoluent bien.

En bref, vous bénéficiez d'un large éventail de technologies éprouvées et bien connues développées au cours de nombreuses années par une grande variété de personnes très intelligentes.

Si vous craignez que votre base de données ne soit trop lourde, consultez SQLite.


21
6. Normalisation, 7. Voir le lien, 8. Lisez sur la tolérance de panne. Oh, et avant de vous laisser entraîner dans l'engouement pour NoSQL, découvrez les bases de données SQL; apprenez à les connaître selon leurs propres conditions. Tu comprendras. Si vous ne parlez que de simples données de configuration, JSON est peut-être tout ce dont vous avez besoin. Mais il existe de nombreux types de données autres que les paramètres de programme.
Robert Harvey

25
Dans la mesure où deux programmes éditant les données à la fois ne sont pas sécuritaires, c'est en partie la raison de l'existence de bases de données. Si jamais vous avez ce besoin (et certains ou tous les autres besoins que j'ai mentionnés), vous serez très heureux de ne pas avoir à réinventer tout cela.
Robert Harvey

23
@Dokkat Ce n'est pas nécessaire, rien ne l'est. Si votre approche fonctionne pour vous, ne vous gênez pas. Je devrais toutefois mentionner que la plupart des serveurs rdbms à moitié corrects prennent en charge les mémoires stockées. Vous pouvez charger tout ce dont vous avez besoin lorsque votre application se réveille (comme vous le faites déjà) et les interroger comme une base de données classique (conservant tous les avantages mentionnés par Robert ).
Yannis

28
En d'autres termes, vous avez parfois besoin d'une tente, mais parfois d'une maison. Construire une maison est un jeu de balle totalement différent de celui de planter une tente.
Robert Harvey

49
@Dokkat quand les gens parlent de crash, ils veulent dire des choses comme ... votre CPU a explosé à la moitié de l'écriture de votre fichier "base de données". Qu'est-ce qui se passe maintenant? Il est fort probable que votre fichier soit corrompu / illisible (du moins, il risque de ne plus être conforme à votre propre format) et vous devez restaurer une sauvegarde (alors que la plupart des "vraies" bases de données ne perdraient que la dernière transaction). Bien sûr, vous pouvez écrire du code pour le faire gérer. Ensuite, vous pouvez écrire du code pour toutes les autres choses. Et ensuite, vous réalisez que vous avez passé 6 mois à écrire un DB, que vous auriez pu utiliser dès le début, avec très peu d’effort.
Daniel B

200

Bien que je sois d’accord avec tout ce que Robert a dit, il ne vous a pas indiqué quand vous devriez utiliser une base de données, par opposition à la simple sauvegarde des données sur disque.

Ajoutez donc cela à ce que Robert a dit sur l'évolutivité, la fiabilité, la tolérance aux pannes, etc.

Voici quelques points à considérer pour savoir quand utiliser un SGBDR:

  • Vous avez des données relationnelles, c’est-à-dire que vous avez un client qui achète vos produits et que ces produits ont un fournisseur et un fabricant
  • Vous avez de grandes quantités de données et vous devez pouvoir localiser rapidement les informations pertinentes.
  • Vous devez commencer à vous soucier des problèmes précédents identifiés: évolutivité, fiabilité, conformité ACID.
  • Vous devez utiliser des outils de reporting ou de renseignement pour résoudre les problèmes de votre entreprise.

Quant à quand utiliser un NoSQL

  • Vous avez beaucoup de données à structurer qui doivent être stockées
  • Evolutivité et besoins de rapidité
  • En règle générale, vous n'avez pas besoin de définir votre schéma à l'avance. Par conséquent, si les exigences changent, cela pourrait être un bon point.

Enfin, quand utiliser des fichiers

  • Vous disposez de données non structurées en quantités raisonnables que le système de fichiers peut gérer.
  • Vous ne vous souciez pas de la structure, des relations
  • Vous ne vous souciez pas de l'évolutivité ou de la fiabilité (bien que cela puisse être fait, en fonction du système de fichiers)
  • Vous ne voulez pas ou ne pouvez pas gérer les frais généraux qu'une base de données va ajouter
  • Vous traitez avec des données binaires structurées appartenant au système de fichiers, par exemple: images, PDF, documents, etc.

14
+1, je pense qu'il est important que vous signaliez qu'il y a des moments où les fichiers sont réellement adaptés au stockage.
GrandmasterB

15
Vous pouvez ajouter un autre exemple à votre troisième liste: lorsque les données sont en fait des fichiers, par exemple des images téléchargées, des documents pdf, etc. Cela peut sembler évident, mais j’ai vu des cas où des images étaient stockées dans un blob de base de données sans aucune raison valable.
Goran Jovic

5
Eh bien, il n’a jamais été explicitement mentionné qu’il s’agissait d’une application Web, mais je l’ai déduit du commentaire JSON. Cependant, il arrive parfois que quelques utilisateurs n'utilisent quelque chose et vous pouvez justifier la portée de l'application pour ne pas vous soucier de son évolutivité et de sa fiabilité. Par cela, je veux dire, ne vous inquiétez pas de choses telles que le clustering et la redondance.
Sam

8
@GoranJovic cela a parfois du sens. Stockez plus de 10 000 images dans un répertoire et certains systèmes de fichiers vont s'arrêter - une base de données peut s'avérer plus simple qu'un schéma de partition manuel de sous-répertoires.
Martin Beckett

2
@MartinBeckett: quel système de fichiers de la dernière décennie fait cela?
Eamon Nerbonne

55

Une chose que personne ne semble avoir mentionnée est l'indexation des enregistrements. Votre approche est satisfaisante pour le moment et je suppose que vous disposez d'un très petit ensemble de données et que très peu de personnes y ont accès.

Au fur et à mesure que vous devenez plus complexe, vous créez une base de données. Quoi que vous souhaitiez l'appeler, une base de données n'est qu'un ensemble d'enregistrements stockés sur le disque. Que vous créiez le fichier, MySQL , SQLite ou tout ce qui crée le (s) fichier (s), ce sont deux bases de données.

Ce qui vous manque, c'est la fonctionnalité complexe intégrée aux systèmes de base de données pour faciliter leur utilisation.

La principale chose qui me vient à l’esprit est l’indexation. OK, vous pouvez donc stocker 10, 20, voire 100 ou 1 000 enregistrements dans un tableau sérialisé ou une chaîne JSON, extraire le fichier de votre fichier et le parcourir de manière relativement rapide.

Maintenant, imaginez que vous ayez 10 000, 100 000 ou même 1 000 000 enregistrements. Lorsque quelqu'un essaie de se connecter, il va falloir ouvrir un fichier de plusieurs centaines de mégaoctets, le charger en mémoire dans votre programme, extraire un tableau d'informations de même taille puis itérer des centaines de milliers d'enregistrements juste pour trouvez l'enregistrement auquel vous souhaitez accéder.

Une base de données appropriée vous permettra de configurer des index sur certains champs d’enregistrements, ce qui vous permettra d’interroger la base de données et de recevoir une réponse très rapidement, même avec d’énormes ensembles de données. Combinez cela avec quelque chose comme Memcached ou même avec un système de cache maison (par exemple, enregistrez les résultats d'une recherche dans un tableau séparé pendant 10 minutes et chargez-les au cas où quelqu'un chercherait la même chose peu de temps après), et vous aurez des requêtes extrêmement rapides, ce que vous ne obtiendrez pas avec un ensemble de données aussi volumineux lorsque vous lisez / écrivez manuellement dans des fichiers.

Une autre chose qui est vaguement liée à l'indexation est le transfert d'informations. Comme je l'ai dit plus haut, lorsque vous avez des fichiers de centaines ou de milliers de mégaoctets, vous devez charger toutes ces informations en mémoire, répétez-les manuellement (probablement sur le même fil), puis manipulez vos données.

Avec un système de base de données, il s'exécutera sur ses propres threads, voire sur son propre serveur. Tout ce qui est transmis entre votre programme et le serveur de base de données est une requête SQL et tout ce qui est transmis est les données auxquelles vous souhaitez accéder. Vous ne chargez pas l'intégralité du jeu de données en mémoire - tout ce que vous envoyez et recevez ne représente qu'une infime fraction de votre ensemble de données total.


1
1. Veuillez ne jamais charger toutes vos informations utilisateur dans le code côté client! (Je suis sûr que ce n'était qu'un exemple.) 2. Charger cela en premier lieu à partir d'un fichier de 100 Mo volumineux prendra un certain temps. 3. Votre exemple est correct, mais supposons que vous ne ferez une recherche que par nom d'utilisateur. Que se passe-t-il si vous souhaitez stocker plus de données sur un utilisateur? par exemple l'âge. Vous souhaitez maintenant rechercher tous les utilisateurs âgés de 20 à 30 ans. Ou encore plus simple, recherchez un utilisateur par adresse lorsque votre json ressemble à ceci: {login: {pass: pass, add1: "123 sasd", ville: "Où que ce soit"}}.
Thomas Clayson

2
Votre dernier point est potentiellement correct, mais je pourrais ensuite utiliser d'anciennes données - en particulier, si j'ouvre votre programme, charge la base de données actuelle puis 5 minutes plus tard, quelqu'un d'autre se connecte et modifie quelque chose, ma base de données est désormais une version ultérieure jusqu'à ce que je quittez le programme et redémarrez-le. Si je modifie ensuite ma base de données et la sauvegarde à nouveau, j'écrase toutes les modifications apportées par l'autre utilisateur. Lorsque vous avez la base de données d’un utilisateur, vous pouvez changer votre mot de passe. Si deux utilisateurs changent leur mot de passe lors de leurs sessions respectives, leur modification sera annulée.
Thomas Clayson

4
J'ai beaucoup appris après quelques recherches sur l'indexation. C'était vraiment éclairant. Les bases de données ont un peu plus de sens maintenant. Il y a encore des choses que je ne comprends pas, mais c'est un grand progrès. Merci pour cette réponse!
MaiaVictor

4
À propos des index, non, la base de données n'indexe pas tout automatiquement. Peu de choses sont automatiquement indexées alors que les autres requièrent explicitement de "faire cette indexation". Et les indices réduisent la recherche au temps logarithmique, O (log (n)) qui est légèrement plus lent que constant.
Empereur Orionii

1
S'inquiéter de la différence entre une implémentation basée sur un hachage et une arborescence binaire est une optimisation prématurée. Si les données sont dans l'index, ce sera quand même douze fois plus rapide que de le lire à partir du disque.
SilverbackNet

14

Lorsque vous avez des données simples, comme une liste de choses que vous décrivez dans les commentaires de votre question, une base de données SQL ne vous en donnera pas beaucoup. Beaucoup de gens les utilisent encore, car ils savent que leurs données peuvent devenir de plus en plus compliquées avec le temps. De nombreuses bibliothèques rendent le travail avec les bases de données trivial.

Mais même avec une simple liste que vous chargez, gardez en mémoire, puis écrivez si nécessaire, peut souffrir de nombreux problèmes:

Une fin de programme anormale peut perdre des données, ou lors de l'écriture de données sur un disque, quelque chose ne va pas et vous pouvez finir par tuer tout le fichier. Vous pouvez utiliser vos propres mécanismes pour gérer cela, mais les bases de données le traitent pour vous en utilisant des techniques éprouvées.

Si vos données commencent à devenir trop volumineuses et à se mettre à jour trop souvent, la sérialisation de toutes vos données et leur enregistrement vont devenir une grosse ressource et tout ralentir. Vous devez commencer à travailler à la partition, afin que cela ne soit pas si coûteux. Les bases de données sont optimisées pour enregistrer uniquement les éléments modifiés sur le disque de manière tolérante aux pannes. En outre, ils sont conçus pour vous permettre de charger rapidement les petites données dont vous avez besoin à tout moment.

De plus, vous n'avez pas besoin d'utiliser des bases de données SQL. Vous pouvez utiliser des "bases de données" NoSQL comme beaucoup, il suffit d'utiliser JSON pour stocker les données. Mais cela se fait de manière tolérante aux pannes et de manière à ce que les données puissent être intelligemment divisées, interrogées et réparties intelligemment sur plusieurs ordinateurs.

En outre, certaines personnes mélangent les choses. Ils peuvent utiliser un magasin de données NoSQL comme Redis pour stocker les informations de connexion. Ensuite, utilisez des bases de données relationnelles pour stocker des données plus complexes où elles doivent effectuer des requêtes plus intéressantes.


12

Je vois que beaucoup de réponses se concentrent sur le problème de la simultanéité et de la fiabilité. Les bases de données offrent d'autres avantages que la concurrence, la fiabilité et les performances. Ils permettent de ne pas gêner la représentation des octets et des caractères dans la mémoire. En d'autres termes, les bases de données permettent au programmeur de se concentrer sur "quoi" plutôt que sur "comment".

Une des réponses mentionne des requêtes. "Poser une question à une base de données SQL" s'adapte bien à la complexité d'une question. Au fur et à mesure que le code évolue au cours du développement, des requêtes simples telles que "tout extraire" peuvent facilement être étendues à "tout extraire où propriété1 est égale à cette valeur, puis trier par propriété2" sans que le programmeur se préoccupe d'optimiser la structure de données pour une telle requête. Les performances de la plupart des requêtes peuvent être accélérées en créant un index pour une propriété donnée.

Les autres avantages sont les relations. Avec les requêtes, il est plus facile de référencer des données de différents ensembles de données, puis d'avoir des boucles imbriquées. Par exemple, la recherche de toutes les publications du forum à partir d'utilisateurs ayant moins de 3 publications dans un système où utilisateurs et publications sont des ensembles de données différents (ou des tables de base de données ou des objets JSON) peut être effectuée avec une seule requête sans compromettre la lisibilité.

Globalement, les bases de données SQL sont meilleures que les tableaux simples si le volume de données peut être important (plus de 1 000 objets), l’accès aux données dans des parties non triviales et différentes de l’accès de code à différents sous-ensembles de données.


Je suis un peu méfiant à l'idée que vous pouvez simplement ignorer la façon dont les choses sont représentées. Alors que vous pouvez ignorer cela, si vous le faites, et surtout. Si vous écrivez une requête légèrement plus complexe, il est fort probable que votre application ne pourra plus évoluer. "Ajouter un index" n'est pas toujours possible - vous devez faire face aux écritures et cela n'aide pas beaucoup aux requêtes dont la complexité couvre plusieurs tables. Lorsque des index sont nécessaires, cela signifie que vous avez perdu l'avantage de l'interrogation interactive, car seules les requêtes spécifiquement structurées peuvent être interrogées dans un délai raisonnable.
Eamon Nerbonne

12

TLDR

On dirait que vous avez pris une décision technique de magasin de données à court terme, essentiellement valable, pour votre application: vous avez choisi d'écrire un outil de gestion de magasin de données personnalisé.

Vous êtes assis sur un continuum, avec des options pour aller dans les deux sens.

À long terme, vous rencontrerez probablement des problèmes (presque, mais pas à 100% certainement) et il sera peut-être préférable de passer à l'utilisation de solutions de stockage de données existantes. Vous devrez résoudre des problèmes de performances spécifiques, très fréquents et prévisibles, et il vaut mieux utiliser les outils existants au lieu de les résoudre vous-même.


On dirait que vous avez écrit une (petite) base de données personnalisée, intégrée et directement utilisée par votre application. Je suppose que vous utilisez un système d’exploitation et un système de fichiers pour gérer l’écriture et la lecture du disque, et vous traitez la combinaison comme un magasin de données.

Quand faire ce que tu as fait

Vous êtes assis à un endroit idéal pour le stockage des données. Un magasin de données de système d’exploitation et de système de fichiers est extrêmement pratique, accessible et portable sur plusieurs plates-formes. La combinaison existe depuis si longtemps que vous êtes certain d'être pris en charge et de faire fonctionner votre application dans presque toutes les configurations de déploiement standard.

C'est aussi une combinaison facile pour écrire du code - l' API est assez simple et basique, et il faut relativement peu de lignes de code pour le faire fonctionner.

Généralement, il est idéal de faire ce que vous avez fait quand:

  • Prototyper de nouvelles idées
  • Construire des applications dont il est très peu probable qu'elles aient besoin d'évoluer, en termes de performances
  • Contraintes par des circonstances inhabituelles, telles que le manque de ressources pour l'installation d'une base de données

Des alternatives

Vous êtes sur un continuum d'options, et il y a deux "directions" que vous pouvez suivre, ce que je considère comme "bas" et "haut":

Vers le bas

C'est l'option la moins probable à appliquer, mais c'est par souci de complétude:

Vous pouvez, si vous le souhaitez, descendre , c'est-à-dire contourner complètement le système d'exploitation et le système de fichiers et réellement écrire et lire directement à partir du disque. Ce choix n’est généralement pertinent que dans les cas où une efficacité extrême est requise - par exemple, un lecteur MP3 minuscule / minime , ne disposant pas de suffisamment de RAM pour un système d’exploitation entièrement fonctionnel, ou de quelque chose comme la Wayback Machine , qui nécessite une masse incroyablement efficace. opérations d'écriture de données (la plupart des magasins de données compensent les écritures plus lentes pour des lectures plus rapides, car c'est le cas d'utilisation extrêmement répandu pour presque toutes les applications).

Up

Il y a plusieurs sous-catégories ici - celles-ci ne sont pas exactement exclusives, cependant. Certains outils couvrent les deux, fournissant des fonctionnalités dans chacun d’eux, certains peuvent basculer complètement d’un mode à l’autre, et certains peuvent être superposés, offrant des fonctionnalités différentes aux différentes parties de votre application.

Des magasins de données plus puissants

Vous devrez peut-être stocker des volumes de données de plus en plus importants tout en vous fiant à votre propre application pour gérer la complexité de la manipulation des données. Toute une gamme de magasins de valeurs-clés sont à votre disposition, avec différents degrés de prise en charge des fonctions associées. Les outils NoSQL entrent dans cette catégorie, ainsi que d’autres.

C’est le chemin évident à suivre lorsque les éléments suivants décrivent votre application:

  • Il est inhabituellement lourd en lecture
  • Vous êtes d'accord avec le compromis entre performances supérieures et garanties de cohérence inférieures (à court terme) (beaucoup offrent une "cohérence éventuelle").
  • Est "directement" en train de gérer la plupart des manipulations de données et manque de cohérence (en pratique, vous finirez probablement par utiliser un outil tiers au début, mais vous finirez par l'introduire dans votre application ou dans une couche intermédiaire écrite personnalisée) .
  • Vous cherchez à redimensionner massivement la quantité de données que vous stockez et / ou votre capacité à y effectuer des recherches, avec des exigences de manipulation de données "relativement simples".

Il y a une certaine marge de manœuvre ici - vous pouvez forcer une meilleure cohérence de lecture, pour des lectures plus lentes. Divers outils et options fournissent des apis pour la manipulation de données, l'indexation et d'autres options, qui peuvent être plus ou moins adaptées pour écrire facilement votre application spécifique. Ainsi, si les points ci-dessus décrivent presque complètement votre application, vous serez peut-être "suffisamment proche" pour utiliser une solution de stockage de données plus puissante.

Exemples connus: CouchDB , MongoDB , Redis , des solutions de stockage dans le cloud telles que Azure de Microsoft , Google App Data Store et Amazon ECE.

Des moteurs de manipulation de données plus complexes

La famille "SQL" d'applications de stockage de données, ainsi que de nombreuses autres, sont mieux décrites comme des outils de manipulation de données que des moteurs de stockage purs. Ils offrent un large éventail de fonctionnalités supplémentaires, allant au-delà du stockage de données et allant souvent au-delà de ce qui est disponible dans le magasin de clés-valeurs. Vous voudrez prendre ce chemin quand:

  • Vous devez absolument avoir une cohérence de lecture, même si cela signifie que vous allez perdre de la performance.
  • Vous cherchez à effectuer efficacement des manipulations de données très complexes - pensez aux opérations JOIN et UPDATE très complexes, aux cubes de données et au découpage en tranches, etc.
  • Vous pouvez accepter une perte de rigidité en termes de performances (pensez à des formats de stockage de données fixes, forcés, tels que des tableaux, qui ne peuvent pas être modifiés facilement et / ou efficacement).
  • Vous disposez des ressources nécessaires pour gérer un ensemble d'outils et d'interfaces souvent plus complexe.

C’est la manière la plus «traditionnelle» de penser une base de données ou un magasin de données, et elle existe depuis bien plus longtemps. C’est pourquoi beaucoup de choses sont disponibles ici, et il ya souvent beaucoup de complexité à gérer. Il est possible, bien que cela demande un peu d’expertise et de connaissances, et de construire des solutions simples / d’éviter une grande partie de la complexité. Vous finirez probablement par utiliser des outils et des bibliothèques tiers pour gérer la plupart de ceux-ci pour vous.

Des exemples bien connus sont MySQL , SQL Server , Oracle's Database et DB2 .

Externaliser le travail

Il existe plusieurs outils et bibliothèques tiers modernes, qui s'interposent entre vos outils de stockage de données et votre application, pour vous aider à gérer la complexité.

Ils tentent au départ d’enlever la plupart ou la totalité du travail de gestion et de manipulation des magasins de données et, idéalement, de vous permettre de passer en douceur à la complexité uniquement lorsque et si cela est nécessaire. Il s’agit d’un domaine actif d’entrepreneuriat et de recherche, avec quelques résultats récents qui sont immédiatement accessibles et utilisables.

Des exemples bien connus sont les outils MVC ( Django , Yii ), Ruby on Rails et Datomic . Il est difficile d'être juste ici, car il existe des dizaines d'outils et de bibliothèques qui encapsulent les API de divers magasins de données.


PS: si vous préférez les vidéos au texte, vous pouvez visionner certaines des vidéos de Rich Hickey relatives à la base de données; il élucide la plupart des réflexions nécessaires pour choisir, concevoir et utiliser un magasin de données.


11

Un système de fichiers correspond à la description d'une base de données NoSQL. Je dirais donc que vous devriez absolument envisager de l'utiliser lorsque vous décidez comment stocker vos données et non pas simplement le rejeter au profit du SGBDR, comme certaines réponses semblent le suggérer ici.

Un problème avec les systèmes de fichiers (et NoSQL en général) est la gestion des relations entre les données. Si ce n’est pas un bloqueur majeur ici, alors je dirais de sauter le SGBDR pour le moment. N'oubliez pas non plus les avantages de l'utilisation d'un système de fichiers en tant que stockage:

  • Administration zéro
  • Faible complexité, facile à mettre en place
  • Fonctionne avec tous les systèmes d'exploitation, langues, plates-formes, bibliothèques, etc.
  • Seul le paramètre de configuration est le répertoire
  • Trivial à tester
  • Trivial à examiner avec les outils existants, sauvegarder, modifier, etc.
  • Bonnes caractéristiques de performance et bien réglées par le système d'exploitation
  • Facile à comprendre pour tout développeur
  • Pas de dépendances, pas de pilotes supplémentaires
  • Le modèle de sécurité est simple à comprendre et constitue un élément de base du système d'exploitation
  • Les données ne sont pas accessibles de l'extérieur

( source )


10

Les systèmes de fichiers sont un type de base de données. Peut-être pas un SGBDR comme tout le monde en parle, mais certainement une base de données au sens strict. Vous fournissez des clés (nom de fichier) pour rechercher des données (contenu du fichier) contenant un stockage abstrait et une API par laquelle votre programme communique.

Donc, vous utilisez une base de données. Les autres posts peuvent discuter des vertus de différents types de bases de données ...


1
la base de données et le stockage ne peuvent pas vraiment être utilisés de manière interchangeable. Une base de données est un type de stockage, mais un système de fichiers n'est certainement pas un type de base de données
Gaz_Edge

3
"storage" est l'endroit où les bits et les octets sont conservés. Une base de données n'utilise pas nécessairement des fichiers sur un système de fichiers. Un système de fichiers est très certainement un type de base de données au sens le plus strict du terme.
Chris S

6
Pour quelqu'un qui soutient que les bases de données ne servent à rien lorsqu'elles sont utilisées, il est préférable d' utiliser une base de données ; Oui. Il semble utile de leur expliquer que leur argument repose sur une notion préconçue qui est fausse. Une fois qu'ils comprennent mieux leur situation initiale, nous pouvons les aider à aller de l'avant avec une compréhension plus complète des technologies disponibles. Les systèmes de fichiers sont des bases de données hiérarchiques, il y a de bonnes raisons pour lesquelles les systèmes de bases de données objet les ont supplantées car elles permettent un stockage / une récupération de données plus rapide, mieux organisé et plus efficace.
Chris S

2
@Gaz_Edge Les données se trouvent déjà dans une "base de données" inefficace, car elles sont stockées dans un groupe de fichiers dont la structure et le contenu sont tous deux gérés par l'application du PO. Essayer d'obtenir l'OP de comprendre et d' accepter c'est une première étape utile pour les amener à comprendre le cas d'utilisation d'un système de base de données « réel »; une fois qu’ils ont compris qu’une «base de données» existe de toute façon, il est plus facile de commencer à parler de la place où un service correctement structuré et géré est plus efficace que de laisser l’application agir à sa guise. Je dirais que cette réponse est très utile.
Rob Moir

8

Une base de données est nécessaire si plusieurs processus (utilisateurs / serveurs) modifient les données. Ensuite, la base de données les empêche de s’écraser les modifications apportées.

Vous avez également besoin d'une base de données lorsque vos données sont plus volumineuses que la mémoire. De nos jours, avec la mémoire dont nous disposons, cela rend en effet l'utilisation de bases de données dans de nombreuses applications obsolètes.

Votre approche est définitivement meilleure que le non-sens des "bases de données en mémoire". Qui sont essentiellement votre approche, mais avec beaucoup de frais généraux ajoutés.


Pour être honnête, j'adore cette réponse et j'aimerais que ce soit vrai, mais je ne suis pas sûr que ce soit le cas. Par exemple, certains utilisateurs (et vous) ont exprimé une préoccupation à propos de la mémoire. Bien sûr, si je stocke une quantité de données en Go, je ne peux pas tout garder en mémoire. Mais si je suis certain que les données ne seront jamais aussi volumineuses, devrais-je utiliser uniquement la mémoire? Eh bien, il y a aussi d'autres choses. Par exemple, j'ai entendu parler des vues incrémentielles de CouchDB. C'est certainement quelque chose qui, contrairement à l'indexation, ne serait PAS trivial à mettre en œuvre par vous-même, et constitue certainement une énorme accélération lorsque vous utilisez un modèle d'affichage,
MaiaVictor

que je suppose que je suis. Par exemple, lorsque je transforme des données de "liste de joueurs" en "classement", il ne s'agit que d'une opération de réduction de carte. Lorsque vous créez un jeu ou un site interactif, pratiquement tout ce que vous présentez est une opération mapReduce à partir de vos données de base! Donc, avoir ce genre d'optimisation pourrait être vraiment souhaitable. Eh bien, je ne sais pas si ce dont je parle a un sens, mais cela a du sens. J'apprends beaucoup aujourd'hui et j'aime beaucoup les concepts NoSQL. Merci pour la réponse (:
MaiaVictor

7

Vous devriez toujours vous demander si une application particulière a besoin d'un SGBDR. Trop d'applications sont construites avec un processus de conception qui suppose automatiquement tous les outils et frameworks requis au départ. Les bases de données relationnelles sont si courantes et de nombreux développeurs ont déjà travaillé sur des applications similaires et sont automatiquement inclus avant le démarrage du projet. De nombreux projets peuvent s'en tirer, alors ne jugez pas trop sévèrement.

Vous avez commencé votre projet sans un, et ça marche. Il était plus facile pour vous de le faire fonctionner sans attendre votre code SQL. Il n'y a rien de mal à cela.

À mesure que ce projet se développe et que les exigences deviennent plus complexes, certaines choses vont devenir difficiles à construire. Jusqu'à ce que vous recherchiez et testiez d'autres méthodes, comment savoir quelle est la meilleure? Vous pouvez poser des questions aux programmeurs et éliminer les mauvaises herbes à travers les flammes et «ça dépend» de répondre à cette question. Une fois que vous l’apprenez, vous pouvez considérer le nombre de lignes de code que vous êtes prêt à écrire dans votre langue pour gérer certains des avantages d’une base de données. À un moment donné, vous réinventez la roue.

Facile est souvent relatif. Certains frameworks peuvent créer une page Web et connecter un formulaire à une table de base de données sans demander à l'utilisateur d'écrire du code. Je suppose que si vous luttez avec la souris, cela pourrait être un problème. Tout le monde sait que ce n'est ni évolutif ni flexible, car, Dieu nous en préserve, tout est étroitement couplé à l'interface graphique. Un non-programmeur vient de construire un prototype; beaucoup de YAGNI se trouve ici.

Si vous préférez apprendre un ORM manipulé par la langue de votre choix plutôt que par SQL, essayez-le, mais essayez d'installer, de créer une table et d'extraire des données d'une base de données populaire avec SQL (Select * De; non trucs époustouflants). C'est facile à faire. C'est pourquoi quelqu'un les a créés en premier lieu. Cela ne semble pas être un investissement énorme pour prendre une décision éclairée. Vous pourriez probablement aussi faire un test de performance.


Juste pour noter que j'ai utilisé mysql pendant des années quand j'ai hébergé un "otserv". Devine quoi? Tout ce que cela apportait était des problèmes. Les gens pouvaient "cloner" des éléments en utilisant un truc sale après s'être rendu compte que leurs personnages avaient été sauvegardés lorsqu'ils s'étaient déconnectés, mais pas lorsque le serveur s'était écrasé. C'est un problème grave pour otservs. Et la communauté otserv est énorme. Cela ne se produirait pas s'ils stockaient simplement des données dans la mémoire et les sérialisaient périodiquement. J'ai donc modifié moi-même les sources, ces longs fichiers C ++, et commencé à enregistrer périodiquement sur mysql, au lieu de déconnecter les caractères. Devine quoi? C'était lent!
MaiaVictor

Mysql ne pouvait tout simplement pas gérer complètement l'état de sauvegarde toutes les 2 minutes environ. Il était assez clair que la sauvegarde a eu lieu - tout le serveur a "traîné" pendant une seconde. Maintenant, j'apprécierais vraiment que les personnes postant ici aient une réponse à cette question!
MaiaVictor

1
Ne jugez pas les SGBDR sur la base d'une seule application probablement mal codée. Surtout quand les modifications pour supporter une base de données ont été faites par une personne sans expérience dans la base de données.
Alroc

1
@Dokkat, j'espère que personne ne coupera le cordon d'alimentation entre le dépôt de fonds dans votre compte bancaire et l'écriture "périodique" du solde du compte sur disque. Vous avez décrit une architecture de perte de données garantie. Cela convient pour certaines applications, mais la plupart des applications de base de données offrent aux utilisateurs le pouvoir de choisir. Vous pouvez exécuter un seul nœud de base de données avec des sauvegardes et risquer de perdre certaines données ou utiliser la réplication pour éliminer les pertes de données en cas de défaillance d'un seul nœud.
mikerobi

@Dokkat afin que vous n'utilisiez pas MySql ni aucune autre base de données de style "serveur" complète. Vous utilisez Sqlite (ou similaire) et il persistera sur le disque à chaque fois, tout en vous donnant une base de données intégrée à votre application (aucune installation distincte n'est donc nécessaire) tout en vous donnant accès à SQL, à l'intégrité transactionnelle et à la persistance du disque.
gbjbaanb

6

Sauvegarde des données sur le disque IS en train d' écrire à une base de données, en particulier si vous mettez chaque objet dans son propre fichier avec le nom du fichier étant la clé de l'enregistrement. Et pour réduire les temps de recherche lors de la lecture du fichier, créez des sous-répertoires basés sur les premiers caractères de la clé.

Par exemple, key = ghostwriter irait dans g / ho / stwriter.json ou g / h / o / stwriter.json ou g / ho / ghostwriter.json ou g / h / o / ghostwriter.json. Choisissez votre schéma de nommage basé sur la distribution de vos clés. Si ce sont des numéros de séquence, alors 5/4/3 / 12345.json est meilleur que l’inverse.

C'est une base de données et si elle fait tout ce dont vous avez besoin, faites-le ainsi. De nos jours, cela s'appellerait une base de données NoSQL comme GDBM ou Berkeley db. Tant de choix. Déterminez d’abord ce dont vous avez besoin, puis créez une bibliothèque d’interface pour traiter les détails, peut-être une interface get / set telle que memcached ou une interface CRUD, puis vous pourrez échanger des bibliothèques si vous devez modifier le format de la base de données pour une seule. avec des caractéristiques différentes.

Notez que certaines bases de données SQL telles que PostgreSQL et Apache Derby DB vous permettront d'effectuer des requêtes SQL par-dessus de nombreux formats NoSQL, notamment vos propres bases de données internes. Pas sûr de MyBatis mais c'est peut-être similaire.

Évitez le battage médiatique NoSQL. Lisez à propos des fonctionnalités, testez les performances et les fonctionnalités, puis choisissez en fonction de la pertinence des fonctionnalités de votre application.

http://www.hdfgroup.org/HDF5/ est un autre format de banque de données intéressant et largement utilisé que les utilisateurs ne considèrent pas souvent.


4

Dès que les données sont mises à jour simultanément, l'approche utilisant une base de données (il pourrait s'agir d'une base de données en mémoire) sera probablement plus correcte et plus performante, tandis que votre code reste facile, car vous n'avez tout simplement pas se préoccuper des mises à jour simultanées, des transactions, de la mise en cache, des E / S asynchrones et de tout cela.


Les modifications simultanées au sein d'un processus seront plus efficaces en utilisant des verrous en cours de processus plutôt que IPC à un démon de base de données qui acquiert un tas de verrous. Mais vous parlez probablement de plusieurs processus modifiant les données.
Dhasenan

@ Dhasenan - Ceci est un autre avantage de bons systèmes de bases de données. Vous obtenez la concurrence, et cela fonctionne dans tous les cas: multi-thread, multi-processus, plusieurs clients sur différents serveurs, ou toute combinaison de ceux-ci. Votre programme multithread, bien que bien construit, peut être "plus efficace" dans certains cas, mais il ne pourra tout simplement pas s’adapter.
Ingo

-5

Vous avez besoin d’une base de données pour stocker / récupérer les QA comme ceux que nous publions ici! Un fichier simple est incapable d'organiser des données liées à différents sujets.


3
Non, les "sujets" peuvent être des dossiers et les "publications" du site peuvent être des fichiers. Il est certainement possible de lancer un site comme celui-ci à partir d'un système de fichiers. Ce n'est pas efficace: il est lent et compliqué à développer, à lancer des requêtes, à insérer de nouvelles données, etc.
Chris S

lent + compliqué = incapable?
Joe

Lent et compliqué à construire! = Lent et compliqué à fonctionner
joe

1
@ joe, ce n'est vraiment pas vrai qu'un fichier (peut-être pas un "simple" fichier, mais qu'est-ce que cela signifie?) ne peut pas être utilisé pour organiser des données liées à différents sujets. Vous pouvez utiliser JSON, comme le suggère Dokkat, ou XML, ou des fichiers à enregistrement mixte, comme nous le faisions à l'époque pré-XML, ou tout autre format de fichier que vous pouvez imaginer. Je ne recommanderais aucune de ces approches pour la plupart des scénarios, mais cela ne signifie pas qu'elles ne peuvent pas être réalisées.
John M Gant

@John M Gant: tout à fait d'accord avec vous, les bases de données ne peuvent remplacer des fichiers simples (car vous n'aimez pas les fichiers simples), et inversement, pour la seule raison qu'une voiture ne peut pas remplacer un vélo. Je parle 3 langues "humaines", et mon choix de mots et de vocabulaire est la raison pour laquelle j'ai été mal compris ... je suppose
joe
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.