De bonnes raisons de NE PAS utiliser une base de données relationnelle ?
https://stackoverflow.com/questions/37823
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianQuestion
Pouvez-vous s'il vous plaît indiquer des outils de stockage de données alternatifs et donner de bonnes raisons de les utiliser à la place des bonnes vieilles bases de données relationnelles ?À mon avis, la plupart des applications utilisent rarement toute la puissance de SQL. Il serait intéressant de voir comment créer une application sans SQL.
La solution
Fichiers texte brut dans un système de fichiers
- Très simple à créer et à modifier
- Facile à manipuler pour les utilisateurs avec des outils simples (par ex.éditeurs de texte, grep etc.)
- Stockage efficace des documents binaires
Fichiers XML ou JSON sur disque
- Comme ci-dessus, mais avec un peu plus de capacité à valider la structure.
Feuille de calcul / fichier CSV
- Modèle très simple à comprendre pour les utilisateurs professionnels
Subversion (ou système de contrôle de version similaire basé sur disque)
- Très bon support pour le versionnage des données
Base de données de Berkeley (En gros, une table de hachage basée sur disque)
- Très simple sur le plan conceptuel (juste une clé/valeur non typée)
- Tres rapide
- Pas de frais administratifs
- Prend en charge les transactions, je crois
Base de données simple d'Amazon
- Un peu comme Berkeley DB je crois, mais hébergé
Banque de données App Engine de Google
- Hébergé et hautement évolutif
- Stockage clé-valeur par document (c.-à-d.modèle de données flexible)
- Objectif du document
- Stockage simple de données semi-structurées/basées sur des documents
Collections en langue native (stockées en mémoire ou sérialisées sur disque)
- Intégration linguistique très étroite
Moteur de stockage personnalisé (écrit à la main)
- Performances potentiellement très élevées dans les cas d’utilisation requis
Je ne peux pas prétendre en savoir grand-chose à leur sujet, mais vous aimeriez peut-être aussi vous pencher sur systèmes de bases de données d'objets.
Autres conseils
La réponse de Matt Sheppard est excellente (mod up), mais je prendrais en compte ces facteurs lorsque je pense à une broche :
- Structure :est-ce qu'il se brise évidemment en morceaux, ou faites-vous des compromis ?
- Utilisation :comment les données seront-elles analysées/récupérées/grokkées ?
- Durée de vie :pendant combien de temps les données sont-elles utiles ?
- Taille :combien de données y a-t-il ?
Un avantage particulier des fichiers CSV par rapport aux SGBDR est qu'ils peuvent être facilement condensés et déplacés vers pratiquement n'importe quelle autre machine.Nous effectuons des transferts de données volumineux, et tout est assez simple, nous utilisons simplement un gros fichier CSV et facile à scripter à l'aide d'outils comme rsync.Pour réduire les répétitions sur les gros fichiers CSV, vous pouvez utiliser quelque chose comme YAML.Je ne suis pas sûr de stocker quelque chose comme JSON ou XML, à moins que vous n'ayez des exigences relationnelles importantes.
En ce qui concerne les alternatives non mentionnées, ne négligez pas Hadoop, qui est une implémentation open source de MapReduce.Cela devrait bien fonctionner si vous avez une tonne de données peu structurées qui doivent être analysées et que vous souhaitez être dans un scénario où vous pouvez simplement ajouter 10 machines supplémentaires pour gérer le traitement des données.
Par exemple, j'ai commencé à essayer d'analyser les performances qui consistaient essentiellement en tous les numéros de synchronisation de différentes fonctions enregistrées sur une vingtaine de machines.Après avoir essayé de tout coller dans un SGBDR, j'ai réalisé que je n'avais vraiment pas besoin d'interroger à nouveau les données une fois que je les avais agrégées.Et cela ne m’est utile que dans son format agrégé.Ainsi, je conserve les fichiers journaux, compressés, puis je laisse les données agrégées dans une base de données.
Note Je suis plus habitué à penser aux « grandes » tailles.
Le système de fichiers est très pratique pour stocker des données binaires, ce qui ne fonctionne jamais à merveille dans les bases de données relationnelles.
Essayez Prevayler :http://www.prevayler.org/wiki/Prevayler est une alternative au SGBDR.Sur le site, vous trouverez plus d'informations.
Si tu n'as pas besoin ACIDE, vous n'avez probablement pas besoin de la surcharge d'un SGBDR.Alors, déterminez si vous en avez besoin en premier.La plupart des réponses non-SGBDR fournies ici le font pas fournir de l'ACIDE.
Moteur de stockage personnalisé (écrit à la main) / Potentiellement très hautes performances dans les cas d'utilisation requis
Si vous disposez d'énormes ensembles de données, au lieu de créer les vôtres, vous pouvez utiliser HDF, le format de données hiérarchique.
http://en.wikipedia.org/wiki/Hierarchical_Data_Format:
HDF prend en charge plusieurs modèles de données différents, notamment des tableaux multidimensionnels, des images raster et des tableaux.
Il est également hiérarchique comme un système de fichiers, mais les données sont stockées dans un fichier binaire magique.
HDF5 est une suite qui permet la gestion de collections de données extrêmement volumineuses et complexes.
Pensez aux pétaoctets de données de télédétection NASA/JPL.
Bonjour,
Un cas auquel je peux penser est celui où les données que vous modélisez ne peuvent pas être facilement représentées dans une base de données relationnelle.
Un tel exemple est la base de données utilisée par les opérateurs de téléphonie mobile pour surveiller et contrôler les stations de base des réseaux de téléphonie mobile.
J'ai presque tous ces cas, un Base de données OO est utilisé, soit un produit commercial, soit un système auto-laminé qui permet des hiérarchies d'objets.
J'ai travaillé sur une application de surveillance 3G pour une grande entreprise qui restera anonyme, mais dont le logo est une tache de vin rouge (- :, et ils ont utilisé une telle base de données OO pour garder une trace de tous les différents attributs des cellules individuelles du réseau.
L'interrogation de ces bases de données est effectuée à l'aide de techniques propriétaires qui sont généralement totalement exemptes de SQL.
HTH.
acclamations,
Rob
Les bases de données d'objets ne sont pas des bases de données relationnelles.Ils peuvent être très pratiques si vous souhaitez simplement insérer quelques objets dans une base de données.Ils prennent également en charge la gestion des versions et modifient les classes pour les objets qui existent déjà dans la base de données. db4o est le premier qui me vient à l’esprit.
Dans certains cas (données des marchés financiers et contrôle des processus par exemple), vous devrez peut-être utiliser une base de données en temps réel plutôt qu'un SGBDR.Voir lien wiki
Il existait un outil RAD appelé JADE écrit il y a quelques années et doté d'un SOODBMS intégré.Les incarnations antérieures du moteur DB prenaient également en charge Digitalk Smalltalk.Si vous souhaitez échantillonner la création d'applications à l'aide d'un paradigme non-SGBDR, cela pourrait être un début.
D'autres produits OODBMS incluent Objectivité, Gemme (Vous devrez obtenir Travaux visuels Smalltalk pour exécuter la version Smalltalk mais il existe également une version java).Il y avait également des projets de recherche open source dans cet espace – EXODUS et son descendant SHORE viennent à l’esprit.
Malheureusement, le concept a semblé mourir, probablement en raison de l'absence d'un standard clairement visible et d'une capacité de requête ad hoc relativement médiocre par rapport aux systèmes RDMBS basés sur SQL.
Un SOODBMS convient particulièrement aux applications dont les structures de données de base sont mieux représentées sous forme de graphique de nœuds interconnectés.J'avais l'habitude de dire que l'application ODBMS par excellence était un donjon multi-utilisateur (MUD) où les salles contenaient les avatars des joueurs et d'autres objets.
Vous pouvez aller très loin en utilisant simplement les fichiers stockés dans le système de fichiers.Les SGBDR s'améliorent dans la gestion des blobs, mais cela peut constituer un moyen naturel de gérer les données d'image, etc., en particulier si les requêtes sont simples (énumération et sélection d'éléments individuels.)
D'autres éléments qui ne s'intègrent pas très bien dans un SGBDR sont les structures de données hiérarchiques et je suppose que les données géospatiales et les modèles 3D ne sont pas non plus si faciles à utiliser.
Des services comme Amazone S3 fournir des modèles de stockage plus simples (clé-> valeur) qui ne prennent pas en charge SQL.L’évolutivité est ici la clé.
Les fichiers Excel peuvent également être utiles, en particulier si les utilisateurs doivent pouvoir manipuler les données dans un environnement familier et qu'il n'est pas possible de créer une application complète pour ce faire.
Il existe un grand nombre de façons de stocker des données - même la "base de données relationnelle" couvre une gamme d'alternatives allant d'une simple bibliothèque de code qui manipule un ou plusieurs fichiers locaux comme s'il s'agissait d'une base de données relationnelle pour un seul utilisateur, en passant par des systèmes basés sur des fichiers pouvant gérer plusieurs utilisateurs à une sélection généreuse de systèmes sérieux basés sur "serveur".
Nous utilisons beaucoup de fichiers XML - vous obtenez des données bien structurées, de bons outils pour les interroger, la possibilité d'effectuer des modifications le cas échéant, quelque chose de lisible par l'homme et vous n'avez alors pas à vous soucier du fonctionnement du moteur de base de données (ou du fonctionnement du moteur de base de données).Cela fonctionne bien pour les éléments essentiellement en lecture seule (dans notre cas, le plus souvent générés à partir d'une base de données ailleurs) et également pour les systèmes mono-utilisateur dans lesquels vous pouvez simplement charger les données et les enregistrer si nécessaire - mais vous créez des opportunités. des problèmes si vous souhaitez une édition multi-utilisateurs - au moins d'un seul fichier.
Pour nous, c'est tout - soit nous allons utiliser quelque chose qui fera du SQL (MS propose un ensemble d'outils qui s'exécutent à partir d'un .DLL pour effectuer des tâches mono-utilisateur jusqu'au serveur d'entreprise et ils parlent tous le même SQL (avec des limitations à l'extrémité inférieure)) ou nous allons utiliser XML comme format car (pour nous) la verbosité est rarement un problème.
Nous n'avons actuellement pas besoin de manipuler des données binaires dans nos applications pour que cette question ne se pose pas.
Murph
On pourrait envisager d'utiliser un serveur LDAP à la place d'une base de données SQL traditionnelle si les données de l'application sont fortement orientées clé/valeur et de nature hiérarchique.
Les fichiers BTree sont souvent beaucoup plus rapides que les bases de données relationnelles.SQLite contient une bibliothèque BTree qui se trouve dans le domaine public (comme dans le véritable « domaine public », sans utiliser le terme au sens large).
Franchement, si je voulais un système multi-utilisateurs, j'aurais besoin de beaucoup de persuasion pour ne pas utiliser une base de données relationnelle de serveur décente.
Bases de données en texte intégral, interrogeables avec des opérateurs de proximité tels que « dans les 10 mots de », etc.
Les bases de données relationnelles sont un outil commercial idéal à de nombreuses fins : assez faciles à comprendre et à concevoir, assez rapides, adéquates même lorsqu'elles ne sont pas conçues et optimisées par un génie qui pourrait « utiliser toute la puissance », etc.
Mais certains objectifs commerciaux nécessitent une indexation de texte intégral, que les moteurs relationnels ne fournissent pas ou y ajoutent après coup.En particulier, les domaines juridique et médical disposent de vastes étendues de textes non structurés à stocker et à parcourir.
Aussi:* Scénarios intégrés : où il est généralement nécessaire d'utiliser quelque chose de plus petit qu'un SGBDR à part entière. DB4o est un ODB qui peut être facilement utilisé dans un tel cas.* Développement rapide ou preuve de concept - où vous souhaitez vous concentrer sur l'entreprise et ne pas vous soucier de la couche de persistance
Théorème du CAP l'explique succinctement.SQL fournit principalement une « cohérence forte :tous les clients voient la même vue, même en présence de mises à jour".
BAISER:Gardez-le petit et simple
J'offrirais des Smbre-RDB :) Si vous n'auriez pas besoin d'avoir des problèmes avec la configuration / l'administration, optez pour SQLite.SGBDR intégré avec prise en charge complète de SQL.Il vous permet même de stocker n'importe quel type de données dans n'importe quelle colonne.
Principal avantage par rapport au fichier journal par exemple :Si vous en avez un énorme, comment allez-vous y chercher ?Avec le moteur SQL, vous créez simplement un index et accélérez considérablement les opérations.
À propos de la recherche en texte intégral :SQLite dispose également de modules pour la recherche en texte intégral.
Profitez simplement d'une belle interface standard pour vos données :)
Une bonne raison de ne pas utiliser de base de données relationnelle serait lorsque vous disposez d’un ensemble de données massif et que vous souhaitez effectuer un traitement massivement parallèle et distribué sur les données.L’index Web de Google serait un parfait exemple d’un tel cas.
Hadoop a également une implémentation du Système de fichiers Google appelé le Système de fichiers distribué Hadoop.
Je recommanderais fortement Lua comme alternative au stockage de données de type SQLite.
Parce que:
- Le langage a été conçu comme un langage de description de données pour commencer
- La syntaxe est lisible par l'homme (XML est pas)
- On peut compiler des morceaux Lua en binaire, pour des performances accrues
Il s'agit de l'option "Collection en langue maternelle" de la réponse acceptée.Si vous utilisez C/C++ comme niveau d'application, il est parfaitement raisonnable d'ajouter le moteur Lua (100 Ko de binaire) juste pour lire les configurations/données ou les écrire.
