Différence entre le stockage d'objets et le stockage de fichiers
Quelqu'un pourrait-il expliquer quelle est la différence entre le stockage d'objets et le stockage de fichiers?
J'ai lu sur Object Storage sur wiki , je lis aussi http://www.Dell.com/downloads/global/products/pvaul/en/object-storage-overview.pdf , je lis aussi amazons docs (S3), openstack Swift, etc. Mais quelqu'un pourrait-il me donner un exemple pour mieux comprendre?
Toute la différence est seulement que pour les objets 'object storage', nous ajoutons plus de métadonnées?
Par exemple, comment stocker une image comme un objet en utilisant un langage de programmation (par exemple, python)?
Merci.
IMO, le stockage d'objet n'a rien à voir avec l'échelle, car quelqu'un pourrait créer un FS capable de stocker un grand nombre de fichiers, même dans un seul répertoire.
Il ne s'agit pas non plus des méthodes d'accès. L'accès HTTP aux données dans les systèmes de fichiers est disponible dans de nombreux systèmes NAS bien connus.
Stockage/accès par OID est un moyen de gérer les données sans se soucier de les nommer. Cela pourrait aussi être fait sur des fichiers. Je crois qu'il existe une extension de protocole NFS qui permet cela.
Je tiens à préciser ceci: le stockage d’objets est une façon (nouvelle/différente) de penser les données de manière centrée sur les objets, leur accès et leur gestion.
Pensez à ces points:
Que sont les instantanés aujourd'hui? Ce sont des copies ponctuelles d'un volume. Lorsqu'un instantané est pris, tous les fichiers du volume le sont également. Que cela leur plaise ou non, qu'ils en aient besoin ou non. Beaucoup d'espace peut être utilisé (gaspillé?) Pour un instantané de volume complet alors que seuls quelques fichiers doivent être capturés.
Dans un système de stockage d'objets, vous verrez rarement des instantanés de volumes, les objets seront instantanés, peut-être automatiquement. Ceci est la gestion des versions d'objet. Tous les objets n'ont pas besoin d'être versionnés, chaque objet individuel peut dire s'il est versionné.
Comment les fichiers/volumes sont-ils protégés d'un sinistre? En règle générale, dans une configuration de récupération après sinistre, des volumes/ensembles de volumes entiers sont configurés pour la réplication sur un site de récupération d'urgence. Encore une fois, cela ne vous gêne pas de savoir si des fichiers individuels doivent être répliqués ou non. L'unité de protection contre les sinistres est le volume. Les dossiers sont de petits alevins.
Dans un système de stockage d'objets, DR n'est pas centré sur le volume. Les métadonnées d'objet peuvent décider du nombre de copies et de l'emplacement (emplacements géographiques/domaines d'erreur).
De même pour d'autres fonctionnalités:
Nivellement - Objets placés dans des niveaux/classes de stockage basés sur ses métadonnées, indépendamment d'autres objets non liés.
Life - Les objets se déplacent d'un niveau à l'autre, modifient le nombre de copies, etc. individuellement, au lieu de les regrouper.
Authentification - Des objets individuels peuvent être authentifiés à partir de différents domaines d'authentification, si nécessaire.
Comme vous pouvez le constater, le changement de mentalité est que, dans un magasin d'objets, tout concerne un objet.
Comparez cela à la manière traditionnelle de penser et de gérer et d'accéder à des conteneurs plus grands, tels que des volumes (contenant des fichiers), ce n'est pas un stockage d'objets.
Les caractéristiques ci-dessus et leur caractère centré sur l'objet répondent bien aux exigences des données non structurées et, partant, à l'intérêt.
Si un système de stockage est centré sur les objets (ou les fichiers) au lieu de se concentrer sur le volume (quel que soit le protocole d'accès ou l'échelle,), il s'agit d'un système de stockage d'objets.
Il existe des différences fondamentales entre le stockage de fichiers et le stockage d'objets.
Le stockage de fichiers se présente comme une hiérarchie de système de fichiers avec des répertoires, des sous-répertoires et des fichiers. Il est génial et fonctionne à merveille lorsque le nombre de fichiers n’est pas très important. Cela fonctionne également bien lorsque vous savez exactement où vos fichiers sont stockés.
Le stockage d’objets, en revanche, se présente généralement via. une API RESTful. Il n'y a pas de concept de système de fichiers. Au lieu de cela, une application enregistrerait un objet (fichiers + métadonnées supplémentaires) dans le magasin d'objets via. L'API PUT et le stockage d'objets sauvegardent l'objet quelque part dans le système. La plate-forme de stockage d'objets attribue à l'application une clé unique (analogue à un ticket de service) pour cet objet, que l'application devrait stocker dans la base de données de l'application. Si une application souhaitait extraire cet objet, il lui suffisait de fournir la clé dans le cadre de l'API GET. L'objet serait récupéré par le stockage d'objets.
J'espère que c'est maintenant clair.
Divulgation - Je travaille pour un fournisseur (NetApp) qui développe et vend des systèmes de fichiers volumineux et des plates-formes de stockage d’objets. Je vais essayer de garder cette implémentation aussi neutre que possible, mais mes biais cognitifs peuvent influer de manière inconsciente sur ma réponse.
Il existe de nombreuses différences à la fois en termes d’accès, de programmabilité et de mise en œuvre. Toutefois, étant donné qu’il est susceptible d’être lu principalement par les programmeurs plutôt que par les responsables de l’infrastructure ou du stockage, je me concentrerai sur cet aspect.
La principale différence du point de vue externe/programmation est qu’un objet d’une librairie est créé, supprimé ou mis à jour comme une unité complète, vous ne pouvez pas ajouter de données à un objet ni mettre à jour une partie d’un objet. objet "en place", vous pouvez toutefois le remplacer tout en conservant le même ID d'objet. La création, la lecture, la mise à jour et la suppression d'objets se font généralement via des API relativement simples, presque toujours basées sur REST ou basées sur REST, qui incitent à penser que le magasin est une ressource programmable ou peut-être un service distant multi-locataire. Bien que la plupart des magasins d'objets que je connaisse prennent en charge les lectures de plage d'octets prises en charge au sein d'un objet, les magasins d'objets étaient initialement conçus pour fonctionner avec des objets entiers. Parmi les exemples d’API de stockage d’objets, citons celles utilisées par Amazon S3 (norme par défaut pour l’accès au stockage d’objet), OpenStack Swift et l’API REST d’Azure Blob Service. Décrire les implémentations dorsales derrière ces API serait un livre à lui tout seul.
D'autre part, les fichiers d'un système de fichiers ont un ensemble plus large de fonctions qui peuvent leur être appliquées, y compris l'ajout de données et la mise à jour de données sur place. Le modèle de programmation est plus complexe qu’un magasin d’objets. Il est maintenant presque toujours accessible par programme via une interface de style "POSIX". Il tente généralement d’utiliser de manière optimale le processeur et la mémoire et encourage le système à penser que le système de fichiers est une ressource locale privée. . NFS et SMB permettent qu'un système de fichiers soit rendu disponible en tant que ressource à locataires multiples. Cependant, les programmeurs le soupçonnent souvent, car ils ont parfois de subtiles différences dans leur réaction par rapport aux systèmes de fichiers "locaux" malgré leur prise en charge complète de la sémantique POSIX. Pour mettre à jour des fichiers dans un système de fichiers local, vous utiliserez probablement des API telles que https://www.classes.cs.uchicago.edu/archive/2017/winter/51081-1/LabFAQ/lab2/fileio.html ou https://msdn.Microsoft.com/en-us/library/mt794711(v=vs.85).aspx . Parler des mérites relatifs des implémentations de systèmes de fichiers, par exemple. NTFS vs BTRFS vs XFS vs WAFL vs ZFS ont tendance à donner lieu à une guerre de religion qui vaut rarement la peine de passer du temps à quiconque. Cependant, si vous m'achetez une bière, je partagerai volontiers mes opinions avec vous.
En ce qui concerne les cas d’utilisation, si vous souhaitez conserver un grand nombre de photos, de vidéos ou d’artefacts de construction binaires, un magasin d’objets est souvent un bon choix. Si, par contre, vous vouliez stocker des données de manière persistante dans une arborescence binaire et les mettre à jour sur le support de stockage, une librairie ne fonctionnerait tout simplement pas et vous seriez bien mieux avec un système de fichiers (vous pouvez également utiliser des périphériques de bloc brut pour cela, mais je n'ai vu personne le faire depuis le début des années 90)
Les autres grandes différences sont que les systèmes de fichiers sont conçus pour être fortement cohérents et sont généralement accessibles via des réseaux à latence faible à modérée (50 microsecondes - 50 millisecondes), tandis que les magasins d’objets sont souvent cohérents, puis distribués sur une infrastructure de partage sans connexion largeur de bande passante élevée, les réseaux longue portée et leur délai jusqu'au premier octet peuvent parfois être mesurés en multiples de secondes entières. Effectuer de nombreuses lectures aléatoires de petite taille (4 à 16 Ko) à partir d'une librairie est susceptible de causer de la frustration et des problèmes de performances.
L'autre avantage principal d'un magasin d'objets par rapport à un système de fichiers est que vous pouvez être raisonnablement sûr que tout ce que vous mettez dans un magasin d'objets y restera jusqu'à ce que vous le demandiez à nouveau et qu'il ne manquera jamais d'espace tant que vous continuez à payer. pour les frais mensuels. Ces ressources sont généralement exécutées à grande échelle avec réplication intégrée, contrôle de version, récupération automatique, etc., et rien de moins qu'un désastre de type ouragan Harvey ne fera disparaître les données (même dans ce cas, vous avez des options faciles pour effectuer une autre copie à un autre emplacement). Avec un système de fichiers, en particulier celui que vous ou votre personnel responsable des opérations locales doit gérer, vous devez espérer que tout sera sauvegardé, qu’il ne se remplira pas accidentellement et que tout se fondra lorsque vous ne pourrez plus mettre à jour vos données.J'ai essayé d'être conscient, mais pour ajouter à la confusion, les mots "système de fichiers" et "magasin d'objets" s'appliquent à des choses qui ne ressemblent en rien aux descriptions que j'ai utilisées ci-dessus, par exemple NFS, le système de fichiers réseau n'est pas réellement un système de fichiers, c’est un moyen d’implémenter les API de stockage posix via des appels de procédure distants, et le VSAN de VMware stocke ses données dans un "magasin d’objets" qui permet des mises à jour très rapides des images de la machine virtuelle.
I've tried to be conscise, but to add to the confusion the words "filesystem" and "object store” get applied to things which are nothing like the descriptions I’ve used above, e.g. NFS the Network file system isn’t actually a filesystem, its a way of implementing the posix storage API’s via remote procedure calls, and VMware’s VSAN stores its data in something they refer to as an "object store" which allows high speed in place updates of the virtual machine images.
La réponse simple est que les systèmes ou services de stockage accédés aux objets utilisent des API et d'autres méthodes d'accès aux objets pour stocker, extraire et rechercher des données, par opposition aux fichiers traditionnels ou aux NAS. Par exemple, avec un fichier ou un NAS, vous accédez au stockage en utilisant NFS (Network File System) ou CIFS (par exemple, un partage de fichiers Windows) aka SMB aka SAMBA où le fichier a un nom/handle avec des métadonnées associées déterminées par système de fichiers.
Les métadonnées incluent des informations sur les dates de création, d'accès, de modification et autres, les autorisations, la sécurité, le type d'application ou de fichier ou d'autres attributs. Les fichiers sont limités par le système de fichiers en termes de taille et de nombre de fichiers par système de fichiers. De même, les systèmes de fichiers sont limités par leur taille totale ou agrégée en termes de capacité d'espace et de nombre de fichiers dans le système de fichiers.
L’accès aux objets est différent car si file ou NAS front-end ou que des passerelles ou des plugins sont disponibles pour de nombreuses solutions ou services, l’accès principal se fait via une API où un objet peut être de taille arbitraire (jusqu’au maximum du système objet) ainsi que des métadonnées de taille variable (dépend de la mise en œuvre du système/service objet). Avec la plupart des systèmes/services de stockage d'objets, vous pouvez spécifier de quelques kilo-octets de métadonnées définies par l'utilisateur ou de plusieurs Go. Pour quoi utiliseriez-vous des Go-octets de métadonnées? Que diriez-vous en plus des informations normales, en ajoutant plus de données pour les stratégies, les gestions, où se trouvent les autres copies, des vignettes ou de petites prévisualisations de vidéos, audio, etc.
Parmi les exemples d’API ou d’interfaces d’accès aux objets, citons les services de stockage simples (S3) d’Amazon Web Services (AWS) ou d’autres services HTTP et REST, SNIA CDMI. Différentes solutions prendront également en charge l’accès IOS (par exemple, iphone/ipad), SOAP, Torrent, WebDav, JSON, XAM, ainsi que NFS/CIFS. En outre, de nombreux systèmes ou services de stockage d'objets prennent en charge des liaisons de programmation pour python, entre autres. Les API vous permettent essentiellement d’ouvrir un flux, puis d’obtenir ou de mettre une liste, ainsi que d’autres fonctions prises en charge par l’API/le système, afin de déterminer son utilisation.
Par exemple, j'utilise les fichiers Rackspace Cloud et Amazon S3 (en plus de EBS et Glacier) pour la sauvegarde, le stockage et l'archivage des données. Je peux accéder aux objets stockés via un navigateur Web ou des outils, notamment le disque Jungle (JD), avec lequel je sauvegarde et synchronise les fichiers. JD gère la gestion des objets et déplace les données vers Rackspace et Amazon pour moi. Si j'avais envie, je pourrais aussi faire de la programmation en utilisant les API, puis accéder directement à l'un de ces sites fournissant mes informations de sécurité pour pouvoir utiliser certaines choses avec mes objets stockés.
Voici un lien vers une introduction aux objets et au stockage en nuage d’une session que j’ai faite en Hollande l’année dernière et qui contient quelques exemples simples d’objets et d’accès . http://storageio.com/DownloadItems/Nijkerk_Nov2012/SIO_IndustryTrends_CloudObjectStorage.pdf
En utilisant la liaison programmatique, vous définissez vos structures de données ou vos objets dans votre programme, puis utilisez les API ou les appels pour le stockage, la récupération, la liste des données, l'accès aux métadonnées, etc. S'il existe un système de stockage, logiciel ou service particulier vous cherchez à travailler avec ou avez besoin de savoir comment programmer, allez sur leur site et vous devriez trouver leurs infos sur le SDK ou l'API avec des exemples. Avec les objets, une fois que vous avez créé votre compartiment ou conteneur initial sur un service ou avec un produit/système, vous créez et stockez simplement des objets supplémentaires au fur et à mesure.
Voici un exemple de lien vers l'API/programmation AWS S3: http://docs.aws.Amazon.com/AmazonS3/latest/API/IntroductionAPI.html
En théorie, on parle de systèmes de stockage d’objets ayant un nombre illimité d’objets, ou de taille d’objet, en réalité, la plupart des systèmes, solutions, logiciels ou services sont limités par ce qu’ils ont soit testés, soit actuellement pris en charge, qui peuvent être des milliards d’objets, avec taille des objets de 5 Go ou plus. Faites attention aux limites sur des services ou produits spécifiques en ce qui concerne ce qui est réellement testé, supporté par rapport à ce qui est possible d'un point de vue architectural ou mis en œuvre sur webex ou PowerPoint.
Là encore, son service et son produit/service/logiciel dépendent du nombre d’objets, de la taille des objets, de la taille des métadonnées et de la quantité de données pouvant être déplacées à l’aide de leurs API. Cependant, il est généralement prudent de supposer que le stockage d'objets peut être beaucoup plus évolutif (selon l'implémentation) que les systèmes de fichiers (sans utiliser d'espace de noms global, de fédération, de virtualisation de fichiers ou d'autres techniques).
Également dans mon livre Réseaux de stockage de données virtuels et en nuage (presse CRC), qui est recommandé par Intel, vous trouverez plus d'informations sur le stockage en nuage et sur les objets.
J'ajouterai bientôt d'autres documents sur www.objectstorage.us.
A bientôt gs
Stockage d'objets = Stockage de blocs + Métadonnées riches - Hiérarchie de fichiers
Block Storage utilise un système de fichiers pour pointer où le contenu est stocké . Object Storage utilise un identificateur pour désigner le contenu et son contexte . C'est ce que je comprends de la lecture contenu adressé par adresse adressée
Le stockage de blocs a besoin d'un système de fichiers et d'une structuration. Ainsi, avec des fichiers plus volumineux, la charge de travail est plus lourde . Le stockage d'objets a beaucoup de contexte pour le fichier et n'a pas besoin de la hiérarchie de fichiers . Dell paper montre clairement ceci..Ce qui me dérangeait, c’est que, à l’échelle du disque dur lui-même, cela n’a pas été expliqué . bien que cela semble changer pour) (bien que cela semble changer)
quelques autres idées peuvent être trouvées ici
Oh, j'aimerais pouvoir voter à la baisse certaines réponses et en voter d’autres avec un compte.
Celui qui a le plus de votes, au moment d'écrire ces lignes, n'explique même rien sur les différences.
Il existe des différences fondamentales entre le stockage de fichiers et le stockage d'objets.
Le stockage de fichiers se présente comme une hiérarchie de système de fichiers avec des répertoires, des sous-répertoires et des fichiers. Il est génial et fonctionne à merveille lorsque le nombre de fichiers n’est pas très important. Cela fonctionne également bien lorsque vous savez exactement où vos fichiers sont stockés.
Le stockage d’objets, en revanche, se présente généralement via. une API RESTful. Il n'y a pas de concept de système de fichiers. Au lieu de cela, une application enregistrerait un objet (fichiers + métadonnées supplémentaires) dans le magasin d'objets via. L'API PUT et le stockage d'objets sauvegardent l'objet quelque part dans le système. La plate-forme de stockage d'objets attribue à l'application une clé unique (analogue à un ticket de service) pour cet objet, que l'application devrait stocker dans la base de données de l'application. Si une application souhaitait extraire cet objet, il lui suffisait de fournir la clé dans le cadre de l'API GET. L'objet serait récupéré par le stockage d'objets.
J'espère que c'est maintenant clair.
Cela explique une grande partie de celle-ci; mais vous avez discuté des métadonnées. Ce qui suit est de ce que j'ai lu ces deux derniers jours, et comme cela n’a pas été résolu, je vais poster.
Le stockage d'objets n'a pas le sens de dossiers, ni de structure d'organisation facilitant l'organisation. Le stockage de fichiers, bien sûr, contient tous ces dossiers qui facilitent l'organisation et la lecture aléatoire des documents par un humain ... Dans un environnement de serveur avec le nombre de fichiers à une échelle astronomique, les dossiers ne sont qu'une perte de temps et le temps.
Les bases de données que vous dites? Eh bien, il ne parle pas du stockage Object lui-même, il dit que votre service http (php, webmail, etc.) possède l’ID unique dans sa base de données pour référencer un fichier qui peut avoir un nom reconnaissable par un humain.
Métadonnées, où est ce fichier stocké, vous dites? C'est à ça que servent les métadonnées. Votre fichier individuel est divisé en un tas de petits morceaux et est réparti entre l'emplacement géographique, les serveurs et les disques durs. Ces petites pièces contiennent également plus de données, elles contiennent des informations de parité pour les autres données, voire une duplication pure et simple.
Les métadonnées sont utilisées pour localiser chaque élément de données de ce fichier sur différents emplacements géographiques, centres de données, serveurs et disques durs, ainsi que pour restaurer tout élément détruit suite à une panne matérielle. Cela le fait automatiquement. Il sera même fluide de déplacer ces pièces pour avoir une meilleure propagation. Il va même recréer un morceau qui est parti et le stocker sur un nouveau bon disque dur.
Ceci peut être une explication simple; mais je pense que cela pourrait vous aider à mieux comprendre. Je pense que le stockage de fichiers peut faire la même chose avec les métadonnées. mais le stockage de fichiers est un stockage que vous pouvez organiser en tant qu'être humain (dossiers, hiérarchie, etc.) alors que le stockage d'objets n'a pas de hiérarchie, pas de dossiers, mais simplement un conteneur de stockage à plat.
La plupart des entreprises proposant des solutions à base d’objets utilisent une combinaison de stockage de blocs/fichiers/objets choisie en fonction de leurs besoins en termes de performances/coûts.
Du point de vue d'un cas d'utilisation:
En fin de compte, le stockage d’objets a été créé pour traiter les données non structurées qui connaissent une croissance explosive, beaucoup plus rapidement que les données structurées.
Par exemple, si une base de données est constituée de données structurées, un document Word ou PDF serait non structuré.
Comment recherchez-vous 1 milliard de fichiers PDF dans un système de fichiers? (si elle pouvait même en stocker autant en premier lieu).
Combien de temps pouvez-vous rechercher uniquement les métadonnées de 1 milliard de fichiers?
Le stockage d'objets est actuellement davantage utilisé pour le stockage à long terme ou d'archivage, bon marché et profond, qui garde une trace plus détaillée de la nature de ces données. Ces métadonnées deviennent très puissantes lors de la recherche ou de l’exploitation de très grands ensembles de données. Parfois, vous pouvez obtenir ce dont vous avez besoin dans les métadonnées sans même accéder aux données. Les solutions de stockage d'objets peuvent généralement se répliquer automatiquement avec le basculement géographique intégré.
Le problème est que l'application devrait être réécrite pour utiliser des méthodes d'accès aux objets plutôt que la hiérarchie des fichiers (ce qui est plus simple du point de vue d'une application). Il s'agit en réalité d'un changement de philosophie de stockage des données, qui consiste à stocker des informations plus exploitables sur ces données du point de vue de la gestion et de l'utilisation.
Un exemple rapide pourrait être une image numérisée par IRM. Sur le système de fichiers, vous avez la date de création/propriétaire, mais pas beaucoup d'autre. S'il s'agissait d'un objet, toutes les informations relatives à l'IRM pourraient être stockées avec des métadonnées, telles que le nom du patient, l'emplacement du centre d'IRM, le médecin demandeur, l'assureur, etc.
Les blocs/fichiers conviennent mieux à l'accès local ou à OTLP, où les performances sont plus importantes que la rétention et le coût.
Par exemple, vous ne voudriez pas attendre que le document Word s'ouvre, mais vous pouvez attendre quelques minutes pour qu'un processus d'exploration de données/d'aide à la décision soit terminé.
Un autre exemple serait une recherche légale dans laquelle vous devez tout rechercher à partir d’il ya 5 ans. Avec des stratégies de rétention en place pour réduire le jeu de données actif et les coûts, comment le feriez-vous sans restaurer à partir d'une bande?
Le stockage d'objets est une excellente solution pour remplacer les méthodes d'archivage à long terme telles que la bande.
La configuration de la réplication et du basculement pour bloc et fichier peut coûter très cher en entreprise et nécessite généralement des logiciels et des services très coûteux.
Remarque: au niveau inférieur, l'accès au stockage des objets s'effectue via l'API RESTful, qui s'apparente davantage à une requête Web qu'à un fichier situé à la fin d'un chemin.
Ce lien explique les différences entre les deux: http://www.Dell.com/downloads/global/products/pvaul/en/object-storage-overview.pdf
Je pense que le livre blanc explique assez bien l'idée du stockage d'objets. Je ne connais aucune méthode standard d'utilisation des périphériques de stockage d'objets (au sens d'un OSD SCSI) à partir d'une application utilisateur.
Le stockage d'objets est utilisé dans certains produits de stockage à grande échelle tels que les dispositifs de stockage de Panasas . Cependant, ces appareils exportent ensuite un système de fichiers vers l'utilisateur final. Il est juste de croire que l’idée du T10 OSD n’a jamais vraiment pris son élan.
Des idées apparentées à la norme OSD peuvent être trouvées dans les systèmes de stockage en nuage tels que S3 et RADOS .
En réalité, vous pouvez monter un compartiment/conteneur et accéder aux objets ou aux sous-dossiers (et à leurs objets) à partir de Linux. Par exemple, s3fs est installé sur Ubuntu et a configuré un point de montage sur l’un de mes compartiments S3. Il est également capable de faire les fonctions cp, ls et autres fonctions normales, comme si c’était un autre système de fichiers. La clé consiste à obtenir un outil logiciel qui vous permet de mapper un seau/conteneur et de le présenter comme point de montage. Il existe également des outils logiciels qui vous permettent d'accéder à S3 et à d'autres compartiments/conteneurs via iSCSI en plus du NAS.