SQL büyük tablo tasarımı

SQL Server 2008 tablo (lar) tasarımı hakkında genel bir sorum var. Şu anda 600GB'ın üzerinde ve günde yaklaşık 3GB büyüyen bir masaya sahibiz. Bu tablo uygun dizinlere sahiptir, ancak sorguları çalıştırırken ve yalnızca boyutu nedeniyle büyük bir hangar haline gelir. Soru, tabloyu yıl ve aya göre birden çok tabloya bölmem (diğer bölümlerin büyük veri kümelerini nasıl bölüştüğüne uyması) ya da SQL Server'da yerleşik bölümlemeyi kullanmamız gerektiğidir. Bölümleme kullanmanın daha az kod değişikliği gerektireceği görülüyor. Bölümleme sırasında okuduğum kadarıyla sadece bir tabloyu sorgula ve sunucu verileri nasıl elde edeceğini işler. Birden çok tablo yoluna gitsek, birden çok tablodan veri çekmemiz gerekirdi.

"Bu tablo uygun dizinlere sahip, ancak sorgular çalıştırılırken önemli bir Hangout haline geliyor"

Tek başına bölümleme, SQL Server bir sorguyu çalıştırırken bölümleri kaldıramadığı sürece sorgu performansına yardımcı olmaz. WHERE yan tümceniz bölümleme şeklinize uygun olmalıdır. Bölümleme alanı olarak kullanmak için yalnızca bir alan elde ederiz, bu nedenle bu alan WHERE yan tümcesinize dahil edilmemişse, bölümlere rağmen yine de tüm tabloyu tarayabilirsiniz.

"ve sadece büyüklüğü yüzünden."

Bölümleme, belirli bakım işlemlerini kolaylaştırabilir, ancak yine de bölüm bölüm temelinde yapamayacağımız şeyler vardır. Dizin bakımı ve istatistik güncellemeleri size sorun çıkarıyorsa, tasarımı bir arşiv tablosuna ve canlı olarak güncellenen bir tabloya bölmeniz daha iyi olur. Verileri canlı tablodan arşiv tablosuna periyodik olarak taşımanız gerektiğinde bunu yaparsınız, dizinleri% 100 doldurma faktörü ile yeniden oluşturur, istatistikleri tam tarama ile günceller ve ardından dosya grubunu salt okunur olarak ayarlarsınız. Bölümleme, arşiv tablosu yüklerinde yardımcı olabilir - ancak canlı tabloyu bölümlemek yardımcı olmayabilir. (Hızlı ve basitmiş gibi birkaç gelişmiş kavramı öne atıyorum, ancak burada biraz arka plan çiziyorum.)

"Bölümleme kullanmanın daha az kod değişikliği gerektireceği anlaşılıyor."

Sorta tür - ilk bakışta bu şekilde görünüyor, ancak ne kadar çok girerseniz, bölümlenmiş görünümler gibi seçenekleriniz var. Mevcut tabloyu yeniden adlandırabilir, yerine bir görünüm koyabilir ve ardından uygulamanızı değiştirmeden temel tablolarda kendi değişikliklerinizi yapabilir (ve birden çok tablo ekleyebilirsiniz).

Burada bölümlemenin tuzakları hakkında daha fazla yazdım:

http://www.brentozar.com/archive/2008/06/sql-server-partitioning-not-the-answer-to-everything/

Tek başına bölümleme yeterli olabilir, ancak bölümlenmiş görünümler ve birden çok tablo ile birleştirerek daha iyi sonuçlar alabilirsiniz. Sorgulama ve büyüme modeline çok bağlıdır.

Bölümleme ile ilgili geçerli sınırlama, sütun istatistiklerinin bölüm düzeyi yerine yalnızca bir tabloda tutulmasıdır. Daha doğru istatistiklerden yararlanacak bir sorgulama modeliniz varsa, tablo bölümlemesini bölümlenmiş görünümlerle birleştirmek önemli performans avantajları sağlayabilir.

Verilerinizin niteliğinin aydan aya, yıldan yıla değiştiği yerlerde, bölümlenmiş görünümler de yardımcı olabilir. Ürün hatlarında çok az tutarlılık olacak şekilde ürün hatlarını sürekli değiştiren bir perakendeci düşünün. Tek bir sipariş / sipariş ayrıntıları tablosu ve dolayısıyla tek bir istatistik histogramı ile, istatistikler sorgu optimize ediciye çok az şey sunacaktır. Yıllara göre bölümlere ayrılmış ve bölümlenmiş görünümlerle (Order, OrderLine) birleştirilen yıllık bir tablo (Order_2010, Order_2011, OrderLine_2010, OrderLine_2011), optimize ediciye daha ayrıntılı ve potansiyel olarak yararlı istatistikler sağlayacaktır.

Tablo bölümlendirmeyi karşılaştırmalı olarak çok az çaba harcayarak tanıtabilirsiniz, oradan başlayın, etkisini ölçün ve daha sonra bölümlenmiş görünümlerin ek çabaya değip değmeyeceğini değerlendirin.

Kimberly Tripp , bölümleme hakkında genellikle konuyla ilgili okuma yapılması gerektiği düşünülen çok sayıda rehberlik ve teknik inceleme yayınlamıştır . Kendra Little ayrıca bazı iyi malzeme ve diğer makalelerin yararlı bir referans listesi var

Performans genellikle insanların bölümlere ayrılmasının 1 numaralı sebebidir. Şahsen, iyileşme süresindeki gelişmelerin bir VLDB ile eşit veya daha büyük bir fayda olduğunu düşünüyorum. Başlamadan önce kısmi kullanılabilirliği ve parça parça geri yüklemeyi anlamak için biraz zaman ayırın , çünkü bu yaklaşımı etkileyebilir.

Ağ üzerinden yedek gönderme için ideal olmayan ancak nadir olmayan bir işleminiz varsa, mevcut 600 GB'ınız için 3 saatlik bir geri yükleme süresine bakıyor olabilirsiniz. 1,5 TB'ı ihlal ettiğiniz bir yılda bir sorununuz var.

Söylediğiniz gibi, burada iki seçeneğiniz var:

1. Birden çok tablo kullanma
2. Bölümlemeyi Kullanın

1 ile, tüm bu tabloları bir araya getiren bir GÖRÜNÜM oluşturabilir ve yeni oluşturulan tabloları içerecek şekilde güncelleyebilirsiniz. Bunun gerçekten bölümlemeyi taklit etmenin bir yolu olduğunu düşünüyorum. Bu yöntemin artıları arasında SQL Server Enterprise Edition gerektirmez.

2 ile dizinlerinizi bölümlerinize hizalayabilir ve bölümlerinizi farklı depolama alanlarına hizalayabilirsiniz. Bölüm işlevinizi ve bölüm düzeninizi ayarladıktan sonra, bölümleri böldüğünüzde veya birleştirdiğinizde bu işlem sizin için yapılır. Bu yöntemin avantajları, kayıtları manuel olarak yeni bir tabloya taşımak zorunda kalmamayı içerir. Bölümleme işlevi ve bölümleme düzeni bunu sizin için halleder. Ayrıca, dediğin gibi, verilere erişmek için çok az veya hiç kod değişikliği gerekmez.

Enterprise Edition sürümünüz varsa, bölümlemeye kesinlikle bir göz atacağım. Ne kadar karmaşık görünse de, o kadar da kötü değil. Değilse, bölümleme sizin için bir seçenek bile değildir.

Bölümlenmiş Tablolar Oluşturma

Bölümlenmiş Tabloları Değiştirme

Veri Altkümelerini Yönetmek için Bölümler Tasarlama

Bu yardımcı olur umarım,

Mat

Sorunuzdan geçmiş verileri (günlükler) depolamış gibi görünüyorsunuz ve sınırlamanız depolama odası sorunlarından değil sorgu hızından kaynaklanıyor gibi görünüyor. Benim için bölme yardımcı olmaz.

Uygun dizinlere sahip olduğunuzu söylediğinizde, tarih alanında bir dizin içeriyor mu? Postgres ile trunc (zaman damgası, gün) endeksi kullanarak iyi sonuçlar elde ettim. Daha sonra, diğer sorgulamalardan önce tüm sorguların günde seçildiğinden emin olmalısınız. Dikkatli olun, saat dilimi alanına sahip bir zaman damgası dizine eklenemez (çünkü saat dilimine bağlı olarak "hareket eder"), bu nedenle dizine eklenecek "sabit" bir zaman damgasına ihtiyacınız vardır.