Quale database utilizza Google?


370

È Oracle o MySQL o qualcosa che si sono costruiti da soli?


187
Utilizzerà Google quando vorrà scoprire quale overflow dello stack del database utilizza
flybywire,

340
Ehi, non picchiarlo, sono finito qui da una ricerca su Google lol.
Shawn Mclean,

141
È inoltre ironico che il risultato migliore per la ricerca del "Database di Google" su Google sia ora questa pagina, in cui il primo commento è utilizzare Google?
Patrick Szalapski,

89
@Patrick Szalapski sembra una situazione di overflow dello stack.
Thomas,

5
Prima di cercare mi chiedevo se Google mi avrebbe dato la risposta giusta ma eccoci qui: P
Abdul Saboor,

Risposte:


581

Tavolo grande

Un sistema di archiviazione distribuito per dati strutturati

Bigtable è un sistema di archiviazione distribuito (creato da Google) per la gestione di dati strutturati progettato per adattarsi a dimensioni molto grandi: petabyte di dati su migliaia di server di prodotti.

Molti progetti presso Google archiviano i dati in Bigtable, tra cui l'indicizzazione web, Google Earth e Google Finance. Queste applicazioni impongono requisiti molto diversi su Bigtable, sia in termini di dimensioni dei dati (dagli URL alle pagine Web alle immagini satellitari) sia in termini di latenza (dall'elaborazione bulk back-end alla pubblicazione di dati in tempo reale).

Nonostante queste diverse esigenze, Bigtable ha fornito con successo una soluzione flessibile e ad alte prestazioni per tutti questi prodotti Google.

Alcune funzionalità

  • DBMS veloce ed estremamente ampio
  • una mappa ordinata multidimensionale sparsa e distribuita, che condivide le caratteristiche dei database orientati alle righe e alle colonne.
  • progettato per adattarsi alla gamma dei petabyte
  • funziona su centinaia o migliaia di macchine
  • è facile aggiungere più macchine al sistema e iniziare automaticamente a sfruttare queste risorse senza alcuna riconfigurazione
  • ogni tabella ha più dimensioni (una delle quali è un campo per il tempo, che consente il controllo delle versioni)
  • le tabelle sono ottimizzate per GFS (Google File System) essendo suddivise in più tablet - segmenti della tabella suddivisi lungo una riga scelta in modo tale che il tablet abbia una dimensione di ~ 200 megabyte.

Architettura

BigTable non è un database relazionale. Non supporta join né supporta query simili a SQL. Ogni tabella è una mappa sparsa multidimensionale. Le tabelle sono costituite da righe e colonne e ogni cella ha un timestamp. Possono esistere più versioni di una cella con diversi timestamp. Il timestamp consente operazioni come "seleziona 'n' versioni di questa pagina Web" o "elimina celle che sono più vecchie di una data / ora specifica".

Per gestire le enormi tabelle, Bigtable divide le tabelle ai limiti delle righe e le salva come compresse. Un tablet è di circa 200 MB e ogni macchina risparmia circa 100 tablet. Questa configurazione consente ai tablet di una singola tabella di essere distribuiti su molti server. Consente inoltre un bilanciamento del carico a grana fine. Se una tabella riceve molte query, può eliminare altri tablet o spostare la tabella occupata su un altro computer che non è così occupato. Inoltre, se una macchina si arresta, un tablet può essere distribuito su molti altri server in modo tale che l'impatto sulle prestazioni di una determinata macchina sia minimo.

Le tabelle sono archiviate come SSTable immutabili e una coda di registri (un registro per macchina). Quando una macchina esaurisce la memoria di sistema, comprime alcuni tablet utilizzando tecniche di compressione proprietarie di Google (BMDiff e Zippy). Le compattazioni minori coinvolgono solo pochi tablet, mentre le compattazioni principali coinvolgono l'intero sistema di tabelle e recuperano spazio sul disco rigido.

Le posizioni dei tablet Bigtable sono memorizzate nelle celle. La ricerca di un determinato tablet è gestita da un sistema a tre livelli. I client ottengono un punto su una tabella META0, di cui ce n'è solo una. La tabella META0 tiene traccia di molti tablet META1 che contengono le posizioni dei tablet da cercare. Sia META0 che META1 fanno un uso pesante del prelievo e della memorizzazione nella cache per ridurre al minimo i colli di bottiglia nel sistema.

Implementazione

BigTable è basato su Google File System (GFS), che viene utilizzato come archivio di backup per file di registro e dati. GFS offre archiviazione affidabile per SSTables, un formato di file proprietario di Google utilizzato per conservare i dati della tabella.

Un altro servizio utilizzato da BigTable è Chubby , un servizio di blocco distribuito affidabile e altamente disponibile. Chubby consente ai client di bloccare, eventualmente associandolo ad alcuni metadati, che può essere rinnovato inviando messaggi di keep alive a Chubby. I blocchi sono memorizzati in una struttura di denominazione gerarchica simile a un filesystem.

Esistono tre tipi principali di server di interesse nel sistema Bigtable:

  1. Server master: assegna tablet ai server tablet, tiene traccia della posizione dei tablet e ridistribuisce le attività secondo necessità.
  2. Server tablet: gestiscono le richieste di lettura / scrittura per tablet e tablet divisi quando superano i limiti di dimensione (in genere 100 MB - 200 MB). Se un server tablet si guasta, quindi un server tablet 100 ogni pickup 1 nuovo tablet e il sistema ripristina.
  3. Server di blocco: istanze del servizio di blocco distribuito Chubby. Molte azioni all'interno di BigTable richiedono l'acquisizione di blocchi tra cui l'apertura di tablet per la scrittura, la garanzia che non ci sia più di un Master attivo alla volta e il controllo del controllo degli accessi.

Esempio dal documento di ricerca di Google:

testo alternativo

Una porzione di una tabella di esempio che memorizza le pagine Web. Il nome della riga è un URL invertito . La famiglia di colonne di contenuti contiene i contenuti della pagina e la famiglia di colonne di ancoraggio contiene il testo di eventuali ancore che fanno riferimento alla pagina. La home page della CNN fa riferimento sia alle home page di Sports Illustrated sia a quelle MY-look, quindi la riga contiene colonne denominate anchor:cnnsi.come anchor:my.look.ca. Ogni cella di ancoraggio ha una versione ; la colonna contenuti ha tre versioni , a timestamp t3, t5e t6.

API

Le operazioni tipiche su BigTable sono la creazione e l'eliminazione di tabelle e famiglie di colonne, la scrittura di dati e l'eliminazione di colonne da una riga. BigTable fornisce queste funzioni agli sviluppatori di applicazioni in un'API. Le transazioni sono supportate a livello di riga, ma non attraverso più chiavi di riga.


Ecco il link al PDF del documento di ricerca .

E qui puoi trovare un video che mostra Jeff Dean di Google in una conferenza all'Università di Washington , che discute del sistema di archiviazione dei contenuti Bigtable utilizzato nel back-end di Google.


4
Qualcuno sa se è stato costruito da zero o basato su un prodotto? Ho sentito da qualche parte che non ricordo dove, quel google ha usato Oracle una volta, ma lo lasciano cadere perché hanno bisogno di alcune modifiche che Oracle non farà né consente loro di fare. Proverò a ottenere il link.
OscarRyz,

5
È da zero, come la maggior parte delle altre competenze chiave (web server, GFS, ...).
Matt J

5
Stavo cercando informazioni sugli algoritmi di compressione (BMDiff e Zippy) e ho scoperto che ora Zippy si chiama Snappy ed è pubblicato in Google Code: code.google.com/p/snappy
helios

7
Ora usano Spanner, il successore di BigTable
deltonio2,

Quindi, sembra simile al database nosql come Mongodb o Marklogic.
stuckedoverflow


32

Spanner è il sistema di gestione di database relazionali distribuiti a livello globale (RDBMS), il successore di BigTable . Google afferma che non è un sistema relazionale puro perché ogni tabella deve avere una chiave primaria.

Ecco il link del documento.

Spanner è il database scalabile, multi-versione, distribuito a livello globale e replicato in modo sincrono di Google. È il primo sistema a distribuire dati su scala globale e supportare transazioni distribuite coerenti con l'esterno. Questo documento descrive come è strutturato Spanner, il suo set di funzionalità, la logica alla base delle varie decisioni di progettazione e una nuova API temporale che espone l'incertezza dell'orologio. Questa API e la sua implementazione sono fondamentali per supportare la coerenza esterna e una varietà di potenti funzionalità: letture senza blocco in passato, transazioni di sola lettura senza blocco e modifiche atomiche dello schema, su tutto Spanner.

Un altro database inventato da Google è Megastore . Ecco l'abstract:

Megastore è un sistema di archiviazione sviluppato per soddisfare i requisiti dei servizi online interattivi di oggi. Megastore unisce la scalabilità di un datastore NoSQL con la praticità di un RDBMS tradizionale in un modo nuovo e offre sia forti garanzie di coerenza che elevata disponibilità. Forniamo semantica ACID completamente serializzabile all'interno di partizioni di dati a grana fine. Questo partizionamento ci consente di replicare in modo sincrono ogni scrittura su una vasta rete con ragionevole latenza e supportare il failover continuo tra i datacenter. Questo documento descrive l'algoritmo di semantica e replica di Megastore. Descrive anche la nostra esperienza a supporto di una vasta gamma di servizi di produzione di Google creati con Megastore.


È un peccato che Spanner sia un progetto chiuso. Secondo la descrizione, mi piacerebbe usarlo anche per i miei progetti.
Mikko Rantalainen,

2
@MikkoRantalainen Potresti voler dare un'occhiata all'ecosistema Apache Hadoop o CockroachDB (anche se Cockroach è alfa)
duplicato il

Grazie, CockroachDB sembra interessante. Devo testarlo per vedere che tipo di prestazioni ha. Le caratteristiche sembrano le cose che vorrei avere.
Mikko Rantalainen,

1
Spanner è disponibile per tutti da utilizzare su Google Cloud dal 2017: cloud.google.com/spanner
Miscreant

19

Come altri hanno già detto, Google utilizza una soluzione fatta in casa chiamata BigTable e hanno pubblicato alcuni articoli che la descrivono nel mondo reale.

La gente di Apache ha implementato le idee presentate in questi articoli chiamati HBase . HBase fa parte del più grande progetto Hadoop che secondo il loro sito "è una piattaforma software che consente di scrivere ed eseguire facilmente applicazioni che elaborano grandi quantità di dati". Alcuni benchmark sono piuttosto impressionanti. Il loro sito è http://hadoop.apache.org .


Il link è 404 non trovato
Shivam Jha,


9

Ed è anche utile sapere che BigTable non è un database relazionale (come MySQL) ma una grande tabella hash (distribuita) che ha caratteristiche molto diverse. Puoi giocare con (una versione limitata) di BigTable tu stesso sulla piattaforma Google AppEngine .

Accanto a Hadoop di cui sopra ci sono molte altre implementazioni che cercano di risolvere gli stessi problemi di BigTable (scalabilità, disponibilità). Ieri ho visto un bel post sul blog elencandone la maggior parte qui .


6

Google utilizza principalmente Bigtable.

Bigtable è un sistema di archiviazione distribuito per la gestione di dati strutturati progettato per adattarsi a dimensioni molto grandi.

Per ulteriori informazioni, scarica il documento da qui .

Google utilizza anche database Oracle e MySQL per alcune delle loro applicazioni.

Altre informazioni che puoi aggiungere sono molto apprezzate.


17
Google also use Oracle- riferimento necessario.
utente

@user cloud.google.com/sql/docs ? Se gli sviluppatori possono utilizzare MySQL, almeno Google deve aver creato un "traduttore di database" con MySQL e Bigtable.

1

I servizi di Google hanno un'architettura di persistenza poliglotta. BigTable è sfruttato dalla maggior parte dei suoi servizi come YouTube, Ricerca Google, Google Analytics ecc. Il servizio di ricerca inizialmente ha utilizzato MapReduce per la sua infrastruttura di indicizzazione, ma in seguito è passato a BigTable durante il rilascio di Caffeina.

L'archivio dati di Google Cloud ha oltre 100 applicazioni in produzione presso Google sia per utenti interni che esterni. Applicazioni come Gmail, Picasa, Google Calendar, Android Market e AppEngine utilizzano Cloud Datastore e Megastore.

Google Trends utilizza MillWheel per l'elaborazione del flusso. Inizialmente Google Ads ha utilizzato MySQL, successivamente migrato in F1 DB, un database relazionale distribuito scritto personalizzato. Youtube utilizza MySQL con Vitess. Google memorizza exabyte di dati attraverso i server delle materie prime con l'aiuto del file system di Google.

Fonte: database di Google: in che modo i servizi Google memorizzano i dati della scala petabyte-exabyte?

Database di YouTube: come memorizza così tanti video senza esaurire lo spazio di archiviazione?

inserisci qui la descrizione dell'immagine

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.