SQL Server'dan alınan veriler iletim için sıkıştırılmış mı?


20

Microsoft SQL Server'dan alınan veriler sıkıştırılıyor mu? Bu bağlantı dizesi tarafından denetleniyorsa, belirli bir uygulamanın onu kullanıp kullanmadığını anlamanın basit bir yolu var mı?

Analiz araçlarını inceliyorum ve veri hacminin ağımız üzerinden iletilmesi birkaç dakika sürebilir. Aynı uzak sunucudaki sıkıştırılmış bir veri deposundan veri alırsak performans artışı beklemem gerekip gerekmediğini merak ediyorum.

Konuyla ilgili olduğumuz sürece, merak ediyorum: veriler ikili veya ASCII'de mi aktarılıyor? Örneğin, değer 12345bir INTsütundan sorgulanırsa , beş bayt 0x31, 0x32, 0x33, 0x34, 0x35; değer için gereken iki bayt; veya sütun için gerekli olan dört bayt mı?

Açık olmak gerekirse, verileri sıkıştırma ile depolama ve yedekleme ile ilgili seçenekler olduğunu anlıyorum . Verilerin nasıl aktarıldığını soruyorum.


Sıkıştırma dahili bir mekanizmadır. Bir sayfa diskte ve arabellek havuzunda sıkıştırılır, ancak tel üzerinde düzenli bir bayt akışı bulunur. @ShawnMelton, daha önce tel biçimini koklama hakkında blog yazdı ve umarım vurgularla yanıt verecektir.
Mark Storey-Smith

Yazdığım şey şifrelenip şifrelenmediğine daha fazla odaklanıyordu. Tamsayı değerlerini denememe rağmen, okunabilir biçimde çektiğim verileri seçebildim. Kesin olarak bilmenin tek yolu sadece kurulum ve denemek: mssqltips.com/sqlservertip/2436/…
Shawn Melton

@ MarkStorey-Smith: Cevap "hayır", veriler sıkıştırılmıyor mu? Bu utanç verici, ancak bu büyük sorguların iletilmesinin neden bu kadar uzun sürdüğünü açıklamaya yardımcı oluyor. Fiziksel olarak daha yakın bir önbelleğe ihtiyacım var gibi görünüyor. Bunu gerçek bir cevap haline getirmek isterseniz, kabul edeceğim.
Tüm Ticaret'ten Jon

@ShawnMelton: Kesinlikle bunu yapmanın doğru yolu gibi geliyor, sadece doğru katmana ulaşmak ve gördüğüm şeyden emin olmak için yeterli ağ geçmişim yok. Neyse ki benim için daha fazla beceri ve daha fazla zamanı olan insanlar var!
Tüm Ticaret'ten Jon

Yanıtlar:


16

Sıkıştırmak istediğiniz veriler tel üzerinden TDS aracılığıyla gönderilen verilerdir . Burada bazı küçük sıkıştırmalar var, ancak sayfa / satır sıkıştırma, yedekleme sıkıştırma veya ColumnStore sıkıştırma ile elde ettiğiniz sıkıştırma türünün yakınında hiçbir yerde yok.

Daha önce istendi:

http://connect.microsoft.com/SQLServer/feedback/details/412131/enable-network-compression-compress-tds-stream

http://connect.microsoft.com/SQLServer/feedback/details/377479/wan-compression-option

Öğeler hala açık, bu yüzden belki biraz umut var. Bunu şimdiye kadar gördüğüm bağlantı dizesi aracılığıyla kontrol etmenin bir yolu yok.

Bu arada, bunu iddia eden bazı ürünler var, ör.

http://www.nitrosphere.com/products/nitroaccelerator/

http://toonel.net/tcpany.htm

Ayrıca, SQL Server ile uygulama sunucuları arasındaki ağı sıkıştırmayı (ve şifreleme gibi diğer şeyleri) destekleyecek şekilde yapılandırabilirsiniz, ancak buradaki kapsamımın dışındasınız ve bunun SQL'in her bir özelliği tarafından desteklenip desteklenmeyeceğinden emin değilim Sunucusu.

Ve dürüst olmak gerekirse, bu optimizasyona odaklanmak istediğiniz yer olduğuna ikna olmadım. Bu akışı sıkıştırmak aslında işleri yavaşlatabilir ve daha az bayt göndermenin avantajlarından daha ağır basabilir. Bu tür işlere yatırım yapmak ve gerçek faydaları olup olmadığını test etmek ve daha sonraya kadar bunu yapamamak yerine, sunucu ve istemci (ler) arasında daha iyi ağ bağlantısına para yatırmayı tercih ederim. 10 / 100'den gig fiber'e kadar ağ G / Ç üzerinde bilinen ve tahmin edilebilir bir etkisi vardır.


Tel üzerinden gönderilen baytların biçiminden emin değilim; bunun için bir çeşit paket dinleyicisi ayarlamanız gerekecek (ya da belki birisi bunu zaten yapmış ve içine girecek).

Sıkıştırma etkisine gelince, Fusion-IO veya diğer üst düzey SSD tipi çözümler üzerinde değilseniz, neredeyse kesinlikle G / Ç'ye bağlısınız ve CPU'ya bağlı değilsiniz. CPU yükünüz olduğu sürece, sıkıştırma etkinken daha hızlı performans görmelisiniz (ancak veriler iletimden önce sıkıştırılmamış olduğundan performansını değiştirmez ). Sunucularınız, uygulamanız, verileriniz veya kullanım alışkanlıklarınız hakkında hiçbir şey bilmediğinizde, sıkıştırmanın gerçekte performansa zarar verdiği veya verilerin iyi sıkıştırma oranları için iyi bir aday olmadığı çok iyi bir durumunuz olabileceğini söylüyorum.


En azından 10s MB iletirken kesinlikle sorun olan ağ. Verileri RDP'de sunucunun kendisinde saniyeler içinde sorgulayabilirim, ancak adı geçen sunucu fiziksel olarak durum dışındadır ve bu nedenle verileri iş yerinde bir bilgisayara kopyalar - basit dosya opuyla veya yerel bir bilgisayardan bana sorgulayarak - dakikalar alır.
Tüm Ticaret'ten Jon

Bu yüzden belki de çoğaltmanız, yansıtmanız veya başka bir şey yapmanız ve verileri kopyadan yerel olarak sorgulamanız gerekir. Bu şekilde gecikme son kullanıcılar tarafından hissedilmez. Buna nasıl yaklaşacağınız, verilerin ne kadar taze olması gerektiğine bağlıdır. Ayrıca, bir kerede 10 MB veriyi sorgulamak için gerçekten bir son kullanıcıya ihtiyacınız olup olmadığı.
Aaron Bertrand

Kesinlikle. BI sunucusunun yerini değiştiremezsek. Verilerin hacmi ile ilgili olarak, analiz (QlikView, ATM kullanarak), yani yıllarca veri ve birçok boyut ve gerçek içindir. Dosyalar 100 MB'a kadar sıkıştırma ile değişir ve bu sadece birkaç yıllık veriler içindir!
Tüm Ticaret'ten Jon

@JonofAllTrades En iyi niyetlerle kastedilen ... yanlış problemi yanlış çözümle çözmeye çalıştığınız anlaşılıyor.
Mark Storey-Smith

@ MarkStorey-Smith: Alternatif nedir? Çok fazla veri var ve WAN'ımıza erişmek yavaş. Aaron'un belirttiği gibi, bir çeşit yerel önbellek yardımcı olacaktır. İletilen veri hacminin azaltılması, görsel veri keşfinin amacını yenen kullanıcıların analiz kapsamını azaltacaktır.
Tüm Ticaret'ten Jon

4

Microsoft SQL Server'dan alınan veriler sıkıştırılıyor mu? Bu bağlantı dizesi tarafından denetleniyorsa, belirli bir uygulamanın onu kullanıp kullanmadığını anlamanın basit bir yolu var mı?

Teknik olarak, sonuçlar olabilir sıkıştırılacaktır çok hafif .

İlk olarak SQL Server 2008 R2 tarafından desteklenen Tablo Veri Akışı (TDS) 7.3B , birden çok null içeren satırların null alan değerleri için normalde gerekenden daha az bayt kullanılarak iletilmesine izin veren null bitmap sıkıştırma adı verilen bir şey sundu .

Sunucu, sonuçları gönderirken normal satırları boş bitmap sıkıştırılmış satırlarla karıştırabilir. İstemcinin bunun üzerinde bir kontrolü yoktur, bu nedenle ilgili istemci tarafı yapılandırma seçenekleri yoktur.

Boş bitmap, şu anda TDS tarafından desteklenen tek sıkıştırma biçimidir. Bir satır boş bitmap sıkıştırılmış değilse, sıkıştırılmamış olarak gönderilir.

Konuyla ilgili olduğumuz sürece, merak ediyorum: veriler ikili veya ASCII'de mi aktarılıyor?

Metin olmayan veri türlerine sahip sütunlar , TDS protokolü tarafından tanımlanan bir ikili biçim kullanılarak iletilir .


2

Başka bir yerde belirtildiği gibi , bu soruna geçici bir çözüm bulmak için bir VPN kurmayı ve sıkıştırmayı etkinleştirmeyi düşünebilirsiniz.

Diğerlerinin söylediği gibi, SQL Server TDS Protokolü'nde yerleşik bir sıkıştırma yoktur. Ayrıca varsayılan olarak şifreleme olmadığını da belirtmek gerekir. Şifrelemeyi etkinleştirmek için sertifikaları kullanmanız ve bağlantı dizelerinde belirtmeniz gerekir.

Her iki sorunu da çözmenin en kolay çözümü şifreleme ve sıkıştırma etkinleştirilmiş bir VPN tüneli açmaktır. Basit Microsoft PPTP her iki sorunu da çözer ve kurulumu kolaydır.


1

Neden ilgili verileri önbelleğe alan ve her n saatte bir eşitlenen yerel bir SQL örneği kurmuyorsunuz? Bakılacak diğer bir şey küpleri önceden hesaplamak ve bir özet hücresine ulaştığınızda bir 'ayrıntıları al' düğmesine sahip olmaktır. Bu, yalnızca ilgili ayrıntılı satırları getirir.


İlk cümleniz bu yoruma çok benziyor .
Aaron Bertrand
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.