Bigtable schema design in GCP - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to define a column family named 'stats' in a Bigtable schema.

GCP

column_families = { '[1]': {} }

Drag options to blanks, or click blank then click option'

Astats

Bdata

Cinfo

Dmetrics

Attempts:

3 left

💡 Hint

Common Mistakes

Using a column qualifier instead of a column family name.

Using an invalid or empty string as the column family.

The column family name 'stats' is used to group related columns in Bigtable.

2fill in blank

medium

Complete the code to set the row key prefix for efficient Bigtable reads.

GCP

row_key = '[1]#user123#2024-06-01'

Drag options to blanks, or click blank then click option'

Auser

Bregion

Ctimestamp

Ddevice

Attempts:

3 left

💡 Hint

Common Mistakes

Using a timestamp prefix that causes hotspotting.

Using a device prefix that is not consistent.

Using 'user' as a prefix helps group rows by user for faster access.

3fill in blank

hard

Fix the error in the Bigtable schema definition by completing the blank.

GCP

column_families = { 'stats': { 'gc_rule': [1] } }

Drag options to blanks, or click blank then click option'

AMaxAgeGCRule('7d')

BMaxVersionsGCRule(3)

CMaxVersionsGCRule('3')

DMaxAgeGCRule(7)

Attempts:

3 left

💡 Hint

Common Mistakes

Passing a string instead of an integer to MaxVersionsGCRule.

Using MaxAgeGCRule with incorrect argument types.

MaxVersionsGCRule expects an integer for the number of versions to keep.

4fill in blank

hard

Fill both blanks to create a Bigtable row key with reversed timestamp and user ID.

GCP

row_key = '[1]#[2]'

Drag options to blanks, or click blank then click option'

Auser123

B20240601

Creverse_timestamp

Duser_id

Attempts:

3 left

💡 Hint

Common Mistakes

Placing user ID before the reversed timestamp causing hotspotting.

Not reversing the timestamp leading to uneven data distribution.

Using a reversed timestamp first helps distribute writes evenly, followed by user ID.

5fill in blank

hard

Fill all three blanks to define a Bigtable schema with a column family, GC rule, and row key prefix.

GCP

schema = {
  'column_families': {
    '[1]': {
      'gc_rule': [2]
    }
  },
  'row_key_prefix': '[3]'
}

Drag options to blanks, or click blank then click option'

Ametrics

BMaxVersionsGCRule(5)

Cuser#

Dstats

Attempts:

3 left

💡 Hint

Common Mistakes

Using an incorrect GC rule type or argument.

Choosing a row key prefix that causes hotspots.

Mixing column family names and prefixes.

The column family 'stats' uses a GC rule to keep 5 versions. The row key prefix 'user#' groups rows by user.

Practice

1. What is the main purpose of designing a row key carefully in Bigtable schema design?

easy

A. To balance load and enable fast queries

B. To store large binary files

C. To create multiple databases

D. To encrypt data automatically

Solution

1. Step 1: Understand the role of row keys in Bigtable

   Row keys uniquely identify rows and determine data distribution across nodes.

2. Step 2: Analyze the impact of row key design

   Good row key design balances load and speeds up queries by avoiding hotspots.

3. Final Answer:

   To balance load and enable fast queries -> Option A

4. Quick Check:

   Row key design = balance load + fast queries [OK]

Hint: Row keys control data distribution and query speed [OK]

Common Mistakes:

• Thinking row keys store data themselves
• Confusing row keys with column families
• Assuming row keys encrypt data

2. Which of the following is the correct way to group related columns in Bigtable?

easy

A. Using multiple row keys

B. Using separate tables

C. Using column families

D. Using indexes

Solution

1. Step 1: Recall Bigtable's data organization

   Bigtable organizes columns into column families to group related data.

2. Step 2: Identify the correct grouping method

   Column families group related columns for performance and management.

3. Final Answer:

   Using column families -> Option C

4. Quick Check:

   Related columns = column families [OK]

Hint: Group related columns with column families [OK]

Common Mistakes:

• Confusing row keys with column grouping
• Thinking indexes group columns
• Using separate tables unnecessarily

3. Given a Bigtable with row keys designed as userID#timestamp, what is the main benefit of this design?

medium

A. It enables efficient queries for a single user's recent activity

B. It groups all data by timestamp only

C. It allows fast retrieval of all users' data at once

D. It prevents any data duplication

Solution

1. Step 1: Analyze the row key format

   The row key combines userID and timestamp, so rows are sorted by user and time.

2. Step 2: Understand query benefits

   This design allows quick access to recent activity for a specific user by scanning a key range.

3. Final Answer:

   It enables efficient queries for a single user's recent activity -> Option A

4. Quick Check:

   Row key userID#timestamp = fast user recent queries [OK]

Hint: Row keys with userID first speed user-specific queries [OK]

Common Mistakes:

• Assuming it groups all users' data together
• Thinking it only sorts by timestamp
• Believing it prevents duplication

4. You notice that your Bigtable cluster has hotspots causing slow queries. Which schema design change can help fix this?

medium

A. Use a sequential numeric row key

B. Add a random prefix to the row key

C. Group all columns into one column family

D. Remove timestamps from row keys

Solution

1. Step 1: Identify cause of hotspots

   Sequential row keys cause data to cluster on few nodes, creating hotspots.

2. Step 2: Apply solution to distribute load

   Adding a random prefix spreads data across nodes, balancing load and reducing hotspots.

3. Final Answer:

   Add a random prefix to the row key -> Option B

4. Quick Check:

   Random prefix = balanced load, fewer hotspots [OK]

Hint: Randomize row keys to avoid hotspots [OK]

Common Mistakes:

• Using sequential keys which cause hotspots
• Grouping columns doesn't fix hotspots
• Removing timestamps reduces query flexibility

5. You want to design a Bigtable schema for IoT sensor data that arrives frequently from many devices. Which design choice best supports fast queries for recent data per device and balanced load?

hard

A. Row key as randomUUID with sensor data in multiple tables

B. Row key as timestamp#deviceID with all columns in one family

C. Row key as deviceID only, with timestamps as columns

D. Row key as deviceID#timestamp with column families for sensor types

Solution

1. Step 1: Consider query pattern

   Queries focus on recent data per device, so deviceID first in row key helps range scans.

2. Step 2: Consider load balancing and data grouping

   Using column families for sensor types groups related data efficiently; timestamp after deviceID orders data by time.

3. Final Answer:

   Row key as deviceID#timestamp with column families for sensor types -> Option D

4. Quick Check:

   DeviceID#timestamp + column families = fast, balanced queries [OK]

Hint: Use deviceID first in row key, group columns by type [OK]

Common Mistakes:

• Putting timestamp first slows device queries
• Using random UUID breaks data locality
• Storing timestamps as columns complicates queries