Discussion :

[Pierre Aguerreberry]

Le Stockage Objet, nouvelle star du stockage en entreprise, par Pierre Aguerreberry, VP Sales Southern Europe chez DataCore Software

L'essor du stockage objet est en lien direct avec l'explosion croissante des données. Les formes traditionnelles de stockage telles que le stockage par blocs et le stockage de fichiers ont lutté sous l'assaut des données non structurées et des afflux de médias sociaux. Ils sont devenus lourds, obsolètes et difficiles à gérer. Le stockage objet a donc été développé pour résoudre le problème du stockage de très gros volumes de données de manière évolutive. Il devient aujourd’hui incontournable pour la plupart des grandes entreprises.

Pierre Aguerreberry, VP Sales Southern Europe chez DataCore Software

En quoi se différencie le stockage objet des autres types de stockage ?

Les solutions de stockage d'objets se distinguent par leur approche de la gestion de l'infrastructure et de la gestion des données.

Le stockage objet est idéal pour les ensembles de données très volumineux. En effet, le logiciel de stockage objet peut être installé sur des serveurs peu coûteux et les données peuvent circuler librement à travers le système. Il peut ajouter des ressources, tout en optimisant et en équilibrant en permanence l'ensemble de la solution de stockage. Cela est en revanche difficile à réaliser avec un stockage fichier, car les fichiers sont verrouillés par le chemin d'accès nom du répertoire/fichier spécifique.

C'est cette approche qui explique que le stockage objet se trouve à la base de tous les services de stockage Cloud et au cœur de tous les services qui fournissent des données non structurées (services audio, services de vidéo à la demande, services de photo, etc.).

Des décennies d’innovation pour aider les entreprises à s’adapter

Alors que le stockage de blocs et de fichiers reste très utilisé, le stockage objet connaît désormais une croissance rapide dans l'entreprise. En effet ces dernières ont besoin de sa puissance et de sa polyvalence. Une architecture de stockage d'objets fournit un moyen de stocker des données sous forme d'unités autonomes appelées objets. Ainsi, elle est devenue la plateforme préférée des grands fournisseurs de cloud public.

Du point de vue des décisions métier, le stockage objet aide un grand nombre d'utilisateurs finaux et d'applications à consulter et à consommer des données non structurées de manière simple, quel que soit l'emplacement des données.

Développer une base software-defined selon les axes du stockage bloc, fichier et objet

Pour rappel, le terme Software-Defined Storage (ou SDS, qui désigne le stockage défini par logiciel) vient d’un concept dénommé virtualisation du stockage. L’objet de la virtualisation du stockage est d’ajouter une couche d’abstraction entre les applications et les solutions de stockage classiques sur lesquelles les données sont inscrites. Cette couche logicielle permet aux administrateurs informatiques de réunir et d’installer les dispositifs de stockage de façon plus souple. Dans le même temps, la virtualisation du stockage permet aussi aux services informatiques d’offrir de meilleurs niveaux de disponibilité sans devoir interrompre les applications pendant la mise à jour des systèmes de stockage.

Chaque architecture de stockage a son intérêt :

• le bloc est optimisé pour des I/O rapides afin d’exécuter efficacement des systèmes de transactions élevées,
  
• le fichier est optimisé pour l’accès au réseau et le partage de fichiers afin de faciliter la collaboration,
  
• et l’objet est optimisé pour l’accès distribué et la livraison de contenu en vue d’une utilisation et d’une rétention à long terme.

Au cours du cycle de vie des données, chacune de ces architectures devient nécessaire. La suite de produits combinée offre immédiatement aux clients une transition simplifiée entre chaque architecture et jette les bases de nouvelles innovations pour résoudre des problèmes de stockage, d’accès et de gestion des données en évolution rapide.

Comme le disait le philosophe Héraclite : « Rien n’est permanent, sauf le changement ». Une entreprise doit désormais sélectionner des produits qui répondent aux exigences d’aujourd’hui, mais aussi ceux qui répondront aux besoins de demain.

Et vous ?

Que pensez-vous du stockage objet ?

Voir aussi :

OVHcloud s'associe à IBM et Atempo pour offrir aux organisations européennes une solution de stockage dans le cloud souveraine et compétitive, partenariat basé sur les solutions de stockage sur bande

[SQLpro]

Rien de nouveau sous le soleil.... dans les années 90 sont nées les premières bases de données objet. Je me souviens particulièrement de O² développé par l'université d'Orsay
https://www.researchgate.net/publica...ted_data_model
Et son langage de requête OQL (Object Query Language)...

De nombreux systèmes de bases de données objet avaient été développés à cette époque, mais tous sont aujourd'hui quasiment disparu par darwinisme. En effet, il est impossible d'indexer tout type d'objet. Or qui dit base de données, dit collections d'objets, donc recherche d'un élément dans l'ensemble, le plus rapidement possible... Il est déjà difficile d'indexer du spatial (une grande majorité de requête ne peuvent utiliser les index spatiaux..) et encore plus le XML (certains éditeurs comme MS SQL Server ont réussi à indexer le XML pour une grande majorité de requêtes, mais ces techniques sont inaccessible dans le libre où, par exemple, PostGreSQL comme MySQL, ne propose aucun moyen d'indexer le XML).

Bref le serpent de mer des bases de données objets, revient dans une nouvelle resucée qui à toutes les chances de se traduire par un flop...

[Derf59]

@SQLPro, on ne parle pas de bases de données dans cet article, on parle de stockage des objets (et il n'y a pas de relations entre ces objets comme tu pourrais l'avoir dans une base type O²)

Le stockage objet c'est plutôt un stockage "clé d'accès" et "contenu" (dans diverses formats) et tu ne sais pas physiquement sur quel support c'est stocké.

Aujourd'hui :
- si on utilise un disque physique, à un moment tu es limité par la taille et peu de tolérances aux pannes
- tu utilise un NAS tu as des problèmes car la clé est le chemin + le fichier et des problèmes de "lock" en cas de mise à jour simultanée.

Le Stockage Object, c'est la possibilité d'offrir une sorte de "disque virtuel" qu'on pourrait augmenter en tout transparence, avec une tolérance aux pannes et un système "minimal" de transaction lorsque tu mets à jour un objet (voir de conserver plusieurs versions de cet objet)

Donc ne par confondre un Stockage Object et une base de données Object (pour lesquelles tu as des relations et des langages de requête)

[yannickt]

L'introduction de cette plaquette publicitaire m'a bien fait rire. Le stockage par fichier, lourd est obsolète ? Euh, les données du stockage objet finissent toujours dans des fichiers finalement, il n'y a pas de miracle. Pour moi, c'est à ce moment-là que l'auteur a perdu toute crédibilité. Le stockage objet, je veux bien croire qu'il a un intérêt, mais si on commence une présentation en me pipeautant, j’apprécie moyen...

[Gugelhupf]

encore plus le XML (certains éditeurs comme MS SQL Server ont réussi à indexer le XML pour une grande majorité de requêtes, mais ces techniques sont inaccessible dans le libre où, par exemple, PostGreSQL comme MySQL, ne propose aucun moyen d'indexer le XML)

C'est drôle parce que tu prones SQL Server pour sa gestion du XML mais visiblement ils n'ont pas fourni le même niveau d'effort pour le JSON contrairement à PostgreSQL

Et puis j'ai envie de dire qu'on s'en fou un peu, qui t'empêche de créer une table avec le contenu que tu souhaites dans une colonne, puis de créer autant de colonne que tu auras d'index ? Tu appliqueras ta clause WHERE sur ces colonnes indexées pour remonter ton XML, ou JSON etc

[redcurve]

@SQLPro, on ne parle pas de bases de données dans cet article, on parle de stockage des objets (et il n'y a pas de relations entre ces objets comme tu pourrais l'avoir dans une base type O²)

Le stockage objet c'est plutôt un stockage "clé d'accès" et "contenu" (dans diverses formats) et tu ne sais pas physiquement sur quel support c'est stocké.

Aujourd'hui :
- si on utilise un disque physique, à un moment tu es limité par la taille et peu de tolérances aux pannes
- tu utilise un NAS tu as des problèmes car la clé est le chemin + le fichier et des problèmes de "lock" en cas de mise à jour simultanée.

Le Stockage Object, c'est la possibilité d'offrir une sorte de "disque virtuel" qu'on pourrait augmenter en tout transparence, avec une tolérance aux pannes et un système "minimal" de transaction lorsque tu mets à jour un objet (voir de conserver plusieurs versions de cet objet)

Donc ne par confondre un Stockage Object et une base de données Object (pour lesquelles tu as des relations et des langages de requête)

Physiquement ce sont des fichiers de toute façon les SSD et HDD ne savent pas stocker autre chose, la partie object est une vue de l'esprit coté dev à la fin des fins on balade des fichiers sous un format ou un autre.

Le stockage objet n'a aucun rapport avec les capacités décrites ont fait ça très bien avec des fichiers, utiliser le chemin de fichier n'est pas forcément une bonne idée, sur notre système tout a un guid et il n'y a pas de notion de type de fichier ou même de fichier, on accès simplement à une ressource point. Donc tout le délire autour du stockage magique objet est du bullshit complet. En outre saucissonner un fichier sur x nœuds et pouvoir y accéder de façon transparente comme un tout cohérent ça se fait sans problème.

[SQLpro]

C'est drôle parce que tu prones SQL Server pour sa gestion du XML mais visiblement ils n'ont pas fourni le même niveau d'effort pour le JSON contrairement à PostgreSQL

Et puis j'ai envie de dire qu'on s'en fou un peu, qui t'empêche de créer une table avec le contenu que tu souhaites dans une colonne, puis de créer autant de colonne que tu auras d'index ? Tu appliqueras ta clause WHERE sur ces colonnes indexées pour remonter ton XML, ou JSON etc

Sujet divergent, mais réponse quand même...

• PostGreSQL ne sait toujours pas indexer le XML alors que cela est fait dans Oracle, SQL Server et IBM DB2...
• Le niveau de fonctionnalité disponible dans SQL Server pour XML est bien plus élevé (support de XPath2, xQuery, XML schema...) alors que PostGreSQL en est a XPath 1 et pas de XQuery ni XML schema... Autrement dit XML est inexploitable dans PostGreSQL.
• Enfin, JSON n'est pas indexé par aucun SGBD actuellement ce qui le rend lent. Pour les petites applications de bidouillage comme PostGreSQL pourquoi pas, mais quand tu as des centaines de milliers de thèses ou de brevets, comme ce que font les universités à Paris, tu met ça dans du XML, pas dans du JSON, et dans du Oracle ou du SQL Server, pas dans du PostGreSQl !

Voir :
http://mssqlserver.fr/postgresql-vs-...ed-comparison/
notamment § 10

Enfin, l'indexation de certains informations extraites d'un XML n'a rien à voir avec l'indexation d'un document qui permet d'indexer les valeurs, les chemins, les balises et les attributs. Pour le cas de PostGreSQL qui ne sait pas indexer le XML, il faudrait créer autant de colonne calculées qu'il y a de points de valeurs dans les arbres XML mais en ayant toujours l'incapacité de rechercher rapidement dans le XML pour savoir si telle branche, telle balise, tel attribut existe à tel endroit du XML... Et cela en ayant une augmentation colossale dans PostGreSQL du volume de la base du fait du nombre de colonnes redondantes à indexer sans être à plus de 1% de la hauteur de ce que font les autres SGBDR !

A +

[Waldar]

Pour revenir au sujet, je pense que le stockage objet a de beaux jours devant lui.
La technologie est relativement simple - on prend des données on les stocke en format parquet = format binaire compressé distribué en colonne, ce qui marche très bien avec un cluster derrière.
Les méthodes d'accès sont effectivement clef d'authentification + contenu, c'est une solution qui a le vent en poupe dans le cloud mais pas seulement, on trouve de plus en plus de solutions de stockage objets pour mettre dans ses centres de données.

Par contre ce n'est pas pour n'importe quel usage avec les bases de données, c'est pour stocker des données massives et/ou froides. En effet à chaque lecture il faudra lire et retravailler les données pour les rendre intelligibles par la base, ce qui a un coût. Pour un usage disons une fois de temps en temps c'est très bien, mais pour un usage où on attend de la performance inférieure à la seconde ça me paraît plus compliqué.

Chez teradata, nous développons notamment des connecteurs natifs pour lire directement des objets depuis la base de données avec d'excellentes performances (largeur de la bande passante à prendre en compte bien entendu si on est sur site et qu'on interroge un stockage cloud par exemple). Ça permet beaucoup de souplesse chez nos clients.
Un billet de présentation de cette techno sur Google Cloud (mais pas que) - en anglais : https://www.teradata.com/Blogs/It-Ju...-Cloud-Storage