シャーディング - Java バックエンド コードの実装と、データベース シャーディングとテーブル切断後のベスト プラクティス

Question

現在のビジネスでは、一部のテーブルがますます大きくなっているため、読み取り時の負荷が非常に高くなります(書き込みの需要が比較的小さい)。そのため、データベース側で、特に量が大きいテーブルをいくつかカットすることにしました。大量のデータがバックエンド コードに含まれている これらのテーブルに結合する必要があるコードやクエリが多数あります。この状況をどのように解決しますか?

たとえば、約 1 億個のデータを含む SampleTable があります。これをロジックに基づいて約 16 の異なるテーブルに分割しました: SampleTable 1、SampleTable2...SampleTable31、
前のコードは次のようなものでした:

リーリー

このクエリを複数回実行し、返された結果としてデータを集計する必要がありますか?

リーリー

より良い方法やライブラリの推奨事項はありますか? 実践的な方法やサンプル コードはありますか?

後で複数のテーブルを異なるデータベース サーバーに分割したい場合、バックエンド コードで異なる DB へのデータベース接続を追加する必要がありますか?

データベース シャーディングの基本的な考え方とシャーディング戦略
この記事はデータベース シャーディングの戦略について詳しく説明しています。実際のプロジェクト コード サンプルを提供できる人はいますか?
データベース シャーディングと JPA
何をすべきか-SQL 結合の代わりに、水平方向にスケーリングしながら

スタックオーバーフローに関するいくつかの回答

Answer 1

データベースミドルウェアの導入を検討できます
sharding-jdbcクライアントレベル
mycat-serverサーバーレベル

Answer 2

友人は、SQL スタイルのクエリをサポートし、1 億個のデータに対して約 0.5 秒で結果を返す Spark を勧めました

Answer 3

プロジェクトの現在の状況のみ: テーブルを分割するとき、ハッシュ アルゴリズムに従って特定のテーブルに分類され、フェッチするときに、まずアルゴリズムに従ってデータの分布位置を取得し、その後通常の選択が行われます。完了しました

Answer 4

テーブル結合クエリは推奨されません
1. データベース リソースは比較的貴重であり、テーブル結合クエリは多くのメモリを占有するため、データベースのパフォーマンスが低下します
2. データは複数のデータベース インスタンスでサポートされておらず、サブデータベースを扱えず、拡張性も悪い

一般的なアプローチは、結合テーブル クエリを複数の単一テーブル クエリに分割し、アプリケーションで結果を要約することです。
1. テーブルクエリの結合に関する上記の問題を解決できます。
2. 複数のクエリの場合、各クエリの中間結果もプログラム内で処理できるため、柔軟性が高まります。
3. アプリケーションはいつでも拡張できるため、より柔軟になります

オフライン シナリオの場合は、Hadoop などの MR (mapreduce) フレームワークを使用して処理することをお勧めします。したがって、データは HDFS に書き込まれる必要があります。

Answer 5

http://blog.csdn.net/tianyale...
サブデータベースとテーブルの詳細説明