MySQLデータベースは、どの程度の大きさになるとパフォーマンスが低下するのか？

データベースの物理的なサイズは重要ではありません。 レコード数は重要ではありません。

私の経験では、最も大きな問題はサイズではなく、一度に処理できるクエリの数です。 ほとんどの場合、マスター/スレーブ構成に移行して、読み込みクエリーはスレーブに対して実行し、書き込みクエリーはマスターに対して実行する必要があります。 しかし、まだその準備ができていない場合は、実行中のクエリに対してインデックスを調整することで、応答時間を短縮することができます。 また、Linuxのネットワークスタックやカーネルに手を加えることで、より効果的になります。

私の場合は、適度な接続数で10GBまで上げたことがありますが、問題なくリクエストを処理できました。

まずインデックスに注目し、次にサーバー管理者にOSを調べてもらい、それでも解決しない場合は、マスター/スレーブ構成を導入する時期かもしれませんね。

一般的にこれは非常に微妙な問題であり、何ら些細なことではありません。mysqlperformanceblog.com]1 と High Performance MySQL を読むことをお勧めします。私は本当にこれに対する一般的な答えはないと思っています。

私は、1TB近いデータを持つMySQLデータベースを持つプロジェクトに携わっています。スケーラビリティの要因として最も重要なのはRAMです。テーブルのインデックスがメモリに収まり、クエリが高度に最適化されていれば、平均的なマシンでそれなりの量のリクエストに対応することができます。

テーブルの形によっては、レコード数は重要です。varcharフィールドが多いか、intやlongが少ないかの違いです。

データベースの物理的なサイズも重要です：例えば、バックアップを考えてみてください。エンジンによっては、例えばinnodbのように、データベースの物理ファイルが大きくなることはあっても、小さくなることはない。つまり、多くの行を削除しても、物理的なファイルを縮小することはできないのです。

この問題には多くのことがあり、多くの場合、悪魔は細部に宿るものです。

データベースサイズは重要です。 100万を超えるレコードを持つ複数のテーブルがある場合、パフォーマンスは確かに低下し始めます。 もちろん、レコード数はパフォーマンスに影響します。大きなテーブルではMySQLが遅くなる可能性があります。 100万件のレコードをヒットすると、インデックスが正しく設定されていないとパフォーマンスの問題が発生します(たとえば、「WHEREステートメント」または「ON条件」のフィールドのインデックスが結合されていません)。 1,000万件のレコードをヒットすると、すべてのインデックスが正しくても、パフォーマンスの問題が発生し始めます。 ハードウェアのアップグレード-より多くのメモリとより多くのプロセッサーパワー、特にメモリを追加-は、少なくともある程度までパフォーマンスを再度向上させることにより、最も深刻な問題の削減に役立ちます。 たとえば、Basecampデータベースサーバーでは、37信号が32 GB RAMから128 GBのRAMに移行しました。

サーバー管理者にOSを見てもらうよりも、まずインデックスに焦点を当てます。それが役に立たない場合は、マスター/スレーブ構成の時間かもしれません。

それは本当だ。 通常機能するもう1つのことは、繰り返し処理されるデータの量を減らすことです。 「古いデータ」と「新しいデータ」があり、クエリの99%が新しいデータで機能する場合は、古いデータをすべて別のテーブルに移動してください。見ないでください;)。

-> パーティションをご覧ください。

2GBと約15Mレコードは非常に小さなデータベースです-私はペンティウムIIIではるかに大きなレコードを実行しました(。!)そして、すべてがまだかなり速く実行されています。. 遅い場合は、データベース/アプリケーション設計の問題であり、mysqlの問題ではありません。

「データベースのパフォーマンス」、「クエリパフォーマンス」について話すのは、ここでは良い用語です。 そして答えは、クエリ、操作するデータ、インデックス、ハードウェアなどに依存します。 スキャンする行の数と、EXPLAIN構文で使用されるインデックスを把握できます。

2GBは実際には「大きな」データベースとしてカウントされません-それは中規模のものです。

私はかつて、「仕事をやめた」mysqlを見るように求められました。 DBファイルは、NFS2がマウントされ、最大ファイルサイズが2GBのネットワークアプライアンスフィラー上にあることがわかりました。そして確かに、トランザクションの受け入れを停止したテーブルは、ディスク上で正確に2GBでした。 しかし、パフォーマンスカーブに関しては、まったく機能しないまでは、チャンプのように機能していたと言われています。! この経験は常に、あなたが自然に疑うものの上下に常に次元があることを思い出させてくれます。

また、複雑な結合にも気をつけましょう。 トランザクションの複雑さは、トランザクション量に加えて大きな要因になり得ます。

重いクエリをリファクタリングすることで、パフォーマンスが大きく向上することがあります。

考慮すべき点は、システムの目的と日々のデータでもあります。

たとえば、車のGPS監視を備えたシステムの場合、前月の車の位置からの関連するクエリデータはありません。

したがって、データを他の履歴テーブルに渡して、可能なコンサルテーションを行い、日中のクエリの実行時間を短縮できます。

私は現在、AmazonのクラウドインフラストラクチャでMySQLデータベースを管理しており、160 GBに成長しています。クエリのパフォーマンスは良好です。 悪夢になっているのは、バックアップ、復元、スレーブの追加、またはデータセット全体、または大きなテーブルのDDLを扱うその他のことです。 ダンプファイルをきれいにインポートすることは問題になっています。 プロセスを自動化するのに十分安定させるためには、パフォーマンスよりも安定性を優先するために、さまざまな選択を行う必要がありました。 SQLバックアップを使用して災害から回復しなければならなかった場合、私たちは数日間ダウンします。

水平方向にSQLをスケーリングすることもかなり苦痛であり、ほとんどの場合、そもそもデータをSQLに配置することを選択したときに、おそらく意図していなかった方法でSQLを使用することになります。 シャード、スレーブ、マルチマスターなどを読むと、それらはすべてDBでこれまでに行ったことすべてに複雑さを追加する本当にくだらないソリューションであり、そのうちの1つが問題を解決するわけではありません。いくつかの方法でそれを軽減するだけです。 これらのタイプの問題が発生するサイズのデータセットに近づき始めるときは、MySQL(または実際には任意のSQL)からデータの一部を移動することを強くお勧めします。

データベースが適切に設計されていない場合、パフォーマンスは数千行で低下する可能性があります。

適切なインデックスがある場合は、適切なエンジンを使用し(複数のDMLが予想される場合はMyISAMを使用しないでください)、パーティション分割を使用し、使用に応じて正しいメモリを割り当てます。もちろん、サーバー構成が良好であれば、MySQLはテラバイトでもデータを処理できます。!

データベースのパフォーマンスを改善する方法は常にあります。

クエリと検証によって異なります。。

例えば。, 私は、その表の各薬物について15文字を超える一般的な名前を持つ列を持つ100 000の薬物のテーブルを使用しました。2つのテーブルの間で薬物の一般的な名前を比較するためにクエリを配置しました。クエリにはさらに数分かかります同じ。,薬物指数を使用して薬物を比較する場合。,ID列を使用します。 (上記のように。) ほんの数秒かかります。

データベースサイズは、バイトとテーブルの行数の点で重要です。 ライトデータベースとblobが入力したデータベースのパフォーマンスの大きな違いに気づくでしょう。 ディスク上のファイルに画像を保持し、データベースにファイル名のみを配置する代わりに、フィールドにバイナリ画像を配置したため、アプリケーションがスタックしました。 一方、多数の行を反復することは無料ではありません。

いいえ、それは本当に問題ではありません。 MySQLの速度は毎秒約700万行です。 したがって、かなりスケーリングできます。