49

約 70 GB の InnoDB データベースがあり、今後 2 ～ 3 年で数百 GB に拡大すると予想しています。データの約 60% が 1 つのテーブルに属しています。現在、64 GB の RAM を備えたサーバーを使用しているため、データベースは非常にうまく機能しているため、データベース全体がほぼメモリに収まりますが、データ量がかなり大きくなる将来が心配です。現在、テーブル (特にデータの大部分を占めるテーブル) を分割する何らかの方法を検討しており、どのように行うのが最善の方法であるかを考えています。

私が現在知っているオプションは

  • バージョン 5.1 に付属する MySQL Partitioning の使用
  • データのパーティショニングをカプセル化するある種のサードパーティ ライブラリを使用する (休止状態のシャードなど)
  • アプリケーション内に自分で実装する

私たちのアプリケーションは、J2EE と EJB 2.1 で構築されています (いつか EJB 3 に切り替えたいと思っています)。

何を提案しますか？

編集 (2011-02-11):
更新情報: 現在、データベースのサイズは 380 GB、「大きな」テーブルのデータ サイズは 220 GB、インデックスのサイズは 36 GB です。したがって、テーブル全体がメモリに収まらなくなりますが、インデックスはメモリに収まります。
システムはまだ (同じハードウェア上で) 正常に動作しており、データのパーティション化についてまだ検討中です。

編集 (2014-06-04): もう 1 つの更新: データベース全体のサイズは 1.5 TB で、「大きな」テーブルのサイズは 1.1 TB です。サーバーを 128 GB RAM の 4 プロセッサ マシン (Intel Xeon E7450) にアップグレードしました。システムはまだ正常に動作しています。次に計画しているのは、大きなテーブルを別のデータベース サーバーに配置することです (ソフトウェアで必要な変更を既に行っています) と同時に、256 GB RAM を備えた新しいハードウェアにアップグレードします。

このセットアップは 2 年間続くことになっています。その後、最終的にシャーディング ソリューションの実装を開始するか、1 TB の RAM を搭載したサーバーを購入する必要があります。

編集 (2016-01-18):

それ以来、大きなテーブルを別のサーバー上の独自のデータベースに配置しました。現在、このデータベースのサイズは約 1.9 TB で、他のデータベース (「大きな」テーブルを除くすべてのテーブルを含む) のサイズは 1.1 TB です。

現在のハードウェア設定:

  • HP ProLiant DL 580
  • 4 x Intel(R) Xeon(R) CPU E7- 4830
  • 256GBのRAM

この設定でパフォーマンスは問題ありません。

4

8 に答える 8

25

42 GB のテーブルがメモリに収まらなくなると、間違いなく問題が発生し始めます。実際、メモリに収まらなくなるとすぐに、パフォーマンスが急速に低下します。テストする 1 つの方法は、そのテーブルを RAM の少ない別のマシンに置き、パフォーマンスがどの程度低いかを確認することです。

まず第一に、いくつかのテーブルを別の物理ボリュームに移動しない限り、テーブルを分割しても問題はありません。

これは正しくありません。パーティショニング (MySQL 5.1 の機能、または MERGE テーブルを使用した同じことによる) は、テーブルが同じドライブ上にある場合でも、パフォーマンスを大幅に向上させることができます。

例として、日付範囲を使用して大きなテーブルで SELECT クエリを実行しているとします。テーブル全体の場合、クエリはテーブル全体をスキャンするよう強制されます (そのサイズでは、インデックスを使用しても遅くなる可能性があります)。パーティショニングの利点は、絶対に必要なパーティションでのみクエリが実行されることです。各パーティションのサイズが 1 GB で、クエリがそれ自体を満たすために 5 つのパーティションにアクセスするだけでよい場合、結合された 5 GB のテーブルは、MySQL が処理するのがモンスターの 42 GB バージョンよりもはるかに簡単です。

自問する必要があることの 1 つは、データのクエリ方法です。クエリが特定のデータ チャンク (つまり、日付範囲または ID 範囲) にのみアクセスする必要がある場合は、何らかのパーティショニングが有効です。

特に MySQL が正しいキーを選択することに関連して、MySQL 5.1 のパーティショニングにはまだバグがあると聞きました。MERGE テーブルは同じ機能を提供できますが、必要なオーバーヘッドはわずかに多くなります。

お役に立てば幸いです...頑張ってください！

于 2008-09-25T13:58:57.003 に答える
9

IO /メモリバウンドになると思うなら、パーティショニングは役に立たないと思います。いつものように、最初にベンチマークを行うと、最善の方向性を見つけるのに役立ちます。64GBのメモリを搭載した予備のサーバーがない場合は、いつでもベンダーに「デモユニット」を依頼できます。

1つのクエリ集計レポートを期待しない場合は、シャーディングに傾倒します。大きなテーブルだけでなく、データベース全体をシャーディングすると想定しています。エンティティ全体をまとめておくのが最善です。とにかく、モデルがうまく分割されれば。

于 2008-09-05T15:00:05.877 に答える
6

これは、MySql パーティショニングが巨大なデータ フローの実際の例で何ができるかを示す良い例です。

http://web.archive.org/web/20101125025320/http://www.tritux.com/blog/2010/11/19/partitioning-mysql-database-with-high-load-solutions/11/1

あなたのケースに役立つことを願っています。

于 2010-11-21T21:51:54.767 に答える
1

少し前に Microsoft ArcReady イベントで、スケーリング パターンに関するプレゼンテーションを見ました。役に立つかもしれません。そのスライドをオンラインで見ることができます。

于 2008-09-05T14:33:17.423 に答える
1

MariaDB InnoDB + パーティション (クエリに応じて、キーまたは日付のいずれか) を使用します。

私はこれを行いましたが、データベースの問題はもうありません。

MySQL は数秒で MariaDB に置き換えることができます...すべてのデータベース ファイルは同じままです。

于 2011-10-11T10:30:05.327 に答える
0

大きなテーブルは何をしますか。

分割する場合は、いくつかのオプションがあります。
- データベース システムを使用して分割します (それについてはよくわかりません)
。 - 行ごとに分割します。
- 列ごとに分割します。

データをチャンクに簡単に分割できる場合にのみ、行ごとに分割できます。たとえば、Basecampのようなものには、完全に別の複数のアカウントがあります。アカウントの 50% を 1 つのテーブルに保持し、50% を別のマシンの別のテーブルに保持できます。

列による分割は、行サイズに大きなテキスト フィールドまたは BLOB が含まれる場合に適しています。(たとえば) ユーザー画像と巨大なテキスト ブロックを含むテーブルがある場合、その画像をまったく別のテーブルにまとめることができます。(別のマシンで)

ここで正規化を破りますが、それほど多くの問題を引き起こすとは思いません。

于 2008-09-05T14:35:53.300 に答える
0

まず第一に、いくつかのテーブルを別の物理ボリュームに移動しない限り、テーブルを分割しても問題はありません。

第 2 に、必ずしも物理サイズが最大のテーブルを移動する必要はありません。大きなテーブルはかなり一定のままであるか、データを追加するだけですが、より多くのアクティビティを取得するはるかに小さなテーブルがある場合があります。

何をするにしても、自分で実装しないでください。データベースシステムに処理させてください。

于 2008-09-05T14:15:14.643 に答える
0

最終的には、その大きなテーブルを分割したいと思うでしょう。2 台目のサーバーを検討する前に、別のハード ディスクに配置することをお勧めします。MySQL を使用するのが最も便利なオプションです。それが可能であれば、それを行ってください。

しかし

すべては、データベースがどのように使用されているかによって異なります。統計学。

于 2008-09-22T20:59:37.080 に答える