sql >> Base de Datos >  >> NoSQL >> MongoDB

Almacenamiento para millones de imágenes

En mi vida, he realizado distribución de video con S3 (archivos en la nube de Rackspace incluidos) y MongoDB.

La mayoría de las personas, sin pensarlo dos veces, optarían por el S3; sin embargo, descubrí que ambos tienen sus desventajas. Uno de los grandes problemas es que S3 no es una CDN, en realidad es un almacenamiento redundante dentro de una región específica que no se replica en otras regiones de S3, esto significa que necesitará usar algo como cloudfront encima de S3 para hacer ping a sus imágenes. a una especie de caché si tuviera una carga importante en su sitio.

S3 también tiene otras características que lo hacen menos CDN-ish y más un almacén de almacenamiento. Dicho esto, para los archivos a los que se accede con poca frecuencia, S3 es increíblemente rápido.

Esta doble capa, por supuesto, crea complejidades como el mantenimiento. No solo eso, sino que una CDN funcionará con TTL y, aunque muchas CDN en la actualidad tienen capacidades de purga de borde, todavía no son una forma 100% segura de asegurarse de que sus archivos no sean accesibles.

Entonces, debido a la configuración y los accesos (posibles accesos de archivos que también deberían eliminarse), esto podría volverse bastante costoso con bastante rapidez.

Aquí es donde MongoDB podría victoria. MongoDB podría, dependiendo de su escenario, en realidad ser más barato aquí debido al hecho de que podría usar un montón de microinstancias en AWS para mantener su información, agregando reserva de instancias puntuales a estas instancias (muy barato) y todo lo que necesita es un disco grande en una sola máquina.

Demonios, incluso podría usar S3 para almacenar las imágenes y luego MongoDB como reemplazo de la nube.

Cuando desee hacer ping a imágenes en diferentes regiones, simplemente cree algunas instancias puntuales en esa región de destino y haga que MongoDB replique sus datos. También puede hacer algunas cosas geniales con la replicación para asegurarse de que solo los archivos de esa región a los que se accede con frecuencia se coloquen en esa región.

Así que no descartaría a MongoDB (o incluso a Cassandra), sino que haría una prueba de medios entre los dos.

Editar

Como nota adicional sobre los precios de S3, si almacena sus archivos en RR (redundancia reducida), el precio se reduce a la mitad (aproximadamente), lo que hace que S3 sea muy barato; sin embargo, todavía tiene el problema de que S3 no es un CDN.

Edición adicional

Dado que realmente solo continué con la respuesta de @cirrus, volveré a evaluar su pregunta, que se respondió más arriba.

Como ejemplo, Youtube en realidad almacena todas sus imágenes en computadoras individuales que luego se distribuyen, por lo que pueden administrar fácilmente 200 millones de miniaturas y... bueno... muchas vistas cada día fácilmente desde el sistema de archivos. Así que creo que su preocupación por el sistema de archivos está sobrevalorada.

En cuanto a qué base de datos es mejor... no sé, eso se reduce a tus pruebas.

Quiero decir que la respuesta a su problema depende de su escenario y su presupuesto y su hardware y sus recursos, es decir, si tiene servidores AWS, esta sería una respuesta completamente diferente a los servidores internos dedicados.