1) Is the problem real?
The problem is that existed distributed store system cannot achieve good scalability to petabytes of data and thousands of machines. It is real.
2) What is the solution’s main idea (nugget)?
BigTable's three components: Rows, Column Families, Timestamps.
Rows: row keys are arbitrary strings, which may also be regarded as the first level of bigtable index. row range for a table is dynamically partitioned. Each row range is called a tablet, which is the basic unit of distribution and load balancing.
Column Families: column can be regarded as the second level of bigtable index (Row-Column two level ). Each row can have limited columns. And columns are separated by its type. Each type of the data in a column will be collected as a column family.
Timestamps: It is used for store the same data of different versions, which may also be regarded as the third level index in bigtable. Basically, the default return value will be the latest version of data in the specified row&column space.
3) Why is solution different from previous work?
Boxwood from Microsoft has some overlapping with BigTable. However, Boxwood is targeted at a lower level (i.e. provide infrastructure for building filesystem/database). Whereas BigTable is to support client app that wish to store data.
Other projects like DB2 from IBM, Real Application Cluster Database from Oracle, they can achieve similar goal as BigTable does. However, their system architecture are totally different.
4) Does the paper (or do you) identify any fundamental/hard trade-offs?
One key concern is that when the B+ tree architecture. It is good for storing and manage data in the system. However, if the root tablet position is missing, or Chubby cannot work, the whole system will break down.
5) Do you think the paper will be influential in 10 years? Why or why not?
Yeah. It is one of Google's 3 masterpieces of art (i.e. BigTable, MapReduce, GFS).
No comments:
Post a Comment