データベースのSSDとHDD


42

MySQLサーバーを実行する新しいサーバーを購入しようとしています。この新しいサーバーは、メインマシンのスレーブになります。ただし、このサーバーは、「大量の読み取りと複雑なクエリ」のみのレポート専用になります。

現在、私はソリッドステートハードドライブへの投資を検討していますが、本当に価格に見合う価値があるのか​​疑問に思っていました。SSDとSATA 7200ハードドライブの違いは約1500ドルで、SSDのディスク容量は少なくなります。SSDに投資した場合、速度は顕著になりますか?

2(500GB SSD)を購入するよりも1500ドル安く4(500GB SATA 7200)を購入できます

アップグレードする価値があるかどうかを判断するのを手伝ってもらえますか?

もう一度言いたいのは、私は使用しquery_cacheていないため、大量のディスク読み取りがあることです。

このサーバーは32GBのRAMを搭載し、Ubuntu 12.04を実行します


データベースのギガバイト単位の大きさは?以下の回答のどれが最も正しいかは、データの量を理解することにかかっています。
ネイサンジョリー14

1
最終的にSSDを使用することになった場合は、Ubuntu 14.04の4月まで待つか、12.04でTRIMを手動で有効にすることができます。詳細については、この記事参照してください。
OSE 14

5
シリアルATA(SATA)はインターフェースです。SATA SSDがあり、SATAを使用しないハードディスクドライブ(HDD)があります。
デニス14

あなたのためにお金をmake

回答:


25

はい、大量の読み取りとSSDの報告は大きな違いをもたらします。7200 RPMのドライブでは、最低100倍のIOPSしか期待できませんが、最安値のSSDは最低でも5倍の速さです。優れたSSDを使用すると、20000 IOPS以上に達することができます。

また、SSDでのランダム書き込みは、ディスクが毎回移動する必要がないため、はるかに高速です。


4
良いSSDをどのように定義しますか?
マイク14

パフォーマンスとベンチマークがすべてです。私がしたいことは、あなたが購入しているSSDのモデルのベンチマークやレビューのためにグーグルです。それ以外は、en.wikipedia.org / wiki / IOPS#Examplesに非常に一般的な概要が記載されています。
nmad 14

20

ここで考慮する必要がある3つの要素があります。

  1. データベースのサイズ
  2. サーバーにあるメモリの量
  3. my.cnf構成、具体的には innodb_buffer_pool_size

場合は、使用可能なメモリ>データベースのサイズ、サーバーは、おそらくメモリ内のすべてのデータを維持することができるようになりますので、SSDはお金の無駄かもしれません。InnoDBバッファーはquery_cacheオプションとは関係ありません。

場合は、使用可能なメモリ<データベースのサイズは、クエリがディスクからデータを取得する必要がありますいる可能性があります。非常に複雑なクエリの場合、または多くのユーザーが一度にクエリを実行している場合、これはディスクに負荷をかけ始める可能性があります。

一般に、データベースは最も使用されているデータをメモリに保持します-データの80%がめったに使用されない場合、パフォーマンスを維持するためにデータベースの20%のみをメモリに保持する必要があります。

必要なメモリの正確な量はすぐにはわかりませんが、データベースが200GB以上でない限り、Up_Oneのアドバイスを受けて、SSDではなくメモリに余分なお金をかけることをお勧めします。

注意:データベースがMyISAMを使用している場合(これはで確認できますshow table status;)、InnoDBへの変更を検討してください。MyISAM key_buffer_cacheはインデックスブロックのみを保存しますが、InnoDBバッファープールはデータブロック全体を保存します。ほとんどの場合、InnoDBはより良いエンジンであることが証明されます。


データベースをメモリに配置するにはどうすればよいですか?それはその上に書き込み、すべての時間を持つことになりますが、それはまた、必要がありますので、サーバーは重いので、レポートの負荷を読んで、スレーブである
マイク・

テーブルがInnoDBで、InnoDBバッファープールが十分に大きい場合、MySQLはメモリ内のデータベースのキャッシュを自動的に管理し、最も頻繁に使用されるデータを常にメモリ内に保持しようとします。MySQLのドキュメントは、これがどのように機能するかについてかなり良い概要を提供します
ネイサンジョリー14

@NathanJollyは、データベース全体がメモリ内にある場合でも、データの保存時にハードディスクへの読み取りと書き込みが行われます+さまざまなサーバーの制限があります。たとえば、SQL Server Expressバージョンは1GBのメモリのみを使用するように制限されているため、最初の段階ではメモリ内の大きなデータベースに対応できません。
ジャックフォール

@Jackofallは確かにそうですが、ここでの質問は読み取りが多いMySQLデータベースを指定しました。ディスクに到達するのではなく、メモリから提供できる読み取り専用クエリはすべて、高速ディスクであっても朗報です。
ネイサンジョリー

6

私はそんなに良い考えだとは思わない!
私のアドバイス
は、MySQLを高速化する最良の方法であるInnoDBバッファープールのサイズを増やすことです。RAMを追加できる場合は、追加してください。これにより、ほとんどのホットデータがメモリに格納されるので、想像してみてください。ディスクvsメモリ!
完璧なシナリオは、データベース
SSDのサイズを記憶させることです。すばらしいですが、高価になります。そして、それは読み取り集中型のジョブにのみ適しています。

Vadim Tkachenkoからのこれに関する素晴らしい記事については、このリンクをチェックしてください


1
リンクしている記事はほぼ4年前のものであり、SSDの価格はその時点と比較して半分以下であり、パフォーマンスも大幅に向上しています。データベースのサイズのメモリ?500Gbデータベースについてはどうですか?RAMの量だけでなく、購入する必要があるサーバーでもあり、非常に多くのメモリバンクが利用可能です。
ヤロスラフ14

DBサイズについて!はい、できません-しかし、私が言ったように、これは完璧なシナリオです!
Up_One 14

6

別の方法として、データを保持するために大きなハードディスク(理想的には3つのディスクを持つRAID1)と、インデックスを保持するために小さなSSDの両方を使用できます。

根拠:

  • インデックスはかなり小さいため、より小さいSSDを使用できます
  • とにかく一般的なクエリは主にインデックスにヒットするはずです
  • RAID1は耐障害性を提供​​します
  • RAID1は、ランダム読み取りの負荷分散を提供します
  • ディスクに障害が発生した場合、3つのディスクがフォールトトレランスを維持します
  • SSDに障害が発生した場合、インデックスを再構築できます

5

やれ。

読み取りが多いワークロードがあると述べたので、データベースでのSSDの使用に関する大きな問題である摩耗を既に回避しています。書き込みなしは摩耗なしを意味するので、あなたは黄金です。

edvinas.meが述べたように、SSDを使用するIOPSは、回転するディスクを使用するよりも桁違いに高速です。データベースの場合、IOPSはほぼ1秒あたりの要求に変換されます。RAMキャッシュを無視すると、7200RPMディスクからのリクエストよりもSSDからのリクエストの約100倍になります。

TRIMは読み取りが多いワークロードであるため、大きな違いはありません。とにかくディスクをいっぱいにする予定があるように聞こえます。それについて強調しないでください。

$ 1500のものがどこから来たのかわかりません。地元(オーストラリア)のサプライヤーを確認すると、960GBの評判の良いメーカーのSSDを750ドルで入手できます(http://www.auspcmarket.com.au/960gb-crucial-m500-sata-6gbps-2-5-7mm-with- 9-5mm-adapter-ssd-read-500mb-s-write-400mb-s /)。回転ディスクは多かれ少なかれ無料ですが、750ドルは1500ドルよりもはるかに魅力的です。

(ああ、待ってください-あなたはおそらく大手サプライヤーから注文しているので、彼らはSSDの鼻からあなたに請求していますか?私は常にSSDを別々に購入して自分で交換しますが、それが環境で許容されます。)

RAMも少なくて済む可能性がありますが、正確なワークロードを知らないと、パフォーマンスを損なうことなくRAMを安全に削減できるかどうかを判断することは困難です。

それでもよくわからない場合は、10k RPMの大きなドライブを入手できますが、SSDと同じくらいの費用がかかりますが、速度はずっと遅くなります。

1TBをはるかに超えて拡張する必要がある場合、SSDは高価になり始めますが、1TBではSSDが明らかな勝利だと思います。


3

コストの最大の価値はinnodb_db_bufferpoolのサイズを増やすことであることは間違いありませんが、残念なことに、データセットの大きさと異なるディスクブロックにアクセスする頻度に完全に依存します。私はかなり大きな200 GB +のデータベースをいくつか管理しているので、すべてをRAMに収めることは実際には選択肢ではないため、最近SSDベースのストレージに切り替えました。私がアクセスできるさまざまなRAIDアレイでMySQLを使用するためのIOPSに関して、かなり大きな研究を行ってきました。結果は次のとおりです。

1,253 IOPS-4 x SCSI 15k(3.5 ")ディスク

テスト:(g = 0):rw = randrw、bs = 4K-4K / 4K-4K / 4K-4K、ioengine = libaio、iodepth = 64 read:io = 3071.7MB、bw = 5012.8KB / s、iops = 1253 、runt = 627475msec書き込み:io = 1024.4MB、bw = 1671.7KB / s、iops = 417、runt = 627475msec cpu:usr = 0.63%、sys = 3.11%、ctx = 985926、majf = 0、minf = 22

2,558 IOPS-8 x 10K RPM 900GB SAS(2.5 ")ディスク

テスト:(g = 0):rw = randrw、bs = 4K-4K / 4K-4K / 4K-4K、ioengine = libaio、iodepth = 64 read:io = 3071.7MB、bw = 10236KB / s、iops = 2558、 runt = 307293msec書き込み:io = 1024.4MB、bw = 3413.5KB / s、iops = 853、runt = 307293msec cpu:usr = 2.73%、sys = 8.72%、ctx = 904875、majf = 0、minf = 25

23,456 IOPS-Rackspace Performance 2 SSDサーバー

テスト:(g = 0):rw = randrw、bs = 4K-4K / 4K-4K / 4K-4K、ioengine = libaio、iodepth = 64 read:io = 3071.7MB、bw = 93708KB / s、iops = 23426、 runt = 33566msec書き込み:io = 1024.4MB、bw = 31249KB / s、iops = 7812、runt = 33566msec cpu:usr = 5.73%、sys = 35.83%、ctx = 181568、majf = 0、minf = 23

35,484 IOPS-2 xミラーリングEDGE Boost 480GB 2.5 "MLC(http://www.edgememory.com

テスト:(g = 0):rw = randrw、bs = 4K-4K / 4K-4K / 4K-4K、ioengine = libaio、iodepth = 64 read:io = 3068.4MB、bw = 141934KB / s、iops = 35483、 runt = 22137msec書き込み:io = 1027.7MB、bw = 47537KB / s、iops = 11884、runt = 22137msec cpu:usr = 11.68%、sys = 69.89%、ctx = 24379、majf = 0、minf = 20

したがって、今日の高品質のSSDが驚くべきパフォーマンスを発揮することは明らかです。2つのミラー化されたSSDは、16ディスクSANストレージエンクロージャよりも簡単に優れた性能を発揮します。

完全な詳細に興味がある場合は、私のブログに残りの記事があります:

http://www.juhavehnia.com/2015/05/using-ssds-to-improve-mysql-performance.html

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.