Bonnes raisons de NE PAS utiliser une base de données relationnelle?

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.

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 exemple, des é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 facile à comprendre pour les utilisateurs professionnels

Subversion (ou système de contrôle de version sur disque similaire)

• Très bon support pour le versionnage des données

Berkeley DB (Fondamentalement, une table de hachage sur disque)

• Conceptuellement très simple (juste une clé / valeur non tapée)
• Tres rapide
• Pas de frais généraux d'administration
• Prend en charge les transactions, je crois

La base de données simple d'Amazon

• Tout comme Berkeley DB je crois, mais hébergé

Le magasin 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)

CouchDB

• Focus sur le document
• Stockage simple des 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, 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:

1. Structure: est-ce qu'il se brise évidemment en morceaux ou faites-vous des compromis?
2. Utilisation: comment les données seront-elles analysées / récupérées / agrandies?
3. Durée de vie: combien de temps les données sont-elles utiles?
4. Taille: combien de données y a-t-il?

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.

Prety du système de fichiers pratique pour stocker des données binaires, qui ne fonctionne jamais étonnamment bien dans les bases de données relationnelles.

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

http://www.hdfgroup.org/

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.

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 le lien wiki

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".

KISS: Gardez-le petit et simple

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:

• Le langage a été conçu comme un langage de description de données pour commencer
• La syntaxe est lisible par l'homme (XML ne l' est pas )
• On peut compiler des morceaux Lua en binaire, pour des performances supplémentaires

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.