web-dev-qa-db-ja.com

非常に大きなMySQLデータベースの処理

長い投稿でごめんなさい!

〜30個のテーブル(InnoDBエンジン)を含むデータベースがあります。これらのテーブルの2つ、つまり「トランザクション」と「シフト」だけが非常に大きい(最初のテーブルには150万行、シフトには23k行)。これですべてが正常に動作し、現在のデータベースサイズに問題はありません。

ただし、同様のデータベース(同じデータ型、設計、...)がありますが、はるかに大きくなります。たとえば、「トランザクション」テーブルには約10億のレコード(1日に約2,300万トランザクション)そして、MySQLでこのような大量のデータをどのように処理すべきかを考えていますか? (読み取りと書き込みの両方が集中します)。 Mysql(より具体的にはInnoDBエンジン)が何十億ものレコードでうまく機能するかどうかを確認するために、関連する投稿をたくさん読みましたが、それでもいくつか質問があります。私が読んだ関連記事の一部を以下に示します。

非常に大きなテーブルのパフォーマンスを向上させるためにこれまでに理解したこと:

  1. (私の場合はinnoDBテーブルの場合)innodb_buffer_pool_sizeを増やします(RAMの最大80%など)。また、他のMySQLパフォーマンスチューニング設定 ここではperconaブログ も見つけました。
  2. テーブルに適切なインデックスがある(クエリでEXPLANを使用)
  3. テーブルの分割
  4. MySQLシャーディングまたはクラスタリング

ここに私の質問/混乱があります:

  • パーティショニングについては、使用すべきかどうか疑問があります。一方で、多くの人々は、テーブルが非常に大きい場合にパフォーマンスを改善することを提案しました。一方、クエリのパフォーマンスが向上せず、クエリの実行が速くならない( herehere など)との記事をたくさん読んだことがあります。また、私は MySQLリファレンスマニュアル を読みましたInnoDB外部キーとMySQLパーティションは互換性がありません(外部キーがあります)。

  • インデックスに関しては、現在、それらはうまく機能しますが、私が理解している限り、非常に大きなテーブルの場合、インデックス付けはより制限的です(Kevin Bedellが彼の回答で述べたように here )。また、インデックスは読み取りを高速化し、書き込みを遅くします(挿入/更新)。それで、この大きなDBを持つ新しい類似プロジェクトでは、最初にすべてのデータを挿入/ロードしてから、インデックスを作成する必要がありますか? (挿入を高速化するため)

  • 大きなテーブル( "トランザクション"テーブル)にパーティショニングを使用できない場合、パフォーマンスを改善するための代替オプションは何ですか? (innodb_buffer_pool_sizeなどのMySQl変数設定を除く)。 Mysqlクラスターを使用する必要がありますか? (結合もたくさんあります)

御時間ありがとうございます、

2
monamona

Re:パーティショニング:

これは、大規模なデータセットを処理するための最善の方法です。セット全体の1つのインデックスではなく、複数のインデックスを異なる範囲で実行できるようにすることで、個々のインデックスの品質がはるかに高くなります。

参照整合性自体を維持するようにアプリケーションを構成できる場合は、外部キーを安全に削除できます。親行が更新されるたびに、子テーブルで参照される行が適切に更新されるようにする必要があります。データベースはもはやそれを台無しにすることを妨げなくなり、カスケード操作はもう利用できなくなります。したがって、それをアプリケーションにプログラムする必要があります。自動的に実行するトリガーを作成すると役立ちます。

Re:インデックス作成:

深さが深すぎると、Bツリーインデックスのパフォーマンスが低下します。リンクした投稿には、良い情報が含まれています。例えばインデックスなしで列にアクセスしようとすることさえ忘れてください。

書き込みの場合、コンテンツを定期的にロードする場合は、一括挿入する前にインデックスを削除し、後でインデックスを再作成するのが理にかなっています。これは、テーブルとインデックスの両方への順次の個別の挿入よりも高速になる可能性があります。すべてのデータを新しいパーティションに挿入し、後でインデックスを作成できるため、パーティショニングによりこれが容易になります。

再:代替オプション

より良いデータベースを使用してください。 ;-)データベースがこの規模に成長すると、MySQLの制限を実際に感じるようになります。他のDBMSは、このスコープのデータを処理するためのはるかに優れたツールセットを提供しています。予算、ユースケース、制約に依存するデータベース。 MySQLは「十分に良い」かもしれませんが、飛び込む前に代替案を確実に評価する必要があります。

Re:クラスタリング

クラスタリングは状況によってはより良い場合もあれば、より悪い場合もあります。例えばデータをシャーディングすることができますが、シャーディングは水平分割にすぎないため、外部キーに対して同じ制限があります。クラスターを維持すると、特に書き込み集中型のアプリケーションでは、多くのオーバーヘッドが発生する可能性があります。

2
Andrew Brennan