Performansı artırmak için denormalizasyon? Kulağa ikna edici geliyor, ama su tutmuyor.
Dr Ted Codd ile ilişkisel veri modelinin orijinal savunucusu olan Chris Date, normalleşmeye karşı yanlış bilgilendirilmiş argümanlarla sabırsız kaldı ve bunları bilimsel yöntemle sistematik olarak yıktı: büyük veritabanları aldı ve bu iddiaları test etti .
Onun içinde o kadar yazdım düşünüyorum İlişkisel Veritabanı Yazıları 1988-1991 ama bu kitap sonradan sürümüne altı içine yuvarlandı edildi Veritabanı Sistemlerine Giriş olup, ben yazmak ve muhtemelen kalması olarak veritabanı teorisi ve tasarım üzerine kesin metin onun sekizinci baskısında, onlarca yıldır baskıda. Çoğumuz yalınayak koşarken Chris Date bu alanda uzmandı.
Bunu buldu:
- Bazıları özel durumlar için geçerlidir
- Hepsi genel kullanım için ödeme yapamıyor
- Diğer özel durumlar için hepsi önemli ölçüde daha kötü
Her şey çalışma setinin boyutunu azaltmak için geri geliyor. Doğru şekilde ayarlanmış dizinlere sahip doğru seçilmiş anahtarları içeren birleşimler ucuzdur, pahalı değildir, çünkü satırlar gerçekleşmeden önce sonucun önemli ölçüde budamasına izin verirler .
Sonucun somutlaştırılması, egzersizin en pahalı yönü olan toplu disk okumalarını büyüklük sırasına göre içerir. Buna karşılık bir birleştirme gerçekleştirmek için mantıksal olarak yalnızca anahtarların alınması gerekir . Uygulamada, anahtar değerler bile alınmaz: birleştirme karşılaştırmaları, çok sütunlu birleşmelerin maliyetini azaltmak ve dize karşılaştırmaları içeren birleşimlerin maliyetini önemli ölçüde azaltmak için anahtar karma değerleri kullanılır. Sadece önbelleğe daha fazla sığmakla kalmaz, daha az disk okuması da yapar.
Dahası, iyi bir iyileştirici en kısıtlayıcı koşulu seçecek ve bir birleşim yapmadan önce uygulayacak ve yüksek kardinaliteye sahip endekslerde birleşimlerin yüksek seçiciliğinden çok etkili bir şekilde yararlanacaktır.
Kuşkusuz bu tür bir optimizasyon, denormalize edilmiş veritabanlarına da uygulanabilir, ancak bir şemayı denormalize etmek isteyen insanlar tipik olarak endeksler kurduklarında (eğer) kardinalite hakkında düşünmezler.
Tablo taramalarının (birleştirme sırasında bir tablodaki her satırın incelenmesi) pratikte nadir olduğunu anlamak önemlidir. Bir sorgu iyileştirici, yalnızca aşağıdakilerden biri veya daha fazlası bekletildiğinde tablo taraması seçer.
- İlişkide 200'den az satır var (bu durumda tarama daha ucuz olacaktır)
- Birleştirme sütunlarında uygun dizinler yoktur (bu sütunlara katılmak anlamlıysa neden dizine eklenmez? Düzeltin)
- Sütunların karşılaştırılması için bir tür zorlama gerekir (WTF ?! düzeltin veya eve gidin) ADO.NET SORUNU İÇİN SON NOTLARA BAKIN
- Karşılaştırmanın argümanlarından biri bir ifade (dizin yok)
Bir işlemi gerçekleştirmek, gerçekleştirmekten daha pahalıdır. Ancak yanlış işlemi gerçekleştirmek, anlamsız disk G / Ç'sine zorlamak ve daha sonra gerçekten ihtiyacınız olan birleştirme işlemini gerçekleştirmeden önce çapağı atmak çok daha pahalıdır. "Yanlış" işlem önceden hesaplanmış ve endeksler hassas bir şekilde uygulanmış olsa bile, önemli cezalar kalmaktadır. Bir birleştirmeyi önceden hesaplamak için denormalize etmek - ilgili güncelleme anormalliklerine rağmen - belirli bir birleştirmeye bağlılıktır. Farklı bir birleşime ihtiyacınız varsa , bu taahhüt size büyük bir maliyet getirecektir .
Eğer birisi bana bunun değişen bir dünya olduğunu hatırlatmak isterse, bence daha büyük donanımlardaki daha büyük veri kümelerinin Date'nin bulgularının yayılmasını abarttığını göreceksiniz.
Faturalandırma sistemleri veya önemsiz posta jeneratörleri (utanç verici) üzerinde çalışan ve öfkeyle klavyeye elinizdeki herkes için, denormalizasyonun daha hızlı, özür dilerim ama özel vakalar - özellikle tüm verileri sırayla işleme koyduğunuz durumdur . Genel bir durum değildir, ve sen edilir senin stratejisinde haklı.
Sen edilir değil yanlış bunu generalising haklı. Veri ambarı senaryolarında denormalizasyonun uygun kullanımı hakkında daha fazla bilgi için notlar bölümünün sonuna bakın.
Ayrıca cevap vermek istiyorum
Birleşimler sadece bazı lipgloss içeren kartezyen ürünlerdir
Ne bollocks bir yük. Kısıtlamalar mümkün olduğunca erken, en kısıtlayıcı olarak uygulanır. Teoriyi okudunuz, ama anlamadınız. Birleşimler, yalnızca sorgu iyileştiricisi tarafından "tahminlerin geçerli olduğu kartezyen ürünler" olarak ele alınır . Bu, sembolik ayrışmayı kolaylaştırmak için sembolik bir temsildir (aslında bir normalizasyon), böylece optimize edici tüm eşdeğer dönüşümleri üretebilir ve bunları en iyi sorgu planını seçebilmesi için maliyet ve seçicilikle sıralayabilir.
Optimize ediciyi kartezyen bir ürün üretmek için almanın tek yolu bir belirti sağlayamamaktır: SELECT * FROM A,B
notlar
David Aldridge bazı önemli ek bilgiler sağlar.
Gerçekten de dizinler ve tablo taramaları dışında çeşitli başka stratejiler de vardır ve modern bir optimize edici bir yürütme planı oluşturmadan önce hepsine mal olacaktır.
Pratik bir tavsiye parçası: eğer yabancı anahtar olarak kullanılabiliyorsa, onu optimize edin, böylece optimizatör için bir endeks stratejisi kullanılabilir .
MSSQL optimize edicisinden daha akıllıydım. Bu iki versiyon önce değişti. Şimdi genellikle bana öğretiyor . Çok gerçek anlamda, bir alanda çok zeki insanın tüm bilgeliğini kodlayan, kural tabanlı bir sistemin etkili olduğunu yeterince kapatmış bir uzman sistemdir.
"Bollocks" dokunmamış olabilir. Daha az kibirli olmam isteniyor ve matematiğin yalan söylemediğini hatırlatıyorum. Bu doğrudur, ancak matematiksel modellerin tüm sonuçları mutlaka tam anlamıyla alınmamalıdır. Negatif sayıların kare kökleri, saçmalıklarını dikkatle incelemekten (orada ceza) kaçarsanız ve denkleminizi yorumlamaya çalışmadan önce hepsini iptal ettiğinizden emin olursanız çok kullanışlıdır.
Bu kadar vahşice cevap vermemin nedeni, ifadedeki ifadenin
Katıldı olan kartezyen ürünleri ...
Bu kastedilen şey olmayabilir ama yazılan şey budur ve kategorik olarak yanlıştır. Kartezyen bir ürün bir ilişkidir. Birleştirme bir işlevdir. Daha spesifik olarak, bir birleşme ilişki-değerli bir işlevdir. Boş bir yüklem ile kartezyen bir ürün üretecek ve bunun bir veritabanı sorgulama motoru için bir doğruluk kontrolü olduğunu kontrol edecektir, ancak hiç kimse pratikte sınırsız birleşimler yazmaz çünkü sınıf dışında pratik bir değeri yoktur.
Bunu söyledim çünkü okuyucuların, modeli modellenen şeyle karıştırmanın eski tuzağına düşmesini istemiyorum. Bir model, uygun manipülasyon için kasıtlı olarak basitleştirilmiş bir yaklaşımdır.
Tablo taraması birleştirme stratejisinin seçimi için yapılan kesme, veritabanı motorları arasında değişiklik gösterebilir. Ağaç düğümü dolgu faktörü, anahtar / değer boyutu ve algoritmanın incelikleri gibi bir dizi uygulama kararından etkilenir, ancak genel olarak konuşursak, yüksek performanslı indekslemenin k log n + c yürütme süresi vardır . C terimi, çoğunlukla kurulum süresinden oluşan sabit bir ek yüktür ve eğrinin şekli, n yüzlerce oluncaya kadar bir getiri (doğrusal aramaya kıyasla) alamayacağınız anlamına gelir .
Bazen denormalizasyon iyi bir fikirdir
Denormalizasyon, belirli bir birleştirme stratejisine bağlılıktır. Daha önce de belirtildiği gibi, bu diğer birleştirme stratejilerine müdahale eder . Ancak, disk alanı kovaları, öngörülebilir erişim kalıpları ve bunların çoğunu veya tamamını işleme eğilimi varsa, bir birleştirmeyi önceden hesaplamak çok değerli olabilir.
Ayrıca, işleminizin genellikle kullandığı erişim yollarını bulabilir ve bu erişim yolları için tüm birleştirmeleri önceden hesaplayabilirsiniz. Bu, veri ambarlarının arkasındaki öncül ya da en azından, sadece terim uyumu için değil, yaptıklarını neden yaptığını bilen insanlar tarafından inşa edildiğinde.
Düzgün tasarlanmış bir veri ambarı, normalleştirilmiş işlem işleme sisteminden toplu bir dönüşümle periyodik olarak üretilir. Operasyonların ve raporlama veritabanlarının bu şekilde ayrılması, OLTP ve OLAP (çevrimiçi işlem işleme, yani veri girişi ve çevrimiçi analitik işleme, yani raporlama) arasındaki çatışmayı ortadan kaldırmak için çok arzu edilen bir etkiye sahiptir.
Burada önemli bir nokta, periyodik güncellemeler dışında veri ambarının salt okunur olmasıdır . Bu, tartışma anormallikleri sorununu gündeme getiriyor.
OLTP veritabanınızı (veri girişinin gerçekleştiği veritabanı) normalleştirme hatası yapmayın. Faturalama işlemleri için daha hızlı olabilir, ancak bunu yaparsanız güncelleme anormallikleri alırsınız. Hiç bir şey göndermeyi durdurmak için Reader's Digest'i almaya çalıştınız mı?
Disk alanı bu günlerde ucuz, bu yüzden kendinizi dışarı çıkarın. Ancak denormalizasyon veri ambarları için hikayenin sadece bir parçasıdır. Daha büyük performans kazançları önceden hesaplanmış toplanmış değerlerden elde edilir: aylık toplamlar, bu tür şeyler. Her zaman çalışma setini azaltmakla ilgilidir.
Tür uyumsuzluklarında ADO.NET sorunu
Varchar türünde dizinlenmiş bir sütun içeren bir SQL Server tablonuz olduğunu ve bu sütunda bir sorguyu kısıtlayan bir parametre iletmek için AddWithValue kullandığınızı varsayalım. C # dizeleri Unicode'dur, bu nedenle çıkarılan parametre türü VARCHAR ile eşleşmeyen NVARCHAR olacaktır.
VARCHAR'dan NVARCHAR'a genişleyen bir dönüşüm olduğundan dolaylı olarak gerçekleşir - ancak dizine eklemeye veda edin ve nedenini iyi şanslar deyin.
"Disk vuruşlarını say" (Rick James)
Her şey RAM'de önbelleğe alınırsa JOINs, oldukça ucuzdur. Yani, normalleşmenin çok fazla performans cezası yoktur .
"Normalleştirilmiş" bir şema JOINsdiske çok fazla vurursa, ancak eşdeğer "denormalize" şemanın diske vurması gerekmiyorsa, denormalizasyon bir performans yarışması kazanır.
Orijinal yazarın yorumu: Modern veritabanı motorları, birleştirme işlemleri sırasında önbellek hatalarını en aza indirmek için erişim sıralaması düzenlemede çok iyidir. Yukarıdakiler, doğru olsa da, birleşmelerin büyük veriler üzerinde mutlaka sorunlu olduğunu ima ettiği için yanlış yorumlanabilir. Bu, deneyimsiz geliştiriciler tarafından zayıf karar verme sürecine neden olacaktır.