Mengkonfigurasi SQL untuk kinerja optimal ... SSD atau HDD?


8

Adakah yang tahu tentang perbandingan yang menunjukkan bagaimana SSD dibandingkan dengan HDD untuk kinerja di lingkungan SQL?

Saya mencoba memahami jenis manfaat kinerja apa yang dapat diperoleh dengan beralih ke SSD.


1
Saya yakin salinan standar SQL akan bekerja sama baiknya pada SSD seperti pada HDD spinning-platter. Atau mungkin Anda tertarik dengan upaya penerapan standar SQL tertentu?
womble

Jawaban:


14

Jika Anda melakukan banyak pembacaan kecil, SSD jauh lebih cepat. Inilah salah satu dari beberapa perbandingan yang beredar tentang kinerja database. Lihat grafik di bawah untuk jawaban singkatnya.

Untuk kinerja yang bagus, SSD menawarkan banyak keuntungan, yang utama adalah bahwa waktu pencarian efektif 0, yang berarti semua HD kecil yang diketuai oleh database ditangani lebih cepat.

Namun ada beberapa kekhawatiran dengan generasi saat ini pada masa tulis, karena setelah begitu banyak menulis blok tidak dapat digunakan lagi. Mereka dapat menulis sedikit, saya percaya intel mengatakan sekitar satu byte byte untuk drive 32GB mereka sebelum mereka mulai mencapai tingkat berbahaya ware ... ini hanya akan menjadi lebih baik seiring waktu.

Untuk pemahaman yang lebih baik tentang mengapa kinerja mereka jauh lebih baik, baca artikel ini dari Anandtech pada SSD . Dia membahas detail drive, apa yang baik, apa yang tidak, dan seluk beluk cara kerjanya. Di bagian atas juga ada tautan ke artikel tindak lanjut yang mencakup serangkaian drive terbaru.


2
Dalam hal keausan karena siklus tulis yang terbatas, SSD yang baik mendekati keamanan disk pemintalan akhir-akhir ini karena kombinasi kemampuan siklus tulis yang lebih besar dari sel-sel individual, gabungan "trik" untuk mengurangi siklus blok tulis yang dibutuhkan, dan perataan keausan algoritma. Bahkan untuk aplikasi dengan beban IO tinggi seperti basis data yang sangat aktif, SSD yang baik tidak jauh lebih mungkin untuk dipasang sebelum penggantian rutin daripada disk yang berputar. Tetap simpan secara teratur, teruji secara teratur, pencadangan seperti dengan solusi penyimpanan apa pun.
David Spillett

Saya setuju, itu sebabnya saya menyebutnya kekhawatiran bukan show-stopper ... disk murah memiliki masalah nyata dengan ini sekarang, dan ini lebih merupakan masalah firmware. Dalam 6 bulan saya tidak berpikir tingkat keausan bahkan akan dinaikkan lagi, itu berkembang sangat baik, sangat cepat.
Nick Craver

1
Jawaban yang bagus. Hanya untuk menambahnya, saya akan berpikir bahwa dalam kebanyakan keadaan log harus tetap pada hard drive normal karena ditulis secara berurutan dan hard drive murah. Hanya memiliki database aktual pada SSD karena di situlah akses acak.
PeteT

@ Paset - sedikit bervariasi / tergantung, ingat bahwa satu log tertentu adalah berurutan ya, tetapi pada server hosting banyak basis data (seperti Stack Exchange hosting banyak situs pada basis data per) perilaku aktual jauh lebih dekat dengan akses acak / tulis daripada berurutan, jadi itu tergantung pada apa / berapa banyak Anda menjalankan.
Nick Craver

Satu hal yang indah adalah ketika SSD mencapai akhir masa pakainya dan tidak dapat ditulis lagi, itu masih dapat dibaca. Anda tidak bisa mengatakan itu tentang disk yang berputar.
djangofan

4

Anda dapat menginstal sistem operasi dan perangkat lunak SQL pada hard drive standar dan kemudian menambahkan SSD untuk hanya menyimpan file database Anda. Ini harus membatasi jumlah penulisan yang dialami drive SSD dan juga memaksimalkan jumlah ruang yang tersedia untuk data Anda pada drive.



2

Jawaban Nick Craver baik; Saya hanya ingin menambahkan dua peringatan ke SSD yang menurut saya orang harus sadar:

a) Masalah SSD dengan keausan tulis tidak hilang, mereka merupakan hal mendasar bagi sel-sel flash yang digunakan. Sel SLC memiliki daya tahan tulis yang jauh lebih tinggi daripada MLC, sehingga OP harus mempertimbangkan untuk mendapatkan drive SLC di atas MLC. Tentu saja, SLC juga jauh lebih mahal.

b) Drive saat ini menyimpan data cache pada drive sebelum menuliskannya. Dengan demikian ada risiko kehilangan data jika daya terputus selama operasi penulisan. Ini adalah sesuatu yang dapat Anda atasi, tetapi cache ada untuk kinerja, dan untuk mengurangi amplifikasi tulis.

IMHO tidak satu pun di atas adalah pelanggar. Saya akan siap untuk menggunakan SSD untuk produksi hari ini, tetapi dengan beberapa perencanaan terlebih dahulu.

  1. Jika risiko kecil kehilangan data tidak dapat diterima, maka harddisk SAS konvensional dengan caching data dimatikan mungkin merupakan pilihan yang lebih baik.
  2. Saya pikir Anda harus mengukur jumlah data yang ditulis ke drive SSD di hari normal. Berdasarkan hal ini dan spesifikasi pakai dari pabrikan, hitung umur SSD yang diharapkan dengan pola penggunaan Anda. Jika masa pakai yang diharapkan lebih rendah dari umur yang direncanakan server, maka tetapkan tanggal penggantian preemptive untuk SSD. Sama seperti bagian-bagian pesawat terbang, swap keluar sebelum menjadi cenderung gagal.

Bagian pesawat terbang? Bukan analogi terbaik jika Anda memperluasnya ke layanan antar jemput NASAs, yang berjalan pada komputer IBM AP101S dengan RAM 1GB dan tidak ada HDD. Kebutuhan akan prediktabilitas dan reliabilitas berada di atas semua pertimbangan lainnya.
CJM

1

Beberapa hal yang perlu diingat.

Jika Anda menekan basis data sehingga bacaan Anda melambat dan Anda membutuhkan SSD, maka Anda perlu memperbaiki indeks Anda atau melihat menambahkan lebih banyak RAM ke server.

Sebagian besar server basis data, setelah disetel sepenuhnya tidak perlu SSD berjalan dengan baik.


Bacaan saya sebenarnya tidak melambat. Kami mencoba untuk mengoptimalkan kueri "klik pertama" di mana diperlukan sekitar 120-130 ms saat permintaan pertama dijalankan dan 80 ms setelah itu. Kali ini mengecualikan pembuatan rencana kueri dan membaca statistik yang relevan. Kita dapat melihat bahwa perbedaan waktu dalam kasus kami dihabiskan membaca dari disk, jadi mencoba mengeksplorasi bagaimana saya dapat membuat hit pertama lebih dekat ke 80ms.
spoon16

Jadi, bahkan setelah menjalankan pertama, masih membutuhkan 80ms? Apakah sebagian besar data berbunyi, atau banyak CPU (agregasi atau penyortiran)? Masih berpikir ada banyak ruang untuk optimasi "tradisional" sebelum pergi ke teknologi penyimpanan eksotis.
BradC

Jika Anda harus pergi ke disk saat menjalankan kueri pertama, maka SQL mengeluarkan data dari cache karena beberapa alasan. Pertama-tama Anda mungkin ingin melihat apa yang harapan hidup halaman Anda. Jika rendah maka lebih banyak RAM dalam urutan. Berapa rasio hit cache Anda sebelum, selama dan setelah permintaan? Jika di bawah 99,8% atau lebih maka pengindeksan dan lebih banyak RAM. Apakah Anda melakukan pemindaian APA SAJA? Jika demikian maka pengindeksan lebih mungkin.
mrdenny

Pada beban kerja tulis-berat dengan cache tembus (yaitu data yang secara fisik dilakukan ke disk sebelum panggilan kembali), Anda seharusnya mendapatkan kinerja penulisan yang jauh lebih baik dari SSD, dengan asumsi aplikasi Anda benar-benar terikat I / O. Perhatikan bahwa ini adalah strategi caching yang disukai untuk SQL Server, terutama pada SAN, dan MS memerlukan SAN untuk menjamin perilaku ini untuk mendapatkan sertifikasi untuk digunakan dengan SQL Server.
ConcernedOfTunbridgeWells

1

Baca artikel ini (cukup lama - 2009):

Ringkasan: ganti 24 x 15k RPM SAS drive dengan 6 (ya enam) SSD dan masih mendapatkan kinerja 35% lebih tinggi. Ini dengan Intel X25Ms yang tidak lagi unggul untuk SSD.

Untuk orang-orang basis data, ini fantastis karena Anda dapat memiliki server lebih cepat yang lebih kecil menggunakan daya yang lebih kecil.


1

Satu hal yang perlu dipertimbangkan adalah memiliki log transatcion pada HDD dan MDF Anda pada SSD. Juga masa hidup akan sangat tergantung pada jenis aplikasi. OLTP dapat terbakar dengan cepat di mana data statis yang seharusnya tidak memiliki masalah.


1

Pengalaman saya sendiri dicampur di sini ...

Pengujian pada windows 7 dengan sql server 2008 express r2. Berjalan di Desktop i7 dengan Sandy Bridge dan ram terpasang 12G (saya pikir DDR3?). Maaf pengaturan sedang desktop, saya hanya setelah melihat berapa banyak catatan saya dapat mengelola pada platform i7 sebelum saya membangun server.

Saya pertama kali menjalankan tes ini pada drive 1.5TB 7200rpm yang diinstal untuk mendapatkan timing dasar.

Catatan 10k dengan memperbarui procs, mengoptimalkan tabel untuk menyimpan data terkait sebelumnya dalam tabel datar, menambahkan indeks sampai saya mendapatkan waktu ke beberapa detik sebagai titik awal, kemudian saya menduplikasi catatan hingga 1,2 juta dan mendapat waktu dari 0: 3: 37 untuk pembaruan yang sama. 3 1/2 menit tidak buruk untuk pengaturan non-raid ini.

Duping catatan hingga 2,56 juta memberi saya waktu 0:15:57 - peningkatan hampir 5x. Mungkin sebagian besar karena paging melewati memori 12G yang terpasang.

Menginstal drive SSD dan memindahkan basis data, waktunya benar-benar meningkat menjadi lebih dari 20 menit. Saya berasumsi ini karena file halaman adalah per hard drive dan tidak ada secara default pada drive SSD karena tidak diinstal sebagai drive OS (bluescreens berlimpah ketika saya mencobanya).

Menambahkan pagefile ke drive SSD dan menguji ulang tes itu, 0: 5: 52-m sehingga pagefile tampaknya telah melakukan trik, tetapi saya tidak yakin pagefile cocok untuk drive SSD karena semua alasan di atas, mereka sangat terikat dan dapat menambah keausan yang tidak semestinya pada drive.

Satu peringatan, saya juga mengaktifkan Smartboost pada drive itu dan yang mungkin juga mempengaruhi timing, akan menjalankannya kembali tanpa itu.

Perasaan terbaik saya adalah bahwa lebih mudah untuk menambahkan memori hari ini, dan untuk biaya mungkin serangan 0 + 1 dari disk Hybrid akan melakukan pekerjaan yang hampir sama baiknya tanpa masalah.

sunting: menonaktifkan paging file pada SSD dan membiarkan smart boost melakukan tugasnya, waktu ditingkatkan dari 5:52 menit menjadi 4:55 menit untuk 2,56 juta catatan dengan serangkaian 3 pembaruan masing-masing. Saya akan mencoba cache 8G ssd pada drive hybrid seagate 750G berikutnya. maka jika itu tidak buruk saya akan mencobanya dalam serangan 0 + 1.

pembaruan terakhir tentang ini karena ini adalah utas lama - tetapi saya ingin meletakkan hasil yang saya dapatkan di sana sehingga seseorang dapat menemukannya.

Memindahkan basis data ke Seagate 750G Hybrid dengan cache SSD 8G Saya menjalankan tes beberapa kali agar cache SSD dapat belajar. Ini memberi saya waktu 5:15 m: s untuk pengujian yang sama, memperbarui 2,56 juta catatan - itu cukup dekat dengan kinerja SSD (4:55 m: s dengan Intel Smartboost) bagi saya untuk mempertimbangkan biaya.

Di sekitar $ 50 lebih banyak ($ ​​239 vs $ 189 sekarang) hibrida menyediakan lebih dari 6x penyimpanan dan kinerja yang hampir sama, tanpa menjalankan perangkat lunak tambahan untuk optimasi. Dalam serangan 0 + 1 saya berharap untuk mendapatkan timing yang jauh lebih baik dan drive ini memiliki garansi 5 tahun, dia berharap saya tidak akan membutuhkannya.


0

Secara pribadi, saya tidak akan menggunakan SSD karena alasan yang telah disebutkan; mereka secara bertahap akan melambat sebelum akhirnya gagal. Kami belum benar-benar tahu kapan ini akan terjadi - perkiraan saat ini hanya itu - perkiraan. Ingat ketika kita semua membeli CD yang 'tidak bisa dihancurkan' di awal / pertengahan 80-an? Beberapa tahun kemudian, kami menganggap penyimpanan data dalam bentuk CD sama bodohnya dengan menggunakan floppy disk.

Jika Anda memiliki perangkat keras, OS, dan DB yang semuanya dikonfigurasi dengan benar, maka Anda tidak perlu bertaruh pada SSD.

Dalam beberapa tahun, ketika produk telah jatuh tempo sedikit, itu akan menjadi skenario yang berbeda. Tapi sampai saat itu ...


0

Artikel Penelitian Microsoft berkaitan dengan biaya per Gb daripada keuntungan kinerja. Sebenarnya tidak pas dan menguji drive tetapi menggunakan algoritma retro-casting berdasarkan file log dari server yang sebenarnya.

Beberapa hal yang muncul dalam pikiran dengan SSD dan SQL:

1 / Jika Anda lalai menambahkan indeks yang tepat, SSD akan jauh lebih memaafkan karena waktu pencarian acak sangat rendah.

2 / Biaya jauh menurun ketika studi itu dilakukan dan untuk aplikasi web kecil, katakanlah untuk menjalankan bagian belakang aplikasi telepon, bukan server Exchange perusahaan, kinerja dapat menghemat biaya dalam menyewa konsultan untuk menyempurnakan SQL Server.

3 / Sebuah drive SSD tunggal dengan salinan bayangan tentunya harus lebih murah daripada sekelompok gelendong dalam kabinet RAID serta pengontrol dan koneksi. Belum lagi tenaga dan pemanas serta ruang rak.

4 / Spindle terkenal karena menjadi bagian yang paling umum mati di komputer. SSD tidak memiliki komponen yang bergerak dan satu jam waktu istirahat bisnis dapat menghabiskan biaya SSD dalam sekali jalan.

5 / Wear adalah masalah tetapi mereka memiliki cara untuk mengelolanya (melibatkan penghamburan blok) yang dimungkinkan karena data yang terfragmentasi secara acak tidak akan memperlambat SSD. Selain itu, basis data kecil pada disk besar kemungkinan tidak akan aus pada waktunya untuk membeli yang baru lebih murah di masa depan.

6 / Ada tren menuju basis data non-relasional dan melakukan join di tingkat menengah. Ini benar-benar dapat mengubah hal-hal: I / O ke tabel sederhana yang tidak diindeks pada drive SSD pada pecahan tanpa penalti kinerja dan dengan proposisi penskalaan yang jauh lebih sederhana. Juga menghemat lisensi SQL Server per shard.

7 / Ini semua teoretis. Jika ada yang memiliki pengujian kinerja dunia nyata terhadap spindle, saya ingin melihatnya.

Luke

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.