İşlem Günlüğünü Ayrı Hacimde Yerleştirme [katı hal]?


12

İşlem günlükleri genellikle ayrı bir birimde yalıtılır. Bu uygulamanın mantığı, anladığım kadarıyla, işlem günlüğü verilerinin sıralı olarak yazılmasıdır - ve sabit diskler, rasgele aksine sırayla çok daha yüksek hızda yazma işlemleri gerçekleştirebilirler. Bunun nedeni, rasgele yazmaların aksine, sıralı veri blokları yazarken çok daha kısa bir mesafe hareket etmesi gereken sürücünün içindeki küçük iğneden kaynaklanmaktadır.

(Saf yorum için özür dilerim. Sadece okuduğum şeyleri anlamaya çalışıyorum.)

Bunu akılda tutarak… Katı hal sürücülerinin, içinde hareket eden çok az iğne ve plaka ve malzeme olmadığı görülür. Veritabanım ve işlem günlüğümün her ikisi de sekiz katı hal sürücüsünün tek bir RAID 5'inde bulunuyorsa, işlem günlüğünü kendi ayrı birimine taşımanın gerçekten bir tersi var mı? Sözde verimlilik artışı, iğnelerin hareket ettiği ve plakaların döndüğü mesafeyi azaltan sıralı yazmaların öncülüne dayanıyorsa ve katı hal sürücüsünde bu hareketli parçaların hiçbiri yoksa, günlüğü izole ederek ne kazanırım?


Hala göz önünde bulundurmanız gereken otobüs ve tamponlarınız var. I / O desen farkları nedeniyle onları ayrı tutardım. Uygulamalarınız çok fazla işlem yapmıyorsa, maliyet önemliyse farkı fark edemezsiniz.
Eric Higgins

"Veri yolu" terimini kullandığınızda ... verilerin anakarttan RAID kartına giden yoldan mı bahsediyorsunuz?
Chad Decker

2
"İşlem günlüğünü kendi ayrı birimine taşımanın gerçekten bir ters tarafı var mı?" neredeyse kesinlikle değil, ama gerçekten tüm diziyi RAID10'a taşımak için bir hız var ve güvenilirliği SSD'leri aşırı provizyona (yani alt bölümlere ayırma)
tersine çeviriyor

Yanıtlar:


10

Kısa cevap, tek bir dizi kullanın, günlükleri 8 SSD sürücüsünde verilerden ayırmaktan herhangi bir performans kazancı olasılığı düşüktür. Bkz Sıcak ve Çılgın Aşk: SSD'ler üzerinde SQL SSD'ler üzerinde daha ayrıntılı (ve eğlenceli) yorumlar için. SSD'lerin ilişkili başarısızlıklarına ilişkin notlara özellikle dikkat edin.

Günlükleri SSD'lerdeki verilerden ayırmak, performans sorunundan çok bir RPO'dur (kurtarma noktası hedefi). Veri dizisinin başarısız olması durumunda, günlük dizinizin erişilebilir / öyle kalması gerektiği şekilde günlükleri verilerden ayırarak RPO'nuzu azaltabileceğiniz düşüncesi. Dikkatli olun, RPO kritikse ilgili başarısızlık sorununu azaltmak için iki dizinin her birinde farklı bir marka / model sürüş düşünür.

Otobüs bant genişliği ile ilgili yorumlar ilgisizdir. Bu kadar IO'yu kaydırmanız gerekiyorsa, endişelenmeniz gereken daha büyük sorunlarınız var.


-4

Bir HDD'de ayırmanın faydalı olacağını kabul eden bir grup var, yine de SSD sürücüler için bunun artık gerekli olmadığını iddia ediyorlar.

Onlar için sormak istiyorum "Eğer bir çekişme sorunu yoksa neden bir RAID 10? Artık sıyırma gerek yok! Bu yüzden tek başına aynalama yeterli olacak ve tabii ki 8 sürücüye gerek yok, veritabanı 2x boyut yeterli olmalı! ".

Ancak gerçek şu ki, bir şey RAID 10'a ihtiyaç duyarsa günlük dosyasıdır!

Bu sadece sıralı veya rasgele (aşağıdaki kaynaklara bakın) sorunu nedeniyle değil, aynı zamanda SSD sürücülerinin nasıl çalıştığını anladıktan sonra gerçekten çok önemlidir.

Uzun bir hikaye kısaltmak için (daha uzun bir açıklama için bkz. Http://arstechnica.com/information-technology/2012/06/inside-the-ssd-revolution-how-solid-state-disks-really-work/ ), bir SSD sürücüsü okumalarda çok etkilidir ve sıfırları yazarken, bunları yazmak için tek bir tane bile yazmak için tüm bölümü silmek zorunda olduğu kadar verimli değildir!

Bu, genel yazma işlemleri için bir sorun olmasa da, yine de bellekte arabelleğe alındıklarından ve sayfa sınırlarında yazıldıklarından, günlük dosyası herhangi bir önbelleği atladığından günlük dosyası için büyük bir sorundur ve bunun yerine SQL sunucusu blokları günlükleri diske yazılır! Bu, her yazma için büyük olasılıkla tam bir bölümün silineceği anlamına gelir.

Bu yüzden optimize etmek için, günlük dosyası için her ekstra diski (2x veritabanı boyutunun yanı sıra, sıyırmaya gerek yok!) Ayırmanızı öneririm, bu şekilde daha kısa bir zaman dilimi içinde mümkün olduğunca çok işleyebileceksiniz.

ESKİ CEVAP

Üç nedenden dolayı cevap evet. 1) Rastgele ve Sıralı - SSD'nin rastgele yazma işlemleri için performansı önemli ölçüde artırdığı açık olmakla birlikte, aşağıdaki beyaz kağıtlardan ve bağlantılardan görülebileceği gibi, rastgele ve sıralı kalıntılar sorunu hala devam etmektedir:

2) Güvenilirlik - Tüm SSD sürücülerinin aynı anda başarısız olma olasılığı yüksektir, bu durumda RAID koruma değildir, ancak yalnızca sıralı olarak kullanılan bir SSD sürücüsünün farklı bir ömrü olduğundan, bu sizin cankurtaranınız olabilir

3) Yazma İçeriği - Günlükleri kendi iş miline koymanın nedeni, rastgele vs sıralı değil, aynı zamanda yazma çekiciliğinden de kaynaklanır, çünkü tempdb'nin ayrı bir birimde belirtilmesi tavsiye edilir. buradaki sorunun da yazışma tartışmasıyla ilgili olduğunu.

Ve bu, günlük dosyasına yazma işleminin disk yüzeyine yazılana kadar işlemlerin değerlendirilmesini engellediğinden, günlük dosyası için daha da geçerli olmalıdır.

Aslında, günlükler için http://www.dell.com/downloads/global/products/pvaul/en/ssd_vs_hdd_price_and_performance_study.pdf adresinde Nisan ayının standart beyaz kağıdı olarak normal HDD sürücülerini kullanabilirsiniz.

DÜZENLE

Diskleri döndürmek için tempdb'yi kendi dizisine koymak Microsoft tarafından önerilir, bkz.

ve diğerleri çok sayıdadır ve Sql Server'da genel kabul gören kavramdır, hiç kimse diziyi bölmeyle ilgili bir sorun ifade etmemiştir.

Dahası, SQL Server ekibi Filegroup ve Partioining bölümleme kavramlarını yarattı, tek amacı onları ayrı bir dizide hareket ettirmekti.

Ve aslında http://msdn.microsoft.com/en-us/library/ms187087(v=sql.105) adresindeki MSDN , kümelenmemiş dizini kendi dizisinde ayırmanın bir performans avantajı olabileceğini önerir ( bu her durum için, sadece belirli iş yükleri için genel bir tavsiye olarak alınmamalıdır, daha fazla bilgi için http://weblogs.sqlteam.com/dang/archive/2008/08/01/Are-you-a-DBA -Monkey.aspx ).

Bu nedenle, eğirme disklerindeki ayrılma nedeninin sadece sıralı ve rastgele okumalar meselesiyle değil, SSD'ler için de geçerli olan genel yazma tartışmasına bağlı olduğunu söylemek mantıklı bir uzantıdır.

Bazı insanlar bu tavsiyeye katılmıyor ve tempdb ve kendi hacmini (Jack Douglas olarak) koymanın bir faydası olmadığını düşünüyor olabilir ve hatta günlük dosyalarını ayırmanın hiçbir faydası olmadığını bile iddia edebilirsiniz (Mark Storey gibi) -Smith) ve bunun yerine diziyi bölmenin çok daha kötü olduğunu iddia et, yine de bunun Microsoft ve topluluk tarafından önerilen genel kabul gören yaklaşıma karşı yeni bir yaklaşım olduğunu unutma ve şimdiye kadar hiç kimse Bunu desteklemek için karşılaştırma testleri.

Yani tüm aşağılıklara karşı olan sözüm şudur: Bir gönderiyi sizinkinden farklı bir düşünceye sahip olduğu için, özellikle de 1) görüşünüz genel kabul edilen teoriye karşı 2) ve satıcılara (Microsoft'a karşı) ) kendi belgeleriniz 3) ve herhangi bir kanıt sunmadınız.

Fakat bu durumda daha da saçma, çünkü yazım bu teoriye mantıklı bir uzantıdan başka bir şey değil, bu yüzden bu yazıyı yatak tavsiyesi olarak kabul eden bir kişi, elbette bu teoriyi öneren ve onları aşağıya düşüren tüm mesajlara geri dönmelidir. .

Birisinin RAID'in eski okul teorisi olduğuna karar verdiğini ve bunu öneren tüm yayınları aşağıladığını varsayalım, bu nasıl mantıklı?


Yorumlar uzun tartışmalar için değildir; bu görüşme sohbete taşındı .
Paul White 9
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.