Vidéo: BDX I/O 2016 : Postgresql - la nouvelle base orientée document 2025
Les banques de colonnes dans NoSQL sont similaires à première vue aux SGBD relationnels traditionnels. Les concepts de lignes et de colonnes sont toujours là. Vous définissez également les familles de colonnes avant de charger les données dans la base de données, ce qui signifie que la structure des données doit être connue à l'avance.
Cependant, les magasins de colonnes organisent les données différemment des bases de données relationnelles. Au lieu de stocker des données dans une rangée pour un accès rapide, les données sont organisées pour des opérations de colonnes rapides. Cette vue centrée sur les colonnes rend les colonnes de stockage idéales pour exécuter des fonctions d'agrégat ou pour rechercher des enregistrements correspondant à plusieurs colonnes.
Les fonctions agrégées sont des combinaisons de données ou des fonctions d'analyse. Ils peuvent être aussi simples que de compter le nombre de résultats, de les additionner ou de calculer leur moyenne. Cependant, ils peuvent être plus complexes, par exemple, en renvoyant une valeur complexe décrivant une plage de temps globale.
Les magasins de colonnes sont parfois appelés Big Tables ou Big Table, reflétant leur ancêtre commun, Google Bigtable.
La principale différence entre les magasins de colonnes et un SGBDR classique est que, dans un magasin de colonnes, chaque enregistrement (think ligne dans un SGBDR) ne nécessite pas une seule valeur par colonne. Au lieu de cela, il est possible de modéliser les familles de colonnes. Un enregistrement unique peut consister en un champ ID, une famille de colonnes pour les informations "client" et une autre famille de colonnes pour les informations "article de commande".
Chacune de ces familles de colonnes comprend plusieurs champs. Une de ces familles de colonnes peut avoir plusieurs "lignes" dans son propre droit. Les informations de l'article de commande, par exemple, comportent plusieurs lignes - une pour chaque élément de campagne. Ces lignes contiendront des données telles que l'ID de l'article, la quantité et le prix unitaire.
Un avantage clé d'un stockage de colonnes sur un SGBDR est que les magasins de colonnes n'ont pas besoin de champs pour toujours être présents et ne nécessitent pas de valeur nulle de remplissage vide comme le fait un SGBDR. Cette fonctionnalité empêche le problème de données éparses, en préservant l'espace disque. Un exemple d'ensemble de données variable et fragmenté est présenté ici.
L'avantage des magasins de colonnes réside dans le fait que vous pouvez récupérer toutes les informations associées à l'aide d'un ID d'enregistrement unique, plutôt que d'utiliser la jointure SQL (Structured Query Language) complexe comme dans un SGBDR. Cela nécessite un peu de modélisation et d'analyse des données.
Dans l'exemple illustré, vous pouvez récupérer toutes les informations de commande en sélectionnant une seule ligne de magasin de colonnes, ce qui signifie que le développeur n'a pas besoin de connaître la syntaxe de jointure complexe exacte d'une requête dans un magasin de colonnes. doivent utiliser des jointures SQL complexes dans un SGBDR.
Ainsi, pour les structures de données relationnelles complexes et variables, une mémoire de colonnes peut être plus efficace en stockage et moins sujet aux erreurs de développement que ses ancêtres de SGBDR.
Notez que dans la famille de colonnes élément , l'ID de chaque élément est représenté dans la clé et la valeur est la quantité commandée. Cette configuration permet une recherche rapide de toutes les commandes contenant cet ID d'article.
Si vous connaissez les champs de données impliqués au premier plan et que vous devez rapidement récupérer les données associées en un seul enregistrement, considérez un magasin de colonnes.
