Module7谷歌云技术.ppt

Google Cluster Computing Faculty Training Workshop Module VII: Other Google Technologies Overview BigTable Chubby BigTable A Conventional Database… Data structure: arbitrary ## of rows Fixed number and type of columns Supports search based on values in all cells Supports synthesis of output reports based on multiple tables (relational operators) Google’s Needs Data reliability High speed retrieval Storage of huge numbers of records (several TB of data) (Multiple) past versions of records should be available Assumptions Many times more reads than writes Individual component failures common Disks are cheap If they control database design as well as application design, the interface need not be standard Reasonable Questions Are structured queries necessary? Can data be organized such that related data is physically close by nature? What is the minimum coordination required to retrieve data? Can existing components be leveraged to provide reliability and abstraction? From Needs to Constraints Simplified data retrieval mechanism (row, col, timestamp) ? value lookup, only No relational operators Atomic updates only possible at row level But Some Additional Flexibility… Arbitrary number of columns per row Arbitrary data type for each column New constraint: data validation must be performed by application layer! Logical Data Representation Rows columns identified by arbitrary strings Multiple versions of a (row, col) cell can be accessed through timestamps Application controls version tracking policy Columns grouped into column families Column Families Related columns stored in fixed number of families Family name is a prefix on column name e.g., “fileattr:owning_group”, “fileattr:owning_user”, etc. Permissions can be applied at family level to grant read/write access to different applications Members of a family compressed together No Data Validation Any number of columns can be stored in a row within the pre-defined families Database will not enforce existence of any