object - que - Diferencia entre almacenamiento de objetos y almacenamiento de archivos
que es lugar de almacenamiento (10)
Este enlace explica las diferencias entre los dos: http://www.dell.com/downloads/global/products/pvaul/en/object-storage-overview.pdf
¿Podría alguien explicar qué diferencia hay entre Object Storage y File Storage?
Leí sobre Object Storage en wiki , también leo http://www.dell.com/downloads/global/products/pvaul/en/object-storage-overview.pdf , también leo amazons docs (S3), openstack swift y etc. ¿Pero alguien podría darme un ejemplo para entender mejor?
¿Toda la diferencia es solo que para los objetos de "almacenamiento de objetos" agregamos más metadatos?
Por ejemplo, ¿cómo almacenar imagen como objeto usando algún lenguaje de programación (por ejemplo, python)?
Gracias.
Creo que el libro blanco explica bastante bien la idea del almacenamiento de objetos. No conozco ninguna forma estándar de usar dispositivos de almacenamiento de objetos (en el sentido de una OSD SCSI) desde una aplicación de usuario.
El almacenamiento de objetos está en uso en algunos productos de almacenamiento a gran escala como los dispositivos de almacenamiento de Panasas . Sin embargo, estos dispositivos luego exportan un sistema de archivos al usuario final. En mi humilde opinión es justo decir que la idea T10 OSD nunca cobró impulso.
Se pueden encontrar ideas relacionadas con el estándar OSD en sistemas de almacenamiento en la nube como S3 y RADOS .
La respuesta simple es que los sistemas o servicios de almacenamiento a los que se accede con objetos utilizan API y otros métodos de acceso a objetos para almacenar, recuperar y buscar datos en lugar de archivos o NAS tradicionales. Por ejemplo, con un archivo o NAS, puede acceder al almacenamiento usando NFS (Network File System) o CIFS (por ejemplo, compartir archivos de Windows) SMB aka SAMBA, donde el archivo tiene un nombre / manejador con metadatos asociados determinados por el sistema de archivos.
Los metadatos incluyen información sobre creación, acceso, modificaciones y otras fechas, permisos, seguridad, aplicación o tipo de archivo u otros atributos. Los archivos están limitados por el sistema de archivos en términos de su tamaño, así como la cantidad de archivos por sistema de archivos. Del mismo modo, los sistemas de archivos están limitados por su tamaño total o agregado en términos de capacidad de espacio y la cantidad de archivos en el sistema de archivos.
El acceso a objetos es diferente porque mientras que el archivo o front-end NAS o gateways o complementos están disponibles para muchas soluciones o servicios, el acceso primario es a través de una API donde un objeto puede tener un tamaño arbitrario (hasta el máximo del sistema de objetos) con metadatos de tamaño variable (depende de la implementación del sistema / servicio del objeto). Con la mayoría de los sistemas / servicios de almacenamiento de objetos puede especificar desde unos pocos Kbytes de metadatos definidos por el usuario o GBytes. ¿Para qué usarías GBytes de metadatos? Además de la información normal, agregue más datos para políticas, administraciones, donde se encuentran otras copias, miniaturas o pequeñas vistas previas de videos, audio, etc.
Algunos ejemplos de API o interfaces de acceso a objetos incluyen los servicios de almacenamiento simple (S3) de Amazon Web Services (AWS) u otros basados en HTTP y REST, SNIA CDMI. Las diferentes soluciones también admitirán el acceso IOS (por ejemplo, iPhone / ipad), SOAP, Torrent, WebDav, JSON, XAM, entre otros más NFS / CIFS. Además, muchos de los sistemas o servicios de almacenamiento de objetos admiten enlaces programáticos para python, entre otros. Las API le permiten esencialmente abrir una transmisión y luego obtener o poner, enumerar y otras funciones compatibles con la API / sistema para determinar cómo la usará.
Por ejemplo, uso tanto los archivos Rackspace Cloud como Amazon S3 (además de EBS y Glacier) para realizar copias de seguridad, almacenar y archivar datos. Puedo acceder a los objetos almacenados a través de un navegador web o herramientas, incluido el Jungle Disk (JD), que es con el que hago copias de seguridad y sincronizo los archivos. JD maneja la gestión de objetos y mueve los datos tanto a Rackspace como a Amazon para mí. Si me inclinara, también podría hacer algo de programación usando las API y luego acceder directamente a cualquiera de esos sitios que proporcionan mis credenciales de seguridad para hacer cosas con mis objetos almacenados.
Aquí hay un enlace a la base de datos de almacenamiento en objetos y en la nube de una sesión que hice en Holanda el año pasado que tiene algunos ejemplos simples de objetos y acceso. http://storageio.com/DownloadItems/Nijkerk_Nov2012/SIO_IndustryTrends_CloudObjectStorage.pdf
Al utilizar el enlace programático, debe definir sus estructuras de datos u objetos en su programa y luego usar las API o llamadas para almacenar, recuperar, listar datos, acceder a metadatos, etc. Si hay un sistema de almacenamiento de objetos en particular, software o servicio que Si desea trabajar con o necesita saber cómo programar para ir a su sitio, debería encontrar su información SDK o API con ejemplos. Con los objetos, una vez que crea su cubo o contenedor inicial en un servicio o con un producto / sistema, simplemente crea y almacena objetos adicionales a medida que avanza.
Aquí hay un enlace como ejemplo de API / programación de AWS S3: http://docs.aws.amazon.com/AmazonS3/latest/API/IntroductionAPI.html
En teoría, se habla de sistemas de almacenamiento de objetos que tienen un número ilimitado de objetos o tamaño de objeto, en realidad, la mayoría de los sistemas, soluciones, software o servicios están limitados por lo que han probado o soportan actualmente, que pueden ser miles de millones de objetos, con objetos de tamaños de 5GBy más grandes. Preste atención a los límites de servicios o productos específicos en cuanto a lo que realmente se prueba, lo que es compatible con lo que es arquitectónicamente posible o lo que se implementa en webex o powerpoint.
De nuevo, su propio servicio y producto / servicio / software depende del número de objetos, el tamaño de los objetos, el tamaño de los metadatos y la cantidad de datos que se pueden mover dentro / fuera a través de sus API. Sin embargo, generalmente es seguro asumir que el almacenamiento de objetos puede ser mucho más escalable (dependiendo de la implementación) que los sistemas de archivos (sin utilizar espacio de nombre global, federación, virtualización de archivos u otras técnicas).
También en mi libro Cloud and Virtual Data Storage Networking (CRC Press) que es Intel Recommended Reading, encontrará más información sobre la nube y el almacenamiento de objetos.
Agregaré más material relacionado a www.objectstorage.us pronto.
Saludos gs
Existen algunas diferencias fundamentales entre Almacenamiento de archivos y Almacenamiento de objetos.
El almacenamiento de archivos se presenta como una jerarquía de sistema de archivos con directorios, subdirectorios y archivos. Es genial y funciona muy bien cuando la cantidad de archivos no es muy grande. También funciona bien cuando sabes exactamente dónde están almacenados tus archivos.
El almacenamiento de objetos, por otro lado, típicamente se presenta a través de. una API RESTful No hay concepto de un sistema de archivos. En cambio, una aplicación guardará un objeto (archivos + metadatos adicionales) en el almacén de objetos a través de. la API PUT y el almacenamiento de objetos guardarían el objeto en algún lugar del sistema. La plataforma de almacenamiento de objetos le daría a la aplicación una clave única (análoga a un ticket de valet) para ese objeto que la aplicación almacenaría en la base de datos de la aplicación. Si una aplicación deseara obtener ese objeto, todo lo que tendrían que hacer es dar la clave como parte de la API GET y el objeto sería recuperado por el almacenamiento del objeto.
Espero que esto esté ahora claro.
IMO, el almacenamiento de objetos no tiene nada que ver con la escala porque alguien podría construir un FS que sea capaz de almacenar una gran cantidad de archivos, incluso en un único directorio.
Tampoco se trata de los métodos de acceso. El acceso HTTP a los datos en los sistemas de archivos ha estado disponible en muchos sistemas NAS conocidos.
Almacenamiento / Acceso por OID es una forma de manejar datos sin molestarse en nombrarlos. Podría hacerse en archivos también. Creo que hay una extensión de protocolo NFS que permite esto.
Lo resumiría: el almacenamiento de objetos es una forma de pensar (nueva / diferente) centrada en el objeto de los datos, su acceso y gestión.
Piensa en estos puntos:
¿Qué son instantáneas hoy? Son copias puntuales de un volumen. Cuando se toma una instantánea, todos los archivos en el volumen también se ajustan. Si a todos les gusta o no, si todos lo necesitan o no. Se puede usar mucho espacio (¿desperdicia?) Para obtener una instantánea de volumen completa, mientras que solo se necesitan ajustar unos pocos archivos.
En un sistema de almacenamiento de objetos, rara vez verá instantáneas de volúmenes, los objetos se tomarán instantáneamente, quizás de forma automática. Esto es el control de versiones de objetos. No es necesario versionar todos los objetos, cada objeto individual puede decir si está versionado.
¿Cómo se protegen los archivos / volúmenes de un desastre? Normalmente, en una configuración de Recuperación ante desastres (DR), volúmenes enteros / conjuntos de volúmenes se configuran para la replicación en un sitio DR. Nuevamente, esto no molesta si los archivos individuales quieren ser replicados o no. La unidad de protección contra desastres es el volumen. Los archivos son pequeños.
En un sistema de almacenamiento de objetos, DR no está centrado en el volumen. Los metadatos de objetos pueden decidir cuántas copias deben existir y dónde (ubicaciones geográficas / dominios de fallas).
Del mismo modo para otras características:
Nivelación: objetos colocados en niveles / clases de almacenamiento basados en sus metadatos independientes de otros objetos no relacionados.
Vida: los objetos se mueven entre niveles, cambian el número de copias, etc., individualmente, en lugar de hacerlo como un grupo.
Autenticación: los objetos individuales pueden autenticarse desde diferentes dominios de autenticación si es necesario.
Como puede ver, el cambio en el pensamiento es que en una tienda de objetos, todo se trata de un objeto.
Contraste esto con la forma tradicional de pensar y gestionar y acceder a contenedores más grandes como volúmenes (que contienen archivos) no es el almacenamiento de objetos.
Las características anteriores y su enfoque centrado en el objeto se ajustan bien a los requisitos de los datos no estructurados y, por lo tanto, al interés.
Si un sistema de almacenamiento está centrado en objetos (o archivos) en lugar de centrarse en el volumen en su pensamiento (independientemente del protocolo de acceso o la escala), es un sistema de almacenamiento de objetos.
Oh, me gustaría poder votar algunas respuestas y votar otras con una cuenta.
El que tiene más votos, al momento de escribir esto, ni siquiera explica nada sobre las diferencias.
Existen algunas diferencias fundamentales entre Almacenamiento de archivos y Almacenamiento de objetos.
El almacenamiento de archivos se presenta como una jerarquía de sistema de archivos con directorios, subdirectorios y archivos. Es genial y funciona muy bien cuando la cantidad de archivos no es muy grande. También funciona bien cuando sabes exactamente dónde están almacenados tus archivos.
El almacenamiento de objetos, por otro lado, típicamente se presenta a través de. una API RESTful No hay concepto de un sistema de archivos. En cambio, una aplicación guardará un objeto (archivos + metadatos adicionales) en el almacén de objetos a través de. la API PUT y el almacenamiento de objetos guardarían el objeto en algún lugar del sistema. La plataforma de almacenamiento de objetos le daría a la aplicación una clave única (análoga a un ticket de valet) para ese objeto que la aplicación almacenaría en la base de datos de la aplicación. Si una aplicación deseara obtener ese objeto, todo lo que tendrían que hacer es dar la clave como parte de la API GET y el objeto sería recuperado por el almacenamiento del objeto.
Espero que esto esté ahora claro.
Esto explica una gran parte de esto; pero discutiste sobre los metadatos. Lo que sigue es lo que he estado leyendo estos dos últimos días, y como esto no se ha resuelto, lo publicaré.
El almacenamiento de objetos no tiene sentido de las carpetas ni de ningún tipo de estructura de organización que facilite la organización de un ser humano. File Storage, por supuesto, tiene todas esas carpetas que hacen que sea tan fácil para un humano organizarse y moverse ... En un entorno de servidor con la cantidad de archivos en una escala que es astronómica, las carpetas son simplemente una pérdida de espacio y tiempo.
Bases de datos que dices? Bueno, él no está hablando del almacenamiento de objetos en sí, está diciendo que su servicio http (php, webmail, etc.) tiene la identificación única en su base de datos para hacer referencia a un archivo que puede tener un nombre humano reconocible.
Metadatos, ¿dónde está guardado este archivo? Para eso están los metadatos. Su archivo individual se divide en un grupo de piezas pequeñas y se extiende desde la ubicación geográfica, los servidores y los discos duros. Estas pequeñas piezas también contienen más datos, contienen información de paridad para los otros datos, o incluso duplicación directa.
Los metadatos se utilizan para ubicar cada dato de ese archivo en diferentes ubicaciones geográficas, centros de datos, servidores y discos duros, así como también para restaurar cualquier pieza destruida por fallas de hardware. Lo hace de forma automática. Incluso moverá estas piezas de forma fluida para tener una mejor dispersión. Incluso recreará una pieza que ya no está y la almacenará en un nuevo disco duro bueno.
Esto tal vez una explicación simple; pero creo que podría ayudarte a comprender mejor. Creo que el almacenamiento de archivos puede hacer lo mismo con los metadatos; pero el almacenamiento de archivos es un almacenamiento que puede organizar como humano (carpetas, jerarquía y demás) mientras que el almacenamiento de objetos no tiene jerarquía, ni carpetas, solo un contenedor de almacenamiento plano.
La mayoría de las empresas con soluciones basadas en objetos tienen una combinación de almacenamiento de bloques / archivos / objetos elegida en función de los requisitos de rendimiento / costo.
Desde una perspectiva de caso de uso:
En última instancia, el almacenamiento de objetos se creó para abordar datos no estructurados que crecen explosivamente, mucho más rápido que los datos estructurados.
Por ejemplo, si una base de datos es datos estructurados, no estructurada sería una palabra doc o PDF.
¿Cómo se buscan mil millones de archivos PDF en un sistema de archivos? (si pudiera incluso almacenar tantos en primer lugar).
¿Qué tan rápido podría buscar solo los metadatos de mil millones de archivos?
Actualmente, el almacenamiento de objetos se usa más para almacenamiento a largo plazo o de archivo, económico y profundo, que realiza un seguimiento de más detalles de los datos. Este metadato se vuelve muy poderoso cuando busca o extrae conjuntos de datos muy grandes. A veces puede obtener lo que necesita de los metadatos sin siquiera acceder a los datos en sí. Las soluciones de almacenamiento de objetos normalmente se pueden replicar automáticamente con failover geográfico integrado.
El problema es que la aplicación debería volver a escribirse para usar métodos de acceso a objetos en lugar de la jerarquía de archivos (que es más simple desde la perspectiva del desarrollador de aplicaciones). Realmente es un cambio en la filosofía del almacenamiento de datos y el almacenamiento de información más procesable sobre esos datos, tanto desde el punto de vista de la administración como del uso.
Un ejemplo rápido podría ser una imagen de escaneo de MRI. En el Sistema de archivos tiene fecha de propietario / creación, pero no mucho más. Si fuera un objeto, toda la información que rodea a la MRI podría almacenarse junto con ella en los metadatos, como el nombre del paciente, la ubicación del centro de MRI, el Dr. solicitante, la aseguradora, etc.
Los bloques / archivos son más adecuados para el acceso local o para OTLP, donde el rendimiento es más importante que la retención y el costo.
Por ejemplo, no querrá esperar minutos para que se abra un documento de Word, pero podría esperar unos minutos para que finalice un proceso de minería de datos / inteligencia empresarial.
Otro ejemplo sería una búsqueda legal donde tienes que buscar todo desde hace 5 años hasta el presente. Con las políticas de retención implementadas para disminuir el conjunto de datos activo y el costo, ¿cómo lo haría sin restaurar desde la cinta?
El almacenamiento de objetos es una gran solución para reemplazar los métodos de archivo a largo plazo, como la cinta.
Configurar la replicación y la conmutación por error para bloques y archivos puede ser muy costoso en la empresa y generalmente requiere software y servicios muy costosos.
Nota: En el nivel inferior, el acceso al almacenamiento de objetos ocurre a través de la API RESTful, que se parece más a una solicitud web que a un archivo al final de una ruta.
De hecho, puede montar un cubo / contenedor y acceder a los objetos o subcarpetas (y sus objetos) desde Linux. Por ejemplo, tengo s3fs instalado en Ubuntu que tengo configurado un punto de montaje para uno de mis cubos S3 y que puedo hacer cp, ls y otras funciones como si fuera otro sistema de archivos. La clave es obtener la herramienta de software de la cual hay muchas que le permiten mapear un cubo / contenedor y presentarlo como punto de montaje. También hay herramientas de software que le permiten acceder a S3 y otros cubos / contenedores a través de iSCSI además de como NAS.
Almacenamiento de objetos = almacenamiento de bloque + metadatos enriquecidos - jerarquía de archivos
Block Storage usa un sistema de archivos para señalar dónde se almacena el contenido. Almacenamiento de objetos utiliza un identificador para señalar el contenido y su contexto. Esta es mi comprensión de la lectura Contenido-dirigido vs. ubicación-dirigido
Block Storage necesita un sistema de archivos y estructuración, por lo que con los sistemas de archivos más grandes, viene más sobrecarga. El almacenamiento de objetos tiene mucho contexto sobre el archivo y no necesita la jerarquía de archivos. La explicación en la página 7 del documento de Dell muestra claramente esto ... Lo que me preocupaba, era que en la escala del disco duro en sí no se explica. Descubrí que un Disco Duro siempre usa un mecanismo de almacenamiento en Bloque (aunque parece que está cambiando a) (aunque eso parece estar cambiando)
algunas otras ideas se pueden encontrar aquí
Divulgación: trabajo para un proveedor (NetApp) que desarrolla y vende grandes sistemas de archivos y plataformas de almacenamiento de objetos. Trataré de mantener esta implementación lo más neutral posible, pero mis prejuicios cognitivos pueden influir inconscientemente en mi respuesta.
Existen muchas diferencias desde un punto de vista de acceso, programabilidad e implementación, sin embargo, dado que es probable que los programadores lo lean principalmente en lugar de personas de infraestructura o de almacenamiento, me centraré en ese aspecto aquí.
La principal diferencia desde un punto de vista externo / de programación es que un objeto en un almacén de objetos se crea o borra o se actualiza como una unidad completa, no se pueden agregar datos a un objeto y no se puede actualizar una parte de un objeto. objeto "en su lugar", puede reemplazarlo sin dejar de mantener el mismo ID de objeto. La creación, lectura, actualización y eliminación de objetos normalmente se realiza a través de API relativamente sencillas, que casi siempre son REST-ful o basadas en REST y fomenta la idea de que la tienda es un recurso programable o quizás un servicio remoto de múltiples usuarios. Si bien la mayoría de las tiendas de objetos que conozco admiten lecturas de rango de bytes dentro de un objeto, en general las tiendas de objetos fueron inicialmente diseñadas para trabajar con objetos completos. Buenos ejemplos de API de almacenamiento de objetos son los utilizados por Amazon S3 (el estándar predeterminado para el acceso de almacenamiento de objetos), OpenStack Swift y API REST de Azure Blob Service. Describir las implementaciones de back-end detrás de estas API sería un libro por sí mismo.
Por otro lado, los archivos en un sistema de archivos tienen un conjunto más amplio de funciones que se pueden aplicar a ellos, incluidos los datos adjuntos y la actualización de los datos en su lugar. El modelo de programación es más complejo que un almacén de objetos y casi siempre se accede programáticamente a través de un estilo de interfaz "POSIX" y generalmente intenta hacer el uso más eficiente de la CPU y la memoria, y fomenta la idea de que el sistema de archivos es un recurso local privado . NFS y SMB permiten que un sistema de archivos esté disponible como recurso de múltiples usuarios, sin embargo, estos son tratados con recelo por los programadores ya que a veces tienen diferencias sutiles en cómo reaccionan en comparación con los sistemas de archivos "locales" a pesar de su total apoyo para POSIX semántica. Para actualizar archivos en un sistema de archivos local, probablemente use API como https://www.classes.cs.uchicago.edu/archive/2017/winter/51081-1/LabFAQ/lab2/fileio.html o https: / /msdn.microsoft.com/en-us/library/mt794711(v=vs.85).aspx . Hablar de los méritos relativos de las implementaciones del sistema de archivos, por ejemplo, NTFS vs BTRFS vs XFS vs WAFL vs ZFS tiene una tendencia a resultar en una guerra religiosa que rara vez vale la pena en cualquier momento, aunque si me compras una cerveza, compartiré contigo mis opiniones contigo. .
Desde el punto de vista de un caso de uso, si desea mantener una gran cantidad de fotografías, videos o artefactos de construcción binarios, entonces una tienda de objetos es a menudo una buena opción. Si, por otro lado, desea almacenar datos de forma persistente en un árbol binario y actualizar esos datos en el medio de almacenamiento, entonces un almacén de objetos simplemente no funcionaría, y estaría mucho mejor con un sistema de archivos (también podría usar dispositivos de bloques crudos para eso, pero no he visto a nadie hacer eso desde principios de los 90)
Las otras grandes diferencias son que los sistemas de archivos están diseñados para ser muy consistentes y generalmente se accede a redes de latencia baja a moderada (50 microsegundos - 50 milisegundos) mientras que las tiendas de objetos a menudo son consistentes y se distribuyen en una infraestructura compartida las redes de área ancha de alta latencia de ancho de banda y su tiempo hasta el primer byte a veces se pueden medir en múltiplos de segundos enteros. Realizar muchas lecturas aleatorias pequeñas (4K - 16K) desde una tienda de objetos puede causar frustración y problemas de rendimiento.
El otro beneficio principal de una tienda de objetos frente a un sistema de archivos es que puede estar razonablemente seguro de que todo lo que coloque en una tienda de objetos permanecerá allí hasta que lo solicite nuevamente y que nunca se quede sin espacio mientras siga pagando para los cargos mensuales. Estos recursos generalmente se ejecutan a gran escala con replicación incorporada, control de versiones, recuperación automatizada, etc. y nada menos que el desastre del estilo del huracán Harvey hará que los datos desaparezcan (incluso entonces, tiene opciones fáciles para hacer otra copia en otra ubicación). Con un sistema de archivos, especialmente uno que usted o las personas de operaciones locales esperan que usted administre, tiene que esperar que todo esté respaldado y que no se llene accidentalmente y que todo se derrita cuando ya no puede actualizar sus datos.
Intenté ser concisa, pero para aumentar la confusión, las palabras "sistema de archivos" y "almacén de objetos" se aplican a cosas que no se parecen en nada a las descripciones que he usado anteriormente, por ejemplo, NFS, el sistema de archivos de red no es un sistema de archivos, es una forma de implementar las API de almacenamiento posix a través de llamadas a procedimientos remotos, y VSAN de VMware almacena sus datos en algo que ellos llaman "almacén de objetos" que permite actualizaciones de alta velocidad de las imágenes de máquinas virtuales.