Tables and views
In Bigtable, you store your data in tables, and you can create several types of views of your tables. The type of view that you use depends on your use case.
Tables
A Bigtable table is a sorted key-value map that stores data in rows and columns. Each row is indexed by a single, unique row key. Columns that are related to one another are typically grouped into a column family.
Bigtable has a flexible data model, and its tables are sparse. This means that if a column is unused in a row, no data is stored for the column. You don't need to store NULL values for unused columns like you would with a relational database. In a Bigtable table, a given row might have one column and the row next to it 100 columns.
In a row, a column can contain multiple cells, each identified by the four-tuple (row key, column family, column qualifier, timestamp). Storing multiple cells in a column provides a record of how the stored data for that row and column has changed over time.
A Bigtable table doesn't support joins, and transactions are supported only within a single row.
A table is an instance-level resource that is automatically replicated to every cluster in the instance. Data retention is controlled with garbage collection policies that are set at the column-family level.
For more information, see the Bigtable overview and Schema design best practices.
Views
Bigtable supports three types of table views: logical views, continuous materialized views, and authorized views. Views let you share table data with particular users and groups without giving them access to the underlying source data.
Logical views
A logical view – often referred to as just a view – is the result of a SQL query. It functions as a virtual table that can be queried by other SQL queries. For more information, see Create and manage logical views.
Continuous materialized views
A continuous materialized view is created by continuously running a SQL query against a Bigtable table. Bigtable creates a new table based on the query output and keeps it in sync with the source table.
Continuous materialized views can help improve query performance. The new table – the continuous materialized view – has a different schema than the source table, containing pre-aggregated or transformed data that is optimized for different queries than those used on the source table.
Continuous materialized views are read-only. You are charged for storage of a continuous materialized view as well as for the processing work that goes into creating the second table, keeping it in sync with the source table, and replicating it.
For more information, see Continuous materialized views.
Authorized views
Authorized views are views of tables that you configure to include specific table data and then grant access to separately from access to the source table. An authorized view is defined by a JSON-formatted definition file.
Unlike continuous materialized views or logical views, Bigtable authorized views can be used to control both read and write access.
Authorized views are useful in cases where you store data for multiple customers in a Bigtable table, and you want to grant each customer access only to a subset of the table that contains their data.
Authorized views don't incur additional storage costs.
For more information, see the Overview of authorized views.
Comparisons
The following table provides additional information about how Bigtable table views differ from each other.
| Logical views | Continuous materialized views | Authorized views | |
|---|---|---|---|
| Structure | Virtual table representing the results of a SQL query | Read-only table based on a source table | Subset of a table |
| Definition | SQL query | SQL query | JSON definition file |
| Consistency with source table | Consistent when the query is run | Eventually consistent | Consistent when the query is run |
| Query options | Must use SQL | SQL or Bigtable Data API | Bigtable Data API |
| Writeable | No | No | Yes |
| Storage | Data remains in the source table | Data is duplicated, aggregated, or transformed and stored in a new read-only table | Data remains in the source table |
| Usage costs | Compute processing to execute the query | Compute processing when syncing, storage costs | Compute processing to execute the query |