mysql大テーブルのソリューション、およびHiveページングクエリー
まず直面した問題を話して、それから自分の解決策を出して、必ずしも最良の解決方法ではありませんが、現在確かに会社の大表データの問題を解決して、もし他の小さい仲間がもっと良い解決方法があれば、多く交流して、自分の解決方法を提供してください.
現在、すべてのデータとツールコンポーネントはテンセントクラウドに基づいて構築され、管理されています.まず、私たちが遭遇した状況を説明します.
1.mysqlテーブルのクエリーデータ量が大きい(最大のテーブルは33億個に達し、mysql全体が2.9 Tのデータストレージに達した).
2.mysql表は毎日の新規データ量が大きい(増量が最も大きい表、毎日の新規データ量が4千万本程度のデータ)
3.トランザクション操作をサポートする必要があり、一部のテーブルでは更新操作をサポートする必要があります.
4.ファジイ、ソート、グループ統計、ページングなどの複雑な操作をサポートします.
5.低遅延、ユーザーが選択したタスク条件クエリー、応答時間は3-5 sに制御すべきである.
6.リアルタイムデータの書き込みと照会操作は、現在、リアルタイムデータは10分ごとに処理され、約400 G程度のデータである.
私たちが出会ったことを上から簡単に見ることができます.
1.単表データ量が多く、フロント部分の業務の正常な操作をサポートできない;
2.一部の統計プログラムの書き込みはすでに上限(MySQLは毎日8万件のデータを書き込む)に達して、その他の任務が正常に実行できないことをもたらして、いつも明け方にスクリプトが起動した後に、時間通りにデータを処理することができなくて、その他の任務の圧迫をもたらします(注:すべてのオフラインとリアルタイムはspark処理、yarnリソーススケジューリングはFairポリシーを採用しており、現在テンセントクラウドはCapacityポリシーをサポートしていない).
私たちのmysqlテーブルについて、私たちが保存しているほとんどは統計データです.初期のデータ量が少なく、統計能力が限られているため、フロントとのインタラクションが頻繁であることを考慮して、リレーショナル・データベースに保存されているため、現在このような窮地に直面しています.データの増加量がますます大きくなっているため、変更しないことはできません.
デルの解決手順と方法:
1.まず、私たちが最初に考えたのは、ビジネスと結びつけて、前のユーザーの操作です.
2.表中のデータの検査と審査を行った後、ビッグデータの中でよく出会う2/8の法則を発見し、20%のユーザーが80%のデータを占めた.ライブラリとテーブル操作を考慮して、データ量の大きい一部のユーザーを他のサーバのデータベースに移行しますが、フロントエンドの可視化部門の作業圧力を増大させ、統計部門の統計プログラムをすべて調整して、異なるユーザーを区別する必要があります.
3.ビッグデータ技術を用いて解決し、オフラインデータをすべてHiveに移行し、日単位でパーティション管理し、prestoを用いて複雑なクエリーを行い、リアルタイムデータを保持し、mysqlに引き続き書き込み、更新操作のあるテーブルに対して、直接Hbaseに書き込み、phoenix処理を用いる.
データを移行する過程で、私たちが最初に使用したのはsqoopがmysqlデータをHive、ダイナミックパーティションに導いたのですが、sparkがMysqlに書き込む性能の問題を解決できないため、sparkを様々に最適化し、データの処理時間を5分程度に抑えましたが、mysqlを書くのに1時間近くかかることがよくあります.そこで直接オフライン統計をすべて直接HDFSに書き込み,現在では基本的に分析と書き込み時間は10分程度である.データ押出の問題も解決した.
最後に問題は解決しました.現在、springbootを使用してクエリーを行い、2つの部分に分けて処理しています.
a.ユーザーは履歴データ(昨日、最近1週間または最近1ヶ月、および任意の時間帯区間を指定し、今日を除く)の操作に対してpresto操作を採用した.
b.ユーザーは今日のリアルタイム操作を照会して、私たちは直接mysqlの中のデータを読み取って、現在単表のデータ量は最大で千万級なので、msyqlは完全に支持することができて、その上性能は悪くありません.ユーザーが長時間指定したクエリーに対して、リアルタイムの今日のデータ操作を含む場合、presto+mysqlは同時に分析処理を行い、プログラムを通じてデータを最後に統一的に統合し、ページ分け、ソートし、これは現在も最適化されており、正確性が許容できる範囲内に達しています.
以上が私たちの解決策で、PHPスタッフが直接私たちのインタフェースを呼び出しました.底辺で使われている技術に関心を持つ必要はありません(もちろん、この解決策は現在のビジネスシーンの解決策に基づいているだけで、必ずしも最適な解決策ではありませんが、現在は大量のデータが殺到した場合、一定のバッファ時間を提供しています)を統計し、可視化と下位データを剥がし、現在の方法がボトルネックに達した場合、再び性能の要求を満たすことができなくなり、後で使用を検討します.その他の技術処理は、最も主要なのは今回の調整が会社の経済支出を下げ、受動的に資源配置をアップグレードする必要がないことだ.
最後に、主にrow_に使用されるHiveでページングされたクエリー操作を示します.numberとbetween,and.
現在、すべてのデータとツールコンポーネントはテンセントクラウドに基づいて構築され、管理されています.まず、私たちが遭遇した状況を説明します.
1.mysqlテーブルのクエリーデータ量が大きい(最大のテーブルは33億個に達し、mysql全体が2.9 Tのデータストレージに達した).
2.mysql表は毎日の新規データ量が大きい(増量が最も大きい表、毎日の新規データ量が4千万本程度のデータ)
3.トランザクション操作をサポートする必要があり、一部のテーブルでは更新操作をサポートする必要があります.
4.ファジイ、ソート、グループ統計、ページングなどの複雑な操作をサポートします.
5.低遅延、ユーザーが選択したタスク条件クエリー、応答時間は3-5 sに制御すべきである.
6.リアルタイムデータの書き込みと照会操作は、現在、リアルタイムデータは10分ごとに処理され、約400 G程度のデータである.
私たちが出会ったことを上から簡単に見ることができます.
1.単表データ量が多く、フロント部分の業務の正常な操作をサポートできない;
2.一部の統計プログラムの書き込みはすでに上限(MySQLは毎日8万件のデータを書き込む)に達して、その他の任務が正常に実行できないことをもたらして、いつも明け方にスクリプトが起動した後に、時間通りにデータを処理することができなくて、その他の任務の圧迫をもたらします(注:すべてのオフラインとリアルタイムはspark処理、yarnリソーススケジューリングはFairポリシーを採用しており、現在テンセントクラウドはCapacityポリシーをサポートしていない).
私たちのmysqlテーブルについて、私たちが保存しているほとんどは統計データです.初期のデータ量が少なく、統計能力が限られているため、フロントとのインタラクションが頻繁であることを考慮して、リレーショナル・データベースに保存されているため、現在このような窮地に直面しています.データの増加量がますます大きくなっているため、変更しないことはできません.
デルの解決手順と方法:
1.まず、私たちが最初に考えたのは、ビジネスと結びつけて、前のユーザーの操作です.
2.表中のデータの検査と審査を行った後、ビッグデータの中でよく出会う2/8の法則を発見し、20%のユーザーが80%のデータを占めた.ライブラリとテーブル操作を考慮して、データ量の大きい一部のユーザーを他のサーバのデータベースに移行しますが、フロントエンドの可視化部門の作業圧力を増大させ、統計部門の統計プログラムをすべて調整して、異なるユーザーを区別する必要があります.
3.ビッグデータ技術を用いて解決し、オフラインデータをすべてHiveに移行し、日単位でパーティション管理し、prestoを用いて複雑なクエリーを行い、リアルタイムデータを保持し、mysqlに引き続き書き込み、更新操作のあるテーブルに対して、直接Hbaseに書き込み、phoenix処理を用いる.
データを移行する過程で、私たちが最初に使用したのはsqoopがmysqlデータをHive、ダイナミックパーティションに導いたのですが、sparkがMysqlに書き込む性能の問題を解決できないため、sparkを様々に最適化し、データの処理時間を5分程度に抑えましたが、mysqlを書くのに1時間近くかかることがよくあります.そこで直接オフライン統計をすべて直接HDFSに書き込み,現在では基本的に分析と書き込み時間は10分程度である.データ押出の問題も解決した.
最後に問題は解決しました.現在、springbootを使用してクエリーを行い、2つの部分に分けて処理しています.
a.ユーザーは履歴データ(昨日、最近1週間または最近1ヶ月、および任意の時間帯区間を指定し、今日を除く)の操作に対してpresto操作を採用した.
b.ユーザーは今日のリアルタイム操作を照会して、私たちは直接mysqlの中のデータを読み取って、現在単表のデータ量は最大で千万級なので、msyqlは完全に支持することができて、その上性能は悪くありません.ユーザーが長時間指定したクエリーに対して、リアルタイムの今日のデータ操作を含む場合、presto+mysqlは同時に分析処理を行い、プログラムを通じてデータを最後に統一的に統合し、ページ分け、ソートし、これは現在も最適化されており、正確性が許容できる範囲内に達しています.
以上が私たちの解決策で、PHPスタッフが直接私たちのインタフェースを呼び出しました.底辺で使われている技術に関心を持つ必要はありません(もちろん、この解決策は現在のビジネスシーンの解決策に基づいているだけで、必ずしも最適な解決策ではありませんが、現在は大量のデータが殺到した場合、一定のバッファ時間を提供しています)を統計し、可視化と下位データを剥がし、現在の方法がボトルネックに達した場合、再び性能の要求を満たすことができなくなり、後で使用を検討します.その他の技術処理は、最も主要なのは今回の調整が会社の経済支出を下げ、受動的に資源配置をアップグレードする必要がないことだ.
最後に、主にrow_に使用されるHiveでページングされたクエリー操作を示します.numberとbetween,and.
select c.*
from(
select row_number() over (order by b.ev_paras_value ASC ) as sort_field, b.*
from (
select a.app_key, a.event_key, a.ev_paras_value, a.paras_uv, a.paras_count
FROM (
select app_key, event_key, ev_paras_value,
sum(ev_paras_uv) as paras_uv,
sum(ev_paras_count) as paras_count
FROM aldstat_event_paras_partition
where 1=1
AND day_time in ('2018-08-01')
AND app_key='xxxxxxxxxx'
AND event_key='bbbbbbbb'
AND ev_paras_name like '%name%'
GROUP BY app_key, event_key, ev_paras_value) a
order by a.ev_paras_value ASC ) b ) c
where c.sort_field between 1 and 30