Suggestion de base de données pour une communauté de réseau social / base de connaissances?


12

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


3
Si vous voulez un 3nf normalisé, vous devez faire un magasin relationnel. Période.
JNK

2
Je ne frapperais pas Java juste parce que c'est "Oracle". Utilisez le bon outil pour le travail. Si Java est le meilleur outil, je l'utiliserais. Si C est le bon travail, utilisez-le. Concentrez-vous sur ce que chaque outil vous offre, pour et contre. Prenez une décision bien éduquée à ce sujet (comme avec le côté DB), plutôt que basée sur le sentiment.
Chris Aldrich

Réponses:


4

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

  • CouchDB - l'une des premières bases de données NoSQL, puissant système de requête de cartographie / réduction, hautement distribué et tolérant aux pannes. L'un des meilleurs prétendants à NoSQL.
  • Hyperdex - toute nouvelle table de hachage distribuée avec des capacités de recherche.
  • Riak - table de hachage distribuée digne d'un certain respect.

Trucs gratuits étranges

  • Metakit - plus d'une base de données intégrée comme SQLite mais pas basée sur SQL, donc plus procédurale.
  • FramerD - un peu comme une base de données "réseau" classique, très centrée sur le pointeur. Peut-être mort?
  • Magma - Smalltalk OODBMS. Cool mais pas bien documenté.

Trucs non gratuits

  • AllegroGraph - Base de données RDF (graphique), prend en charge SPARQL. Saveur Lisp.
  • Caché - une base de données relationnelle / OO hybride, basée à l'origine sur MUMPS (IIRC).
  • Objectivité - L'un des derniers très gros OODB. Très puissant, impressionnant et cher.
  • VoltDB - Base de données principalement relationnelle hautement évolutive. Prend en charge "la plupart" SQL. Tout nouveau. Je suppose qu'ils ont aussi une version communautaire.

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.


Résumé du long fil de commentaire supprimé d'ici: "Il est injuste d'impliquer que les magasins NOSQL vont d'une manière ou d'une autre rendre plus probable la perte de données".
Jack dit d'essayer topanswers.xyz

Ce que je dis a à voir avec l'âge et une large utilisation, pas avec la conception du moteur de stockage.
Daniel Lyons

6

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.


0

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)


2
Si vous choisissez de grandir, c'est parce que vous êtes déjà passé du micro au petit, et du petit au petit, et en cours de route, vous avez appris des choses qui vous aideront à faire les bons choix. Lorsque vous êtes prêt à évoluer, vous pouvez vous permettre les ingénieurs qui savent évoluer.
jcolebrand
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.