Which Database Fits the Meeting-Room Sensor Data?

PCA By islever Editorial Last updated

Designing network, storage, and compute resources.

Short answer

C Use a relational database so analysts can join per-second sensor readings with account owner and office location data.

Question

Your company wants to track whether someone is present in a meeting room reserved for a scheduled meeting. There are 1000 meeting rooms across 5 offices
on 3 continents. Each room is equipped with a motion sensor that reports its status every second. The data from the motion detector includes only a sensor ID and
several different discrete items of information. Analysts will use this data, together with information about account owners and office locations.
Which database type should you use?
  1. Flat file
  2. NoSQL
  3. Relational Correct Answer
  4. Blobstore

Key Takeaways

It tests whether you weigh the analyst's cross-dataset join and the defined 'discrete' schema more heavily than the raw sensor write rate.

This PCA question asks which database suits 1,000 meeting-room motion sensors streaming discrete fields that analysts must combine with owner and office data. The answer is a relational database (C).

Common mistake: Choosing NoSQL (B) because 1,000 readings per second sounds like high-velocity time-series data; that volume is modest, the fields are discrete and structured, and NoSQL makes the required joins with owners and locations painful.

Expert Analysis

Trace the data path

Each of the 1000 rooms emits one reading per second, so the ingest rate is about 1,000 rows/second, or roughly 86 million rows per day. That is a steady but modest write load that a managed relational engine such as Cloud SQL or Cloud Spanner absorbs without sharding. Note also that a one-second cadence is not millisecond latency — "high velocity" here is an overstatement that lures you toward NoSQL.

What the payload really is

The reading carries a sensor ID plus "several different discrete items of information." Discrete means a finite, known set of values — a schema you can declare up front (status, state, room, timestamp). It is not free-form or unknown-shape log text, which removes the main argument for a schemaless store.

Where the answer takes effect — the analyst query

The decisive clause is that analysts will use this data together with account owners and office locations. The request being served is a query that joins the sensor fact stream to owner and office dimension data. A relational database performs that join inside the query engine, backed by indexes on the sensor ID, owner and office keys. NoSQL would force you to denormalize owner and office fields into every reading, or to run the join in application code. Relational makes that combination a first-class operation, and it is the tier where this question's answer actually lands.

Eliminating the rest

A flat file (A) and Blobstore/object storage (D) hold bytes but expose no query, join or indexing layer for analysts, so they fail the reporting requirement outright. NoSQL (B) only wins on ingest scale this scenario never reaches, and it loses on the join.

Verdict: C — Relational.

Exam Strategy

Read for the query the workload must serve, not just the ingest pattern: when a question mentions analysts combining datasets, treat the join requirement as the deciding constraint. Then sanity-check the stated rate — 1,000 events per second is well within relational capacity, so do not let round-sounding throughput numbers push you to NoSQL. Finally, eliminate any option with no query layer (flat file, blob/object store) before comparing the two real database choices.

Frequently Asked Questions

Why isn't NoSQL the answer when 1,000 sensors report every second?

1,000 writes per second is only about 86 million rows per day, which managed relational databases handle easily. The one-second cadence is not true low-latency pressure, and the payload is described as discrete, structured fields rather than unknown-shape data.

Why does joining with account owners and office locations matter so much?

That join is the actual analyst workload: sensor readings are facts that must be related to owner and office dimensions. A relational engine executes that join in the query engine with indexes, while NoSQL would require denormalizing those fields into every reading.

Why are flat file and Blobstore ruled out immediately?

Both store bytes but provide no indexing, querying or join capability, so analysts could not run the required reporting against them. They are storage tiers, not analytical databases.

More PCA FAQ →

Community Votes

B
79%
C
21%

79% of anonymous learners picked answer B. Votes are pick records left by other test-takers — they are not the verified answer.

Discussion 56 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 30 of 56

  1. clouddude 👍 35
    I'll go with B. This is time series data. We also have no idea what kinds of data are being captured so it doesn't appear structurd. A does not seem reasonable because a flat file is not easy to query and analyze. B seems reasonable because this accommodates unstructured data. C seems unreasonable because we have no idea on the structure of the data. D seems unreasonable beacause there is no such Google database type.
  2. tartar 👍 6
    B is ok
  3. Eroc 👍 4
    B because the data is not yet structured but atleast provides 1 block of structured data. The ID.
  4. gfhbox0083 👍 4
    B, for sure. nosql for time series data
  5. GoCloud 👍 4
    B - for Bigtable ;)
Show 25 more comments
  1. victory108 👍 4
    B. NoSQL
  2. Ekramy_Elnaggar 👍 3 Answered B
    Answer is B. 1. High Volume and Velocity of Data: You have 1000 rooms reporting data every second, resulting in a massive amount of data with high velocity. NoSQL databases are designed to handle this kind of volume and speed efficiently. 2. Simple Data Structure: The data from the motion sensor is relatively simple (sensor ID and discrete information). NoSQL databases are well-suited for storing and processing this type of data without the need for complex schemas. 3. Flexible Schema: NoSQL databases offer schema flexibility, allowing you to easily adapt to changes in the data structure if needed. This is important as your tracking requirements might evolve over time. 4.Scalability: NoSQL databases are highly scalable, making it easy to accommodate future growth in the number of meeting rooms or data volume.
  3. znd 👍 3
    And what if you need to use the data from sensor together with information about account owners and office locations? Then you will need a relational database to use a join between the different table. I would say C
  4. Yogikant 👍 3
    There is need to join sensor data with "account owners and office locations.". Only relational database can allow this. Also latency requirement is not very low. Will go with C.
  5. Deb2293 👍 3 Answered B
    This will be time-series data. The best DB would be a Big Table (also sensorID can be used in the row key for faster retrieval of data)
  6. aviratna 👍 3
    B: Is a correct answer to store unstructured data like sensor data in NoSQL database like BigTable
  7. gauravagrawal 👍 3
    B........ Bigtable, more specifically
  8. sasithra 👍 3
    B is correct
  9. hzaoui 👍 2 Answered C
    C. Relational database. Here's why: Scalability: A relational database can handle the data volume from 1000 sensors reporting every second effectively. Structure: It provides a well-defined schema for organizing data like sensor ID, timestamp, motion status, account owner, and office location, making it easily queryable and understandable for analysts. Relationships: It allows establishing relationships between tables, such as linking sensor data to specific meeting rooms and their corresponding owners and locations. This facilitates analyses involving multiple data sources. Flexibility: Relational databases offer flexibility for expanding data collection beyond motion sensors in the future to include other sensor types or meeting room details.
  10. Mndwsk 👍 2
    C is correct. Discrete data means a defined number of known fields. Meaning a schema. One (1) second latency is NOT low latency. Low Latency is usually measured in milliseconds. Data stored is to be used by Analysts. Meaning joins and query support. Those things made me to lean towards Relational database.
  11. BiddlyBdoyng 👍 2
    The requirement to join the data to other data sets implies RDBMS. BigQuery can handle 1GB/s when streaming inserts, I doubt these 1000 sensors will send that much data. Bigtable seems over the top and not able to fulfil all the requirements.
  12. ashishdwi007 👍 2 Answered B
    With frequencies of data (per second), the best case would be using pub/sub and NoSQL. Relational DB/BlobStore/FlatFile are not good for Near realtime data.
  13. zr79 👍 2
    surprised by the options given, this is a great use case of Bigtable so NoSQL
  14. Joyjit_Deb 👍 2
    "B" is best suited, most simple & cost effective method in this case.
  15. mlantonis 👍 2
    NoSQL because we have time series data. So B is the correct
  16. laksg 👍 2
    Agree B . Time series data - no sql
  17. Nirms 👍 2
    B is the correct answer
  18. lynx256 👍 2
    IMO - B (eg. Bigtable)
  19. Ausias18 👍 2
    Answer is B
  20. 2g 👍 2
    answer: B
  21. 41168b9 👍 1 Answered C
    A Relational Database Management System (RDBMS) is the ideal choice because the application involves combining or joining several distinct, structured data sets to answer analytical questions. Data Structure and Relationships The system must handle and link at least three different types of structured information: Motion Sensor Data: High-volume time series data (Sensor ID, timestamp, presence status). Room/Office Data: Static data linking the Sensor ID to the Room Name, Office Location, and Continent. Meeting/Account Data: Static data linking Room Name and Time Slot to the Account Owner (who reserved the room).
  22. hitmax87 👍 1 Answered B
    SQL would work here. But NoSQL will be faster. Because: 1. We mostly append data, we dont update or delete data. We also dont have any relations. 2. Analysts typically request bulks of data, so that it will work faster with warehouse than with SQL. I dont think DB distribution is meaningful here, nowadays there are solutions that allow to replicate both SQL and NoSQL DBs across regions with either strong and eventual consistency.
  23. teofil 👍 1 Answered C
    While a NoSQL database would be excellent at ingesting the high volume of sensor data, it would make the required analytical queries that join different data entities significantly more complex and inefficient to perform. A modern, managed relational database (like Google Cloud SQL or Spanner) is designed to handle both the required transaction volume and the complex analytical queries.
  24. JoseCloudEng1994 👍 1 Answered B
    It is B, From the start flat file cannot be an answer Blobstore (I believe that is particular to AppEngine but its really old) so I guess they are referring to Cloud Storage which stores things in Blobs. So yeah, not this one either, no way to query it Then we know its semi-structured date so its got to be B
  25. Pokchok 👍 1
    The data is only sending sensor Id and other data. The analyst will still need to do a join with other data like office id and only then they will be able to solve it. Postgresql can hold both json and relational data. To avoid joins, I would go for relational database.

Reader comments & corrections

No reader corrections yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

Multi-Regional vs Regional Cloud Storage for Global Software Downloads

S-grade

Surviving a Zone Outage With SQL Server on GCP

S-grade

Fixing BigQuery connection errors from a Compute Engine VM

S-grade

Moving 75 TB into Cloud Storage with Google-recommended practices

S-grade

Practice All PCA Questions

Access 81 questions with complete answers and detailed explanations.

View Full PCA Practice Test →

← Back to PCA Study Guide