Pouvez-vous s'il vous plaît indiquer des outils de stockage de données alternatifs et donner de bonnes raisons de les utiliser au lieu des bonnes vieilles bases de données relationnelles? À mon avis, la plupart des applications n'utilisent que rarement toute la puissance de SQL - il serait intéressant de voir comment construire une application sans SQL.
Réponses
Trop de publicités?
Fichiers textes simples dans un système de fichiers
- Très simple à créer et à éditer
- Facile pour les utilisateurs à manipuler avec des outils simples (i.e. éditeurs de texte, grep etc)
- Stockage efficace des documents binaires
Fichiers XML ou JSON sur le disque
- Comme ci-dessus, mais avec un peu plus de possibilité de valider la structure.
Fichier de feuille de calcul / CSV
- Modèle très facile à comprendre pour les utilisateurs professionnels
Système de contrôle de version basé sur le disque, Subversion (ou similaire)
- Très bon support pour la version des données
Berkeley DB (Essentiellement, une table de hachage basée sur le disque)
- Très simple conceptuellement (juste une clé/valeur non typée)
- Plutôt rapide
- Pas de surcharge d'administration
- Supporte les transactions je crois
- Très similaire à Berkeley DB je crois, mais hébergé
- Hébergé et hautement scalable
- Stockage par clé-valeur par document (c'est-à-dire un modèle de données flexible)
- Concentration sur les documents
- Stockage simple des données semi-structurées/basées sur des documents
Collections de langage natif (stockées en mémoire ou sérialisées sur le disque)
- Intégration très serrée avec le langage
Moteur de stockage personnalisé (écrit à la main)
- Potentiellement très performant dans les cas d'utilisation requis
Je ne prétends pas en savoir beaucoup sur eux, mais vous pourriez également envisager de regarder les systèmes de base de données objet.
Tristan Juricek
Points
1362
La réponse de Matt Sheppard est excellente (répondez positivement), mais je prendrais en compte ces facteurs lorsque vous réfléchissez à une broche :
- Structure : est-ce qu'elle se casse évidemment en morceaux, ou faites-vous des compromis ?
- Utilisation : comment les données seront-elles analysées/récupérées/comprises ?
- Durée de vie : pendant combien de temps les données seront-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 de gros transferts de données, et tout est assez simple, nous utilisons simplement un gros fichier CSV, et facile à scripter à l'aide d'outils comme rsync. Pour réduire la répétition sur de gros fichiers CSV, vous pourriez utiliser quelque chose comme YAML. Je ne suis pas sûr de stocker quoi que ce soit comme JSON ou XML, sauf si vous avez des exigences de relation significatives.
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 autres machines pour gérer le traitement des données.
Par exemple, j'ai commencé à essayer d'analyser des performances qui étaient essentiellement tous des timings de différentes fonctions enregistrées sur environ 20 machines. Après avoir essayé de tout mettre dans une 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, elle n'est utile pour moi qu'à son format agrégé. Donc, je garde les fichiers journaux, compressés, et laisse les données agrégées dans une base de données.
Remarque Je suis plus habitué à penser avec des tailles "grandes".
Ubiguchi
Points
2145
zaca
Points
417
Essayez Prevayler : http://www.prevayler.org/wiki/ Prevayler est une alternative aux SGBDR. Sur le site, vous trouverez plus d'informations.
Jared Updike
Points
3946
Moteur de stockage personnalisé (écrit à la main) / Potentiellement très performant dans les cas d'utilisation requis
Si vous avez d'énormes ensembles de données, au lieu de créer le vôtre, vous pourriez 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 matricielles et des tables.
C'est aussi hiérarchique comme un système de fichiers, mais les données sont stockées dans un seul fichier binaire magique.
HDF5 est une suite qui rend possible la gestion de collections de données extrêmement grandes et complexes.
Pensez aux pétaoctets de données de télédétection de la NASA/JPL.
