Table
import type { Table } from "https://googleapis.deno.dev/v1/bigtableadmin:v2.ts";
A collection of user data indexed by row, column, and timestamp. Each table is served using the resources of its parent cluster.
§Properties
If specified, automated backups are enabled for this table. Otherwise, automated backups are disabled.
If specified, enable the change stream on this table. Otherwise, the change stream is disabled and the change stream is not retained.
Output only. Map from cluster ID to per-cluster table state. If it could
not be determined whether or not the table has data in a particular cluster
(for example, if its zone is unavailable), then there will be an entry for
the cluster with UNKNOWN replication_status
. Views: REPLICATION_VIEW
,
ENCRYPTION_VIEW
, FULL
The column families configured for this table, mapped by column family ID.
Views: SCHEMA_VIEW
, STATS_VIEW
, FULL
Set to true to make the table protected against data loss. i.e. deleting the following resources through Admin APIs are prohibited: * The table. * The column families in the table. * The instance containing the table. Note one can still delete the data stored in the table through Data APIs.
Immutable. The granularity (i.e. MILLIS
) at which timestamps are stored
in this table. Timestamps not matching the granularity will be rejected. If
unspecified at creation time, the value will be set to MILLIS
. Views:
SCHEMA_VIEW
, FULL
.
The unique name of the table. Values are of the form
projects/{project}/instances/{instance}/tables/_a-zA-Z0-9*
. Views:
NAME_ONLY
, SCHEMA_VIEW
, REPLICATION_VIEW
, STATS_VIEW
, FULL
Output only. If this table was restored from another data source (e.g. a backup), this field will be populated with information about the restore.
The row key schema for this table. The schema is used to decode the raw
row key bytes into a structured format. The order of field declarations in
this schema is important, as it reflects how the raw row key bytes are
structured. Currently, this only affects how the key is read via a
GoogleSQL query from the ExecuteQuery API. For a SQL query, the _key column
is still read as raw bytes. But queries can reference the key fields by
name, which will be decoded from _key using provided type and encoding.
Queries that reference key fields will fail if they encounter an invalid
row key. For example, if _key = "some_id#2024-04-30#\x00\x13\x00\xf3" with
the following schema: { fields { field_name: "id" type { string { encoding:
utf8_bytes {} } } } fields { field_name: "date" type { string { encoding:
utf8_bytes {} } } } fields { field_name: "product_code" type { int64 {
encoding: big_endian_bytes {} } } } encoding { delimited_bytes { delimiter:
"#" } } } The decoded key parts would be: id = "some_id", date =
"2024-04-30", product_code = 1245427 The query "SELECT _key, product_code
FROM table" will return two columns:
/------------------------------------------------------\ | _key |
product_code | | --------------------------------------|--------------| |
"some_id#2024-04-30#\x00\x13\x00\xf3" | 1245427 |
------------------------------------------------------/ The schema has the
following invariants: (1) The decoded field values are order-preserved. For
read, the field values will be decoded in sorted mode from the raw bytes.
(2) Every field in the schema must specify a non-empty name. (3) Every
field must specify a type with an associated encoding. The type is limited
to scalar types only: Array, Map, Aggregate, and Struct are not allowed.
(4) The field names must not collide with existing column family names and
reserved keywords "_key" and "_timestamp". The following update operations
are allowed for row_key_schema: - Update from an empty schema to a new
schema. - Remove the existing schema. This operation requires setting the
ignore_warnings
flag to true
, since it might be a backward incompatible
change. Without the flag, the update request will fail with an
INVALID_ARGUMENT error. Any other row key schema update operation (e.g.
update existing schema columns names or types) is currently unsupported.
Output only. Only available with STATS_VIEW, this includes summary statistics about the entire table contents. For statistics about a specific column family, see ColumnFamilyStats in the mapped ColumnFamily collection above.
Rules to specify what data is stored in each storage tier. Different tiers store data differently, providing different trade-offs between cost and performance. Different parts of a table can be stored separately on different tiers. If a config is specified, tiered storage is enabled for this table. Otherwise, tiered storage is disabled. Only SSD instances can configure tiered storage.