Q: 1
(You need to migrate multiple PostgreSQL databases from your on-premises data center to Google
Cloud. You want to significantly improve the performance of your databases while minimizing
changes to your data schema and application code. You expect to exceed 150 TB of data per
geographical region. You want to follow Google-recommended practices and minimize your
operational costs. What should you do?)
Options
Discussion
I don’t think it’s Spanner. B isn’t right since Spanner isn’t fully compatible with PostgreSQL, so you’d have to do a ton of schema and code changes. A (AlloyDB) lets you keep your Postgres stuff and adds better performance, which is what the question wants. That fits Google’s migration best practices. Anyone disagree?
AlloyDB is made for this since it's fully PostgreSQL-compatible and gives a big performance boost without much migration hassle. D would be faster, but you'd have to redo your data model, so that's not minimal changes. I'm pretty sure A is right here.
Seen similar practice questions and the official Google guide, both recommend AlloyDB for PostgreSQL migrations with minimal app changes. A
D , since Bigtable is built to handle massive datasets and scales really well performance-wise. You'd probably get the boost needed at that size. I think schema changes might be unavoidable, but maybe not as big a deal in this scenario? Disagree if you interpret "minimize changes" as almost none.
D imo, because Bigtable can handle massive data and excels in performance at scale. But I'm reading "minimize changes" as only some schema tweaks might be ok, not a full overhaul. Maybe I'm stretching the requirement though-disagree?
A is wrong, AlloyDB (A). Official docs and practice exams always mention AlloyDB for PostgreSQL migrations with minimal changes.
Its D, seen similar in exam reports.
AlloyDB makes the most sense, so A. It’s PostgreSQL compatible, so you hardly need schema or code changes, plus you get better performance and can handle big data sets. Pretty much what Google recommends for this case. Disagree?
Nope, it's not D. Bigtable would force a full rework of schema and queries since it's NoSQL, so that's a trap. A fits best since AlloyDB is PostgreSQL-compatible and boosts performance with almost no app/code changes. Pretty sure Google's docs recommend AlloyDB here.
C or D? The question says "minimizing changes to data schema and application code" and I’m wondering if they allow for some rewrites or strict minimal change. If extensive rewrites are allowed, then Bigtable might work, otherwise AlloyDB fits better.
Be respectful. No spam.
