Il utilisera Google quand il veut découvrir ce que le débordement de pile de base de données utilise
flybywire
340
Hé, ne le battez pas, je me suis retrouvé ici à partir d'une recherche google lol.
Shawn Mclean
141
Est-il encore plus ironique que le premier résultat de la recherche de la "base de données de Google" sur Google soit maintenant cette page, sur laquelle le premier commentaire est d'utiliser Google?
Patrick Szalapski
89
@Patrick Szalapski ressemble à une situation de débordement de pile.
Bigtable est un système de stockage distribué (construit par Google) pour gérer les données structurées qui est conçu pour évoluer vers une très grande taille: des pétaoctets de données sur des milliers de serveurs de base.
De nombreux projets de Google stockent des données dans Bigtable, notamment l'indexation Web, Google Earth et Google Finance. Ces applications imposent des exigences très différentes à Bigtable, à la fois en termes de taille des données (des URL aux pages Web en passant par l'imagerie satellite) et aux exigences de latence (du traitement en bloc backend au service de données en temps réel).
Malgré ces demandes variées, Bigtable a réussi à fournir une solution flexible et hautes performances pour tous ces produits Google.
Certaines fonctionnalités
SGBD rapide et à très grande échelle
une carte triée multidimensionnelle distribuée et clairsemée, partageant les caractéristiques des bases de données orientées lignes et colonnes.
conçu pour évoluer dans la gamme de pétaoctets
il fonctionne sur des centaines ou des milliers de machines
il est facile d'ajouter plus de machines au système et de commencer automatiquement à tirer parti de ces ressources sans aucune reconfiguration
chaque table a plusieurs dimensions (dont l'une est un champ pour le temps, permettant le contrôle de version)
les tables sont optimisées pour GFS (Google File System) en étant divisées en plusieurs tablettes - des segments de la table divisés le long d'une ligne choisie de telle sorte que la tablette aura une taille de ~ 200 mégaoctets.
Architecture
BigTable n'est pas une base de données relationnelle. Il ne prend pas en charge les jointures ni les requêtes riches de type SQL. Chaque table est une carte clairsemée multidimensionnelle. Les tableaux sont constitués de lignes et de colonnes, et chaque cellule a un horodatage. Il peut y avoir plusieurs versions d'une cellule avec des horodatages différents. L'horodatage permet des opérations telles que «sélectionner des versions de cette page Web» ou «supprimer des cellules antérieures à une date / heure spécifique».
Afin de gérer les énormes tables, Bigtable divise les tables aux limites des lignes et les enregistre sous forme de tablettes. Une tablette fait environ 200 Mo et chaque machine enregistre environ 100 tablettes. Cette configuration permet aux tablettes d'une même table d'être réparties sur plusieurs serveurs. Il permet également un équilibrage de charge à grain fin. Si une table reçoit de nombreuses requêtes, elle peut supprimer d'autres tablettes ou déplacer la table occupée vers une autre machine qui n'est pas si occupée. De plus, si une machine tombe en panne, une tablette peut être répartie sur de nombreux autres serveurs afin que l'impact sur les performances d'une machine donnée soit minime.
Les tables sont stockées sous forme de SSTables immuables et d'une queue de journaux (un journal par machine). Lorsqu'une machine manque de mémoire système, elle compresse certaines tablettes à l'aide des techniques de compression propriétaires de Google (BMDiff et Zippy). Les compactages mineurs n'impliquent que quelques tablettes, tandis que les compactages majeurs impliquent l'ensemble du système de table et récupèrent de l'espace sur le disque dur.
Les emplacements des comprimés Bigtable sont stockés dans des cellules. La recherche d'une tablette particulière est gérée par un système à trois niveaux. Les clients obtiennent un point sur une table META0, dont il n'y en a qu'un. Le tableau META0 conserve la trace de nombreux comprimés META1 qui contiennent les emplacements des comprimés recherchés. META0 et META1 font un usage intensif de la prélecture et de la mise en cache pour minimiser les goulots d'étranglement dans le système.
la mise en oeuvre
BigTable est construit sur Google File System (GFS), qui est utilisé comme magasin de sauvegarde pour les fichiers journaux et de données. GFS fournit un stockage fiable pour SSTables, un format de fichier propriétaire de Google utilisé pour conserver les données de la table.
Chubby est un autre service dont BigTable fait un usage intensif : un service de verrouillage distribué hautement disponible et fiable. Chubby permet aux clients de prendre un verrou, éventuellement en l'associant à certaines métadonnées, qu'il peut renouveler en renvoyant des messages keep alive à Chubby. Les verrous sont stockés dans une structure de dénomination hiérarchique de type système de fichiers.
Le système Bigtable présente trois types de serveurs principaux :
Serveurs maîtres: affectez des tablettes aux serveurs de tablettes, gardez une trace de l'emplacement des tablettes et redistribuez les tâches selon les besoins.
Serveurs de tablettes: gérez les demandes de lecture / écriture pour les tablettes et les tablettes fractionnées lorsqu'elles dépassent les limites de taille (généralement 100 à 200 Mo). Si un serveur de tablettes tombe en panne, alors 100 serveurs de tablettes ramassent chaque nouvelle tablette et le système se rétablit.
Serveurs de verrouillage: instances du service de verrouillage distribué Chubby. De nombreuses actions dans BigTable nécessitent l'acquisition de verrous, y compris l'ouverture de tablettes pour l'écriture, garantissant qu'il n'y a pas plus d'un maître actif à la fois et la vérification du contrôle d'accès.
Exemple tiré du document de recherche de Google:
Tranche d'un exemple de tableau qui stocke des pages Web. Le nom de la ligne est une
URL inversée . La famille de colonnes de contenu contient le contenu de la page et la famille de colonnes d'ancrage contient le
texte des ancres faisant référence à la page. La page d'accueil de CNN est référencée à la fois par les pages d'accueil Sports Illustrated et MY-look, de sorte que la ligne contient des colonnes nommées
anchor:cnnsi.comet
anchor:my.look.ca. Chaque cellule d'ancrage a une version ; la colonne de contenu a trois versions , à horodatages
t3, t5et t6.
API
Les opérations typiques de BigTable sont la création et la suppression de tables et de familles de colonnes, l'écriture de données et la suppression de colonnes d'une ligne. BigTable fournit ces fonctions aux développeurs d'applications dans une API. Les transactions sont prises en charge au niveau de la ligne, mais pas sur plusieurs clés de ligne.
Est-ce que quelqu'un sait s'il a été construit à partir de zéro ou basé sur un produit? J'ai entendu quelque part, je ne me souviens pas où, que Google a utilisé Oracle une fois, mais ils l'ont abandonné car ils ont besoin de modifications qu'Oracle ne fera pas ni ne leur permettra de faire. Je vais essayer d'obtenir le lien.
OscarRyz
5
C'est à partir de zéro, comme la plupart de leurs autres compétences de base (serveur Web, GFS, ...).
Matt J
5
Je cherchais des informations sur les algorithmes de compression (BMDiff et Zippy) et j'ai découvert que maintenant Zippy s'appelle Snappy et qu'il est publié dans Google Code: code.google.com/p/snappy
helios
7
Maintenant, ils utilisent Spanner, le successeur de BigTable
deltonio2
Ainsi, il ressemble à la base de données nosql telle que Mongodb ou Marklogic.
stuckedoverflow
52
C'est quelque chose qu'ils ont eux-mêmes construit - cela s'appelle Bigtable.
Spanner est le système de gestion de bases de données relationnelles (RDBMS) de Google distribué mondialement, le successeur de BigTable . Google affirme qu'il ne s'agit pas d'un système relationnel pur car chaque table doit avoir une clé primaire.
Spanner est la base de données évolutive, multi-version, distribuée à l'échelle mondiale et répliquée de manière synchrone de Google. Il s'agit du premier système à distribuer des données à l'échelle mondiale et à prendre en charge les transactions distribuées cohérentes avec l'extérieur. Cet article décrit comment Spanner est structuré, son ensemble de fonctionnalités, la logique qui sous-tend diverses décisions de conception, et une nouvelle API temporelle qui expose l'incertitude d'horloge. Cette API et son implémentation sont essentielles pour prendre en charge la cohérence externe et une variété de fonctionnalités puissantes: lectures non bloquantes dans le passé, transactions en lecture seule sans verrouillage et modifications du schéma atomique, sur l'ensemble de Spanner.
Une autre base de données inventée par Google est Megastore . Voici le résumé:
Megastore est un système de stockage développé pour répondre aux exigences des services interactifs en ligne d'aujourd'hui. Megastore allie l'évolutivité d'une banque de données NoSQL à la commodité d'un SGBDR traditionnel d'une manière nouvelle, et offre à la fois de solides garanties de cohérence et une haute disponibilité. Nous fournissons une sémantique ACID entièrement sérialisable dans des partitions de données à granularité fine. Ce partitionnement nous permet de répliquer de manière synchrone chaque écriture sur un réseau étendu avec une latence raisonnable et de prendre en charge un basculement transparent entre les centres de données. Cet article décrit la sémantique et l'algorithme de réplication de Megastore. Il décrit également notre expérience de la prise en charge d'une large gamme de services de production Google construits avec Megastore.
C'est dommage que Spanner soit un projet open source. Selon la description, j'aimerais aussi l'utiliser pour mes projets.
Mikko Rantalainen
2
@MikkoRantalainen Vous voudrez peut-être consulter l'écosystème Apache Hadoop ou CockroachDB (bien que Cockroach soit alpha)
dualed
Merci, CockroachDB a l'air intéressant. Je dois le tester pour voir quel type de performance il a. Les fonctionnalités ressemblent à ce que j'aimerais avoir.
Mikko Rantalainen
1
Spanner est disponible pour tout le monde à utiliser sur Google Cloud depuis 2017: cloud.google.com/spanner
Miscreant
19
Comme d'autres l'ont mentionné, Google utilise une solution locale appelée BigTable et ils ont publié quelques articles la décrivant dans le monde réel.
Les gens d'Apache ont une implémentation des idées présentées dans ces articles appelées HBase . HBase fait partie du plus grand projet Hadoop qui, selon leur site, "est une plate-forme logicielle qui permet d'écrire et d'exécuter facilement des applications qui traitent de grandes quantités de données". Certains des repères sont assez impressionnants. Leur site est à http://hadoop.apache.org .
Bien que Google utilise BigTable pour toutes leurs applications principales, ils utilisent également MySQL pour d'autres applications (peut-être mineures).
Et c'est peut-être aussi pratique de savoir que BigTable n'est pas une base de données relationnelle (comme MySQL) mais une énorme table de hachage (distribuée) qui a des caractéristiques très différentes. Vous pouvez jouer avec (une version limitée) de BigTable vous-même sur la plate-forme Google AppEngine .
À côté de Hadoop mentionné ci-dessus, il existe de nombreuses autres implémentations qui tentent de résoudre les mêmes problèmes que BigTable (évolutivité, disponibilité). Hier, j'ai vu un joli billet de blog répertoriant la plupart d'entre eux ici .
@utilisateur cloud.google.com/sql/docs ? Si les développeurs peuvent utiliser MySQL, Google doit au moins avoir créé un "traducteur de base de données" avec MySQL et Bigtable.
1
Les services Google ont une architecture de persistance polyglotte. BigTable est exploité par la plupart de ses services comme YouTube, Google Search, Google Analytics, etc. Le service de recherche a initialement utilisé MapReduce pour son infrastructure d'indexation, mais est ensuite passé à BigTable lors de la sortie de la caféine.
La banque de données Google Cloud compte plus de 100 applications en production chez Google, à la fois face aux utilisateurs internes et externes. Des applications telles que Gmail, Picasa, Google Agenda, Android Market et AppEngine utilisent Cloud Datastore & Megastore.
Google Trends utilise MillWheel pour le traitement des flux. Google Ads a initialement utilisé MySQL, puis migré vers F1 DB - une base de données relationnelle distribuée écrite personnalisée. Youtube utilise MySQL avec Vitess. Google stocke des exaoctets de données sur les serveurs de base à l'aide du système de fichiers Google.
Réponses:
Grande table
Un système de stockage distribué pour les données structurées
Certaines fonctionnalités
Architecture
BigTable n'est pas une base de données relationnelle. Il ne prend pas en charge les jointures ni les requêtes riches de type SQL. Chaque table est une carte clairsemée multidimensionnelle. Les tableaux sont constitués de lignes et de colonnes, et chaque cellule a un horodatage. Il peut y avoir plusieurs versions d'une cellule avec des horodatages différents. L'horodatage permet des opérations telles que «sélectionner des versions de cette page Web» ou «supprimer des cellules antérieures à une date / heure spécifique».
Afin de gérer les énormes tables, Bigtable divise les tables aux limites des lignes et les enregistre sous forme de tablettes. Une tablette fait environ 200 Mo et chaque machine enregistre environ 100 tablettes. Cette configuration permet aux tablettes d'une même table d'être réparties sur plusieurs serveurs. Il permet également un équilibrage de charge à grain fin. Si une table reçoit de nombreuses requêtes, elle peut supprimer d'autres tablettes ou déplacer la table occupée vers une autre machine qui n'est pas si occupée. De plus, si une machine tombe en panne, une tablette peut être répartie sur de nombreux autres serveurs afin que l'impact sur les performances d'une machine donnée soit minime.
Les tables sont stockées sous forme de SSTables immuables et d'une queue de journaux (un journal par machine). Lorsqu'une machine manque de mémoire système, elle compresse certaines tablettes à l'aide des techniques de compression propriétaires de Google (BMDiff et Zippy). Les compactages mineurs n'impliquent que quelques tablettes, tandis que les compactages majeurs impliquent l'ensemble du système de table et récupèrent de l'espace sur le disque dur.
Les emplacements des comprimés Bigtable sont stockés dans des cellules. La recherche d'une tablette particulière est gérée par un système à trois niveaux. Les clients obtiennent un point sur une table META0, dont il n'y en a qu'un. Le tableau META0 conserve la trace de nombreux comprimés META1 qui contiennent les emplacements des comprimés recherchés. META0 et META1 font un usage intensif de la prélecture et de la mise en cache pour minimiser les goulots d'étranglement dans le système.
la mise en oeuvre
BigTable est construit sur Google File System (GFS), qui est utilisé comme magasin de sauvegarde pour les fichiers journaux et de données. GFS fournit un stockage fiable pour SSTables, un format de fichier propriétaire de Google utilisé pour conserver les données de la table.
Chubby est un autre service dont BigTable fait un usage intensif : un service de verrouillage distribué hautement disponible et fiable. Chubby permet aux clients de prendre un verrou, éventuellement en l'associant à certaines métadonnées, qu'il peut renouveler en renvoyant des messages keep alive à Chubby. Les verrous sont stockés dans une structure de dénomination hiérarchique de type système de fichiers.
Le système Bigtable présente trois types de serveurs principaux :
Exemple tiré du document de recherche de Google:
API
Les opérations typiques de BigTable sont la création et la suppression de tables et de familles de colonnes, l'écriture de données et la suppression de colonnes d'une ligne. BigTable fournit ces fonctions aux développeurs d'applications dans une API. Les transactions sont prises en charge au niveau de la ligne, mais pas sur plusieurs clés de ligne.
Voici le lien vers le PDF du document de recherche .
Et ici, vous pouvez trouver une vidéo montrant Jeff Dean de Google dans une conférence à l'Université de Washington , discutant du système de stockage de contenu Bigtable utilisé dans le backend de Google.
la source
C'est quelque chose qu'ils ont eux-mêmes construit - cela s'appelle Bigtable.
http://en.wikipedia.org/wiki/BigTable
Il y a un article de Google sur la base de données:
http://research.google.com/archive/bigtable.html
la source
Spanner est le système de gestion de bases de données relationnelles (RDBMS) de Google distribué mondialement, le successeur de BigTable . Google affirme qu'il ne s'agit pas d'un système relationnel pur car chaque table doit avoir une clé primaire.
Voici le lien du papier.
Une autre base de données inventée par Google est Megastore . Voici le résumé:
la source
Comme d'autres l'ont mentionné, Google utilise une solution locale appelée BigTable et ils ont publié quelques articles la décrivant dans le monde réel.
Les gens d'Apache ont une implémentation des idées présentées dans ces articles appelées HBase . HBase fait partie du plus grand projet Hadoop qui, selon leur site, "est une plate-forme logicielle qui permet d'écrire et d'exécuter facilement des applications qui traitent de grandes quantités de données". Certains des repères sont assez impressionnants. Leur site est à http://hadoop.apache.org .
la source
Bien que Google utilise BigTable pour toutes leurs applications principales, ils utilisent également MySQL pour d'autres applications (peut-être mineures).
la source
Et c'est peut-être aussi pratique de savoir que BigTable n'est pas une base de données relationnelle (comme MySQL) mais une énorme table de hachage (distribuée) qui a des caractéristiques très différentes. Vous pouvez jouer avec (une version limitée) de BigTable vous-même sur la plate-forme Google AppEngine .
À côté de Hadoop mentionné ci-dessus, il existe de nombreuses autres implémentations qui tentent de résoudre les mêmes problèmes que BigTable (évolutivité, disponibilité). Hier, j'ai vu un joli billet de blog répertoriant la plupart d'entre eux ici .
la source
Google utilise principalement Bigtable.
Bigtable est un système de stockage distribué pour la gestion de données structurées conçu pour évoluer vers une très grande taille.
Pour plus d'informations, téléchargez le document ici .
Google utilise également des bases de données Oracle et MySQL pour certaines de leurs applications.
Toute autre information que vous pouvez ajouter est très appréciée.
la source
Google also use Oracle- référence nécessaire.Les services Google ont une architecture de persistance polyglotte. BigTable est exploité par la plupart de ses services comme YouTube, Google Search, Google Analytics, etc. Le service de recherche a initialement utilisé MapReduce pour son infrastructure d'indexation, mais est ensuite passé à BigTable lors de la sortie de la caféine.
La banque de données Google Cloud compte plus de 100 applications en production chez Google, à la fois face aux utilisateurs internes et externes. Des applications telles que Gmail, Picasa, Google Agenda, Android Market et AppEngine utilisent Cloud Datastore & Megastore.
Google Trends utilise MillWheel pour le traitement des flux. Google Ads a initialement utilisé MySQL, puis migré vers F1 DB - une base de données relationnelle distribuée écrite personnalisée. Youtube utilise MySQL avec Vitess. Google stocke des exaoctets de données sur les serveurs de base à l'aide du système de fichiers Google.
Source: Bases de données Google: comment les services Google stockent-ils les données à l'échelle pétaoctet-exaoctet?
Base de données YouTube - Comment stocke-t-il autant de vidéos sans manquer d'espace de stockage?
la source