リレーショナルデータベースからビッグデータへの移行

Question

現在、Googleアナリティクスを提供し、セッションのアクティビティ（クリック、ダウンロードなど）を提供するGoogle Cloud Platformでホストされているアプリケーションを持っており、ウェブ登録でウェブ活動を関連付けています。

現時点では、私たちはすべてのクリックとセッションのプロファイルデータをMySQLに保存し、SQLクエリを使用して集計レポートとユーザー別レポートを生成していますが、データ量が増加するにつれて、クエリの応答が低下し、ページの読み込み時間が遅くなります。

この問題を解決する方法を検討するにあたり、DataprocとDataflowやNoSQLソリューションのようなGoogle Cloud Platformで利用できるツールを検討しましたが、私たちが現在のソリューションをどのように適用できるかを理解するのは苦労しています。これらのソリューションのいずれか。

現在、私たちのデータスキーマの目安は次のとおりです。

User table 
- id 
- name 
- email 

Profile table (web browser/device) 
- id 
- user id 
- user agent string 

Session table 
- id 
- profile id 
- session string 

Action table 
- id 
- session id 
- action type 
- action details 
- timestamp 

を私の研究に基づいて、最善の解決策になるかの私の理解は、同様のNoSQLデータベースソリューションに格納するアクションデータになりますデータをDataProcやDataFlowなどのレポートに生成するソリューションにデータを供給するBigTable。しかし、私たちの現在のスキーマは、リレーショナル・データをNoSQLソリューションに移行すべきではないことを示しているので、現在のスキーマは非常にリレーショナルな構造であるため、NoSQLソリューションへの移行オプションを削除しているようです。

私の質問は、これらのツールを正しく適用する方法を理解したことですか？または、より良い解決策がありますか？ MySQLから離れることを検討する必要さえありますか？そうでない場合は、バックグラウンドでレポートデータを前処理/生成する可能性のあるソリューションはどのようなものがありますか？

Answer 1

sessionsとactionsテーブル値は更新されず、挿入のみと仮定します。最善の方法は、データベースを2つの部分に分けることです。 userとprofileテーブルのMySQL DBを維持し、actionsとsessionsにはBigQueryを使用してください。

次ている。この方法：

• はあなたが大幅にデータストレージのコストを削減します
• 両側（データ摂取および抽出）にしなければならない変化量を最小限に抑える
• クエリ時間が大幅に改善されます。あなたが知る前に、
• が大きく改善されます。大きなデータ領域に入り、BigQueryはその解決策にすぎません。

BigQueryが最適です。ただし、余分なリソースと時間がある場合は、NoSQL dbに格納してからDataFlowを使用してパイプラインジョブを実行し、分析データを抽出します。このデータはクエリ用にデータベースに保存する必要があります。

Answer 2

質問のカップル/解決策：

1. プロフィール！クエリーを最適化したり、最も頻繁なページの結果の一部をキャッシュすることで、処理の負荷を軽減できます。データベース設定、RAMなどの場合は
2. データベースのサイズはどれくらいですか？64GB未満であれば、データベースがRAMに収まるような大規模なサーバーにスケールアップすることは簡単に勝つことができます。
3. データはどのように使用されていますか？純粋に履歴データの場合は、クリック数をルックアップテーブルに減らすことができます（例： 1週間あたりのセッション数または1週間あたりのユーザー数。データを5分/時間単位で照合すると、生データをダウンロードしてローカルで処理することもできます。
4. あなたは非正規化することができます。ユーザーエージェント|セッション|アクションタイプ|詳細|タイムスタンプを1つの行に結合しますが、ストレージ要件とルックアップ時間が増加する可能性があります。
5. また、より多くの正規化も役立ちます。ユーザーエージェント文字列を独自のテーブルに分割すると、そのテーブルのデータ要件が低下し、処理速度が向上する可能性があります。
6. データがユーザーによって分割/分割される可能性があるので、別のオプションになる可能性があります。

一般的に、これらの質問を解決する最も速い方法は、特定のワークロード、妥当な量のRAMを搭載した開発マシンで、通常のリクエスト（またはランダムダッシュボード）をいくつ行うことができますか（またはサーバーをスピンアップしたり、別のテストデータベースを作成したりできます）。

また、リレーショナルデータベースによく慣れている場合は、スイッチングに若干のオーバーヘッドがあります（特に、エッジソリューションのブリード）。スイッチを切り替える前にコストがそのメリットよりも大きいかどうかを確かめる必要があります。一度に少しずつ切り替えることで、うまくいかない場合は元に戻すことができます。繰り返しますが、テストが役立ちます。

Answer 3

実際には、膨大な量のデータを保存しないでください。

それらが到着するようにする代わりに、要約を保存次に、データの（集計）チャンクをまとめたものです。

長所：おそらく10分の1ほどのディスク容量が必要

• 。
• レポートは、おそらく
• は、既存のRDBMSで行うことができ、10倍の速さです。

短所：

• あなたが別の集約を改造することはできません。 （OK、生のデータを保存してからやり直すことができますが、これはとにかく良いかもしれません）
• コードの複雑さが増します。要約表の

Discussion