Magasins de données NoSQL contre hadoop

Les magasins de données NoSQL initialement souscrit à la notion “ Just Say No to SQL ” (pour paraphraser à partir d'une campagne de publicité anti-drogue dans les années 1980), et ils étaient une réaction aux limites perçues de bases de données relationnelles (SQL) sur la base. Il a pas que ces gens détestait SQL, mais ils étaient fatigués de forcer des chevilles carrées dans des trous ronds en résolvant les problèmes que bases de données relationnelles ne sont pas conçus pour.

Une base de données relationnelle est un outil puissant, mais pour certaines sortes de données (comme les paires clé-valeur, ou graphiques) et certains modèles d'utilisation (comme extrêmement grand stockage de l'échelle) une base de données relationnelle est tout simplement pas pratique. Et quand il vient au stockage à haut volume, base de données relationnelle peut être coûteux, tant en termes de coûts de licence de base de données et les coûts de matériel. (Bases de données relationnelles sont conçus pour fonctionner avec le matériel de classe entreprise.)

Donc, avec le mouvement NoSQL, les programmeurs créatifs développé des dizaines de solutions pour différents types de stockage et de traitement de données des problèmes épineux. Ces bases de données NoSQL fournissent généralement une extensibilité massive par voie de regroupement, et sont souvent conçus pour permettre un débit élevé et une faible latence.

Le nom NoSQL est quelque peu trompeur parce que beaucoup de bases de données qui correspondent à la catégorie faire avoir le soutien de SQL (plutôt que “ NoSQL ” soutien). Pensez à son nom à la place que “ Not Only SQL ”.

Les offrandes NoSQL disponibles aujourd'hui peuvent être décomposés en quatre catégories distinctes, en fonction de leur conception et le but:

• 
  
  
  
  

  Clé-valeur magasins: Cette offre fournit un moyen de stocker tout type de données sans avoir à utiliser un schéma. Ceci est en contraste aux bases de données relationnelles, où vous avez besoin pour définir le schéma (la structure de table) avant que des données est inséré. Depuis magasins clé-valeur ne nécessitent pas un schéma, vous avez une grande flexibilité pour stocker des données dans de nombreux formats.

  Dans un magasin clé-valeur, une rangée consiste simplement d'une clé (un identifiant) et une valeur, qui peut être quelque chose d'une valeur entière à une grande chaîne de données binaires. De nombreuses implémentations de magasins clé-valeur sont basées sur le papier Dynamo d'Amazon.

• Les magasins de la famille de la colonne: Ici vous avez des bases de données dans lequel les colonnes sont regroupées en familles de colonnes et stockés ensemble sur disque.

  Strictement parlant, beaucoup de ces bases de données ne sont pas axées sur la colonne, car ils sont basés sur le papier BigTable de Google, qui stocke les données comme une carte multidimensionnelle triés.

• Magasins de documents: Cette offre repose sur des collections de documents de même codés et formatés pour améliorer l'efficacité. Magasins de documents permettent documents individuels dans une collection d'inclure seulement un sous-ensemble de champs, de sorte que les données qui est nécessaire est stocké. Pour les ensembles de données éparses, où de nombreux champs ne sont pas souvent peuplées, ce qui peut se traduire par d'importantes économies d'espace.

  En revanche, les colonnes vides dans les tables de base de données relationnelles ne prennent de la place. Magasins de document permet également la flexibilité de schéma, parce que seuls les champs qui sont nécessaires sont stockés, et de nouveaux champs peuvent être ajoutés. Là encore, contrairement aux bases de données relationnelles, les structures de table sont définis à l'avance avant que les données sont stockées, et en changeant les colonnes est une tâche fastidieuse que les impacts de l'ensemble du jeu de données.

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

  Google, bien sûr, est partout dans la technologie graphique, et a inventé un moteur de traitement graphique appelé Prégel pour alimenter son algorithme de PageRank. (Et oui, il ya un livre blanc sur Prégel.) Dans la communauté Hadoop, il ya un projet Apache appelé Giraph (basé sur le papier Prégel), qui est un moteur de traitement graphique conçu pour traiter des graphiques stockés dans HDFS.

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