Pouvez-vous indiquer des outils de stockage de données alternatifs et donner de bonnes raisons de les utiliser à la place de 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.
Réponses:
Fichiers texte brut dans un système de fichiers
Fichiers XML ou JSON sur disque
Feuille de calcul / fichier CSV
Subversion (ou système de contrôle de version sur disque similaire)
Berkeley DB (Fondamentalement, une table de hachage sur disque)
La base de données simple d'Amazon
Le magasin de données App Engine de Google
Collections en langue native (stockées en mémoire ou sérialisées sur disque)
Moteur de stockage personnalisé (écrit à la main)
Je ne peux pas prétendre en savoir grand-chose, mais vous aimerez peut-être aussi vous pencher sur les systèmes de bases de données d'objets .
La réponse de Matt Sheppard est excellente (mod up), mais je prendrais en compte ces facteurs lorsque je pense à une broche:
Un avantage particulier des fichiers CSV par rapport aux SGBDR est qu'ils peuvent être faciles à condenser et à déplacer vers pratiquement n'importe quelle autre machine. Nous effectuons des transferts de données volumineux, et tout est assez simple, nous n'utilisons qu'un seul gros fichier CSV et facile à créer des scripts à l'aide d'outils tels que rsync. Pour réduire la répétition sur les gros fichiers CSV, vous pouvez utiliser quelque chose comme YAML . Je ne suis pas sûr que je stocke quelque chose comme JSON ou XML, sauf si vous avez 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 faiblement structurées à analyser et que vous voulez ê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 étaient essentiellement tous les nombres de chronométrage des différentes fonctions enregistrées sur environ 20 machines. Après avoir essayé de tout coller dans un SGBDR, j'ai réalisé que je n'ai vraiment pas besoin d'interroger à nouveau les données une fois que je les ai agrégées. Et ce n'est utile que dans son format agrégé pour moi. Donc, je garde les fichiers journaux autour, compressés, puis laisse les données agrégées dans une base de données.
Notez que je suis plus habitué à penser aux "grandes" tailles.
Essayez Prevayler: http://www.prevayler.org/wiki/ Prevayler est une alternative au SGBDR. Dans le site ont plus d'informations.
Si vous n'avez pas besoin d' ACID , 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 ne fournissent pas ACID.
Moteur de stockage personnalisé (manuscrit) / Performances potentiellement très élevées dans les cas d'utilisation requis
Si vous avez d'énormes ensembles de données, au lieu de déployer 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, y compris des tableaux multidimensionnels, des images raster et des tables.
C'est aussi 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 de la NASA / JPL.
G'day,
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.
Dans presque tous ces cas, un OO DB est utilisé, soit un produit commercial, soit un système auto-roulé qui permet des héritages d'objets.
J'ai travaillé sur une application de surveillance 3G pour une grande entreprise qui restera sans nom, mais dont le logo est une tache de vin rouge (-:, et ils ont utilisé un tel OO DB pour garder une trace de tous les différents attributs des cellules individuelles dans le 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.
à votre santé,
Rob
Les bases de données d'objets ne sont pas des bases de données relationnelles. Ils peuvent être très utiles si vous souhaitez simplement insérer des 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.
Il y avait un outil RAD appelé JADE écrit il y a quelques années avec un OODBMS intégré. Les versions antérieures du moteur DB supportaient également Digitalk Smalltalk. Si vous souhaitez échantillonner la création d'applications à l'aide d'un paradigme non SGBDR, cela peut être un début.
Les autres produits OODBMS incluent Objectivity , GemStone (vous aurez besoin de VisualWorks Smalltalk pour exécuter la version Smalltalk mais il existe également une version java). Il y avait aussi quelques projets de recherche open source dans cet espace - EXODUS et son descendant SHORE viennent à l'esprit.
Malheureusement, le concept a semblé mourir d'une mort, probablement en raison de l'absence d'une norme clairement visible et d'une capacité de requête ad hoc relativement faible par rapport aux systèmes RDMBS basés sur SQL.
Un OODBMS est le plus approprié pour les applications avec des structures de données de base qui sont mieux représentées sous la forme d'un graphique de nœuds interconnectés. J'avais l'habitude de dire que l'application OODBMS par excellence était un donjon multi-utilisateur (MUD) où les salles contiendraient les avatars des joueurs et d'autres objets.
Vous pouvez aller très loin en utilisant simplement des fichiers stockés dans le système de fichiers. Les SGBDR s'améliorent dans la gestion des blobs, mais cela peut être un moyen naturel de gérer les données d'image et autres, 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 faciles à utiliser.
Des services comme Amazon S3 fournissent des modèles de stockage plus simples (clé-> valeur) qui ne prennent pas en charge SQL. L'évolutivité est la clé ici.
Les fichiers Excel peuvent également être utiles, en particulier si les utilisateurs doivent pouvoir manipuler les données dans un environnement familier et créer une application complète pour ce faire n'est pas faisable.
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 à partir d'une simple bibliothèque de code qui manipule un fichier local (ou des fichiers) comme s'il s'agissait d'une base de données relationnelle sur une base utilisateur unique, via des systèmes basés sur des fichiers qui peuvent gérer plusieurs utilisateurs à une sélection généreuse de systèmes sérieux basés sur des «serveurs».
Nous utilisons beaucoup les fichiers XML - vous obtenez des données bien structurées, de bons outils pour interroger, même la possibilité de faire des modifications si nécessaire, quelque chose qui est 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 db). Cela fonctionne bien pour les éléments qui sont 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 où vous pouvez simplement charger les données et les enregistrer si nécessaire - mais vous créez des opportunités. pour les problèmes si vous voulez l'édition multi-utilisateur - au moins d'un seul fichier.
Pour nous, c'est à peu près tout - nous allons soit utiliser quelque chose qui fera du SQL (MS propose un ensemble d'outils qui s'exécutent à partir d'un .DLL pour faire des choses à un seul 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 à manipuler les données binaires dans nos applications pour que cette question ne se pose pas.
Murph
On pourrait envisager l'utilisation d'un serveur LDAP à la place d'une base de données SQL traditionnelle si les données d'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 en son sein une bibliothèque BTree qui est dans le domaine public (comme dans véritablement «domaine public», n'utilisant pas le terme de manière lâche).
Franchement cependant, 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, qui peuvent être interrogées 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 ne s'attaquent pas après coup. En particulier, les domaines juridique et médical ont de grandes bandes de texte non structuré à stocker et à parcourir.
Aussi: * Scénarios intégrés - Là 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 ce 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
Le théorème CAP l' explique succinctement. SQL fournit principalement une "forte cohérence: tous les clients voient la même vue, même en présence de mises à jour".
J'offrirais RDBMS :) Si vous n'avez pas l'habitude d'avoir des problèmes avec l'installation / l'administration, optez pour SQLite. SGBDR intégré avec support SQL complet. Il vous permet même de stocker tout 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 le rechercher? 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 propose également des 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 une base de données relationnelle serait lorsque vous avez 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és Hadoop .
Je recommanderais fortement Lua comme alternative au stockage de données de type SQLite.
Car:
Il s'agit de l'option «collection de langue maternelle» de la réponse acceptée. Si vous utilisez C / C ++ comme niveau d'application, il est parfaitement raisonnable de lancer le moteur Lua (100 Ko de binaire) juste pour lire les configurations / données ou les écrire.