Stockages de données noSQL par rapport à Hadoop - dummies

Les banques de données NoSQL souscrites à la notion "Just Say No to SQL" (pour paraphraser campagne de publicité anti-drogue dans les années 1980), et ils étaient une réaction aux limitations perçues des bases de données relationnelles (basées sur SQL). Ce n'est pas que ces gens détestaient SQL, mais ils étaient fatigués de forcer des chevilles carrées dans des trous ronds en résolvant des problèmes pour lesquels les bases de données relationnelles n'étaient pas conçues.

Une base de données relationnelle est un outil puissant, mais pour certains types de données (comme les paires clé-valeur ou graphiques) et certains modèles d'utilisation (comme le stockage à très grande échelle), une base de données relationnelle n'est pas disponible. t pratique. Et quand il s'agit de stockage à haut volume, la base de données relationnelle peut être coûteuse, à la fois en termes de coûts de licence de base de données et de coûts matériels. (Les bases de données relationnelles sont conçues pour fonctionner avec du matériel de niveau entreprise.)

Ainsi, avec le mouvement NoSQL, les programmeurs créatifs ont développé des dizaines de solutions pour différents types de problèmes de stockage et de traitement des données épineuses. Ces bases de données NoSQL fournissent généralement une évolutivité massive au moyen de la mise en cluster et sont souvent conçues pour permettre un haut débit et une faible latence.

Le nom NoSQL est quelque peu trompeur car beaucoup de bases de données qui correspondent à la catégorie ont le support SQL (plutôt que le support "NoSQL"). Pensez à son nom à la place "Non seulement SQL. "

Les offres NoSQL disponibles aujourd'hui peuvent être réparties en quatre catégories distinctes, en fonction de leur conception et de leur destination:

• Stocks de valeur-clés: Cette offre permet de stocker n'importe quel type de données sans avoir à utiliser un schéma. Ceci est en contraste avec les bases de données relationnelles, où vous devez définir le schéma (la structure de la table) avant toute insertion de données. Étant donné que les magasins de valeurs-clés ne nécessitent pas de schéma, vous disposez d'une grande flexibilité pour stocker des données dans de nombreux formats.

  Dans une banque de valeurs-clés, une ligne se compose simplement d'une clé (un identificateur) et d'une valeur, qui peut aller d'une valeur entière à une grande chaîne de données binaires. De nombreuses implémentations de magasins de valeurs-clés sont basées sur le papier Dynamo d'Amazon.

• Magasins de familles de colonnes: Vous trouverez ici des bases de données dans lesquelles les colonnes sont regroupées en familles de colonnes et stockées ensemble sur le disque.

  Strictement parlant, nombre de ces bases de données ne sont pas axées sur les colonnes, car elles sont basées sur l'article BigTable de Google, qui stocke les données sous forme de carte triée multidimensionnelle.

• Magasins de documents: Cette offre repose sur des collections de documents de même format et encodés pour améliorer l'efficacité.Les magasins de documents permettent à des documents individuels d'une collection d'inclure uniquement un sous-ensemble de champs, de sorte que seules les données nécessaires sont stockées. Pour les ensembles de données clairsemés, où de nombreux champs ne sont souvent pas remplis, cela peut se traduire par des économies d'espace significatives.

  En revanche, les colonnes vides dans les tables de base de données relationnelles occupent de l'espace. Les magasins de documents permettent également la flexibilité du schéma, car seuls les champs nécessaires sont stockés et de nouveaux champs peuvent être ajoutés. Une fois de plus, contrairement aux bases de données relationnelles, les structures de table sont définies avant que les données ne soient stockées et la modification des colonnes est une tâche fastidieuse qui affecte l'intégralité de l'ensemble de données.

• Bases de graphe: Ici vous avez des bases de données qui stockent des structures de graphe - des représentations qui montrent des collections d'entités (sommets ou nœuds) et leurs relations (arêtes) entre elles. Ces structures permettent aux bases de données graphiques d'être extrêmement bien adaptées au stockage de structures complexes, comme les relations de liaison entre toutes les pages Web connues. (Par exemple, les pages Web individuelles sont des nœuds, et les liens qui les relient sont des liens d'une page à l'autre.)

  Google, bien sûr, utilise la technologie graphique et a inventé un moteur de traitement graphique appelé Pregel. algorithme. (Et oui, il y a un livre blanc sur Pregel.) Dans la communauté Hadoop, il y a un projet Apache appelé Giraph (basé sur le papier Pregel), un moteur de traitement graphique conçu pour traiter les graphiques stockés dans HDFS.

Les options de stockage et de traitement des données disponibles dans Hadoop sont dans de nombreux cas des implémentations des catégories NoSQL répertoriées ici. Cela vous aidera à mieux évaluer les solutions qui s'offrent à vous et à voir comment Hadoop peut compléter les entrepôts de données traditionnels.