> For the complete documentation index, see [llms.txt](https://code.janardhanpulivarthi.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://code.janardhanpulivarthi.com/google-cloud/bigtable.md).

# BigTable

Heatmap

* <https://cloud.google.com/bigtable/docs/keyvis-exploring-heatmaps>
* <https://cloud.google.com/bigtable/docs/keyvis-overview>

Key patterns

![](https://1074895821-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MKpcZyxGXJcyzkNoKkm%2F-MSfzqKUBTuvVCXUI2oW%2F-MSg0ek-5q5K_MANFYgi%2Fimage.png?alt=media\&token=db76a3d2-2953-4084-b1eb-6666dad51356)

Row key design

.<https://cloud.google.com/bigtable/docs/schema-design-time-series>

![](https://1074895821-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MKpcZyxGXJcyzkNoKkm%2F-MT0wb2jFwJyF49gWPvp%2F-MT4p0X0YoAWrJwKoii3%2Fimage.png?alt=media\&token=7f8c8c8b-7493-4c2c-ab84-92f56efdb988)

**Choosing a row key that facilitates common queries is of paramount importance to the overall performance of the system.** Enumerate your queries, put them in order of importance, and then design row keys that work for those queries.

Granular access control

.<https://docs.datastax.com/en/security/5.1/security/secDataPermission.html>

## Cost savings

.<https://cloud.google.com/blog/products/databases/how-to-save-money-when-using-cloud-databases>

### Data storage volume

Some applications or workloads generate significant amount of data. An opportunity raises by storing less data in Cloud Bigtable. As there is a minimum node count applicable for the stored data, reduction in node count is also possible.

### Storage type

HDD can manage more data than SSD. Also, the cost of HDD is lower.

However, the performance characteristics are different for HDD:

* read, write latencies are higher
* supported reads per second are lower
* throughput is lower

### Instance topology

In case the topology encompasses more than one cluster, the following are some opportunities:

* Each additional cluster results in additional node, data, and a network cost implication. The data will be replicated between all of the clusters in the instance topology.
* If instance clusters are located in different regions, the instance will accrue network egress cost inter-region data replication. If an application issues workloads to a cluster in a different region egress cost for both calls from application and response from Bigtable.
* One can choose additional clusters in geo-disparate closer to the distributed application endpoints.
* Clusters are not required to have a symmetric node count.

vs BigQuery

| BigQuery                | Bigtable                                                           | Cloud Spanner                                                                                                      |
| ----------------------- | ------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------ |
|                         | Optimized for timeseries data, highly available, low-latency       | Globally scalable strongly consistent database                                                                     |
| Fast wide-range queries | narrow-range queries and have low-latency for this case            |                                                                                                                    |
| analytics database      | For IoT data, low-latency writes and scalable to petabytes of data |                                                                                                                    |
| -                       | -                                                                  | <p>Data in a Relational database with worldwide high-performance accessibility. and</p><p>Multiple data stores</p> |