Choosing Storage for High-Volume Clickstream Data
Designing network, storage, and compute resources.
Configuring individual storage systems.
You have been asked to select the storage system for the click-data of your company's large portfolio of websites. This data is streamed in from a custom website analytics package at a typical rate of 6,000 clicks per minute. With bursts of up to 8,500 clicks per second. It must have been stored for future analysis by your data science and user experience teams. Which storage infrastructure should you choose?
Answer
Correct answer: B — Google Cloud Bigtable ingests the 6,000-clicks-per-minute stream with 8,500-per-second bursts and serves the teams' future analysis.
Community Insight
The test is matching a very high write-rate event stream destined for analytics to the right storage class, and the trap is picking Cloud Storage (object, batch-oriented) simply because the data is 'stored for later analysis' rather than served live.
This Google Cloud Professional Cloud Architect question asks which storage infrastructure should ingest a continuous clickstream (6,000 clicks per minute with bursts up to 8,500 clicks per second) and hold it for later data science and UX analysis. The correct choice is Google Cloud Bigtable, the managed wide-column NoSQL database purpose-built for sustained high-throughput event writes and time-series/clickstream analytics at scale.
The most common wrong answer is C, Google Cloud Storage: learners reason that because the data is only needed for future (not real-time) analysis, cheap object storage is sufficient. That ignores that a stream of thousands of individual click events per second needs low-latency, row-level append and query semantics — object storage writes are metadata-heavy, latency-bound, and a poor fit for a continuous per-event feed.
Community Discussion (57 comments)
shallah
👍 1
Selected: B
Bigtable supports sub millisecond multiple concurrent writes and is able to scale for the load
fff2e69
👍 4
Selected: B
Google Cloud Bigtable is well-suited for handling high-throughput, low-latency workloads like clickstream data. It is optimized for analytics on time-series and event data at scale, and it supports high write rates, with the capacity to handle thousands of writes per second. This makes it ideal for storing large volumes of clickstream data with bursts, ensuring data is available for analysis by data science and user experience teams.
Ekramy_Elnaggar
👍 4
Selected: B
1. High throughput for clickstream data: Bigtable is a NoSQL database designed for high write throughput, making it ideal for handling the continuous stream of click data with bursts up to 8,500 clicks per second. 2. Scalability: Bigtable is highly scalable, allowing you to handle increasing data volumes as your website portfolio grows. 3. Low latency: Bigtable provides low latency data access, which is important for real-time analysis and reporting on clickstream data. 4. Integration with BigQuery: Bigtable integrates well with BigQuery, enabling your data science team to perform complex analysis and generate insights from the clickstream data.
upliftinghut
👍 3
Selected: C
Big table if it needs real time but here the need for analysis is not urgent => Google cloud storage.
pakilodi
👍 1
Selected: B
The right answer is BigTable for a such large volume of data.
Nora9
👍 1
Selected: B
B. Google cloud Bigtable is most suitable as it is for analysis and streamed data.
MartinFish
👍 1
Selected: B
Note: DataStore is now rename as FireStore.
hiromi
👍 1
Selected: B
B is correct
alekonko
👍 3
Selected: B
Bigtable is a high-perf NoSQL db service that handle large volumes of structured data with low latency
zerg0
👍 1
Selected: B
The Google Cloud Bigtable goes together with the BigQuery. The question itself gives away a bit.
omermahgoub
👍 4
For storing click-data that is streamed in at a rate of 6,000 clicks per minute, with bursts of up to 8,500 clicks per second, and that needs to be stored for future analysis by your data science and user experience teams, you should consider using a scalable, high-performance, and low-latency NoSQL database such as Google Cloud Bigtable, option B. Google Cloud Bigtable is a fully managed, high-performance NoSQL database service that is designed to handle large volumes of structured data with low latency. It is well-suited for storing high-velocity data streams and can scale to handle millions of reads and writes per second. Option A: Google Cloud SQL, option C: Google Cloud Storage, and option D: Google Cloud Datastore, would not be suitable for this use case, as they are not designed to handle high-velocity data streams at this scale.
i_am_robot
👍 2
B. Google Cloud Bigtable Google Cloud Bigtable is a scalable, high-performance NoSQL database that is well-suited for storing large amounts of data with low latency. It is designed for high-throughput workloads such as streaming data, and is able to handle bursts of up to millions of reads and writes per second. Given the high volume of click data that needs to be stored and the requirement for low latency, Google Cloud Bigtable would be a good choice for storing the data. It is able to handle the high rate of incoming data and provide fast access to the data for analysis by the data science and user experience teams. Google Cloud SQL is a fully-managed relational database service, and may not be the best choice for storing high-volume streaming data. Google Cloud Storage is an object storage service, and may not provide the necessary performance for storing and querying large amounts of data in real-time. Google Cloud Datastore is a NoSQL document database, and while it may be suitable for storing large amounts of data, it may not provide the necessary performance for handling high volumes of streaming data.
Melampos
👍 1
Selected: B
https://cloud.google.com/bigtable#section-9
Bry_040706
👍 1
B. Google Cloud Bigtable
AniketD
👍 1
Selected: B
Cloud Bigtable has all the features to fulfill the requirements mentioned in the question
Mahmoud_E
👍 1
D is right answer
zr79
👍 3
Bigtable for a high volume of writes. 8500 clicks per sec
minmin2020
👍 1
Selected: B
B. Google Cloud Bigtable
holerina
👍 2
for analystics choose big table
chickennuggets
👍 1
They don't call it Bigtable for no reason - high throughput and low latency. GCS not enough performance. SQL & datastore not good fit
AashishAggarwal2000
👍 3
B. Google Cloud Bigtable because it supports : a) the low latency + high throughput workloads are required in this use-case to support 8500 clicks events per second. b) the OLAP use case to integrate and analyse this data with various ML and data-science services.
AzureDP900
👍 1
B is right
sgofficial
👍 1
I would go with Bigtable, because here question is stressing on huge volume of data writes and for analysis pupose....bigtable supports heavy reads/writes within seconds
ZLT
👍 1
The question says for future analysis. CBT is a very expensive storage option to keep the data for future analysis. Cloud storage would be a great place to keep data, and it can then be loaded to BQ via cloud dataflow ETL, saving a lot of money
kuboraam
👍 3
They didnt say anything about cost savings in the question, so BigTable is the clear solution. Also they mention bursts of around 8500 clicks per second. Cloud Storage supports a max of only about 1000 writes per second. https://cloud.google.com/storage/docs/request-rate
Dhiraj03
👍 1
Bigtable
Nirca
👍 1
Selected: B
Google Cloud Bigtable is the right option.
pakochiu
👍 1
Selected: B
Google Cloud Bigtable for heaily read write
belly265
👍 2
Ans B -Google cloud big table can only handle this
llanerox
👍 1
For me is B.
Moss2011
👍 3
Selected: B
For the amount of clicks per second the only storage that supports that is BigTable
OrangeTiger
👍 1
Selected: C
The more I look up, C is correct. Store in Cloud Starage for future analysis. Load it into BigQuely when analysis is needed. That way i can reduce costs. The question does not mention real-time analysis.
RitwickKumar
👍 1
Objects in GCS are immutable, how are you planning to store the data: Individual event file or batched file or a single file using post processing? GCS would never fit the bill for streaming data.
OrangeTiger
👍 1
First, i choose C Cloud strage. I confused by a word 'future analysis'. Low data keep on CloudStrage until i need it. Store large amounts of data for analysis, B is best options. But can I stream data directly to BigTable? Don't you need CloudDataflow or CloudFunction in between?
StelSen
👍 3
Answer is B. This links provides nice explanation. https://stackoverflow.com/questions/53489250/price-aside-why-ever-choose-google-cloud-bigtable-over-google-cloud-datastore
haroldbenites
👍 2
Go for C. Analytics event - Cold Path: https://cloud.google.com/architecture/optimized-large-scale-analytics-ingestion
vincy2202
👍 2
Answer is B
Q_Review
👍 2
The question references "Analytics" a large quantity of data. It's not a trick question; Bigtable is the answer. B.
victory108
👍 12
B. Google Cloud Bigtable
rsamant
👍 3
it should be C for real time streaming also . IO can be throttled using pubsub or dataflow while writing data justifying bigtable cost for later analysis is not justified . look @ below diagram from GCS Page https://cloud.google.com/storage#section-6
penelop
👍 3
What are you talking about? Cloud storage is being used as a data lake there, and is being queried by BigQuery. Click-streams are not SQL, therefore this diagram is not applicable at all. You need a non-SQL solution. Hence B.
jeff001
👍 10
B, Bigtable due to the IoT like requirements
Jambalaja
👍 9
B is right. C is wrong, because Cloud Storage has IO write limits of 1000 writes / second. See source: https://cloud.google.com/storage/docs/request-rate#auto-scaling
guid1984
👍 3
Answer is C, if you read below two articles then its clear https://cloud.google.com/solutions/build-a-data-lake-on-gcp https://cloud.google.com/solutions/architecture/optimized-large-scale-analytics-ingestion
army234
👍 4
Nope, B is correct.
doumx
👍 4
B for sure cause : NoSQL and hight volume transaction
RomiAwasthy
👍 1
D - Web traffic, same as game state
Pipoca
👍 3
Tricky question. Usually google recommends Bigtable for IoT. But none of the requirements rule out Datastore as far as I could find. For safety I would go with Bigtable, as bursts of 8500 writes per second have the potencial to disrupt operations in Datastore. If someone can find documentation on this it would be much appreciated.
gfhbox0083
👍 2
B, for sure. BigTable for IOT https://cloud.google.com/solutions/iot-overview
Ziegler
👍 2
B is rght
AD2AD4
👍 2
Final Decision to go with Option B
Mont
👍 2
Data is in IoT Nature and Big Table is the right choice. Cloud SQL is mainly for OLTP (Transactional, CRUD) not for taking and storing streaming data. It does not have the scalability and elasticity to absorb this amount of data in real-time. SO the answer is without any doubt Big Table B.
dotdotc
👍 1
since its stored for future analysis, bigtable is not required. it says data science teams would use it hence would go for cloud storage as bigquery can read from cloud storage
SanderA
👍 4
The data is stored for later analysis only, not for live reporting, So why go with BigTable? I would say go for Cloud Storage. C
bjuneja
👍 1
B is ok reason- GCS is ideally for Object storage purpose although it has pretty good scalability. It's not suitable for IoT kind of spiky streaming data. Its buckets initially support roughly 1000 writes per second and then scale as needed. As the request rate for a given bucket grows, Cloud Storage automatically increases the IO capacity for that bucket by distributing the request load across multiple servers. Especially considering the click stream rate of 6,000 clicks per minute, with bursts of up to 8,500 clicks per second, the way GCS handle and absorb this kind high and low data stream by scale up and down make it not suitable for this task.
Shabje
👍 2
Since this is required only for future analysis, won’t we prefer to land it on the less expensive Cloud Datastore, instead of BigTable whose cost is not justified here.
nitinz
👍 1
Ans is B. high rate = bigtable
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
Google Cloud Bigtable (B) is a fully managed wide-column NoSQL database explicitly recommended by Google for clickstream data, IoT ingestion, and time-series/event workloads with heavy write throughput. It scales horizontally by node, absorbs sustained ingestion in the thousands-of-writes-per-second range plus burst load, and keeps per-row read latency low for later analytical scans. Because the click data must be retained and queried by the data science and UX teams, Bigtable's model of sparse, time-ordered event rows keyed for range scans fits perfectly. Google's own use-case documentation lists clickstream and behavioral analytics as a flagship Bigtable workload, which is exactly what this scenario describes.Why the Other Options Are Wrong
Cloud Storage (C) is object storage: it is excellent for files, images, and batch exports, but it offers no row-level updates, has no database engine, and imposes per-request/per-operation overhead and throughput ceilings that make it unsuitable for a live per-click ingest stream. (The community claim that Cloud Storage caps at 1,000 writes per second is now an outdated figure, but the architectural mismatch still stands.) Cloud SQL (A) is a managed relational OLTP engine — vertical write throughput, connection limits, and storage growth ceilings make it a poor choice for millions of rapidly accumulating event rows, and it is not an analytics store. Datastore/DFirestore in Datastore mode (D) targets entity/document workloads with transactional semantics and strong per-entity contention and throughput constraints, not bulk high-rate time-series ingestion at 8,500 events per second.Community Comment Notes
The community is heavily split toward B: victory108, jeff001, fff2e69, Ekramy_Elnaggar, omermahgoub, army234 and doumx all argue Bigtable, with fff2e69 noting it "is well-suited for handling high-throughput, low-latency workloads like clickstream data." Jambalaja cites a Cloud Storage request-rate limit to rule out C, though that specific figure is outdated — the deeper reason C fails is the object-storage data model, not one number. On the other side, SanderA objects that "the data is stored for later analysis only, not for live reporting" and upliftinghut likewise picks C because "the need for analysis is not urgent" — both confuse query urgency with ingest mechanics: the data still has to be written per event as it streams in, and that requirement alone eliminates object storage.Official Reference
Exam Strategy
In PCA storage-selection items, always separate the ingest path from the serving path: a stream of thousands of events per second needs a write-optimized NoSQL/time-series store (Bigtable), regardless of whether results are read in real time. Read the workload verbs — 'streamed,' 'clicks per second,' 'for future analysis' — and map them to Bigtable's documented clickstream use case rather than to object or relational storage.
Frequently Asked Questions
Why not Google Cloud Storage if the click data is only stored for later analysis?
Object storage has no rows or query engine and is built for batch-oriented file access, not a continuous per-click ingest stream. Bigtable handles the event-rate write volume and still supports the later analytical reads.
Could Google Cloud SQL absorb 8,500 clicks per second of write traffic?
No — Cloud SQL is a relational OLTP service whose write throughput, connection count, and storage growth scale vertically and saturate far below a sustained event stream of this size.
Related Analysis
Practice All PCA Questions
Access 81 questions with complete answers and detailed explanations.
View Full PCA Practice Test →