Bisakah data MySQL yang besar diimpor pada SSD merusaknya?

28

Saya harus mengimpor cukup banyak data (~ 100 juta baris, ~ 100 kali) ke dalam database MySQL. Saat ini, disimpan di hard disk drive saya, dan hambatan impor saya tampaknya adalah kecepatan tulis hard disk drive.

Saya telah mendengar bahwa SSD tidak suka penulisan terus menerus yang masif, dan cenderung merusaknya. Apa yang kamu pikirkan? Apakah ini benar-benar masalah pada SSD modern?

christophetd
sumber
Selama Anda meninggalkan (katakanlah) 2-3GB di luar area yang dipartisi untuk penyediaan yang berlebihan, saya kira Anda aman dengannya. Saya tidak melihat banyak masalah dengan itu. Sebagian besar SSD sudah memiliki beberapa bagian disk yang tidak dapat diakses oleh sistem operasi. Ruang tersebut digunakan untuk meratakan keausan dan untuk overprovisioning, jika hard drive terlalu penuh. GB tambahan ini akan memberi lebih banyak ruang bagi SSD untuk mendistribusikan data untuk menghindari kerusakan. Jika Anda hard-core dan ingin melanjutkan ini, Anda dapat mengetahui berapa banyak chip memori yang dimiliki SSD Anda dan memberikan 1GB dengan chip. 10 chip adalah 10 GB yang tidak dipartisi.
Ismael Miguel
5
Betapapun nilainya, kami secara rutin mengimpor jauh, jauh lebih banyak data daripada ini. Satu tabel kami memiliki lebih banyak data daripada yang Anda impor, dan kami memiliki beberapa ratus tabel. Kami menggunakan SSD. Saya berharap kamu akan baik-baik saja.
ChrisInEdmonton
4
Saat ini SSD cukup pintar untuk menangani keausan leveling sendiri bahkan tanpa dukungan OS (meskipun OS meminta untuk menulis ulang blok yang sama, controller SSD secara transparan menulis ke blok yang berbeda setiap kali) sehingga akan baik-baik saja.
7
Pengalih perhatian. Tingkat kegagalan SSD bukan hal yang perlu dikhawatirkan - itu akan cukup lama bahwa mereka masih akan bertahan lebih lama dari karat yang setara.
Sobrique
2
Orang-orang terlalu khawatir tentang SSD mereka. Pada dasarnya Anda tidak akan pernah berhasil "menghancurkan" SSD Anda secara tidak sengaja, dan bahkan melakukannya dengan sengaja mungkin memerlukan berminggu-minggu atau berbulan-bulan menulis terus menerus. Bahkan jika Anda "menghancurkan" itu, itu akan tetap memberikan data sebagai hanya-baca. Berhentilah khawatir dan gunakan saja. Anda mungkin juga bertanya tentang bagaimana kepala baca / tulis HDD Anda rusak oleh akselerasi.
mic_e

Jawaban:

27

Ini sebenarnya bukan jawaban langsung untuk ini.

SSD tidak peduli tentang penulisan terus menerus sebanyak berapa kali sektor tertentu ditimpa. Ketika SSD pertama kali keluar, sesuatu seperti SQL adalah kata yang buruk karena sistem operasi pada umumnya memperlakukan drive seperti HDD tradisional dan kegagalan sangat sering terjadi.

Sejak itu, drive menjadi lebih besar, lebih murah, lebih dapat diandalkan, dimaksudkan untuk lebih banyak membaca / menulis dan sistem operasi menjadi lebih pintar.

SSD dalam SQL tidak hanya umum, tetapi sering dianjurkan. Jangan ragu untuk membaca situs situs DBA .

Pikiranku adalah untuk melakukannya, dengan asumsi server SQL dibangun dengan benar dengan disk yang berlebihan. Jika tidak, maka harapkan kegagalan pada akhirnya.

Austin T French
sumber
5
"Jika tidak, tetap mengharapkan kegagalan pada akhirnya." Jika server memang menggunakan disk berlebihan, masih pasti mengharapkan kegagalan di beberapa titik, dan rencanakan untuk itu. Hanya saja dengan redundansi di tempatnya, kegagalan perangkat penyimpanan tunggal memiliki kemungkinan yang jauh lebih rendah untuk menyebabkan downtime sistem.
CVn
@ MichaelKjörling ya, tepatnya. Dalam pikiran saya "dibangun dengan benar" juga mengasumsikan cadangan database jika terjadi kegagalan ... Tapi kadang-kadang bahkan apa yang seharusnya OK untuk dibiarkan tidak perlu dikatakan, terima kasih.
Austin T Prancis
19

Bacaan baik-baik saja, dan SSD dapat membaca bitnya tanpa efek yang merugikan.

Menulis adalah masalah lain. Membersihkan bit memengaruhi integritas bit dan setelah banyak menulis berurutan, bit tersebut akan berhenti menerima tulisan baru sama sekali. Namun itu masih bisa dibaca.

Izinkan saya mengatakan bahwa batasan penulisan pada drive perusahaan baru sangat besar. Ambil 845DC Pro baru dari Samsung. Ini baik untuk menulis 10 drive per hari selama 5 tahun dengan garansi. Saya akan membayangkan itu akan melakukan dua kali angka itu. Untuk memasukkannya ke dalam angka, itu 14.600 TB ditulis lebih dari 5 tahun pada model 800 GB.
Atau 2920 TB per tahun,
Atau 8 TB per hari, selama lima tahun .

Tunjukkan saya hard drive dengan garansi yang mencakup banyak penggunaan. Saya bahkan tidak yakin Anda dapat menulis 8 TB ke HDD dalam sehari: - (50 MB / s throughput rata-rata * 60 (detik) * 60 (menit) * 24 (jam) = 4.320.000 MB / hari = 4,32 TB / hari) Ternyata Anda tidak bisa (pada drive rata-rata).

Selama Anda menggunakan drive seperti ini, berdasarkan V-NAND (atau SLC yang sama-sama tahan lama), tidak didasarkan pada TLC atau flash MLC yang buruk, Anda harus baik-baik saja. Lagi pula, RAID 10 dan cadangan adalah teman Anda karena suatu alasan. Dan setidaknya jika batas penulisan SSD tidak menjadi masalah, Anda masih dapat membaca data yang disimpan dalam bit yang rusak.

SSD juga lebih murah untuk dijalankan, lebih dingin, lebih tenang dan model perusahaan sangat tahan terhadap masalah daya. Tidak ada lagi kekhawatiran akan kerusakan kepala dan tentu saja, peningkatan kinerja yang sangat besar untuk kebutuhan akses basis data Anda.

Ctrl-alt-dlt
sumber
12
Bisakah saya bertanya mengapa downvote?
Ctrl-alt-dlt
Kamu bisa bertanya, tetapi kamu tidak akan menerima, rupanya.
Dana Gugatan Monica
12

Menulis ke SSD tidak selalu buruk. Menulis dan menulis ulang satu blok saja yang buruk. Berarti jika Anda menulis file hapus maka tuliskan lagi, atau lakukan sedikit perubahan pada file berulang-ulang. Ini menyebabkan keausan pada SSD. Database pasti akan masuk dalam kategori ini.

Namun menurut artikel ini , petabyte data telah ditulis ke SSD dan masih dapat dioperasikan. Ini mungkin disebabkan oleh kemajuan penggunaan leveling :

Upaya levelling wear untuk mengatasi keterbatasan ini dengan mengatur data sehingga penghapusan dan penulisan ulang didistribusikan secara merata di seluruh media. Dengan cara ini, tidak ada blok penghapusan tunggal yang gagal sebelum waktunya karena konsentrasi tinggi siklus tulis.

Dalam situasi khusus Anda, saya ingin agar basis data berada pada SSD untuk kecepatan, tetapi didukung setiap hari. Anda juga dapat mempertimbangkan untuk mendapatkan dua SSD dalam array RAID 1 juga. Kemungkinan dua SSD gagal pada saat yang sama rendah.

Catatan: RAID array BUKAN backup !!!! Tidak masalah jika Anda menggunakan array RAID atau tidak, miliki cadangan. Tidak masalah apakah Anda menggunakan SSD atau tidak, miliki cadangan.

James Mertz
sumber
1
RAID1 akan melakukan sangat sedikit untuk jenis kerusakan yang Anda bicarakan. Tingkat keausan cenderung bersifat deterministik, yang berarti mereka akan mengenakan dengan kecepatan dan cara yang persis sama, menyebabkan kesalahan terjadi hampir persis di tempat yang sama.
Aron
dari artikel yang ditautkan: "elektronik di SSD akan gagal jauh sebelum NAND habis" ... tunggu, apa?
Michael
4

Anggap impor Anda tidak melibatkan pembaruan dan penghapusan. Jadi, Anda melakukan semua penyisipan. Ini seharusnya hanya menulis data baru ke log transaksi.

Ini berarti saat data ditambahkan, selalu ditulis ke sektor baru. Mungkin ada beberapa buffer / swap yang diaduk / ditulis berulang kali, tetapi mengabaikan itu, semua sisipan tersebut secara teoritis akan menghasilkan tidak lebih dari satu penulisan per sektor . Bergantung pada bagaimana MySQL diimplementasikan, dan apa jenis penyisipan massal yang Anda lakukan, Anda dapat menghasilkan set kedua penulisan nanti ketika log transaksi diintegrasikan ke dalam file data utama (saya akan pergi pemahaman tentang mesin DB yang berbeda , dan dengan asumsi MySQL agak mirip dalam bagaimana log transaksi dibilas)

Intinya, Anda tidak "mengaduk" SSD. Artinya, Anda tidak melakukan banyak modifikasi / gerakan / penghapusan / dll. yang berpotensi menulis ulang di sektor yang sama beberapa kali. Jadi pada dasarnya Anda hanya akan menghasilkan jumlah menulis yang sangat kecil per sektor dan itulah yang benar-benar penting.

Dengan asumsi Anda tidak mengisi penuh SSD, harus ada ruang kosong yang cukup untuk hot spot tersebut (seperti buffer / swap) yang sedang diaduk untuk meminimalkan keausan melalui algoritma levelling keausan.

(Indeks mungkin masalah lain. Karena indeks berkerumun di banyak DB melibatkan banyak modifikasi ketika data dimasukkan. Biasanya ketika melakukan isnert yang besar di lingkungan data warehouse, Anda mematikan indeks selama impor massal kemudian memperbaruinya setelah itu.)

AaronLS
sumber
3

Ini bukan masalah.

Pertama-tama, SSD telah meningkat pesat selama beberapa tahun terakhir. Overprovisioning dan levelling wear (dan dalam jumlah kecil, perintah TRIM, meskipun tidak berlaku dalam kasus Anda) telah membuatnya sangat cocok sebagai disk tugas berat dan serba guna. Saya tidak menggunakan apa pun kecuali SSD pada PC pengembangan saya (yang secara teratur melakukan banyak kompilasi) bahkan tanpa mendekati jumlah siklus penghapusan.

Lebih lanjut, pernyataan ini:

SSD tidak suka penulisan terus menerus yang masif, dan cenderung merusaknya

sama sekali salah. Yang terjadi adalah sebaliknya, tulisan kecil yang sering , jika ada, dapat menyebabkan kerusakan pada SSD.

Tidak seperti hard disk tradisional, SSD (atau lebih tepatnya flash berbasis NAND di dalam) secara fisik diatur dalam blok besar yang secara logis berisi beberapa sektor. Ukuran blok yang umum adalah 512kB sedangkan sektor (yang merupakan unit yang menggunakan sistem file) secara tradisional 1kB (nilai yang berbeda dimungkinkan, dua dekade lalu 512B adalah umum).
Tiga hal dapat dilakukan dengan blok-512kB. Itu dapat dibaca dari, sebagian atau semua dapat diprogram (= ditulis untuk), dan keseluruhannya dapat dihapus. Menghapus adalah yang bermasalah karena jumlah siklus penghapusan yang terbatas, dan Anda hanya dapat menghapus blok yang lengkap.

Oleh karena itu, penulisan besar sangat ramah SSD sedangkan penulisan kecil tidak.

Dalam kasus penulisan kecil, controller harus membaca blok, memodifikasi salinan, menghapus blok yang berbeda, dan memprogramnya. Tanpa caching, dalam kasus terburuk, Anda harus menghapus 512.000 blok untuk menulis 512 kilobyte. Dalam kasus terbaik (tulis besar, kontinu) Anda harus melakukan persis 1 penghapusan.

Melakukan impor ke dalam database MySQL jauh berbeda dengan melakukan banyak permintaan insert yang terpisah. Mesin ini dapat meruntuhkan banyak penulisan (baik data dan indeks) bersama-sama dan tidak perlu disinkronkan di antara setiap pasang sisipan. Ini menghasilkan pola penulisan yang lebih ramah SSD.

Damon
sumber
2
Sektor secara tradisional 1 KiB? Tolong kutip. Pada drive rotasi, dua ukuran sektor adalah umum: 512 byte (tradisional, seperti pada HDD 4 TB saya, pada IBM-compatibles tanggal sekitar tahun 1981 atau lebih) dan 4096 byte ("Format Lanjutan"). Unit alokasi tingkat sistem file dapat bervariasi dalam ukuran, tetapi itu masalah yang sama sekali berbeda dan murni merupakan konstruksi sistem file untuk menjaga alokasi pelacakan struktur data ke ukuran yang wajar dalam sistem file yang tidak menumbuhkannya secara dinamis berdasarkan kebutuhan sesuai kebutuhan ; selain itu, saya ragu ukuran 1 blok KiB sangat umum dalam praktek.
CVn
@ MichaelKjörling: Terima kasih atas masukan Anda yang sangat berharga. Anda tentu saja membaca dan memahami jawabannya, bukan? Fakta yang relevan adalah bahwa SSD memiliki ukuran blok fisik yang jauh lebih besar dari itu, terlepas dari ukuran sektor logis (yang saya lihat di mana saja dari 500 hingga 4.096 byte, bahkan ukuran non-power-of-dua). Tidak perlu kutipan.
Damon
1

SSD tidak menyukainya. Jika Anda mempertahankan kecepatan penulisan maks hingga 5-10 tahun (24 jam per hari, 7 hari per minggu) maka Anda mungkin berakhir dengan SSD yang rusak.

Ofc. Setelah 5 tahun sebagian besar server telah mencapai akhir hidup ekonomis mereka.


Penafian:
Jangan coba ini dengan SSD generasi pertama. Mereka yang kurang kuat.

Hennes
sumber
Saya sadar bahwa menggunakan disk apa pun pada kapasitas maksimalnya 7/24 akan berakhir merusaknya ... Pertanyaan saya adalah apakah aman untuk waktu terbatas (misalkan beberapa kali 2-3 jam)
christophetd
@christophetd - Tergantung. Perbarui pertanyaan Anda untuk memperkirakan jumlah data. Lebih lanjut tentang persentase drive. Menulis 20GB per jam pada SSD 80GB adalah yang terburuk daripada melakukan 20GB per jam pada SSD 1TB.
Ramhound
Pada catatan yang sama: Memiliki sebagian besar drive kosong berarti bahwa banyak sel flash 'kosong' digunakan dalam meratakan keausan. (dan drive yang lebih besar dengan jumlah data yang sama adalah% -telah emtier).
Hennes
1

Jika Anda benar-benar tertarik untuk mencari tahu detailnya maka Anda perlu menjawab pertanyaan berikut:

Rata-rata berapa banyak byte di setiap baris?

Jika Anda dapat memberi tahu saya bahwa ada 10 kolom, setiap kolom adalah varchar (100), dan pengkodeannya adalah UTF-8 maka saya dapat menebak skenario terburuk bahwa Anda memiliki data bernilai 4.000 byte per baris dan menambahkan beberapa byte lagi untuk meta-data jadi katakanlah 4.200 byte?

SQL penyiksaan Anda menghitung 4,200 x 100 x 100,000,000 = 42,000,000,000,000 bytesdata yang ditulis ke disk

42.000.000.000.000 / 1000 = 42.000.000.000 KB

42.000.000.000 / 1000 = 42.000.000 MB

42.000.000 / 1000 = 42.000 GB

42.000 / 1000 = 42 TB

Pada skenario terburuk ini, Anda akan menulis 42 TB ke disk

Menurut artikel ini , disediakan oleh @ KronoS Anda harus baik untuk sekitar 25 putaran SQL penyiksaan Anda.

MonkeyZeus
sumber
-2

Seperti yang dikatakan oleh poster tulisan ini pada SSD , apa yang benar-benar berbahaya adalah berulang-ulang menulis potongan kecil data.

  • bit disimpan ke sel {1,2,3} -bit. Ini memiliki umur yang terbatas.
  • sel dikelompokkan ke dalam halaman [2-16] KB (unit terkecil yang dapat ditulis)
  • halaman dikelompokkan ke dalam (128-256 halaman-) blok (unit terkecil yang bisa dihapus)
  • untuk halaman yang akan ditulis ulang, itu --- dan seluruh bloknya --- perlu dihapus terlebih dahulu

Itu sebabnya dianjurkan

  • jangan pernah menulis kurang dari satu halaman sekaligus,
  • buffer menulis kecil, dan
  • pisahkan permintaan baca dan tulis
  • "Penulisan single-threaded besar lebih baik daripada banyak menulis bersamaan kecil"

Jadi, jumlah yang sangat besar sekaligus tampak jauh lebih baik.

serv-inc
sumber
2
Jawaban ini tidak benar-benar memberikan informasi yang relevan yang belum dikatakan, selain itu pada dasarnya komentar dengan tautan yang terkandung di dalamnya.
Ramhound
@Ramhound: akankah Anda memberikan komentar Anda atas komentar Anda (terima kasih, btw), dan ini juga, harus ditandai sudah usang? Atau apakah Anda masih menganggap info yang sudah dikatakan / tidak relevan?
serv-inc
Meskipun tidak lagi berupa tautan, sejujurnya, informasi teknis itu sendiri, tidak benar-benar berlaku untuk pertanyaan pengguna sehubungan dengan menjalankan database pada SSD I
Ramhound
@Ramhound: bagi saya sepertinya tentang impor, bukan berlari. Menilai dari downvotes, sepertinya Anda benar
serv-inc