Introduction
Before reading this page, you should be familiar with Bigtable's overview. You should also know about instances, clusters, and nodes.
Let us have a quick revisit on instances before moving ahead:
A Bigtable instance is a data container.
Instances have one or more clusters in various zones. Each cluster has at least one node.
You should be aware of the following properties of an instance:
The type of storage (SSD or HDD)
When you create an instance, you must specify whether the instance's clusters will use solid-state disks (SSD) or hard disk drives to store data (HDD). SSDs are frequently, but not always, the most efficient and cost-effective option.
The application profiles, which are primarily for replication instances
Bigtable uses the instance you construct to store application profiles or app profiles.
Keeping this basic knowledge in mind, let us now learn to create, modify and delete instances in cloud BigTable.
Choose between SSD and HDD storage
You may use the Logging query language through the Google Cloud console's Logs Explorer, the Logging API, or the command-line interface. The Logging query language may query data and construct filters to generate sinks and log-based metrics.
A query is a Boolean expression that specifies a subset of all the log entries in the Google Cloud resource you have chosen, such as a Cloud project or folder.
You may construct searches based on the LogEntry indexed column using the logical operators AND and OR. The Logging query language syntax looks like this when the resource.type field is used in the following examples:
- Simple restriction: resource.type = "gae_app"
- Conjunctive restriction: resource.type = "gae_app" AND severity = ERROR
- Disjunctive restriction: resource.type = "gae_app" OR resource.type = "gce_instance"
- Alternatively: resource.type = ("gae_app" OR "gce_instance")
- Complex conjunctive/disjunctive expression: resource.type = "gae_app" AND (severity = ERROR OR "error")
Advantages of SSD storage
When in doubt, go for SSD storage.
There are various reasons why SSD storage is generally preferred for your Bigtable cluster:
- SSDs are substantially quicker and provide more consistent performance than HDDs.
- HDD throughput is much lower than SSD throughput.
- Individual row reads on an HDD are very slow.
- Unless you're storing massive volumes of data, HDD's cost savings are small compared to the cost of the nodes in your Bigtable cluster.
Disadvantage of SSD storage
One possible disadvantage of SSD storage is that it necessitates additional nodes in your clusters depending on the quantity of data stored. In practice, though, you may require those extra nodes not merely to handle the quantity of data that you're storing but also to keep up with incoming traffic.
Use cases for HDD storage
HDD storage is appropriate for use cases that match the following requirements:
- You anticipate storing at least 10 TB of data.
- The data will not be used to power a user-facing or latency-sensitive application.
- Your workload is classified as one of the following:
- Batch workloads with scans and writes, and just occasional random reads of a limited number of rows or point read.
- Data archival is the practice of writing enormous amounts of data and infrequently reading that data.
For example, suppose you intend to store a large amount of historical data for many remote-sensing devices and subsequently utilize the data to create daily reports. In that case, the cost savings from HDD storage may outweigh the performance tradeoff. However, if you want to utilize the data to present a real-time dashboard, using HDD storage is generally not a good idea—reads would be considerably more frequent in this instance, and reads that are not scans are significantly slower with HDD storage.
Switching between SSD and HDD storage
When you create a Bigtable instance, you may choose between SSD and HDD storage for the instance. You cannot alter the kind of storage utilized for the instance using the Google Cloud app.
If you wish to alter the storage type on which a table is saved, use the backups feature:
- Create or plan to use an instance that uses the desired storage type.
- Create a backup of the table.
- Restore to a new table in the other instance from the backup.





