Je recherche différents types de bases de données et de SGBD pour un nouveau projet que je souhaite démarrer en été.
J'ai construit des systèmes dans MySQL et postgreSQL, maintenant je veux étendre mes connaissances et mon expérience dans les bases de données.
Mon projet sera un type de réseau social / de connaissances agrégées. (Je n'ai pas encore développé de terme pour le décrire).
J'ai regardé:
- Cassandra (utiliser son propre type de langage de requête); Il semble être bon pour le contenu riche en fonctionnalités et offrant une exécution de requête haute performance. Cependant, je ne suis pas trop intéressé car il nécessite un environnement java pour fonctionner et je préférerais ne rien avoir à faire avec Oracle.
- MongoDB (type de SGBD noSQL); grande évolutivité, mais vous perdez toutes les capacités déjà disponibles sur le langage SQL éprouvé comme les requêtes d'informations commerciales.
Exigences du système:
- Texte de données , dates, heures, xml, petits caractères, blob,
- Structure / comportement : 3NF normalisé, non temps réel, relationnel, évolutif, robuste
- Environnement: unix / linux, pas de JAVA !, fonctionne de préférence sur C
Je me demandais si vous pouviez me diriger vers d'autres systèmes de base de données sur lesquels je devrais faire des recherches.
J'ai également jeté un œil aux bases de données relationnelles objet, j'aime beaucoup l'idée de travailler avec des objets PHP (PDO) mais leurs performances semblent un peu médiocres.
Étant donné qu'il y aura des DBA ici, tout commentaire sur ces systèmes que vous avez exploités serait apprécié.
Merci
la source
Réponses:
Vos exigences abstraites me crient "PostgreSQL". Cependant, je pense que cela vaut la peine de se tenir au courant de ce que fait la bourgeoisie, alors voici une liste de diverses choses que vous voudrez peut-être vérifier.
Trucs gratuits
Trucs gratuits étranges
Trucs non gratuits
Conclusion
Je n'ai utilisé aucune de ces choses de façon intensive. J'ai joué un peu avec la plupart d'entre eux et je me suis toujours retrouvé avec PostgreSQL. Au vu de vos besoins, le seul PostgreSQL qui ne répond pas dès le départ est l'évolutivité. D'un autre côté, pour mes besoins, il est beaucoup plus facile de lancer 4000 $ de matériel sur une seule machine de base de données dédiée que de lancer 4000 $ de nœuds cloud ou de machines bas de gamme à ce problème. Et il existe des moyens d'atteindre l'évolutivité avec PostgreSQL, comme avec EnterpriseDB .
C'est très amusant de jouer avec ces choses sur le côté, mais quand vient le temps de mettre des données de production précieuses et irréproductibles dans quelque chose, un tas d'attributs ennuyeux comme la fiabilité, la stabilité et la viabilité à long terme se retrouvent au premier plan.
Expérience de pensée pour vous
Considère ceci. Imaginez que vous êtes Mark Zuckerberg, et vous devez choisir de renoncer à votre base de code ou à vos données. Vous pouvez conserver toute votre équipe de développement, mais vous devez soit abandonner tout votre code - chaque ligne, dire même à tous les développeurs les souvenirs de la façon dont ils ont tout implémenté - mais vous pouvez garder tous vos comptes d'utilisateurs et tous vos utilisateurs téléchargés données et tout ça, ou vous pouvez renoncer à toutes les données. Conservez toutes les structures et serveurs et la configuration, la configuration, mais perdez chaque ligne de chaque table de chaque base de données.
Il devrait être évident qu'il serait pire de perdre les données. Pourquoi tous vos utilisateurs régénéreraient-ils toutes ces données? Pensez à toutes les données marketing perdues, c'est ainsi que Facebook gagne réellement de l'argent. Et il y a des tonnes d'entrepreneurs qui salivent à l'occasion d'amener les gens à utiliser leur clone Facebook - maintenant tous ces anciens utilisateurs de Facebook privés de leurs droits seraient là-bas à envisager des alternatives. D'un autre côté, s'ils perdaient la base de code, ils pourraient la reconstruire, probablement encore mieux qu'aujourd'hui, mais ils pourraient avoir quelque chose en ligne en très peu de temps. Heck - ils pourraient probablement acheterFacebook clone la base de code de quelqu'un d'autre et chargez-le avec les vraies données, mais vous ne pouvez pas simplement copier leurs données. Si Facebook a toujours les données importantes de tout le monde sur ses serveurs, l'incitation à partir est beaucoup plus faible. Encore mauvais, mais beaucoup moins. Étonnamment moins.
L'ironie est qu'il est beaucoup plus facile de perdre toutes vos données dans un accident bizarre que de perdre tout votre code. Pour la plupart des entreprises Internet, cependant, les données est la société, il est votre atout le plus précieux. Et c'est une bonne raison d'envisager l'utilisation d'une base de données relationnelle traditionnelle, éprouvée, ancienne et non sexy.
la source
Considérez également qu'il n'y a aucune raison pour laquelle vous ne pouvez pas utiliser une base de données relationnelle pour certaines choses et la base de données nosql pour d'autres choses.
la source
En parlant de nosql, je n'ai qu'une chose à ajouter sur la référence Facebook:
Si vous envisagez de vous développer à très grande échelle, je vous suggère d'obtenir un moteur DB convivial pour les administrateurs de systèmes par rapport aux développeurs.
Quittez MongoDB convivial et super rapide qui ne peut pas être dispersé géographiquement et n'a aucun moyen de sauvegarder efficacement et facilement. Bien que nous utilisions ici MongoDB, il semble que Riak ou CouchDB aient une meilleure apparence dans les spécifications des administrateurs système (je n'ai aucune expérience avec Riak ou CouchDB)
la source