# BigTable

Heatmap

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

Key patterns

![](/files/-MSg0ek-5q5K_MANFYgi)

Row key design

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

![](/files/-MT4p0X0YoAWrJwKoii3)

**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> |


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://code.janardhanpulivarthi.com/google-cloud/bigtable.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.