現在のビジネスでは、一部のテーブルがますます大きくなっているため、読み取り時の負荷が非常に高くなります(書き込みの需要が比較的小さい)。そのため、データベース側で、特に量が大きいテーブルをいくつかカットすることにしました。大量のデータがバックエンド コードに含まれている これらのテーブルに結合する必要があるコードやクエリが多数あります。この状況をどのように解決しますか?
たとえば、約 1 億個のデータを含む SampleTable があります。これをロジックに基づいて約 16 の異なるテーブルに分割しました: SampleTable 1、SampleTable2...SampleTable31、
前のコードは次のようなものでした:
このクエリを複数回実行し、返された結果としてデータを集計する必要がありますか?
リーリーより良い方法やライブラリの推奨事項はありますか? 実践的な方法やサンプル コードはありますか?
後で複数のテーブルを異なるデータベース サーバーに分割したい場合、バックエンド コードで異なる DB へのデータベース接続を追加する必要がありますか?
データベース シャーディングの基本的な考え方とシャーディング戦略
この記事はデータベース シャーディングの戦略について詳しく説明しています。実際のプロジェクト コード サンプルを提供できる人はいますか?
データベース シャーディングと JPA
何をすべきか-SQL 結合の代わりに、水平方向にスケーリングしながら
スタックオーバーフローに関するいくつかの回答
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
データベースミドルウェアの導入を検討できます
sharding-jdbcクライアントレベル
mycat-serverサーバーレベル
友人は、SQL スタイルのクエリをサポートし、1 億個のデータに対して約 0.5 秒で結果を返す Spark を勧めました
プロジェクトの現在の状況のみ: テーブルを分割するとき、ハッシュ アルゴリズムに従って特定のテーブルに分類され、フェッチするときに、まずアルゴリズムに従ってデータの分布位置を取得し、その後通常の選択が行われます。完了しました
テーブル結合クエリは推奨されません
1. データベース リソースは比較的貴重であり、テーブル結合クエリは多くのメモリを占有するため、データベースのパフォーマンスが低下します
2. データは複数のデータベース インスタンスでサポートされておらず、サブデータベースを扱えず、拡張性も悪い
一般的なアプローチは、結合テーブル クエリを複数の単一テーブル クエリに分割し、アプリケーションで結果を要約することです。
1. テーブルクエリの結合に関する上記の問題を解決できます。
2. 複数のクエリの場合、各クエリの中間結果もプログラム内で処理できるため、柔軟性が高まります。
3. アプリケーションはいつでも拡張できるため、より柔軟になります
オフライン シナリオの場合は、Hadoop などの MR (mapreduce) フレームワークを使用して処理することをお勧めします。したがって、データは HDFS に書き込まれる必要があります。
http://blog.csdn.net/tianyale...
サブデータベースとテーブルの詳細説明