Google Professional Cloud Developer データ、ストレージ、メッセージングGoogle Professional Cloud Developer Data, Storage, and Messaging

2 週間かけて試験を受けて合格しましたが、ここから出題された問題は 1 つもありませんでした。練習目的にはまだ適していますが、試験を受けるためにこれらの問題を覚えているだけではいけません。

-- 上記の私のコメントは 2 週間経っても承認を待っています。誰かが公開を望まないようです。

Took the exam 2 weeks and got pass, however, NOT A SINGLE question is from here! Although it is still good for practice purpose, DO NOT just remember these questions to take the exam.

-- My comment above is still waiting approval after two weeks, it seems someone doesn't want it to be published.

A. gsutil cp [LOCAL_OBJECT] gs://[DESTINATION_BUCKET_NAME]/
gsutil は次の理由から正しいツールです。
Google Cloud Storage 操作専用のコマンドライン ツールです
GCS でのファイルとバケットの管理用に特別に設計
ローカル システムとクラウド ストレージ間の効率的なファイル転送をサポートします。
自動再試行メカニズムを備えた信頼性の高いアップロード機能を提供します
コマンド構造:
gsutil cp [LOCAL_OBJECT] gs://[DESTINATION_BUCKET_NAME]/
cp: コピーコマンド
[LOCAL_OBJECT]: ソースファイルのパス
gs://: Google Cloud Storage のプロトコル識別子
[DESTINATION_BUCKET_NAME]: ターゲットのバケット名

A. gsutil cp [LOCAL_OBJECT] gs://[DESTINATION_BUCKET_NAME]/
gsutil is the correct tool because:
It's the dedicated command-line tool for Google Cloud Storage operations
Specifically designed for file and bucket management in GCS
Supports efficient file transfer between local systems and Cloud Storage
Provides reliable upload capabilities with automatic retry mechanisms
The command structure:
gsutil cp [LOCAL_OBJECT] gs://[DESTINATION_BUCKET_NAME]/
cp: Copy command
[LOCAL_OBJECT]: Source file path
gs://: Protocol identifier for Google Cloud Storage
[DESTINATION_BUCKET_NAME]: Target bucket name

Google Cloud SDK の更新として、「gcloud」ツールに「storage」コマンド グループが含まれるようになりました。これにより、「gsutil」コマンドと同様に Google Cloud Storage (GCS) と対話できるようになります。

As updates to the Google Cloud SDK, the `gcloud` tool now includes a `storage` command group that allows you to interact with Google Cloud Storage (GCS) similarly to how you would with `gsutil` command

A. gsutil cp [LOCAL_OBJECT] gs://[DESTINATION_BUCKET_NAME]/
このコマンドは、ローカル ストレージから Google Cloud Storage にファイルをコピーするために使用されます。これは、Cloud Dataproc によって使用される移行プロセスの一部としてデータをアップロードするための正しいオプションです。

A. gsutil cp [LOCAL_OBJECT] gs://[DESTINATION_BUCKET_NAME]/
This command is used to copy files from local storage to Google Cloud Storage. It’s the correct option for uploading data as part of a migration process that will be consumed by Cloud Dataproc.

Aが正解です

A is correct answer

答え: A
クラウドストレージ => gsutil。ファイルがどのように使用されるかは関係なく、タスクはファイルをアップロードすることです。

Answer: A
Cloud Storage => gsutil. Doesn't matter how the files are going to be consumed, the task is to upload them.

私ならAと一緒に行きます。

I would go with A.

確かにA

for sure A

最近試験を受けた人はいますか。質問の何パーセントが試験トピックからのものですか?

Anyone took exam recently, what percent of questions came from examtopics?

最近試験を受けた人はいますか。質問の何パーセントが試験トピックからのものですか?

Anyone took exam recently, what percent of questions came from examtopics?

Aが正しいです

A is correct

Aが正しいです

A is correct

試験はダンプで提示されたものとはまったく異なり、まったく異なることが証明されます。
元の試験で問題を更新してください。

The exam is totally different from the one presented in the dump, it proves TOTALLY DIFFERENT.
Please update the questions with the original exam!!

特に istio では GKE が多かったです。

There was a lot of GKE especially with istio.

クラウドストレージコマンド: gsutil

cloud storage command: gsutil

この質問セットは更新されていますか?

is this question set updated ?

質問によると、Cloud SQL へのアクセスを実行しているアプリケーションは Compute Engine 上で実行されており、Cloud SQL 自体にはインスタンス レベルのアクセス制御を管理する役割がないため、提案された回答は間違っているようです。 https://cloud.google.com/sql/docs/mysql/connect-compute-engine によると、Compute Engine から接続するには「プライベート IP」、「パブリック IP」、「Cloud SQL Proxy」の 3 つの方法が考えられます。
回答には「Cloud SQL Proxy」オプションはありません。「パブリック IP」では、質問によると受け入れられないものを IP ホワイトリストに登録する必要があるため、唯一の有効な回答は「プライベート IP」です。

The proposed answer seems incorrect, as according to the question application running access to Cloud SQL is run on the Compute Engine and the are no roles in Cloud SQL itself to manage Instance-level access control. According to https://cloud.google.com/sql/docs/mysql/connect-compute-engine there are 3 possible ways to connect from Compute Engine: 'Private IP', 'Public IP', 'Cloud SQL Proxy'.
There is no 'Cloud SQL Proxy' option in answers, 'Public IP' requires IP whitelisting what is unacceptable according to the question, so the only valid answer is 'Private IP'

答えはAです。

the answer is A.

プライベート IP を有効にすると、Compute Engine インスタンスと Cloud SQL インスタンスは、外部 IP のホワイトリストに依存するのではなく、Google Cloud Platform (GCP) 内のプライベートな内部ネットワーク経由で通信できるようになります。

Enabling private IP allows the Compute Engine instances and the Cloud SQL instance to communicate over a private, internal network within Google Cloud Platform (GCP), rather than relying on external IP whitelisting.

回答 A「Cloud SQL インスタンスのプライベート IP を有効にする」を選択することは、IP アドレスをホワイトリストに登録することなく、Google Compute Engine 仮想マシン インスタンスをマネージド Cloud SQL データベースに接続できるようにする最も効率的で安全な方法です。このアプローチには、Google Cloud Platform (GCP) ネットワーク内でアクセス可能なプライベート IP アドレスを使用するように Cloud SQL インスタンスを構成することが含まれます。この設定により、Compute Engine インスタンスが Google のプライベート ネットワーク経由で Cloud SQL データベースに安全に接続できるようになり、データベースが公共のインターネットに公開されないため、高レベルのセキュリティが提供されます。これにより、ネットワーク構成が簡素化され、IP ホワイトリストの維持に伴う管理オーバーヘッドとセキュリティ リスクが回避されます。

Selecting Answer A, "Enable private IP for the Cloud SQL instance," is the most efficient and secure method to allow your Google Compute Engine virtual machine instances to connect with a managed Cloud SQL database without the need to whitelist IP addresses. This approach involves configuring the Cloud SQL instance to use a private IP address that is accessible within your Google Cloud Platform (GCP) network. This setup ensures that your Compute Engine instances can securely connect to the Cloud SQL database over Google's private network, providing a high level of security as the database isn't exposed to the public internet. It simplifies the network configuration and avoids the management overhead and security risks associated with maintaining an IP whitelist.

Cloud SQL インスタンスを Compute Engine インスタンスに接続するために使用できるオプションは次のとおりです。

1. プライベート IP: Cloud SQL インスタンスのプライベート IP を使用して、Compute Engine インスタンスから接続できます。これには、Cloud SQL インスタンスと Compute Engine インスタンスが同じ VPC ネットワーク内にある必要があります。

2. パブリック IP: Cloud SQL インスタンスのパブリック IP を使用して、Compute Engine インスタンスから接続できます。これには、Compute Engine インスタンスのパブリック IP からの接続を許可するように Cloud SQL インスタンスが構成されている必要があります。

These are the options you can use to connect a Cloud SQL instance to a Compute Engine instance:

1. Private IP: You can use the private IP of the Cloud SQL instance to connect to it from the Compute Engine instance. This requires that the Cloud SQL instance and the Compute Engine instance are in the same VPC network.

2. Public IP: You can use the public IP of the Cloud SQL instance to connect to it from the Compute Engine instance. This requires that the Cloud SQL instance is configured to allow connections from the public IP of the Compute Engine instance.

Aが正しいです

A is correct

質問は「つながり」についてです。ロールの割り当てにより、コンピューティング エンジンに一連の権限が付与されますが、接続は許可されません。

The question is about "connection". Role assignment gives a set of permission to compute engine but doesn't allow connection.

正解は A. emmet に同意します。

Right answer is A. Agree with emmet.

答えはAでなければなりません

Answer should be A

答えは A です。プライベート IP により gce と Cloudsql 間の接続が許可されます。一方、ファイアウォール ルール、プライベート IP またはクラウドプロキシによるパブリック IP のないロールを介して gce から Cloudsql にアクセスすることはできません。

The answer is A, private ip allows the connection between gce and cloudsql, for other hand isn't possible access to from gce to cloudsql though roles without public ip with firewall rules, private ip o cloudproxy

個人的にはオプション C に同意します。プライベート IP を使用すると、すべてのコンピューティング エンジン インスタンスがデータベースにアクセスできるようになります。同じ VPC 内のすべてのコンピューティング インスタンスが許可されていない場合はどうなりますか?

Personally agree the option C, using a private IP will allow all compute engine instances to access the database. What if not all of the compute instances within the same VPC are allowed?

同意するC

agree C

答えはAです。

the answer is A.

https://cloud.google.com/sql/docs/mysql/connect-compute-engine#connect-gce-private-ip

提示された選択肢を考慮すると、答えは A です

https://cloud.google.com/sql/docs/mysql/connect-compute-engine#connect-gce-private-ip

Answer is A given the options presented

ここではCが正解です。

Union と Union All の唯一の違いは、Union All は重複する行やレコードを削除せず、特定のクエリの条件を満たすすべてのテーブルからすべての行を選択し、結果テーブルに結合するだけであることです。

C is correct answer here.

The only difference between Union and Union All is that Union All will not removes duplicate rows or records, instead, it just selects all the rows from all the tables which meets the conditions of your specifics query and combines them into the result table.

C が正解です。

C is correct.

UNION は重複した行を削除します。
UNION ALL は重複行を削除しません。

UNION removes duplicate rows.
UNION ALL does not remove duplicate rows.

Cが正解です

C is correct

Cが正解です

C is correct

SQL を十分に理解している場合は、C が答えです

If you know SQL well enough, C is the answer

ノードの数が多いほど読み取りレイテンシーが少なくなるため、オプション A と C を使用します。

The more number of node less read latency hence i will go with option A and C

答えは A) + 何かになると思います。
彼らは 99.999% の可用性を望んでいます。これに適合するのはマルチリージョン インスタンスだけです。読み取りレイテンシを最小限に抑えるには、北米、ヨーロッパ、アジア リージョンにレプリカがあるため、nam-asia-eur1 インスタンスが最適に機能します。


2番目の答えについては、私には強い意見はありません。ドキュメントによると、「ノードを追加すると、各レプリカのCPUとRAMが増加し、レプリカのスループットが向上します」とあり、「高優先度の合計CPU使用率を65％未満に保つ」ようにノード数を選択することをお勧めします。したがって、ノードは SLA や読み取りレイテンシーに関するものではありません。別のハンドスパナからは、「Cloud Spanner は、強力な一貫性が保証され、リージョン間でデータを自動的にレプリケートします」ため、アプリに Spanner とその DB の間に他の DB と ETL がない限り、データをレプリケートするために DataFlow パイプラインは必要ありません。

I think the answer should be A) + something.
They wants 99.999% availability - only multi-regional instance fits this. To minimize read latency nam-asia-eur1 instance works best as it has replicas in Noth America, Europe and Asia regions.


As for second answer - I do not have strong opinion.. As per documentation "Adding nodes gives each replica more CPU and RAM, which increases the replica's throughput" and they recommend to choose number of nodes to "keep high priority total CPU utilization under 65%". So nodes are not about SLA and read latency. From another hand spanner "Cloud Spanner automatically replicates your data between regions with strong consistency guarantees" so no DataFlow pipeline needed to replicate data, unless the app has other DBs and ETL between Spanner and that DBs.

99.999% の可用性を達成し、グローバルに分散したユーザー ベースの読み取り遅延を最小限に抑えるには、企業は次のことを行う必要があります。
- 「nam-asia-eur1」構成を使用してマルチリージョンの Cloud Spanner インスタンスをデプロイします（オプション A）。この設定により、北米、アジア、ヨーロッパの 3 大陸にわたってデータが地理的に分散されます。このオプションのマルチリージョンの性質は、高可用性を維持し、これらのリージョンにまたがるユーザーがデータベースにアクセスする際の待機時間を確実に短縮できるように設計されています。
- Cloud Spanner インスタンスに少なくとも 3 つのノードがあることを確認します (オプション C)。この構成は、データベースの高可用性とフォールト トレランスに貢献します。異なるリージョンにあるこれらのノードにわたる Spanner の組み込みレプリケーションは、ファイブ ナイン (99.999%) の可用性目標をさらにサポートすると同時に、読み取り操作のスケーラビリティも提供します。

To achieve 99.999% availability and minimize read latency for a globally distributed user base, the company should:
- Deploy a multi-regional Cloud Spanner instance with the "nam-asia-eur1" configuration (Option A). This setup will provide the geographical distribution of data across three continents — North America, Asia, and Europe. The multi-regional nature of this option is designed to maintain high availability and ensure users across these regions experience low latency when accessing the database.
- Ensure that the Cloud Spanner instance has a minimum of three nodes (Option C). This configuration will contribute to the high availability and fault tolerance of the database. Spanner's built-in replication across these nodes in different regions will further support the five nines (99.999%) availability target, while also providing scalability for read operations.

考えられるすべての答えを考えてみましょう。
- 「nam3」は必要なグローバル構成ではないため、B は意味がありません。
- D は問題ありません。1 ノードでは不十分だからです
- グローバル構成が必要なので、E では不十分です。
- Fはまったく関係ありません。

Let's think about all possible answers:
- B does not make sense, as "nam3" is not the global configuration we want;
- D is not ok, 'cause 1 node is not enough
- E is not enough, as we want a global configuration;
- F is totally unrelated.

ここではACが最適です。

AC are best suited here.

99.999% の可用性と遅延の削減
オプション A では 99.999% の可用性が得られます (リージョン名のタイプミスだと思います)
オプション C は、コンピューティング能力、ノード数の増加 -> 遅延の減少に関するものです。
https://cloud.google.com/spanner/docs/instances#compute-capacity
B - そのようなマルチリージョン構成はありません nam3
D - 1 つのノードではなく 3 つのノードでクラスターを作成する方がよい
E、F - オーバーエンジニアリング

99.999% availability and reduce latency
Option A gives us 99.999% availability (think its typo in region name)
Option C is about compute capacity, more nodes -> less latency
https://cloud.google.com/spanner/docs/instances#compute-capacity
B - there is no such multi-region configuration nam3
D - its better to create cluster with 3 nodes, not 1
E,F - overengineering

A - グローバルで 99.999% の可用性を提供します
C - より多くのノード - 待ち時間の短縮

A - global and provides 99.999% availability
C - more nodes - less latency

それは明らかです

it's obvious

なぜCとFではないのか

why not C and F

少なくとも 3 つのリージョンがあり、リージョン「man-asia-eur1」が存在しない場合は、コンソールのマルチリージョン命名法を見てください。

3 regions at least, and for those that says there is no region "man-asia-eur1", take a look at the console, its multiregion nomenclature!

「nam-asia-eur1」というリージョンはありません
Aは間違っています、
B&Cは正しいです

There is no region called ""nam-asia-eur1""
A is wrong,
B&C is correct

99,999% の SLA を満たすためにはマルチ リージン データベース (スパナ) が必要であり、必要なリソースを確保するにはマルチノードが必要です。

We need multi-regin db (spanner) to satisfy 99,999% SLA and have multi-node to ensure resource needed.

ACは正しいです

AC are correct

C はノードの数により計算能力が増加するため (数秒間のクエリとわずかな待ち時間)、F は世界中の可用性をカバーするためです。 A 構成「nam-asia-eur1」が存在しないため誤りです。Google は「nam-eur-asia1」または「nam-eur-asia3」を提案します。D ノード数が少なすぎるため誤りです。 E は高価すぎる解決策です

C because the number of nodes increases the computational capabilities ( queries for seconds and so minor latency), F to cover worldwide availability; A it's wrong because the configuration "nam-asia-eur1" not exist, Google suggests "nam-eur-asia1" o "nam-eur-asia3", D it's wrong because the number of nodes is too few; E is too expensive a solution

AとCは意味がある

A and C make sense

これは A と F である必要があります。

This should be A and F.

AさんとCさんに同意

Agree with A and C

私にとっての正解はAです。
実際、ループは単一の InsertReqeust を構築して送信します。
ただし、すべてのリクエストをリスト内に構築し、InsertAllRequest.newBuilder(tableId).setRows(rows).build() を使用して送信することができます。
https://cloud.google.com/bigquery/streaming-data-into-bigquery#streaminginsertexamples

For me the correct answer is A.
Infact the loop build a single InsertReqeust and send it.
But we can build all request in a list and use InsertAllRequest.newBuilder(tableId).setRows(rows).build() to send.
https://cloud.google.com/bigquery/streaming-data-into-bigquery#streaminginsertexamples

元のコードは一度に 1 行をプッシュするため、バッチ処理と比較して時間がかかるため、応答は A になるはずです。

提案された回答 C は不正解です。バッチ処理を使用する場合よりも、各行を個別のリクエストで送信する方がオーバーヘッドが依然として大きいためです。

Response should be A, because original code pushes one row at a time, which is more time consuming in contrast to batch processing.

Proposed answer C is incorrect, because we still have more overhead in sending each row in separate request than using batch processing.

正解 A: 行のバッチ処理: 複数の行を 1 つのリクエストにバッチ処理することで、ネットワーク通信のオーバーヘッドと API 呼び出しの待ち時間を最小限に抑えます。 BigQuery の InsertAllRequest は、1 回の API 呼び出しでの複数行の挿入をサポートしています。
並列挿入 (オプション B): 並列処理によりパフォーマンスは向上しますが、複雑さが増し、同時実行の問題の処理が必要になる場合があります。一般に、最初に行をバッチ化することをお勧めします。
Cloud Storage への書き込み（オプション C および D）: Cloud Storage にデータを書き込んでから BigQuery に読み込むことは、非常に大規模なデータセットの場合は効率的ですが、追加の手順と複雑さが追加されます。これは、小規模で頻繁な挿入ではなく、一括ロード操作に適しています。

Correct answer A: Batching Rows: By batching multiple rows into a single request, you minimise the overhead of network communication and API call latency. BigQuery's InsertAllRequest supports inserting multiple rows in a single API call.
Parallel Inserts (Option B): While parallel processing can improve performance, it introduces complexity and may require handling concurrency issues. It's generally better to batch rows first.
Writing to Cloud Storage (Options C & D): Writing data to Cloud Storage and then loading it into BigQuery can be efficient for very large datasets, but it adds extra steps and complexity. It's more suitable for bulk load operations rather than small, frequent inserts.

データセットが小さい場合、またはシンプルさが最優先される場合: 多くの場合、各リクエストに複数の行を含めるだけで十分です。
大規模なデータセットの場合、またはパフォーマンスが重要な場合: 並列挿入が適しています。

For smaller datasets or when simplicity is paramount: Including multiple rows with each request is often sufficient.
For larger datasets or when performance is critical: Parallel inserts are the way to go.

A. 各リクエストに複数の行を含めます。
これは、挿入操作をバッチ処理する非常に効率的な方法です。 BigQuery の insertAll メソッドはバッチ挿入をサポートしているため、各行を個別のリクエストに挿入する代わりに、複数の行を 1 つの insertAll リクエストにグループ化できます。このアプローチにより、BigQuery サービスに対して行われる HTTP リクエストの数が減り、スループットが向上し、レート制限に達するリスクが軽減されます。

A. Include multiple rows with each request:
This would be a very efficient way to batch the insert operations. BigQuery's insertAll method supports batched inserts, so instead of inserting each row in a separate request, you could group multiple rows into a single insertAll request. This approach reduces the number of HTTP requests made to the BigQuery service, which can improve throughput and reduce the risk of hitting rate limits.

B - 私は A と B の間にいました。どちらのオプションでもコードの変更が必要で、オプション B ではコレクションの管理方法の変更が必要です。一度に複数の行を挿入する場合でも、コレクション内の ROWS を 1 つずつ移動して (これはループであることに注意してください)、一括で挿入する必要があります。最初にコレクションを (n) 個のサブセットに分割し、次に (n) 個の脅威で関数を実行すると、一度に (n) 個のサブセットを移動し、一度に (n) 個の挿入をすべて並行して実行することになります。それが私の見方でした。

オプション A では、実際には (ある種の) パフォーマンスの変化さえも生じず、単にデータベースとの対話が少なくなるだけです。 (対話速度が速くなった場合、挿入レイテンシーがわずかに減少することがわかります)

B - I was between A and B. Both options require changes in the code and Option B requires changes in the way you are managing the Collection. If you insert multiples rows at a time, you would still need to move through the ROWS in the collection one by one (remember, this is a loop) to then insert in bulk. If you first break the Collection into (n) subsets and then run the function in (n) threats, you would be moving through (n) subsets at a time, making (n) insertions at a time, all in parallel. That was my way of viewing it.

Option A would actually not even make a change in performance (sort of), you would just be interacting with the database less. (if interacting less in faster then you would see a small decrease in insert latencies)

私ならAと一緒に行きます。

I would go with A.

A. 各リクエストに複数の行を含めます。

バッチ挿入は個別の挿入より効率的であり、行ごとに個別のリクエストを作成して送信するオーバーヘッドが削減されるため、書き込みパフォーマンスが向上します。並列挿入は書き込みの競合やリソースの枯渇につながる可能性があり、Cloud Storage に書き込んでから BigQuery に読み込むステップを追加すると、オーバーヘッドと複雑さがさらに増す可能性があります。

A. Include multiple rows with each request.

Batch inserts are more efficient than individual inserts and will increase write performance by reducing the overhead of creating and sending individual requests for each row. Parallel inserts could potentially lead to conflicting writes or cause resource exhaustion, and adding a step of writing to Cloud Storage and then loading into BigQuery can add additional overhead and complexity.

A が正解です

A is the corret answer

答え A、biquery は 1 つのリクエストで複数の挿入をサポートします
https://cloud.google.com/bigquery/docs/samples/bigquery-table-insert-rows

answer A, biquery support multiple insert in one request
https://cloud.google.com/bigquery/docs/samples/bigquery-table-insert-rows

A. 各リクエストに複数の行を含めます。

一般に、行ごとに個別のリクエストを行うよりも、単一のリクエストで複数の行を挿入する方が効率的です。これにより、複数の HTTP リクエストを行う際のオーバーヘッドが軽減され、BigQuery がより効率的なバッチ操作を実行できるようになり、パフォーマンスも向上します。 InsertAllRequest.RowToInsert.of(row) メソッドを使用して、単一のリクエストに複数の行を追加できます。

A. Include multiple rows with each request.

It is generally more efficient to insert multiple rows in a single request, rather than making a separate request for each row. This reduces the overhead of making multiple HTTP requests, and can also improve performance by allowing BigQuery to perform more efficient batch operations. You can use the InsertAllRequest.RowToInsert.of(row) method to add multiple rows to a single request

Ａに投票する

vote A

元のコードは一度に 1 行を挿入するため、並列リクエストを使用しても意味がありません。

Original code inserts one row at a time so no point on using parallel requests..

データベースに並行して保存すると、合計の追加時間が長くなる可能性があり、多くのシステム条件に依存します。バッチ保存はデータベース コア レベルで最適化されます。

Parallel saving to the database can increase the total addition time and depends on many system conditions. While batch saving is optimized at the database core level.

B が正しいです

B is correct

これは A である必要があります。

This should be A.

C. 429 エラーを処理するには、切り捨てられた指数バックオフ戦略を実装することをお勧めします。このアプローチでは、失敗したリクエストを再試行する前に短期間待機する必要があり、再試行が続くたびに待機時間は (最大制限まで) 増加します。これは、レート制限に達する原因となる負荷を軽減するのに役立ち、分散システムでこのようなエラーを処理するための確立されたパターンです。

C. Implementing a truncated exponential backoff strategy is a recommended practice for handling 429 errors. This approach involves waiting for a short period before retrying the failed request, with the wait time increasing (up to a maximum limit) with each successive retry. This can help to alleviate the load causing the rate limit to be hit and is a well-established pattern for handling such errors in distributed systems.

指数バックオフ式では遅延が発生します

Exponential backoff formula will generate delay

C が正解です

C is Correct

C は必須です。そうしないとコードが機能しません。ただし、クォータの増加をリクエストするのは後からになるか、指数バックオフに頼るのは面倒です...

C is a must or your code won't do the job. But Request a quota increase will come afterwards or it will be a pain rely on exponential backoff....

Cloud Storage からデータをリクエストするときに HTTP 429「リクエストが多すぎます」エラーを処理するには、切り捨てられた指数バックオフ戦略 (C) を使用してリクエストを再試行する必要があります。

HTTP 429「リクエストが多すぎます」ステータス コードは、サーバーが受信したリクエストが多すぎてすべてを処理できないことを示します。この状況では、一般に、切り捨てられた指数バックオフ戦略を使用して、一定期間後にリクエストを再試行することが最善です。これには、最大遅延まで、各再試行間の遅延が徐々に長くなってリクエストが再試行されることが含まれます。遅延は、再試行ごとに遅延を 2 の累乗ずつ増加させる指数バックオフ式を使用して生成できます。再試行に時間がかかりすぎるのを防ぐために、再試行は最大遅延で切り詰めることができます。

To handle HTTP 429 "Too Many Requests" errors when requesting data from Cloud Storage, you should retry the request with a truncated exponential backoff strategy (C).

An HTTP 429 "Too Many Requests" status code indicates that the server is receiving too many requests and is unable to handle them all. In this situation, it is generally best to retry the request after a period of time, using a truncated exponential backoff strategy. This involves retrying the request with increasingly longer delays between each retry, up to a maximum delay. The delays can be generated using an exponential backoff formula, which increases the delay by a power of two on each retry. The retries can be truncated at a maximum delay to prevent the retries from taking too long.

Cが正解です

C is correct

C が正しいです。適切なバックオフ戦略を選択してください

C is right one, choose proper backoff strategy

ここでは C が正しいオプションです

C is correct option here

ここで述べたように、https://cloud.google.com/spanner/docs/reference/rest/v1/TransactionOptions 読み取り/書き込みトランザクション タイプにはオプションがなく、このトランザクション タイプで古い読み取りを行う方法がないため、D) は間違いなく間違っています。
質問では、一貫性よりも低レイテンシの方が重要であるため、C) はオプションではありません。読み取り専用トランザクションは、Single Read メソッドと同様に古い読み取りも実行できますが、ドキュメント https://cloud.google.com/spanner/docs/transactions#read-only_transactions では、可能な限り SingleRead メソッドを使用することが推奨されています。
私の投票はBです）

As mentioned here https://cloud.google.com/spanner/docs/reference/rest/v1/TransactionOptions read-write transaction type has no options, and there is no way to make stale reads with this transaction type, so D) is definitely wrong.
In the question, low latency is more critical than consistency, so C) is not an option. Read-Only transactions can do stale reads as well as Single Read methods, but in the documentation https://cloud.google.com/spanner/docs/transactions#read-only_transactions , they encourage to use SingleRead methods where possible.
My vote is B)

https://cloud.google.com/spanner/docs/reads:
「古い読み取りは、過去のタイムスタンプで読み取られます。アプリケーションがレイテンシーに敏感だが古いデータを許容できる場合、古い読み取りによってパフォーマンス上の利点が得られます。」

qn は Cloud Spanner からの読み取りについて尋ねているため、B が答えです。書き込みは関係ありません

https://cloud.google.com/spanner/docs/reads:
"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 is the answer since the qn is asking about reading from Cloud Spanner; no writes involved

B. シングル読み取りメソッドを使用して古い読み取りを実行する: 古い読み取り (境界付きの古い読み取りとも呼ばれます) は、最近の過去のタイムスタンプからデータを提供でき、進行中の書き込みが完了するのを待つ必要がないため、より低いレイテンシーで実行できます。これにより、アプリケーションは、待ち時間を短縮するためにある程度の一貫性を犠牲にすることができ、このシナリオに適しています。

B. Perform stale reads using single-read methods: Stale reads (also known as bounded staleness reads) can execute with lower latency because they can serve data from a timestamp in the recent past and do not have to wait for ongoing writes to be completed. This allows the application to trade off some consistency for lower latency, which is suitable for this scenario.

それはBであるはずです。
アプリケーションはレイテンシーにはより敏感で、一貫性にはそれほど敏感ではないため、ここでは古い読み取りを実行することが最良の選択です。古いデータが返される可能性がありますが、待ち時間は短くなります。

It Should be B.
Since the application is more sensitive to latency and less sensitive to consistency performing stale reads is the best choice here. It will provide low latency at the cost of potentially returning stale data.

B である必要があります

Should be B

B が正しいです

B is correct

B が正しいです

B is correct

B が正しいです

B is correct

私の謙虚な意見では、アプリケーションはユーザー連絡先テーブルに書き込む必要があるため、D です。

in my humble opinion it's D because the application must write on user contacts table.

B は正しいです。データの一貫性はそれほど重要ではありません。

B is right, data consistency is less sensitive.

B が正解です

B is the correct answer

「あなたのアプリケーションはユーザーから入力を受け取り、それをユーザーの連絡先に公開します。」
「出版する」とはどういう意味ですか? 「データベースに書き込む」場合、私の投票は D です

"Your application takes an input from a user and publishes it to the user's contacts"
What does "publishes" mean? If "write to database" than my vote is D

ここではBが正解です。

B is correct answer here.

選択肢 A が最も合理的です

B は間違っています。B は、より多くのコストが発生するため、QN が望んでいることではありません。
ロールの作成は QN が求めているものではないため、C は間違いなくアウトです
D は労力を最小限に抑えられないため、間違っています。

Option A makes the most sense

B is wrong since it will incur more costs which is not what the qn wants
C is definitely out as creating roles is not what the qn is asking for
D is wrong as it would not minimise effort

答えはAです
https://cloud.google.com/bigquery/docs/running-queries#batch

Answer is A
https://cloud.google.com/bigquery/docs/running-queries#batch

Google Cloud ドキュメントの「バッチ クエリ ジョブ。これらのジョブを使用すると、BigQuery はユーザーに代わって各バッチ クエリをキューに入れ、アイドル状態のリソースが利用可能になったときに、通常は数分以内にクエリを開始します。」

As read from google cloud docs "Batch query jobs. With these jobs, BigQuery queues each batch query on your behalf and then starts the query when idle resources are available, usually within a few minutes."

A. ユーザーにジョブをバッチ ジョブとして実行するよう依頼します。

BigQuery ジョブをバッチジョブとして実行することは、ジョブの完了にかかる時間を気にする必要がない場合に適したソリューションです。バッチジョブは、BigQuery に使用可能なリソースがあるときに実行されるため、優先度の高いワークロードが妨げられることはありません。これは、追加のリソースや別のプロジェクトを管理するオーバーヘッドを必要としないため、費用対効果の高いソリューションでもあります。 BigQuery はバッチ ジョブよりもインタラクティブ ジョブを自動的に優先するため、重要なワークロードが中断される可能性が低くなります。

A. Ask the user to run the jobs as batch jobs.

Running BigQuery jobs as batch jobs is a good solution when there is no concern about how long it takes to complete these jobs. Batch jobs are executed when BigQuery has available resources, which ensures that they do not interfere with high-priority workloads. This is also a cost-effective solution since it does not require additional resources or the overhead of managing a separate project. BigQuery automatically prioritizes interactive jobs over batch jobs, so important workloads are less likely to be interrupted.

BigQuery のバッチジョブには通常の割り当て制限が適用されず、同時実行速度制限にもカウントされないため、大規模なクエリの実行とコスト削減に適しています。これらのジョブはシステム リソースが利用可能になったときに実行されるため、遅延が発生する可能性がありますが、ユーザーはこれらのジョブの実行にかかる時間を気にしていないため、これは適切な解決策となります。

Batch jobs in BigQuery are not subject to the usual quota limits and do not count towards your concurrent rate limit, which makes them suitable for running large queries and reducing costs. They are executed when system resources become available, so there might be a delay, but since the user isn’t concerned about the time it takes to run these jobs, this would be a suitable solution

正解:A

Correct Answer:A

間違いなく正解はAです

Definitly the correct answer is A

選択肢 A が正解です。ジョブをバッチ ジョブとして実行することにより、ユーザーはジョブの優先レベルを指定して、システム リソースが利用可能なときにジョブを実行できるようになります。これにより、重要なワークロードへの影響が最小限に抑えられ、ユーザーは他のユーザーを中断することなくジョブを実行できるようになります。さらに、バッチ ジョブは一般に対話型クエリよりも実行コストが低いため、このオプションを選択すると企業のコストも最小限に抑えられます。オプション B は、ユーザーがジョブを実行するために別のプロジェクトを作成する必要があり、不必要な複雑さと労力が追加されるため、良い解決策とは言えません。オプション C は、job.user ロールは、ユーザーがすでに持っている可能性が高い bigquery.user ロールを超える追加の権限を提供しないため、適切な解決策ではありません。オプション D は、重要なワークロードが実行されていない時期を判断するために手動介入が必要になるため、適切な解決策ではありません。これは管理が難しく、ユーザーのジョブの実行に遅れが生じる可能性があります。

Option A is the correct answer. By running the jobs as batch jobs, the user can specify a priority level for their jobs, allowing them to be run when system resources are available. This minimizes the impact on important workloads and allows the user to run their jobs without interrupting other users. Additionally, batch jobs are generally less expensive to run than interactive queries, so this option would also minimize cost to the company. Option B is not a good solution because it would involve creating a separate project for the user to run their jobs, which would add unnecessary complexity and effort. Option C is not a good solution because the job.user role does not provide any additional permissions beyond those of the bigquery.user role, which the user likely already has. Option D is not a good solution because it would require manual intervention to determine when important workloads are not running, which would be difficult to manage and could lead to delays in running the user's jobs.

Aが正しいです

A is correct

Aが正しいです

A is correct

Aは正しいです

A is right

ここでは A の方が適切な答えです

A is more suitable answer here

Aがベストアンサーです

A is best answer

私にとっては選択肢 c が正しいです。
ビューの作成は、適切な where 句を使用する 1 つのデータセットで簡単に行えます。そして部門に許可を与えます。
部門用に別のデータセットを作成する (オプション A) は、質問がそれを拒否するステップをさらに作成することです。

For me option c is correct.
create view is easy on one dataset with appropriate where clause. And give permission to department.
Create different dataset(option A) for department is create more steps where question denying it.

答え A) の方が B) よりも優れていると思います
部門固有のデータセット内にある承認されたビューは、マスター データセット (https://cloud.google.com/bigquery/docs/share-access-views) からデータを読み取ることができます。また、Cloud IAM はデータセット レベルでアクセスを設定できます（https://cloud.google.com/bigquery/docs/dataset-access-controls）。

I think that answer A) is better than B)
Authorized views being in the department-specific dataset will be able to read data from the master dataset(https://cloud.google.com/bigquery/docs/share-access-views). And Cloud IAM can set access on dataset level (https://cloud.google.com/bigquery/docs/dataset-access-controls)

A が正解です。共通ビューではユーザーはソーステーブルにアクセスできる必要がありますが、承認されたビューではアクセスできません。

A is correct. with common view users should have acces to source tables but with authorized view they do not.

「A」が最良の解決策であると思います。「C」も最善の解決策である可能性がありますが、データセット マスターはすでに存在します。

I think that "A" is the best solution, "C" could be too but the dataset Master already exists.

C. マスター データセットという名前のデータセットを作成します。 Create a separate view for each department in the Master dataset. Give employees access to the specific view for their department.

このオプションは最も簡単で、BigQuery に行レベルのセキュリティを実装するために必要な手順は最小限です。部門に基づいてレコードをフィルターする適切な WHERE 句を使用して部門ごとにビューを作成すると、従業員に自分に関連するデータのみが表示されるようにすることができます。ビューは、基礎となるデータへの安全なインターフェイスとして機能します。次に、各従業員にそれぞれの部門のビューへのアクセスを許可します。この方法では、管理する必要があるデータセットとテーブルの数を最小限に抑え、BigQuery の組み込みアクセス制御メカニズムを活用します。

C. Create a dataset named Master dataset. Create a separate view for each department in the Master dataset. Give employees access to the specific view for their department.

This option is the most straightforward and requires the fewest steps to implement row-level security in BigQuery. By creating a view for each department with an appropriate WHERE clause that filters records based on the department, you can ensure that employees only see data that's relevant to them. The views act as a secure interface to the underlying data. You then grant each employee access to the view of their respective department. This method minimizes the number of datasets and tables you have to manage and leverages BigQuery's built-in access control mechanisms.

1 つの大きなデータセットを扱うことは、多数の小さなデータセットを維持するよりも確かに簡単です。

Handling one, big dataset is surely easier than maintaining many smaller ones.

なるほど、なぜ C が「データセット名マスターを作成する」と言っているのかわかりません、なんと、データセットはすでに持っています

rly, I don't understand why C says "Create a dataset name Master" wtf, I have the dataset already

正解は C です。アクセス ビューについて提案したリンクには、基になるデータセットへのアクセスを防止し、クエリの適用後にビュー内のデータへのアクセスのみを付与できることが明確に記載されています。

correct answer is C. In the link you proposed about access view is clearly stated that you can prevent access to the underlying dataset and give access only to data that is in the view after applying the query.

正解は C です。アクセス ビューについて提案したリンクには、基になるデータセットへのアクセスを防止し、クエリの適用後にビュー内のデータへのアクセスのみを付与できることが明確に記載されています。 (https://cloud.google.com/bigquery/docs/share-access-views)

correct answer is C. In the link you proposed about access view is clearly stated that you can prevent access to the underlying dataset and give access only to data that is in the view after applying the query. (https://cloud.google.com/bigquery/docs/share-access-views)

このアプローチにより、単一の「マスター」データセットを維持しながら、ビューを使用して部門に基づいてデータへのアクセスを制御できます。これにより、部門ごとに個別のデータセットやデータ パイプラインを作成する必要がなくなるため、必要な手順の数が最小限に抑えられます。

This approach allows you to maintain a single “master” dataset, while using views to control access to data based on department. This minimizes the number of steps required, as you don’t need to create separate datasets or data pipelines for each department.

承認されたビュー。したがって、承認されたビューを使用しているのは A だけです。部門ごとにデータセットを作成するのは、余分な不必要な手順である可能性があります。しかし、これはこの部門のユーザーに権限を与える方法であり、すべてを適切に保つためのものです...

Authorized views. So A since is the only one using authorized views. It may be a extra unnecessary step to create a dataset for each department. But it is a way to grant permission to users in this department, and keeps all in order...

正解 c.ビューの回答では、部門ごとにデータセットを作成する方が手順が多いため、アクセス A の必要性がなくなりました。

correct answer c. the view answer the need of acess A is elminited because create dataset by department is more steps.

正解は C です。マスター データセット内の部門ごとに個別のビューを作成すると、従業員が自分の部門の情報のみを表示できるようにするという要件を強制できます。これは、このセキュリティ フレームワークを実装するために必要な最小限の手順です。オプション A は、部門ごとに個別のデータセットを作成する必要があるため、不正解です。これは不必要です。オプション B は、部門ごとにデータ パイプラインを作成する必要があるため不正解です。これは不必要です。オプション D は不正解です。部門ごとに個別のテーブルを作成する必要がありますが、これは不必要です。

The correct answer is C. By creating a separate view for each department in the Master dataset, you can enforce the requirement that employees should only be able to view information for their department. This is the minimum number of steps required to implement this security framework. Option A is incorrect because it involves creating separate datasets for each department, which is unnecessary. Option B is incorrect because it involves creating data pipelines for each department, which is unnecessary. Option D is incorrect because it involves creating separate tables for each department, which is unnecessary.

Cが正解です

C is correct

Cであるはずです。
同じデータセット内にビューを作成するだけで済むのに、なぜ別のデータセットを作成する必要があるのでしょうか。

It should be C.
Why create a separate dataset when you can get it done simply by creating a view in the same dataset.

私は C に投票します。A と比較してステップ数が最小です。

I vote C. Least steps compared to A.

なぜCではないのでしょうか？手順が少なくなります。各部門に固有のデータセットとビュー。アプローチとしては賢くて早いと思います。

Why not C? Less steps. A unique dataset and n view for each department. I thinks is smarter and faster as approach.

答えはDです
https://cloud.google.com/storage/docs/request-rate#ramp-up

Answer is D
https://cloud.google.com/storage/docs/request-rate#ramp-up

D. アプリケーション クライアントからのアップロード レートを制限して、休止バケットのピーク リクエスト レートに徐々に到達するようにします。

Google Cloud Storage バケットにはスループット制限があり、特に以前は非アクティブだったバケットでは、継続的なトラフィックが増加するにつれて増加します。非アクティブなバケットへのトラフィックの送信を開始すると、トラフィックの突然の増加に合わせて Cloud Storage が自動的にスケーリングするまでに時間がかかります。バケットへのトラフィックを徐々に増やすことで、Cloud Storage インフラストラクチャにスケーリングする時間を与え、リクエストを失敗させることなく増加した負荷を処理できます。

D. Limit the upload rate from your application clients so that the dormant bucket's peak request rate is reached more gradually.

Google Cloud Storage buckets have throughput limits that ramp up as sustained traffic increases, especially for previously inactive buckets. When you start sending traffic to an inactive bucket, it takes time for Cloud Storage to automatically scale to accommodate the sudden increase in traffic. By gradually increasing the traffic to the bucket, you give the Cloud Storage infrastructure time to scale and handle the increased load without failing requests.

Google Cloud Storage バケットには、リクエスト レートの初期制限があります。バケットが一定期間非アクティブである場合、バケットには下限が設定されます。トラフィックが増加すると、Google Cloud Storage はリクエスト レート制限を動的に増加させます。このプロセスには数分かかる場合があります。トラフィックが急激に増加すると、断続的な 5xx および 429 HTTP 応答が表示されることがあります。アプリケーション クライアントからのアップロード レートを制限すると、バケットのピーク リクエスト レートがより緩やかに増加し、これらのエラーが発生する可能性が減ります。

Google Cloud Storage buckets have an initial limit on the request rate. If a bucket is inactive for a period of time, it will have a lower limit. As traffic increases, Google Cloud Storage dynamically increases the request rate limit. This process can take several minutes. If the traffic increases too quickly, you may see intermittent 5xx and 429 HTTP responses. By limiting the upload rate from your application clients, you allow the bucket’s peak request rate to increase more gradually, reducing the chance of receiving these errors.

Cloud Storage API からの失敗した応答を減らすには、アプリケーション クライアントからのアップロード レートを制限して、休止バケットのピーク リクエスト レートに徐々に到達するようにする必要があります。これは、リクエストの突然の増加によってバケットが超過するのを防ぐのに役立ちます。

A 多数の個別のストレージ バケットにアップロードを分散しても、失敗した応答が必ずしも減少するとは限らず、システムの複雑さが増大する可能性があります。

B では、JSON API の代わりに XML API を使用しますが、必ずしもパフォーマンスが向上するとは限らず、アプリケーションに大幅な変更が必要になる可能性があります。

C では、HTTP 応答コードをクライアントに返しますが、問題の根本原因に対処できない可能性があり、さらなるエラーが発生する可能性があります。

To decrease the failed responses from the Cloud Storage API, you should limit the upload rate from your application clients so that the dormant bucket's peak request rate is reached more gradually. This will help prevent the bucket from being overwhelmed by a sudden increase in requests.

A, distributing the uploads across a large number of individual storage buckets, may not necessarily decrease the failed responses and could potentially increase the complexity of the system.

B, using the XML API instead of the JSON API, may not necessarily improve performance and could require significant changes to the application.

C, passing the HTTP response codes back to clients, may not address the root cause of the issue and could lead to further errors.

Dが正解です

D is correct

Dが正解です

D is correct