Bir SSD'ye devasa bir MySQL verisi içe aktarılabilir mi?

Bir MySQL veritabanına çok fazla veri (~ 100 milyon satır, ~ 100 kez) almak zorundayım. Şu anda, sabit disk sürücümde depolanıyor ve içe aktarma işlemimin darboğazı, sabit disk sürücüsünün yazma hızı gibi görünüyor.

SSD'lerin yoğun sürekli yazılardan hoşlanmadığını ve onlara zarar verme eğiliminde olduğunu duydum. Ne düşünüyorsun? Bu gerçekten modern SSD'lerde bir sorun mu?

Bu gerçekten basit bir cevap değil.

SSD'ler, herhangi bir sektörün üzerine kaç kere yazıldığının sürekli yazımlarını umursamıyor. SSD'ler ilk çıktığında SQL gibi bir şey kötü bir sözdü, çünkü genel olarak işletim sistemi sürücüye geleneksel bir HDD gibi davranıyordu ve arızalar çok sık görülüyordu.

O zamandan beri sürücüler daha büyük, daha ucuz, daha güvenilir, daha fazla okuma / yazma ve işletim sistemleri daha akıllı hale geldi.

SQL'deki SSD'ler yalnızca yaygın değildir, ancak çoğu zaman teşvik edilir. DBA kardeş sitesini incelemek için çekinmeyin .

Düşüncelerim, SQL sunucusunun yedekli disklerle düzgün bir şekilde oluşturulduğunu varsayar. Olmazsa, eninde sonunda bir başarısızlık bekleyin.

Okumalar gayet iyi ve SSD'ler bitlerini herhangi bir zararlı etkiye yol açmadan okuyabilirler.

Yazarlar başka bir konudur. Bir bitin temizlenmesi, bitin bütünlüğünü etkiler ve çok sayıda sıralı yazma işleminden sonra , bit, yeni yazmaların tamamen kabul edilmesini durduracaktır. Ancak yine de okunabilir.

Yeni kurumsal sürücülerdeki yazma sınırlarının çok büyük olduğunu söylememe izin verin. Samsung'un yeni 845DC Pro'yu kullanın. Garanti kapsamında 5 yıl boyunca günde 10 sürücü için iyidir. Bu rakamın iki katına çıkacağını hayal ediyorum. Rakamlara koymak, 800 GB modelinde 5 yıl boyunca yazılmış 14.600 TB.
Veya yılda 2920 TB
, beş yıl boyunca günde 8 TB .

Bana bu kadar kullanımı kapsayan garantili bir sabit disk göster. Bir günde 8 TB’lik bir HDD’ye yazabildiğinizden bile emin değilim: - (50 MB / sn ortalama verim * 60 (saniye) * 60 (dakika) * 24 (saat) = 4.320.000 MB / gün = 4.32 TB / gün) Yapamayacağın ortaya çıkıyor (ortalama bir sürücüde).

Böyle bir sürücüyü kullandığınız sürece, V-NAND (veya eşit derecede dayanıklı SLC) tabanlı olarak, TLC veya kötü MLC flaşına dayanarak değil, iyi olmalısınız. Her neyse, RAID 10 ve yedeklemeler bir nedenden dolayı arkadaşınız. Ve en azından SSD yazma sınırı bir sorun haline gelirse, hatalı bitlerde depolanan verileri hala okuyabilirsiniz.

SSD'ler ayrıca daha ucuzdur, daha soğuk, daha sessiz ve kurumsal modeller güç sorunlarına karşı özellikle dirençlidir. Artık kafa çarpma korkusu ve tabii ki, veritabanı erişim ihtiyaçlarınız için büyük bir performans artışı yok.

SSD'lere yazmak mutlaka fena değil. Tek bir bloğun yazması ve yeniden yazılması kötü. Bir dosyayı yazarsanız silin, ardından tekrar yazın veya bir dosya üzerinde tekrar tekrar küçük değişiklikler yapın. Bu, SSD'lerde aşınmaya neden olur. Veritabanları kesinlikle bu kategoriye sığacak.

Bununla birlikte, bu makaleye göre , veri petabaytları SSD'lere yazılmıştır ve hala çalışmaktadır. Bu muhtemelen aşınma dengelemesindeki ilerlemelerden kaynaklanmaktadır :

Aşınma dengeleme, silme ve yeniden yazma işlemlerinin ortama eşit olarak dağıtılmasını sağlayacak şekilde verileri düzenleyerek bu sınırlamaları aşmaya çalışır. Bu şekilde, yüksek bir yazma döngüsü yoğunluğundan dolayı hiçbir tek silme bloğu erken başarısız olmaz.

Kendi durumunuzda, veritabanlarının hız için SSD'de bulunmasını, ancak günlük olarak yedeklenmesini istiyorum. RAID 1 dizisine iki SSD almayı da düşünebilirsiniz . İki SSD'nin aynı anda başarısız olma olasılığı düşüktür.

Not: RAID dizileri yedeklemeler DEĞİLDİR !!!! RAID dizisi kullansanız da kullanmasanız da, bir yedeğiniz olsun. Bir SSD kullanıyor olsanız da kullanmasanız da, bir yedeğiniz olsun.

İçe aktarma işleminizin hiçbir güncelleme veya silme olmadığını varsayalım. Demek bütün eklemeleri yapıyorsun. Bu sadece işlem günlüğüne yeni veriler yazıyor olmalıdır.

Bu, veri eklendikçe, her zaman yeni bir sektöre yazılmış demektir. Birden fazla defa çalkalanan / yazılı olan bazı tamponlar / takaslar olabilir, ancak görmezden gelindiğinde , bu eklerin tümü teorik olarak sektör başına birden fazla yazma ile sonuçlanmayacaktır . MySQL'in nasıl uygulandığına ve ne tür bir toplu ekleme yaptığınıza bağlı olarak, işlem günlüğü ana veri dosyasına entegre edildiğinde daha sonra ikinci bir yazı dizisi oluşturabilirsiniz (Farklı DB motorları hakkında bir anlayışa giriyorum) ve MySQL'in işlem günlüklerinin nasıl temizlendiğine benzer olduğunu farz ediyorum).

Demek ki, SSD'yi "çalkalamıyor" değilsiniz. Yani, çok fazla değişiklik / hamle / silme / vb yapmıyorsunuzdur. Bu, potansiyel olarak aynı sektörleri defalarca yeniden yazabilir. Yani aslında sektör başına sadece çok az sayıda yazı yazacaksınız ve asıl önemli olan şey bu.

SSD'yi tamamen doldurmadığınızı varsayarsak, aşınma seviyeleme algoritmaları yoluyla aşınmayı en aza indirmek için çalkalanan sıcak noktalar (tamponlar / takas gibi) için yeterli boş alan olmalıdır.

(Endeksler başka bir konu olabilir. Birçok DB'deki kümelenmiş endeksler, veriler eklenirken bir sürü değişiklik gerektirdiğinden. Genellikle, bir veri ambarı ortamında büyük isnerts yaparken, toplu içe aktarma sırasında endeksleri kapatıp sonra güncellersiniz.)

Bu sorun değil.

Her şeyden önce, SSD'ler son yıllarda büyük ölçüde iyileşmiştir. Aşırı tedarik ve aşınma seviyelendirme (ve küçük miktarlarda TRIM komutu, sizin durumunuz için geçerli olmasa da) onları ağır iş tipi genel amaçlı diskler olarak oldukça uygun kılmıştır. Geliştirme bilgisayarımda SSD'den başka bir şey kullanmıyorum (düzenli olarak çok fazla derleme yapıyor), silme döngüsü sayımına bile yaklaşmadan.

Ayrıca, bu açıklama:

SSD'ler sürekli büyük yazılar yazmayı sevmez ve onlara zarar verme eğilimindedir.

düpedüz yanlış. Aksi durumda, sık sık küçük yazılar , eğer varsa, SSD'lere zarar verebilir.

Geleneksel sabit disklerin aksine, SSD'ler (veya içindeki NAND tabanlı flaş) fiziksel olarak mantıksal olarak birkaç sektör içeren büyük bloklarda düzenlenir. Tipik bir blok boyutu 512kB iken, sektörler (dosya sisteminin kullandığı birimdir) geleneksel olarak 1kB'dir (farklı değerler mümkündür, yirmi yıl önce 512B yaygındı).
512kB blok ile üç şey yapılabilir. Bir kısmından okunabilir, bir kısmı veya tamamı programlanabilir (= yazılır) ve tamamı silinebilir. Silme problemlidir, çünkü sınırlı sayıda silme çevrimi vardır ve yalnızca tam bir bloğu silebilirsiniz.

Bu nedenle, büyük yazılar çok SSD uyumludur, oysa küçük yazılar değildir.

Küçük yazma durumunda, denetleyici bir blok okumalı, kopyayı değiştirmeli, farklı bir bloğu silmeli ve programlamalıdır. Önbellek olmadan, mümkün olan en kötü durumda, 512 kilobayt yazmak için 512.000 bloğu silmeniz gerekir. Mümkün olan en iyi durumda (büyük, sürekli yazma) tam olarak 1 silme yapmanız gerekir.

Bir MySQL veritabanına bir içe aktarma yapmak, birçok ayrı ekleme sorgusu yapmaktan çok farklıdır. Motor bir çok yazıyı (hem veri hem de endeksleri) birlikte daraltabilir ve her bir uç çifti arasında senkronize edilmesine gerek yoktur. Bu, çok daha SSD dostu bir yazma düzeni anlamına gelir.

SSD'ler bundan hoşlanmadı. Maksimum yazma hızını 5-10 yıl (günde 24 saat, haftada 7 gün) tutarsanız, bozuk SSD ile sonuçlanabilir.

Ofc. 5 yıl sonra çoğu sunucu ekonomik ömrünün sonuna geldi.

Uyarı:
Bunu ilk nesil SSD ile denemeyin. Daha az sağlam olanlar.

Ayrıntıları anlamakla gerçekten ilgileniyorsanız, aşağıdaki soruyu cevaplamanız gerekir:

Ortalama olarak her satırda kaç bayt var?

Bana 10 sütun olduğunu söylerseniz, her sütun varchar (100) ve kodlama UTF-8'dir, o zaman en kötü durumda senaryo başına 4.000 bayt değerine sahip olduğunuzu tahmin edebilir ve meta-veri böylece 4.200 byte diyelim?

İşkence SQL'iniz 4,200 x 100 x 100,000,000 = 42,000,000,000,000 bytes, diske yazılan verileri hesaplar

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

Bu teorik en kötü senaryoda diske 42 TB yazacaksınız.

Bu makaleye göre , @KronoS tarafından sağlanan, işkence SQL'iniz için yaklaşık 25 tur daha iyidir.

SSD'ler üzerine bu yazının posterinin dediği gibi, gerçekten zararlı olan şey tekrar tekrar küçük veri parçaları yazmaktır.

• bitler {1,2,3} -bit hücrelere depolanır. Bunlar sınırlı bir ömre sahiptir.
• hücreler [2-16] KB sayfalarında gruplandırılmıştır (en küçük yazılabilir birim)
• sayfalar (128-256 sayfa-) bloklar halinde (en küçük silinebilir birim)
• bir sayfanın yeniden yazılması için, --- ve tüm bloğu --- önce silinmesi gerekir

Bu yüzden tavsiye edilir

• asla bir kerede bir sayfadan daha az yazmayın,
• arabellek küçük yazarlar ve
• ayrı okuma ve yazma istekleri
• "Tek bir iş parçacıklı büyük yazma, aynı anda birçok küçük yazma işleminden daha iyidir"

Yani, bir kerede çok büyük bir miktar daha iyi görünüyor.