6 technologies de stockage de données au choix

Les problématiques métier sont trop vastes, trop complexes et trop variées pour qu'un seul outil puisse toutes les résoudre, en particulier en matière de big data et d'analytique. Cet article présente 6 technologies alternatives pour le stockage de données.
1. Stockage de données structurées
Le stockage de données structurées existe depuis des décennies et constitue la technologie de stockage de données la plus répandue. La plupart des bases de données transactionnelles sont des bases de données en mode ligne, car elles prennent en charge de fréquentes écritures de données provenant d'applications logicielles.
Les entreprises utilisent souvent les bases de données transactionnelles simultanément pour le reporting, auquel cas les données doivent être lues fréquemment, mais sont écrites beaucoup moins souvent. Face à la demande croissante en lecture de données, de nombreuses innovations ont vu le jour dans le domaine des requêtes sur le stockage de données structurées, notamment le format de fichier colonaire, qui contribue à améliorer les performances de lecture et à répondre aux besoins d'analyse.
Les formats en mode ligne stockent les données dans un fichier sous forme de lignes. L'écriture en mode ligne est la méthode la plus rapide pour écrire des données sur disque, mais ce n'est pas nécessairement la plus rapide en lecture, car il faut ignorer une grande quantité de données non pertinentes.
Les formats en mode colonne regroupent toutes les valeurs d'une même colonne dans le fichier. Il en résulte une meilleure compression, puisque les mêmes types de données sont désormais regroupés. Souvent, cela offre également de meilleures performances en lecture, car vous pouvez ignorer les colonnes dont vous n'avez pas besoin.
Examinons les choix courants pour le stockage de données structurées. Par exemple, vous devez interroger le nombre total de ventes pour un mois donné dans la table des commandes, mais la table comporte 50 colonnes. Dans l'architecture en mode ligne, les 50 colonnes de la table entière sont parcourues lors de la requête, tandis que dans l'architecture colonaire, seule la colonne des ventes est parcourue, ce qui améliore les performances des requêtes. Examinons de plus près les bases de données relationnelles, en nous concentrant sur les données transactionnelles et le besoin d'entrepôts de données pour le traitement analytique.
Les entreprises utilisent souvent les bases de données transactionnelles simultanément pour le reporting, auquel cas les données doivent être lues fréquemment, mais sont écrites beaucoup moins souvent. Face à la demande croissante en lecture de données, de nombreuses innovations ont vu le jour dans le domaine des requêtes sur le stockage de données structurées, notamment le format de fichier colonaire, qui contribue à améliorer les performances de lecture et à répondre aux besoins d'analyse.
Les formats en mode ligne stockent les données dans un fichier sous forme de lignes. L'écriture en mode ligne est la méthode la plus rapide pour écrire des données sur disque, mais ce n'est pas nécessairement la plus rapide en lecture, car il faut ignorer une grande quantité de données non pertinentes.
Les formats en mode colonne regroupent toutes les valeurs d'une même colonne dans le fichier. Il en résulte une meilleure compression, puisque les mêmes types de données sont désormais regroupés. Souvent, cela offre également de meilleures performances en lecture, car vous pouvez ignorer les colonnes dont vous n'avez pas besoin.
Examinons les choix courants pour le stockage de données structurées. Par exemple, vous devez interroger le nombre total de ventes pour un mois donné dans la table des commandes, mais la table comporte 50 colonnes. Dans l'architecture en mode ligne, les 50 colonnes de la table entière sont parcourues lors de la requête, tandis que dans l'architecture colonaire, seule la colonne des ventes est parcourue, ce qui améliore les performances des requêtes. Examinons de plus près les bases de données relationnelles, en nous concentrant sur les données transactionnelles et le besoin d'entrepôts de données pour le traitement analytique.
(1) Base de données relationnelle
Le SGBDR est plus adapté aux applications de traitement transactionnel en ligne (OLTP). Les bases de données relationnelles populaires incluent MSSQL, MariaDB, PostgreSQL, etc. Certaines de ces bases de données traditionnelles existent depuis des décennies.
De nombreuses applications, notamment le commerce électronique, les services bancaires et les réservations d'hôtels, reposent sur des bases de données relationnelles. Les bases de données relationnelles excellent dans le traitement des données transactionnelles nécessitant des requêtes de jointure complexes entre tables. Du point de vue des exigences en matière de données transactionnelles, les bases de données relationnelles doivent respecter les principes d'atomicité, de cohérence, d'isolation et de durabilité, définis comme suit :
Atomicité : la transaction est exécutée intégralement du début à la fin, et en cas d'erreur, l'ensemble de la transaction est annulé.
Cohérence : une fois la transaction terminée, toutes les données sont validées dans la base de données.
Isolation : plusieurs transactions doivent s'exécuter simultanément de manière isolée, sans interférer les unes avec les autres.
Durabilité : en cas d'interruption (panne réseau ou coupure de courant, par exemple), la transaction doit pouvoir récupérer le dernier état connu.
En règle générale, les données des bases de données relationnelles sont déversées dans un entrepôt de données à des fins de reporting et d'agrégation.
Le SGBDR est plus adapté aux applications de traitement transactionnel en ligne (OLTP). Les bases de données relationnelles populaires incluent MSSQL, MariaDB, PostgreSQL, etc. Certaines de ces bases de données traditionnelles existent depuis des décennies.
De nombreuses applications, notamment le commerce électronique, les services bancaires et les réservations d'hôtels, reposent sur des bases de données relationnelles. Les bases de données relationnelles excellent dans le traitement des données transactionnelles nécessitant des requêtes de jointure complexes entre tables. Du point de vue des exigences en matière de données transactionnelles, les bases de données relationnelles doivent respecter les principes d'atomicité, de cohérence, d'isolation et de durabilité, définis comme suit :
Atomicité : la transaction est exécutée intégralement du début à la fin, et en cas d'erreur, l'ensemble de la transaction est annulé.
Cohérence : une fois la transaction terminée, toutes les données sont validées dans la base de données.
Isolation : plusieurs transactions doivent s'exécuter simultanément de manière isolée, sans interférer les unes avec les autres.
Durabilité : en cas d'interruption (panne réseau ou coupure de courant, par exemple), la transaction doit pouvoir récupérer le dernier état connu.
En règle générale, les données des bases de données relationnelles sont déversées dans un entrepôt de données à des fins de reporting et d'agrégation.
(2) Entrepôt de données
Les entrepôts de données sont plus adaptés aux applications de traitement analytique en ligne (OLAP). Ils offrent des capacités d'agrégation rapides pour de grands volumes de données structurées. Les données doivent être chargées par lots, ce qui empêche les entrepôts de fournir des analyses en temps réel sur les données chaudes.
Les entrepôts de données modernes utilisent le stockage colonaire pour améliorer les performances des requêtes. Grâce au stockage colonaire, ces entrepôts de données offrent une vitesse de requête très élevée et améliorent l'efficacité des E/S.
Un entrepôt de données est un référentiel central qui peut stocker les données accumulées provenant d'une ou plusieurs bases de données. Il stocke les données actuelles et historiques pour créer des rapports analytiques sur les données métier.
Bien que les entrepôts de données centralisent les données de plusieurs systèmes, ils ne peuvent pas être considérés comme des lacs de données. Un entrepôt de données ne peut traiter que des données relationnelles structurées, tandis qu'un lac de données peut traiter à la fois des données relationnelles structurées et des données non structurées telles que les données JSON, les journaux et les données CSV.
Les entrepôts de données sont plus adaptés aux applications de traitement analytique en ligne (OLAP). Ils offrent des capacités d'agrégation rapides pour de grands volumes de données structurées. Les données doivent être chargées par lots, ce qui empêche les entrepôts de fournir des analyses en temps réel sur les données chaudes.
Les entrepôts de données modernes utilisent le stockage colonaire pour améliorer les performances des requêtes. Grâce au stockage colonaire, ces entrepôts de données offrent une vitesse de requête très élevée et améliorent l'efficacité des E/S.
Un entrepôt de données est un référentiel central qui peut stocker les données accumulées provenant d'une ou plusieurs bases de données. Il stocke les données actuelles et historiques pour créer des rapports analytiques sur les données métier.
Bien que les entrepôts de données centralisent les données de plusieurs systèmes, ils ne peuvent pas être considérés comme des lacs de données. Un entrepôt de données ne peut traiter que des données relationnelles structurées, tandis qu'un lac de données peut traiter à la fois des données relationnelles structurées et des données non structurées telles que les données JSON, les journaux et les données CSV.
2. Base de données NoSQL
Les bases de données NoSQL telles que Dynamo DB, Cassandra et Mongo DB permettent de résoudre les défis de mise à l'échelle et de performance souvent rencontrés avec les bases de données relationnelles. Comme son nom l'indique, NoSQL désigne une base de données non relationnelle. Les bases de données NoSQL stockent les données sans mécanisme structurel bien défini pour relier les données entre différentes tables (pas de jointures, de clés étrangères ni de paradigmes).
NoSQL utilise une variété de modèles de données, notamment les modèles colonaire, clé-valeur, de recherche, documentaire et orienté graphe. Les bases de données NoSQL offrent des performances évolutives, une haute disponibilité et une résilience accrue.
NoSQL ne dispose généralement pas d'un schéma de base de données strict : chaque enregistrement peut comporter un nombre quelconque de colonnes (attributs), ce qui signifie qu'une ligne peut avoir 4 colonnes tandis qu'une autre ligne de la même table peut en avoir 10. Les clés de partition sont utilisées pour récupérer des valeurs ou des documents contenant des propriétés associées. Les bases de données NoSQL sont hautement distribuées et peuvent être répliquées. Elles offrent une grande durabilité et une haute disponibilité sans problème de performance.
NoSQL utilise une variété de modèles de données, notamment les modèles colonaire, clé-valeur, de recherche, documentaire et orienté graphe. Les bases de données NoSQL offrent des performances évolutives, une haute disponibilité et une résilience accrue.
NoSQL ne dispose généralement pas d'un schéma de base de données strict : chaque enregistrement peut comporter un nombre quelconque de colonnes (attributs), ce qui signifie qu'une ligne peut avoir 4 colonnes tandis qu'une autre ligne de la même table peut en avoir 10. Les clés de partition sont utilisées pour récupérer des valeurs ou des documents contenant des propriétés associées. Les bases de données NoSQL sont hautement distribuées et peuvent être répliquées. Elles offrent une grande durabilité et une haute disponibilité sans problème de performance.
3. Types de bases de données NoSQL
Les principaux types de bases de données NoSQL sont les suivants :
Bases de données colonnaires : les stores de données colonnaires permettent de parcourir une colonne lors d'une requête, plutôt que de parcourir la ligne entière. Si la table des articles comporte 10 colonnes et 1 million de lignes, et que vous souhaitez interroger la quantité d'un article dans l'inventaire, la base de données colonaire n'appliquera la requête qu'à la colonne de quantité, sans parcourir l'ensemble de la table.
Bases de données documentaires : les bases de données documentaires les plus populaires sont MongoDB, Couchbase, MarkLogic, Dynamo DB et Cassandra. Une base de données documentaire permet de stocker des données semi-structurées aux formats JSON et XML.
Bases de données orientées graphe : une base de données orientée graphe stocke des sommets et des liens entre les sommets (appelés arêtes). Les graphes peuvent être construits sur des bases de données relationnelles et non relationnelles.
Stores clé-valeur en mémoire : ils stockent les données en mémoire vive et sont utilisés dans les scénarios où les données sont lues fréquemment. La requête de l'application est d'abord adressée à la base de données en mémoire, et si les données sont disponibles dans le cache, la base de données principale n'est pas sollicitée. Les bases de données en mémoire sont idéales pour stocker les informations de session utilisateur qui génèrent des requêtes complexes et des demandes fréquentes de données telles que les profils utilisateur.
NoSQL couvre de nombreux cas d'utilisation, mais pour construire un service de recherche de données, toutes les données doivent être indexées.
Bases de données colonnaires : les stores de données colonnaires permettent de parcourir une colonne lors d'une requête, plutôt que de parcourir la ligne entière. Si la table des articles comporte 10 colonnes et 1 million de lignes, et que vous souhaitez interroger la quantité d'un article dans l'inventaire, la base de données colonaire n'appliquera la requête qu'à la colonne de quantité, sans parcourir l'ensemble de la table.
Bases de données documentaires : les bases de données documentaires les plus populaires sont MongoDB, Couchbase, MarkLogic, Dynamo DB et Cassandra. Une base de données documentaire permet de stocker des données semi-structurées aux formats JSON et XML.
Bases de données orientées graphe : une base de données orientée graphe stocke des sommets et des liens entre les sommets (appelés arêtes). Les graphes peuvent être construits sur des bases de données relationnelles et non relationnelles.
Stores clé-valeur en mémoire : ils stockent les données en mémoire vive et sont utilisés dans les scénarios où les données sont lues fréquemment. La requête de l'application est d'abord adressée à la base de données en mémoire, et si les données sont disponibles dans le cache, la base de données principale n'est pas sollicitée. Les bases de données en mémoire sont idéales pour stocker les informations de session utilisateur qui génèrent des requêtes complexes et des demandes fréquentes de données telles que les profils utilisateur.
NoSQL couvre de nombreux cas d'utilisation, mais pour construire un service de recherche de données, toutes les données doivent être indexées.
4. Elasticsearch
Elasticsearch est l'un des moteurs de recherche les plus populaires pour les scénarios big data tels que l'analyse de flux de clics et de journaux. Les requêtes ad hoc sur des données chaudes comportant un nombre quelconque d'attributs, y compris des jetons de texte, sont bien prises en charge par les moteurs de recherche. Elasticsearch est très largement adopté. Le stockage binaire générique ou le stockage objet convient aux données non structurées, non indexables et autres données dans un format qu'aucun outil spécialisé ne peut interpréter.
La recherche et l'analyse de journaux sont des scénarios d'application courants du big data, et Elasticsearch peut vous aider à analyser les données de journaux provenant de sites web, de serveurs et de capteurs IoT. Elasticsearch est utilisé par un grand nombre d'applications sectorielles telles que la banque, le gaming, le marketing, la surveillance d'applications, l'ad tech, la détection de fraude, les systèmes de recommandation et l'IoT.
La recherche et l'analyse de journaux sont des scénarios d'application courants du big data, et Elasticsearch peut vous aider à analyser les données de journaux provenant de sites web, de serveurs et de capteurs IoT. Elasticsearch est utilisé par un grand nombre d'applications sectorielles telles que la banque, le gaming, le marketing, la surveillance d'applications, l'ad tech, la détection de fraude, les systèmes de recommandation et l'IoT.
5. Stockage de données non structurées
Lorsque vous avez des besoins en stockage de données non structurées, Hadoop semble être un choix idéal, car il est évolutif et très flexible. Il fonctionne sur des équipements grand public, dispose d'un vaste écosystème d'outils et s'avère économique à exploiter.
Hadoop adopte un mode de fonctionnement avec nœud maître et nœuds enfants. Les données sont distribuées sur plusieurs nœuds enfants, et le nœud maître coordonne les opérations et exécute les requêtes sur les données. Le système Hadoop repose sur le traitement massivement parallèle (MPP), ce qui permet d'interroger rapidement différents types de données, qu'elles soient structurées ou non.
Lorsqu'un cluster Hadoop est créé, chaque nœud enfant créé sur le serveur esclave est accompagné d'un bloc de stockage sur disque appelé système de fichiers distribué Hadoop local (HDFS). Vous pouvez interroger les données stockées à l'aide de frameworks de traitement courants tels que Hive, Ping et Spark. Toutefois, les données sur le disque local ne sont persistées que pendant la durée de vie de l'instance associée.
Si vous utilisez la couche de stockage de Hadoop (c'est-à-dire HDFS) pour stocker des données, le stockage et le calcul sont alors couplés. Ajouter du stockage implique d'ajouter davantage de machines, ce qui augmente également la puissance de calcul. Pour une flexibilité maximale et un rapport coût-efficacité optimal, le calcul et le stockage doivent être séparés et évoluer indépendamment l'un de l'autre.
En règle générale, le stockage objet est mieux adapté aux lacs de données pour stocker toutes sortes de données de manière économique. Grâce au stockage objet, les lacs de données cloud peuvent découpler le calcul et le stockage en toute flexibilité.
Hadoop adopte un mode de fonctionnement avec nœud maître et nœuds enfants. Les données sont distribuées sur plusieurs nœuds enfants, et le nœud maître coordonne les opérations et exécute les requêtes sur les données. Le système Hadoop repose sur le traitement massivement parallèle (MPP), ce qui permet d'interroger rapidement différents types de données, qu'elles soient structurées ou non.
Lorsqu'un cluster Hadoop est créé, chaque nœud enfant créé sur le serveur esclave est accompagné d'un bloc de stockage sur disque appelé système de fichiers distribué Hadoop local (HDFS). Vous pouvez interroger les données stockées à l'aide de frameworks de traitement courants tels que Hive, Ping et Spark. Toutefois, les données sur le disque local ne sont persistées que pendant la durée de vie de l'instance associée.
Si vous utilisez la couche de stockage de Hadoop (c'est-à-dire HDFS) pour stocker des données, le stockage et le calcul sont alors couplés. Ajouter du stockage implique d'ajouter davantage de machines, ce qui augmente également la puissance de calcul. Pour une flexibilité maximale et un rapport coût-efficacité optimal, le calcul et le stockage doivent être séparés et évoluer indépendamment l'un de l'autre.
En règle générale, le stockage objet est mieux adapté aux lacs de données pour stocker toutes sortes de données de manière économique. Grâce au stockage objet, les lacs de données cloud peuvent découpler le calcul et le stockage en toute flexibilité.
6. Lac de données
Un lac de données est un référentiel centralisé de données structurées et non structurées. Les lacs de données deviennent une solution prisée pour stocker et analyser de grands volumes de données dans un stockage centralisé. Les données sont stockées telles quelles, dans un format de fichier open source, pour une analyse directe. Les données pouvant être stockées telles quelles dans leur format actuel, il n'est pas nécessaire de les convertir selon un schéma prédéfini, ce qui accélère l'ingestion des données.
Les avantages d'un lac de données sont les suivants :
Ingérer des données de sources variées : un lac de données vous permet de stocker et d'analyser des données provenant de sources variées (bases de données relationnelles, non relationnelles, flux, etc.) en un emplacement centralisé, afin de constituer une source de vérité unique. Il répond à des questions telles que : pourquoi les données sont-elles dispersées dans plusieurs emplacements ? Où se trouve la source de vérité unique ?
Ingérer et stocker les données efficacement : les lacs de données peuvent ingérer tout type de données, y compris des données semi-structurées et non structurées, sans nécessiter de schéma. Cela répond à la question de la manière d'ingérer rapidement des données de sources variées, dans différents formats, et de les stocker efficacement à grande échelle.
Face à la croissance continue des volumes de données générées : un lac de données vous permet de séparer la couche de stockage de la couche de calcul, en faisant évoluer chaque composant indépendamment. Cela répond à la question de la mise à l'échelle en fonction du volume de données produites.
Appliquer l'analytique à des données de sources hétérogènes : avec un lac de données, vous pouvez identifier des motifs dans les données au fil de la lecture et créer un catalogue de données centralisé à partir de données collectées depuis des sources hétérogènes. Vous pouvez ainsi analyser les données rapidement et à tout moment. Cela répond à la question de savoir si plusieurs frameworks d'analyse et de traitement peuvent être appliqués aux mêmes données.
Les avantages d'un lac de données sont les suivants :
Ingérer des données de sources variées : un lac de données vous permet de stocker et d'analyser des données provenant de sources variées (bases de données relationnelles, non relationnelles, flux, etc.) en un emplacement centralisé, afin de constituer une source de vérité unique. Il répond à des questions telles que : pourquoi les données sont-elles dispersées dans plusieurs emplacements ? Où se trouve la source de vérité unique ?
Ingérer et stocker les données efficacement : les lacs de données peuvent ingérer tout type de données, y compris des données semi-structurées et non structurées, sans nécessiter de schéma. Cela répond à la question de la manière d'ingérer rapidement des données de sources variées, dans différents formats, et de les stocker efficacement à grande échelle.
Face à la croissance continue des volumes de données générées : un lac de données vous permet de séparer la couche de stockage de la couche de calcul, en faisant évoluer chaque composant indépendamment. Cela répond à la question de la mise à l'échelle en fonction du volume de données produites.
Appliquer l'analytique à des données de sources hétérogènes : avec un lac de données, vous pouvez identifier des motifs dans les données au fil de la lecture et créer un catalogue de données centralisé à partir de données collectées depuis des sources hétérogènes. Vous pouvez ainsi analyser les données rapidement et à tout moment. Cela répond à la question de savoir si plusieurs frameworks d'analyse et de traitement peuvent être appliqués aux mêmes données.
Articles connexes
-
Qu'est-ce que la blockchain
Équipe Base de connaissances
-
Qu'est-ce que le CDN
Équipe Base de connaissances
Découvrir plus d'offres spéciales
-
Service de messagerie courte (SMS) et service de courrier
50,000 email package starts as low as USD 1.99, 120 short messages start at only USD 1.00
