Bigtable: A Distributed Storage System for Structured DataChang, et al., 2006.<br />Gemini Mobile Technologies, Inc.<br />...
Bigtable: A Distributed Storage System for Structured Data<br />Authors: Fay Chang, Jeffrey Dean, Sanjay Ghemawat, Wilson ...
1. Introduction<br />“Big Table” is a distributed storage system for managing structured data.<br />Scales to “Petabytes o...
2. Data Model<br />(row, column, time)  => string<br />Row, column, value are arbitrary strings.<br />Every read or write ...
2.1 Tablets<br />Rows are sorted lexicographically.<br />Consecutive keys are grouped together as “tablets”.<br />Allows d...
2.2 Column Families<br />Column keys are grouped into sets called “column families”.<br />Column key is named using syntax...
3. API<br />Data Design<br />Creating/deleting tables and column families<br />Changing cluster, table and column family m...
4. Building Blocks<br />SSTable file: Data structure for storage<br />Maps keys to values<br />Ordered.  Enables data loca...
5. Implementation<br />3 components:<br />Client library<br />Master Server (exactly 1).  <br />Assigns tablets to tablet ...
5.1 Tablet Location<br />How to know which node to route client request?<br />3-level hierarchy<br />One file in Chubby fo...
Tablet Assignment<br />Master keeps track of tablet assignment and live servers<br />Chubby<br />Tablet server creates & l...
5.3 Tablet Serving<br />Write<br />Check well-formedness of request.<br />Check authorization in Chubby file.<br />Write t...
5.4 Compaction<br />In order to control size of memtable, tablet log, and SSTable files, “compaction” is used.<br />MinorC...
6. Refinements<br />“Locality group”.  <br />Client can group multiple column families into a locality group.  Enables mor...
7. Performance Evaluation<br />Random reads are slowest.  Need to access SSTable block from disk.<br />Writes are faster t...
7. Performance Evaluation: Scaling<br />Not linear, but not bad up to 250 tablet servers.<br />Random read has worst scali...
8. Conclusions<br />Satisfies goals of high-availability, high-performance, massively scalable data storage.<br />API.  Su...
Big Table Family Tree<br />2010/7/23<br />Gemini Mobile Technologies, Inc.  All rights reserved.<br />18<br />Non-relation...
Upcoming SlideShare
Loading in...5
×

Summary of "Google's Big Table" at nosql summer reading in Tokyo

13,301
-1

Published on

This is the summary materials of "Google's Big Table" at nosql summer reading in Tokyo on July 22, 2010 hosted by Gemini

Published in: Technology
2 Comments
19 Likes
Statistics
Notes
No Downloads
Views
Total Views
13,301
On Slideshare
0
From Embeds
0
Number of Embeds
28
Actions
Shares
0
Downloads
426
Comments
2
Likes
19
Embeds 0
No embeds

No notes for slide

Summary of "Google's Big Table" at nosql summer reading in Tokyo

  1. 1. Bigtable: A Distributed Storage System for Structured DataChang, et al., 2006.<br />Gemini Mobile Technologies, Inc.<br />NOSQL Tokyo Reading Group<br />(http://nosqlsummer.org/city/tokyo)<br />July 22, 2010<br />2010/7/23<br />Gemini Mobile Technologies, Inc.<br />1<br />
  2. 2. Bigtable: A Distributed Storage System for Structured Data<br />Authors: Fay Chang, Jeffrey Dean, Sanjay Ghemawat, Wilson C. Hsieh, Deborah A. Wallach, Mike Burrows, Tushar Chandra, Andrew Fikes, and Robert E. Gruber Fay<br />Abstract: Bigtable is a distributed storage system for managing structured data that is designed to scale to a very large size: petabytes of data across thousands of commodity servers. Many projects at Google store data in Bigtable, including web indexing, Google Earth, and Google Finance. These applications place very different demands on Bigtable, both in terms of data size (from URLs to web pages to satellite imagery) and latency requirements (from backend bulk processing to real-time data serving). Despite these varied demands, Bigtable has successfully provided a flexible, high-performance solution for all of these Google products. In this paper we describe the simple data model provided by Bigtable, which gives clients dynamic control over data layout and format, and we describe the design and implementation of Bigtable.<br />Appeared in: OSDI'06: Seventh Symposium on Operating System Design and Implementation, Seattle, WA, November, 2006.<br />http://labs.google.com/papers/bigtable.html<br />2010/7/23<br />Gemini Mobile Technologies, Inc. All rights reserved.<br />2<br />
  3. 3. 1. Introduction<br />“Big Table” is a distributed storage system for managing structured data.<br />Scales to “Petabytes of data and thousands of machines”.<br />Developed and in use at Google since 2005. Used for more than 60 Google products.<br />2010/7/23<br />Gemini Mobile Technologies, Inc. All rights reserved.<br />3<br />
  4. 4. 2. Data Model<br />(row, column, time) => string<br />Row, column, value are arbitrary strings.<br />Every read or write of data under a single row key is atomic (regardless of the number of different columns being read or written in the row).<br />Columns are dynamically added.<br />Timestamps for different versions of data. <br />Assigned by client application.<br />Older versions are garbage-collected.<br />Example: Web map<br />2010/7/23<br />Gemini Mobile Technologies, Inc. All rights reserved.<br />4<br />
  5. 5. 2.1 Tablets<br />Rows are sorted lexicographically.<br />Consecutive keys are grouped together as “tablets”.<br />Allows data locality. <br />Example rows: com.google.maps/index.html and com.google.maps/foo.html are likely to be in same tablet. <br />2010/7/23<br />Gemini Mobile Technologies, Inc. All rights reserved.<br />5<br />
  6. 6. 2.2 Column Families<br />Column keys are grouped into sets called “column families”.<br />Column key is named using syntax: family:qualifier<br />Access control and disk/memory accounting are at column family level<br />Example: “anchor:cnnsi.com”<br />2010/7/23<br />Gemini Mobile Technologies, Inc. All rights reserved.<br />6<br />
  7. 7. 3. API<br />Data Design<br />Creating/deleting tables and column families<br />Changing cluster, table and column family metadata like access control rights<br />Client Interactions<br />Write/Delete values<br />Read values<br />Scan row ranges<br />Single-row transactions (e.g., read/modify/write sequence for data under a row key)<br />Map/Reduce integration. <br />Read from Big Table; Write to Big Table.<br />2010/7/23<br />Gemini Mobile Technologies, Inc. All rights reserved.<br />7<br />
  8. 8. 4. Building Blocks<br />SSTable file: Data structure for storage<br />Maps keys to values<br />Ordered. Enables data locality for efficient writes/reads.<br />Immutable. On reads, no concurrency control needed. Need to garbage collect deleted data.<br />Stored in Google File System (GFS), and optionally can be mapped into memory.<br />Replicates data for redundancy.<br />Chubby: Distributed lock service.<br />Store the root tablet, schema info, access control list<br />Synchronize and detect tablet servers<br />2010/7/23<br />Gemini Mobile Technologies, Inc. All rights reserved.<br />8<br />
  9. 9. 5. Implementation<br />3 components:<br />Client library<br />Master Server (exactly 1). <br />Assigns tablets to tablet servers.<br />Detecting the addition and expiration of tablet servers.<br />Balancing tablet-server load<br />Garbage collection of GFS files<br />Schema changes such as table and column family creations.<br />Tablet Servers (multiple, dynamically added/removed)<br />Handles read and write requests to the tablets that it has loaded<br />Splits tablets that have grown too large. Each tablet 100-200 MB.<br />2010/7/23<br />Gemini Mobile Technologies, Inc. All rights reserved.<br />9<br />
  10. 10. 5.1 Tablet Location<br />How to know which node to route client request?<br />3-level hierarchy<br />One file in Chubby for location of Root Tablet<br />Root tablet contains location of Metadata tablets<br />Metadata table contains location of user tablets<br />Row: [Tablet’s Table ID] + [End Row]<br />Key: [Node ID]<br />Client library caches tablet locations.<br />2010/7/23<br />Gemini Mobile Technologies, Inc. All rights reserved.<br />10<br />
  11. 11. Tablet Assignment<br />Master keeps track of tablet assignment and live servers<br />Chubby<br />Tablet server creates & locks a unique file.<br />Tablet server stops serving if loses lock.<br />Master periodically checks tablet servers. If fails, master tries to lock the file and un-assigns the tablet.<br />Master failure does not change tablets assignments.<br />Master restart<br />2010/7/23<br />Gemini Mobile Technologies, Inc. All rights reserved.<br />11<br />
  12. 12. 5.3 Tablet Serving<br />Write<br />Check well-formedness of request.<br />Check authorization in Chubby file.<br />Write to “tablet log” (i.e., a transaction log for “redo” in case of failure).<br />Write to memtable (RAM).<br />Separately, “compaction” moves memtable data to SSTable. And truncates tablet log.<br />2010/7/23<br />Gemini Mobile Technologies, Inc. All rights reserved.<br />12<br />Read<br />Check well-formedness of request.<br />Check authorization in Chubby file.<br />Merge memtable and SSTables to find data.<br />Return data.<br />
  13. 13. 5.4 Compaction<br />In order to control size of memtable, tablet log, and SSTable files, “compaction” is used.<br />MinorCompaction. Move data from memtable to SSTable. Truncate tablet log.<br />Merging Compaction. Merge multiple SSTables and memtable to a single SSTable.<br />Major Compaction. Remove deleted data.<br />2010/7/23<br />Gemini Mobile Technologies, Inc. All rights reserved.<br />13<br />
  14. 14. 6. Refinements<br />“Locality group”. <br />Client can group multiple column families into a locality group. Enables more efficient reads since each locality group is a separate SSTable.<br />Compression. <br />Client can choose to compress at locality group level.<br />Two level caching in servers<br />Scan cache ( K/V pairs)<br />Block cache (SSTable blocks read from GFS)<br />Bloom filter<br />Efficient check if a SSTable contain data for a row/column pair.<br />Commit log implementation<br />Each tablet server has a single commit log (not one-per-tablet).<br />2010/7/23<br />Gemini Mobile Technologies, Inc. All rights reserved.<br />14<br />
  15. 15. 7. Performance Evaluation<br />Random reads are slowest. Need to access SSTable block from disk.<br />Writes are faster than reads. Commit log is append-only. Reads require merging of SSTables and memtable.<br />Scans reduce number of read operations.<br />2010/7/23<br />Gemini Mobile Technologies, Inc. All rights reserved.<br />15<br />
  16. 16. 7. Performance Evaluation: Scaling<br />Not linear, but not bad up to 250 tablet servers.<br />Random read has worst scaling. Block transfers saturate network.<br />2010/7/23<br />Gemini Mobile Technologies, Inc. All rights reserved.<br />16<br />
  17. 17. 8. Conclusions<br />Satisfies goals of high-availability, high-performance, massively scalable data storage.<br />API. Successfully used by various Google products (>60).<br />Additional features in progress:<br />Secondary indexes<br />Cross data center replication.<br />Deploy as a hosted service.<br />Advantages of the custom development:<br />Significant flexibility due to own data model.<br />Can remove bottlenecks and inefficiencies as they arise.<br />2010/7/23<br />Gemini Mobile Technologies, Inc. All rights reserved.<br />17<br />
  18. 18. Big Table Family Tree<br />2010/7/23<br />Gemini Mobile Technologies, Inc. All rights reserved.<br />18<br />Non-relational DBs (HBase, Cassandra, MongoDB, etc.)<br />Column-oriented data model.<br />Multi-level storage (commit log, RAM table, SSTable)<br />Tablet management (assignment, splitting, recovery, GC, Bloom filters)<br />Google related technologies and open-source equivalents<br />GFS => Hadoop Distributed File System (HDFS)<br />Chubby => Zookeeper<br />Map/Reduce => Apache Map/Reduce<br />
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×