Magasin de fichiers : CouchDB vs SQL Server + système de fichiers

En réponse à Redmumba. L'équipe de développement de CouchDB serait intéressée par les pannes que vous rencontrez.

En plus de cela : L'architecture entière de CouchDB est basée sur le principe du fail-early. Tous les sous-systèmes, ainsi que le serveur principal, sont conçus de manière à s'arrêter et à se rétablir immédiatement lorsqu'une erreur se produit. Les "plantages" font simplement partie du fonctionnement normal, ce qui rend les logiciels beaucoup plus fiables (ironiquement, mais c'est toute la philosophie d'Erlang).

Pour ce qui est de la question, CouchDB répondra suffisamment bien aux exigences. Le streaming des pièces jointes de CouchDB est définitivement lié aux entrées-sorties, à une vitesse très proche de celle des systèmes de fichiers. Les documents CouchDB vous offrent tout l'espace dont vous avez besoin pour les métadonnées et les pièces jointes des documents conservent les données binaires à proximité. Il n'est pas nécessaire d'utiliser des systèmes différents pour cela.

L'expérience que nous avons eue avec CouchDB dans un environnement à forte charge n'a pas été trÃ?s bonne ; nous avons constaté beaucoup d'instabilité (plantages fréquents), que les listes de diffusion ont tendance à indiquer comme pouvant être simplement résolue par l'installation d'un démon de surveillance pour le redémarrer en cas de panne. Nous n'utilisons pas de grands ensembles de valeurs, mais nous le faisons assez fréquemment - mais gardez ceci à l'esprit, car des fichiers plus grands signifient des temps de connexion plus longs. Ce qui signifie qu'une panne au milieu d'un transfert serait encore plus douloureuse selon la bande passante et la taille du fichier.

Je vous recommande de vous pencher sur MongoDB avec le support de GridFS. MongoDB vous conviendrait (sur la base de vos spécifications) car vous semblez avoir des métadonnées supplémentaires que vous souhaitez stocker avec le fichier ; comme il est orienté document, vous pourrez stocker ces métadonnées avec les fichiers binaires. À cette fin, GridFS vous permet de stocker des fichiers volumineux dans la base de données.

La BBC semble l'utiliser avec succès. Je crois qu'il y a une vidéo sur TED qui explique ce qu'ils font avec.

Je n'ai pas utilisé CouchDB mais j'ai de l'expérience avec SQL Server. Si vous stockez les fichiers dans le serveur SQL (varbinary(max) est physiquement stocké sur le système de fichiers), je pense que vous serez mieux loti. Il pourra évoluer vers des milliards de lignes et les performances, quelle que soit la base de données utilisée ( oracle, sql server, etc...), dépendront de la conception de l'application et du matériel. Je pense que c'est la clé. Les problèmes de performance sont presque toujours le résultat d'applications ou d'infrastructures mal conçues, et non de la base de données sous-jacente de classe entreprise.