Bisakah data MySQL yang besar diimpor pada SSD merusaknya?

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?

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.

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.

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.

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.)

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.

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.

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.

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.