52 votes

Stockage d'images évolutif

Je suis actuellement à la conception d'une architecture d'une application basée sur le web qui devrait également fournir une certaine forme de stockage d'image. Les utilisateurs seront en mesure de télécharger des photos comme l'un des principaux fonctionnalité du service. Également la visualisation de ces images sera l'un des principaux usages (via le web).

Cependant, je ne suis pas sûr de la façon de réaliser une image évolutive des composants de stockage dans mon application. J'ai déjà pensé à des solutions différentes, mais en raison du manque d'expériences, j'ai hâte d'entendre vos suggestions. Outre les images, aussi méta-données doivent besaved. Voici mes premières impressions:

1) Utiliser un (distribué) système de fichiers comme de la SF et de préparer dédié serveurs web en tant que "système de fichiers clients" afin d'enregistrer les images téléchargées et des demandes de service. Image méta-données sont enregistrées dans une base de données supplémentaire, y compris le chemin d'accès de l'information pour chaque image.

2) Utiliser un BigTable le système d'orientation comme HBase sur le dessus de la SF et enregistrer des images et des méta-données. Encore une fois, des serveurs pont les images et les demandes.

3) Utiliser un complètement schemaless base de données comme CouchDB pour stocker à la fois des images et des métadonnées. En outre, l'utilisation de la base de données elle-même pour l'envoi et de livraison en utilisant le HTTP API RESTful. (Question supplémentaire: CouchDB ne économiser de gouttes par Base64. Il peut cependant renvoyer des données sous forme d'image/jpeg etc.)?

Merci d'avance pour vos suggestions!

42voto

mdorseif Points 7473

Nous avons été unsing CouchDB pour que, de l'enregistrement des images comme une "pièce Jointe". Mais après une année, le multi-douzaine de GO CouchDB fichiers de Base de données s'est avéré être un mal de tête. Par exemple CouchDB de réplication a encore des questions si vous l'utilisez avec de très grands formats de document.

Donc nous avons juste réécrire notre logiciel à utiliser CouchDB pour les informations de l'image et Amazon S3 pour le stockage d'image. Le code est disponible sur http://github.com/hudora/huImages

Vous souhaiterez peut-être définir un Amazon S3 compatible avec le Service de Stockage sur le site de votre projet. Cela vous maintient souple et laisse la amazon option sans recourir aux services pour l'instant. Walruss semble devenir le plus populaire et évolutive S3 clone.

Je vous invite également à regarder dans la Conception de Livejournal avec leur excellent Open Source MogileFS et Perlbal offres. Cette combinaison est probablement le plus Célèbre de diffusion d'images d'installation.

Aussi le flickr de l'Architecture peut être une source d'inspiration, même si elles n'offrent pas de logiciel Open Source pour le public, comme Livejournal.

14voto

Robert Newson Points 3383

"Question supplémentaire: CouchDB ne économiser de gouttes par Base64."

CouchDB ne pas enregistrer les blobs en Base64, ils sont stockés en tant que droit binaire. Lors de la récupération d'un document JSON ?les pièces jointes=vrai que nous ne convertir le disque binaire en Base64 pour l'ajouter en toute sécurité en JSON, mais c'est juste un niveau de la présentation de la chose.

http://wiki.apache.org/couchdb/HTTP_Document_API#Standalone_Attachments

CouchDB sert pièces jointes avec le type de contenu qu'ils sont stockés, il est possible, en fait commun, serveur HTML, CSS et GIF/PNG/JPEG pièces jointes directement dans les navigateurs.

Les pièces jointes peuvent être diffusés en continu et, dans CouchDB 1.1, même l'appui de la Gamme en-tête (pour la diffusion multimédia en continu et/ou la reprise d'un téléchargement interrompu).

8voto

user997701 Points 124

Utilisez Weed-FS, il est hébergé sur Google Code, une implémentation du papier de la botte de foin de Facebook.

Weed-FS est très flexible et rudimentaire. Il a été créé pour stocker des milliards d’images et les servir rapidement.

3voto

danben Points 35312

Avez-vous envisagé d'Amazon Web Services? S3 est basé sur le web de stockage de fichiers, et SimpleDB est un touche->attribut magasin. À la fois performant et hautement évolutive. C'est plus cher que le maintien de vos propres serveurs et des configurations (en supposant que vous allez faire vous-même et de ne pas embaucher des gens), mais de vous lever et courir beaucoup plus vite.

Edit: je retire ce que - son plus cher à long terme à des volumes élevés, mais pour un faible volume, il bat le coût initial de l'achat de matériel.

S3: http://aws.amazon.com/s3/ (vous pouvez stocker vos fichiers d'image ici, et pour l'exécution peut-être avoir un cache des images sur votre serveur, ou peut-être pas)

SimpleDB: http://aws.amazon.com/simpledb/ (métadonnées pourrait aller ici: id de l'image de la cartographie de toutes les données que vous souhaitez stocker)

Edit 2: je ne savais même pas à ce sujet, mais il est un nouveau service web appelé Amazon CloudFront (http://aws.amazon.com/cloudfront/). Il est rapide de diffusion de contenu web, et il s'intègre bien avec le S3. Un peu comme Akamai pour vos images. Vous pouvez l'utiliser à la place de l'image cache.

3voto

Leen Toelen Points 258

Peut-être jetez un coup d'œil à la description de Facebook hayStack

Aiguille dans une botte de foin: stockage efficace de milliards de photos

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by: