データポータル レポートでは、フィルタの適用や期間の変更など閲覧者が加えた変更を読み込み、応答するのにかかる時間が、次のようなさまざまな要因によって変わります。
- 基盤となるデータセットのパフォーマンス
- レポートの可視化によってクエリが実行されているデータの量
- 上記クエリの複雑さ
- ネットワーク レイテンシ
こうした要因の中には、ユーザー自身(またはデータポータル)では制御できないものもあります。たとえば、基盤となるデータ プラットフォームの応答性を向上させたり、ネットワーク接続の速度を上げたりするためにユーザーができることはほとんどありません。ただし、データポータルでレポートのパフォーマンスを調整する方法はいくつかあります。
データの更新速度を調整する
ほとんどのデータソースのタイプにはデータの更新頻度のオプションがあります(抽出済みデータソースは例外です)。このオプションを使用すると、レポートのパフォーマンス、クエリ費用や割り当てとのバランスを取りながら、最新情報を取得できます。各データソースのタイプにはそれぞれデフォルトのデータ更新頻度のしきい値がありますが、このしきい値は必要に応じて調整できます。たとえば、サイトやアプリでの広告のパフォーマンスを測定している場合は、1 日に 1 回データを更新すれば十分である可能性があります。一方、ソーシャル メディア分析に基づくレポートでは、1 日に複数回データを更新する必要がある場合があります。
詳しくは、データの更新速度を管理するをご覧ください。
抽出されたデータソースを使用する
抽出済みデータソースは、最大 100 MB のデータの静的スナップショットです。作成後、レポートからのデータ リクエストが、基盤となるデータセットではなく、このスナップショットに送信されます。抽出済みデータソースを使用すると、元のデータにライブ接続した状態よりも、レポートやデータ探索の読み込みが速くなり、応答性が高くなります。
抽出済みデータソースには、データの更新速度に関するオプションはありません。代わりに、抽出済みデータソースのデータを更新するタイミングをスケジュールできます。
詳しくは、データの抽出に関する記事をご覧ください。
同時実行とスケーリングについて
データポータルはサーバーレス アーキテクチャで設計されているため、データポータル自体がレポートを閲覧する同時ユーザー数に厳しい制限を課すことはありません。パフォーマンスとスケーリングは、主にレポートが接続する基盤となるデータソースの容量と応答性によって決まります。
データソースの詳細
BigQuery: BigQuery を使用する場合、レポートの同時実行性とパフォーマンスは、BigQuery スロットの可用性、クエリの複雑さ、データサイズ、キャッシュ保存などの要因によって異なります。BigQuery スロットの使用率とクエリ パフォーマンスをモニタリングします。
最適化するには、パーティショニング、クラスタリング、BI Engine の使用など、BigQuery のベスト プラクティスを検討してください。
その他のデータソース: その他のコネクタ(Google スプレッドシートやサードパーティのデータベースなど)の場合、同時実行数の上限は、ソースシステムの API レート制限、データベース接続プール、クエリ処理の全体的な機能によって異なります。
実行可能な最適化案
- データソースのクエリを最適化する: クエリをできるだけ効率的にします。
- キャッシュ保存を活用する: データポータルのデータの更新速度の設定を利用してデータをキャッシュに保存し、ソースへの直接クエリを減らします。
- 段階的なロールアウト: ユーザーベースが非常に大きい場合(数千人のユーザーなど)、基盤となるデータソースへの影響をモニタリングしながら、段階的なロールアウトを検討します。
- 基盤となるシステムをモニタリングする: データソース(BigQuery スロットや API 割り当てなど)のパフォーマンスと割り当て使用量を確認します。
BigQuery データソースの改善
以降のセクションでは、BigQuery データを使用するレポートのパフォーマンスを改善するためのヒントについて説明します。
BI Engine を使用して BigQuery データソースを高速化する
BigQuery BI Engine は、高速なメモリ内分析サービスです。BI Engine を使用すると、BigQuery に保存されたデータを分析できます。クエリ応答時間は 1 秒未満で、同時実行性にも優れています。
BI Engine はデータポータルと統合されるため、データ探索や分析がスピードアップします。BI Engine を使用すると、パフォーマンス、スケーリング、セキュリティ、データの更新速度を損なうことなく、データポータルで高機能かつインタラクティブなダッシュボードとレポートを作成できます。
詳しくは、BI Engine をデータポータルで使ってみるをご覧ください。
大規模なデータセットに対する複雑なクエリにはマテリアライズド テーブルを使用する
特に大規模なデータセットの場合、ビューが実行時に複雑な計算や変換を行うと、データポータルを BigQuery ビューに接続するのに時間がかかることがあります。ビューはデータの再構築に役立ちますが、数百万件のレコードに対して署名付き URL を動的に生成するなどのリアルタイム計算を行うと、データポータルでタイムアウトが発生する可能性があります。
処理負荷の高いビューを使用する代わりに、次のいずれかのオプションを使用して、ビューのクエリの結果をテーブルにマテリアライズします。
- BigQuery マテリアライズド ビューを使用します。
- クエリ結果からテーブルを作成し、BigQuery のスケジュール設定されたクエリを使用して、そのテーブルのデータを定期的に更新します。
次に、標準ビューではなく、マテリアライズド ビューまたはテーブルにデータポータルを接続します。これにより、データポータルからのリクエストごとに複雑な計算を再実行する必要がなくなります。マテリアライズド データのパフォーマンスをさらに向上させるには、BI Engine を使用します。
BigQuery Storage Read API を有効にする
ページ分けされた結果を使用するクエリでは、BigQuery Storage Read API を有効にすると、クエリ時間を短縮できます。データポータルでは、クエリの実行時間を短縮できる場合に、Storage Read API が自動的に使用されます。
BigQuery Storage Read API を有効にするには、データポータルに接続されている BigQuery ユーザーに次の権限を付与します。
bigquery.readsessions.createbigquery.readsessions.getData