Bigtable schema design in GCP - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding Row Key Design in Bigtable

Why is it important to design row keys in Bigtable to avoid sequential patterns?

A Because sequential row keys cause data to be stored in multiple tables automatically.

B Because sequential row keys increase storage costs significantly.

C Because sequential row keys prevent data from being compressed.

D Because sequential row keys can cause hotspotting, leading to uneven load on nodes.

💡 Hint

Think about how Bigtable distributes data across nodes.

Sequential row keys cause all writes to go to the same node, creating a hotspot and reducing performance.

❓ query_result

intermediate

Predicting Data Retrieval Order

Given a Bigtable with row keys formatted as 'userID#timestamp', what will be the order of rows returned when scanning the table?

A Rows will be returned sorted by userID ascending, then timestamp ascending.

B Rows will be returned in random order.

C Rows will be returned sorted by timestamp ascending, then userID ascending.

D Rows will be returned sorted by userID descending, then timestamp descending.

💡 Hint

Remember how Bigtable sorts rows lexicographically by row key.

Bigtable sorts rows lexicographically by row key, so 'userID#timestamp' sorts first by userID, then timestamp.

📝 Syntax

advanced

Identifying Invalid Row Key Design

Which of the following row key designs is invalid because it can cause performance issues in Bigtable?

A Using a random UUID as the row key.

B Using a hashed user ID as the prefix of the row key (e.g., 'a1b2c3#20240601').

C Using a timestamp as the prefix of the row key (e.g., '20240601#user123').

D Using a reversed timestamp as the prefix of the row key (e.g., '10964202#user123').

💡 Hint

Consider how row key prefixes affect data distribution.

Using a timestamp prefix causes sequential writes to the same node, creating hotspots and degrading performance.

❓ optimization

advanced

Optimizing Column Family Usage

Which practice optimizes Bigtable schema design regarding column families?

A Put all columns into a single column family regardless of access patterns.

B Group columns with similar access patterns into the same column family.

C Create a separate column family for every individual column.

D Avoid using column families and store all data in row keys.

💡 Hint

Think about how column families affect read and write efficiency.

Grouping columns with similar access patterns reduces unnecessary data reads and improves performance.

🔧 Debug

expert

Diagnosing Hotspotting in Bigtable

A Bigtable instance is experiencing slow write performance. The row keys are user IDs followed by timestamps in ascending order (e.g., 'user123#20240601'). What is the most likely cause?

A Row keys are causing hotspotting because timestamps are ascending, leading to sequential writes on the same node.

B The row keys are too short, causing collisions.

C The table has too many column families, causing overhead.

D Column families are too large, causing slow writes.

💡 Hint

Consider how row key order affects write distribution.

Ascending timestamps at the end of the row key do not distribute writes evenly if user IDs are not well distributed or if many writes target the same user.