I hope you enjoyed learning about Google Cloud Bigtable. Let’s do a quick review of what you learned. Bigtable is designed for applications that need low latency access to large amounts of data. A couple of common uses are to support MapReduce operations and real-time analytics.

Bigtable is not a relational database. You can’t query it using SQL, which is why it’s called a NoSQL database. Only single-row transactions have strong consistency. Multi-row transactions have eventual consistency.

Bigtable has an architecture designed for high performance. A Bigtable cluster has nodes that contain pointers to tablets, which are groups of rows. Tables are sparse. That is, empty cells don’t take up any space, so you can have millions of columns. The row key is the only index, so if a query doesn’t reference the row key, it will result in a full table scan. Rows contain key/value pairs. A column key consists of the column family plus the column qualifier plus the timestamp for this version of the data. And columns are grouped into column families.

The most important part of schema design is choosing a row key. It should contain the information needed to support the most common queries. It should also distribute reads and writes evenly across nodes by avoiding hotspotting. When row keys are sorted, they should ideally have identical chunks on adjacent rows, which helps Bigtable compress them. Finally, row keys should have a relatively short length.

Columns that are usually retrieved together should be grouped into a column family. And when you’re working with time series data, you should use tall tables with a relatively small number of columns.

When you’re configuring a cluster, you should use SSDs, rather than HDDs, in most cases, to optimize performance. You need to run large workloads to take advantage of Bigtable’s architecture. To ensure good performance, you should monitor your cluster and add nodes when necessary. For low latency, you should put your client applications in the same zone as your Bigtable cluster.

To control which Google Cloud Platform users have read and write permissions to your tables, set reader, user, and admin roles in IAM. They can only be assigned at the project level, though.

Pricing is based on the number of nodes in your cluster, the amount of data stored in your tables, and the amount of cross-region network traffic. You can monitor a cluster’s performance either manually in the the web console or using Stackdriver Monitoring. You can query and manipulate the data in your tables using either the HBase shell or the cbt command.

Now you know the best use cases for Bigtable, the details of its architecture and its storage model, how to optimize performance by designing a good schema and properly configuring a cluster, how to monitor a cluster, and how to use the HBase shell to send commands to Bigtable.

To learn more about Cloud Bigtable, you can read Google’s documentation. Also, watch for new big data courses on Cloud Academy, because we’re always publishing new courses.

If you have any questions or comments, please let me know in the Comments tab below this video or by emailing support@cloudacademy.com. Thanks and keep on learning!