Bigtable de Google contre une base de données relationnelle
Doublons
Je ne connais pas grand-chose à la Bigtable de Google, mais je me demande quelle est la différence entre la Bigtable de Google et les bases de données relationnelles comme MySQL. Quelles sont les limites des deux?
Bigtable est l'invention de Google pour gérer les quantités massives d'informations que la société traite régulièrement. Un ensemble de données Bigtable peut atteindre une taille immense (plusieurs pétaoctets) avec un stockage réparti sur un grand nombre de serveurs. Les systèmes utilisant Bigtable incluent des projets tels que l'index Web de Google et Google Earth.
Selon livre blanc de Google sur le sujet:
Une Bigtable est une carte triée multidimensionnelle répartie, persistante et clairsemée. La carte est indexée par une clé de ligne, une clé de colonne et un horodatage; chaque valeur de la carte est un tableau d'octets non interprété.
Les mécanismes internes de Bigtable par rapport à, disons, MySQL sont si différents qu'ils rendent la comparaison difficile, et les objectifs visés ne se chevauchent pas beaucoup non plus. Mais vous pouvez penser à Bigtable un peu comme une base de données à table unique. Imaginez, par exemple, les difficultés que vous rencontriez si vous tentiez d'implémenter l'intégralité du système de recherche Web de Google avec une base de données MySQL - Bigtable a été conçu pour résoudre ces problèmes.
Les ensembles de données Bigtable peuvent être interrogés à partir de services comme AppEngine en utilisant un langage appelé GQL ("gee-kwal") qui est basé sur un sous-ensemble de SQL. Manifestement absent de GQL est toute sorte de commande JOIN. En raison de la nature distribuée d'une base de données Bigtable, effectuer une jointure entre deux tables serait terriblement inefficace. Au lieu de cela, le programmeur doit implémenter une telle logique dans son application, ou concevoir son application de manière à ne pas en avoir besoin.
Google BigTable et d'autres projets similaires (ex: CouchDB , HBase ) sont des systèmes de base de données qui sont orientés de sorte que les données sont principalement dénormalisées (c'est-à-dire dupliquées et groupés).
Les principaux avantages sont les suivants: - Les opérations de jointure sont moins coûteuses en raison de la dénormalisation - La réplication/distribution des données est moins coûteuse en raison de l'indépendance des données (c'est-à-dire que si vous souhaitez distribuer des données sur deux nœuds, vous n'aurez probablement pas le problème de ayant une entité dans un nœud et une autre entité associée dans un autre nœud car des données similaires sont regroupées)
Ce type de systèmes est indiqué pour les applications qui doivent atteindre une échelle optimale (c'est-à-dire que vous ajoutez plus de nœuds au système et que les performances augmentent proportionnellement). Dans un SGBDR comme MySQL ou Oracle, lorsque vous commencez à ajouter d'autres nœuds si vous joignez deux tables qui ne se trouvent pas dans le même nœud, le coût de la jointure est plus élevé. Cela devient important lorsque vous traitez avec des volumes élevés.
Les SGBDR sont sympas du fait de la richesse du modèle de stockage (tables, jointures, fks). Les bases de données distribuées sont agréables en raison de la facilité de mise à l'échelle.