Exam Professional Data Engineer topic 1 question 165 discussion

I'd say B as the documentation primarily says ACID compliance for Spanner, not Cloud SQL. https://cloud.google.com/blog/topics/developers-practitioners/your-google-cloud-database-options-explained Also, spanner supports read-write transactions for use cases, as handling bank transactions: https://cloud.google.com/spanner/docs/transactions#read-write_transactions

"locations throughout North America" implies multi-region (northamerica-northeast1, us-central1, us-south1, us-west4, us-east5, etc.) Cloud SQL can only do read replicas in other regions.

B. Store transaction in Cloud Spanner. Use locking read-write transactions. Since the banking transaction system requires ACID compliance and SQL access to the data, Cloud Spanner is the most appropriate solution. Unlike Cloud SQL, Cloud Spanner natively provides ACID transactions and horizontal scalability. Enabling stale reads in Spanner (option A) would reduce data consistency, violating the ACID compliance requirement of banking transactions. BigQuery (option C) does not natively support ACID transactions or SQL writes which are necessary for a banking transactions system. Cloud SQL (option D) provides ACID compliance but does not scale horizontally like Cloud Spanner can to handle large transaction volumes. By using Cloud Spanner and specifically locking read-write transactions, ACID compliance is ensured while providing fast, horizontally scalable SQL processing of banking transactions.

Spanner is an enterprise level resource which Banks require, Cloud SQL is limited to 30TB of storage. And Banking transactions should be read write locked.

ACID Compliance: Cloud Spanner is a globally distributed, strongly consistent database service that offers ACID compliance, making it a suitable choice for handling bank account transactions where data consistency and integrity are crucial. SQL Access: Cloud Spanner supports SQL queries, which align with your requirement to access data with SQL. You can use standard SQL to interact with the data stored in Cloud Spanner. Locking Read-Write Transactions: Cloud Spanner allows you to perform locking read-write transactions, ensuring that transactions are executed in a serializable and consistent manner. This is essential for financial transactions to prevent conflicts and maintain data integrity.

B. Store transaction data in Cloud Spanner. Use locking read-write transactions. Here's why: ACID Compliance: ACID stands for Atomicity, Consistency, Isolation, and Durability. Cloud Spanner is a fully managed, globally distributed database that provides strong consistency and ACID compliance. This ensures that bank account transactions are processed reliably and accurately, avoiding issues like data corruption or incomplete transactions. Ability to access data with SQL: Cloud Spanner supports SQL, which allows you to perform standard SQL queries on the data. This means that you can use familiar SQL commands to access, retrieve, and manipulate transaction data easily.

I initially selected B. However, it might be D. https://cloud.google.com/blog/topics/developers-practitioners/your-google-cloud-database-options-explained Cloud Spanner: Cloud Spanner is an enterprise-grade, globally-distributed, and strongly-consistent database that offers up to 99.999% availability, built specifically to combine the benefits of relational database structure with non-relational horizontal scale. It is a unique database that combines ACID transactions, SQL queries, and relational structure with the scalability that you typically associate with non-relational or NoSQL databases. As a result, Spanner is best used for applications such as gaming, payment solutions, global financial ledgers, retail banking and inventory management that require ability to scale limitlessly with strong-consistency and high-availability.

Answer B: locking read-write = for data accuracy state read = for speed up or latency

Answer B: Spanner It's incomplete question, what do you assume by large bank, until we are not sure about size and scale. Region is north america, that can be managed by cloud sql. but i am going for spanner, as its large bank and transaction data.

This is definitely a tricky question because both B and D are "appropriate" as the question suggests, of course we can make assumptions with the "large bank" sentence but there are other questions here where making assumptions is not accepted by the community so I wonder when can we make assumptions and when we can't. I think the real problem here is the ambiguous question. This is one of the few questions where the community accept that both (B and D) answers are appropriate but some comments (and I agree) argue the BEST approach is B. I really think some questions can be written in a better and non-ambiguous way, it's just about thinking a little bit more and not conforming when a poor spelling.

The question is hinting a requirement for global consistency, i.e. being available for NA region, which does not just include US but also Mexico, Argentina etc. Large bank = priority over consistency over read-write

Finally, it's [B]. There is no measurable requirement that rules out [D] (Cloud SQL) and this fact made me to select it as a preferrable answer. But since we are talking about a large bank (which normally implies massive reads/writes per sec.) and nobody has posed any cost limitation, in a real case I would definitely prefer the advantages of Spanner.

B is the answer. https://cloud.google.com/spanner/docs/transactions Spanner supports these transaction modes: - Locking read-write. This type of transaction is the only transaction type that supports writing data into Spanner. These transactions rely on pessimistic locking and, if necessary, two-phase commit. Locking read-write transactions may abort, requiring the application to retry.

[A] No - Stale reads not accepted for bank account transactions. "A stale read is read at a timestamp in the past. If your application is latency sensitive but tolerant of stale data, then stale reads can provide performance benefits." [B] Yes - Fulfills all requirements [C] No - BigQuery is ACID-compliant, but it is too much to use it for such a case (mainly a CRUD app) [D] Yes+ - Fulfills all requirements. The BigQuery part may seem redundant, but it states a true fact that doesn't violate the "access data with SQL" requirement. So, when SQL Cloud and SQL Spanner fit both, there is no reason to prefer the second. And the question doesn't mention any obvious fact for which should we prefer the expensive SQL Spanner: - We don't know if we have to deal with a big amount of data and thousands of writes per second. - We don't know the database size. - There is no need for multi-regional writes that would exclude SQL Cloud as an alternative. Is it a coincidence that the question limits the problem to the single region of North America?

I'd go for B. The only other somewhat valid option is D, but there's no requirement for analytics in the question.

Surely its B, transactional data at a large US based bank would surely be massive in size and probably too much for CloudSQL? There is also no mention of a requirement for analytics

why not spanner?