SSD SQL Server veritabanı - her tablo için ayrı bir dosyaya herhangi bir avantajı?


19

Yaklaşık 30 tablo olacak bir veritabanı oluşturuyorum, her tablo on milyonlarca satır içeren ve her tablo ağır karşısında sorgu verimliliğini en üst düzeye çıkarmak için tek bir önemli sütun ve birincil / yabancı anahtar sütun içeren güncellemeler ve eklemeler ve kümelenmiş dizinlerin yoğun şekilde kullanılması. Tablolardan ikisi değişken uzunlukta metin verileri içerecek ve bunlardan biri yüz milyonlarca satır içerecek, ancak geri kalanı yalnızca sayısal veriler içerecektir.

Gerçekten sahip olduğum donanımın (yaklaşık 64GB RAM, çok hızlı bir SSD ve 16 çekirdek) her son performans düşüşünü sıkmak istediğim için, her tablonun kendi dosyasına sahip olmasına izin vermeyi düşünüyordum, 2, 3, 4, 5 veya daha fazla masaya katılıyorum, her tablo her zaman ayrı bir iş parçacığı kullanılarak okunacak ve her dosyanın yapısı, umarım parçalanmayı en aza indirecek ve daha hızlı hale getirecek olan tablo içeriğiyle yakından hizalanacaktır. SQL Server için herhangi bir tablonun içeriğine eklemek için.

Bir uyarı, SQL Server 2008 R2 Web Edition'da kaldım . Bu da, performans artışı olarak ortaya çıkan otomatik yatay bölümlemeyi kullanamayacağım anlamına geliyor.

Tablo başına bir dosya kullanmak aslında performansı en üst düzeye çıkaracak mı yoksa bu kadar gereksiz hale getirecek yerleşik SQL Server motor özelliklerini mi görüyorum?

İkincisi, tablo başına bir dosya kullanmak avantajlıysa, neden create tabletabloyu belirli bir mantıksal dosyaya değil de yalnızca bir dosya grubuna tahsis etme seçeneği veriyor? Bu, benim senaryomdaki her dosya için ayrı bir dosya grubu oluşturmamı gerektirecek, bu da bana SQL Server'ın önerdiğim şeyi yapmaktan geleceğini düşündüğüm avantajları öngörmediğini gösteriyor.

Yanıtlar:


18

2, 3, 4, 5 veya daha fazla tabloya katılırsam, her tablo her zaman ayrı bir iş parçacığı kullanılarak okunacak ve her dosyanın yapısı umarım parçalanmayı en aza indirecek ve SQL Server'ın verilen herhangi bir tablonun içeriğine eklemesini hızlandıracak olan tablo içerikleriyle yakından hizalanmalıdır.

Ne halt hakkında konuşuyorsun? Bilgilerinizi nereden aldığınızdan emin değilsiniz, ancak bu kaynağı kesinlikle atmalısınız. Burada varsaydığın hiçbir şey aslında doğru değil.

SQL Server için SSD performansı hakkında iyi bir tartışma okumak istiyorsanız, orada birkaç blog serisi vardır. Genellikle, Paul Randal'ın biri en çok okunan şey:

Brent'in de konuyla ilgili güzel bir sunumu var: SSD'lerde SQL: Hot and Crazy Love ve daha fazlası var.

Tüm bu sunumlardan geçtikçe, SSD'lerin performansının ortaya çıktığı yer olduğu için hepsinin yazmalara odaklandığını hemen fark edeceksiniz . Yazı ifadeniz neredeyse tamamen farklı bir konu olan okumalarla ilgilidir. Eğer okumanız acı noktanızsa, SSD'lerden değil RAM'den ve uygun indeksleme ve sorgulama stratejilerinden bahsediyor olmalısınız.


1
Evet, hattın herhangi bir yerinde yanlış bilgi verildi ama Stuart'ın cevabına yorum yaptığım gibi, kararımı yanlış bilgilere dayandırmamaya emin olmam için soruyu sordum. Bağlantılar için teşekkürler, onları kontrol edeceğim.

17

İlk önerim, her iki yapılandırmaya karşı yük testi yapmadan performans hakkında herhangi bir varsayımda bulunmamak olacaktır.

Geçmişte bu tür yapılandırmaları (kağıt üzerinde anlamlı olan) görmüş olmaktan tahmin ediyorum, her bir tablonun ayrı bir dosyaya sahip olmasının performans için ölçülebilir olumlu bir etkisi olmayacağı ve ek karmaşıklığın herhangi bir performans kazancını dengeleyeceği olacaktır. ölçülebilir olsalar bile.

Son olarak, bir Sql Sunucusundan her performans düşüşünü sıkmak söz konusu olduğunda, sizi aşağıdaki tabloya yönlendiriyorum (Microsoft'um varsa):

resim açıklamasını buraya girin

Uygulama perspektifinden yapılabilecek olası optimizasyonlar, herhangi bir olası optimizasyonu donanım / veritabanı konfigürasyon düzeyinde kolayca gölgede bırakır ... bu yüzden dikkatinizi uygun şekilde odaklayın.


Elbette. Benim durumumda olsa da, tüm sistemi olabildiğince optimize ediyorum ve şu anda sahip olduğum birincil darboğaz, sık güncellemeler, silme ve eklemeler karşısında çok hızlı sorgu hızları. Bu sorunu çözmek için SQL Server'dan yararlanacağım için, verilerimde olabildiğince hızlı çalışması için mümkün olan en iyi şansı verdiğimden emin olmak istiyorum.

@NathanRidley Tamam, anladım ... Birisi "asla bunu yapma" diyen bir kaynağa sahip olmadıkça, en iyi eylemin tipik iş yükünüzle iki yapılandırmayı karşılaştırmak ve ölçülebilir bir fark olup olmadığını görmek olacağını düşünüyorum.
Michael Fredrickson

4

Diğerlerinin de belirttiği gibi, tablo başına bir dosyadan doğrudan fayda yoktur; İşte bu efsanenin nasıl ortaya çıktığı konusunda Steve Jones'dan büyük bir özet: http://www.sqlservercentral.com/blogs/steve_jones/2009/10/13/sql-server-legend-data-files-and-threads/

Ayrıca, 2008 Web Edition tarafından desteklendiğine inandığım bölümlenmiş bir görünümü de incelemek isteyebilirsiniz. Bölümlenmiş bir görünüme karşı kodlama yapmak için bazı püf noktaları vardır, ancak bölümlenmiş tabloların işlevselliğinin çoğunu nispeten kolayca taklit edebilirsiniz.


2

Her tablo için ayrı dosyaların performans avantajı getirmeyeceğini düşünüyorum. Doğru dizinler veritabanı sunucusunda olası bir performans (disk okuma) artışına sahip olabilir.

SQL Server 2008 R2 sıkıştırmayı destekliyor mu? Evet ise, açın.

Yanlışsam düzelt.


Performans faydasının neden olmayacağı konusunda ayrıntılı bilgi verebilir misiniz? En azından, ayrı dosyalar SQL Server'ın okumak için birden çok iş parçacığı kullanmasına izin verdiğinde neden böyle olduğunu açıklayın.

Tüm tabloyu kendi dosya grubuna koyarsanız, ancak aynı sürücüye yerleştirirseniz, bölümleme işleminden önce performans eşit olacaktır. Ancak, bazı tabloları farklı bir hızlı diskteki dosya gruplarına ayırıyorsanız performans avantajı elde edersiniz. Ayrıca, yıla bağlı çok fazla veriniz varsa, yıla göre bölümlere ayırabilirsiniz. Bu teknik ile en çok kullandığınız verileri eskisinden daha hızlı bir diskte tutabilirsiniz. Dizinleri de ayırabilirsiniz, ancak yalnızca yeni bir fiziksel diske koyduğunuzda herhangi bir performans avantajı elde edersiniz.

Paralel iş parçacıkları (tablolar / dosyalar) hakkında haklısın ama sadece bir fiziksel disk olana kadar performans kazancı küçük olacağını düşünüyorum.

Ve SSD yakında öleceğinden veritabanı için daha güçlü bir HDD RAID dizisi almanızı öneririm.
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.