Alternative Möglichkeit, NVARCHAR (MAX) zu komprimieren?

14

Ich versuche, einige Tabellen mit NVARCHAR(MAX)Feldern zu komprimieren . Leider haben die rowund die pageKomprimierung nicht die gewünschte Auswirkung (nur ~ 100/200 MB für 20-GB-Tabelle gespeichert). Außerdem kann ich keine Archivkomprimierungen für Spaltenspeicher und Spaltenspeicher anwenden, da sie die Komprimierung von NVARCHAR(MAX)Feldern nicht unterstützen .

Kann jemand sagen, ob ich hier Alternativen habe?

Ich denke auch, dass die Komprimierung rowund pagekeine Auswirkungen haben, da der Inhalt der NVARCHAR(MAX)Spalten eindeutig ist.

sql-server sql-server-2014 compression

— gotqn
quelle

2

Sind die Spaltenwerte definitiv breiter als 8000 Zeichen? zB SELECT MAX (CAST (LEN (breite Spalte) AS BIGINT)) FROM dbo.largeTable Andernfalls könnten Sie sie in gewöhnliche varchar konvertieren und Clustered Columnstore anwenden.

— wBob

@wBob Selbst wenn der größte Wert nur 2000 Zeichen betrug, würde eine Konvertierung nicht zu VARCHARDatenverlusten führen, wenn Zeichen aus mehr als einer Codepage verwendet werden? Ich würde denken, der Rat sollte sein, umzuwandeln, NVARCHAR(4000)wenn die maximale Länge nicht größer als 4000 ist, weil dann alle Werte für die volle Unicode-Komprimierung geeignet wären. Dennoch ist es wahrscheinlich sicher anzunehmen, dass die Werte weit über 4000 Zeichen liegen, weshalb sie derzeit nicht komprimiert werden.

— Solomon Rutzky

16

Sowohl die Seiten- als auch die Zeilenkomprimierung komprimieren keine BLOBs .

Datentypen mit großen Werten werden aufgrund ihrer Größe manchmal getrennt von den normalen Zeilendaten auf Spezialseiten gespeichert. Für die Daten, die separat gespeichert werden, ist keine Datenkomprimierung verfügbar.

Wenn Sie BLOBs komprimieren möchten, müssen Sie diese als speichern VARBINARY(MAX)und den gewünschten Stream-Komprimierungsalgorithmus anwenden. Zum Beispiel GZipStream. Es gibt viele Beispiele dafür, suchen Sie einfach nach GZipStream und SQLCLR.

— Remus Rusanu
quelle

10

Es gibt (jetzt) möglicherweise zwei Möglichkeiten, eine benutzerdefinierte Komprimierung durchzuführen:

Ab SQL Server 2016 gibt es integrierte Funktionen für COMPRESS und DECOMPRESS . Diese Funktionen verwenden den GZip-Algorithmus.
Verwenden Sie SQLCLR, um einen beliebigen Algorithmus zu implementieren (wie @Remus in seiner Antwort erwähnt). Diese Option ist in Versionen vor SQL Server 2016 verfügbar und reicht bis zu SQL Server 2005 zurück.

GZip ist eine einfache Wahl, da es in .NET und in den unterstützten .NET Framework-Bibliotheken verfügbar ist (der Code kann sich in einer SAFEAssembly befinden). Wenn Sie GZip verwenden möchten, sich aber nicht mit dem Codieren / Bereitstellen befassen möchten, können Sie die Funktionen Util_GZip und Util_GUnzip verwenden, die in der kostenlosen Version der SQL # SQLCLR-Bibliothek (deren Autor ich bin) verfügbar sind .

Wenn Sie sich für die Verwendung von GZip entscheiden, unabhängig davon, ob Sie es selbst codieren oder SQL # verwenden, beachten Sie, dass sich der in .NET für die GZip-Komprimierung verwendete Algorithmus in Framework Version 4.5 zum Besseren geändert hat (siehe Abschnitt "Hinweise" im MSDN) Seite für die GZipStream-Klasse ). Das heisst:
1. Wenn Sie SQL Server 2005, 2008 oder 2008 R2 verwenden - alle mit CLR v 2.0 verknüpft, das die Framework-Versionen 2.0, 3.0 und 3.5 unterstützt -, hat die in Framework-Version 4.5 vorgenommene Änderung keine Auswirkungen und Sie bleiben leider hängen .NETs ursprünglicher, nerviger Algorithmus.
2. Wenn Sie SQL Server 2012 oder neuer (bisher 2014 und 2016) verwenden - alle mit CLR v 4.0 verknüpft, das die Framework-Versionen 4.0, 4.5.x und 4.6 unterstützt - können Sie den neueren, besseren Algorithmus verwenden. Die einzige Voraussetzung ist, dass Sie .NET Framework auf dem Server, auf dem SQL Server ausgeführt wird, auf Version 4.5 oder höher aktualisiert haben.
Sie müssen jedoch nicht GZip verwenden und können beliebige Algorithmen implementieren.

BITTE BEACHTEN SIE: Alle oben genannten Methoden sind eher "Workarounds" als tatsächliche Ersetzungen, obwohl sie technisch "alternative Wege zur Komprimierung von NVARCHAR (MAX) -Daten" darstellen. Der Unterschied besteht darin , dass mit der eingebauten in Data Compression - rowund page- angeboten von SQL Server wird die Kompression hinter den Kulissen und die Daten sind noch brauchbar, lesbar und Wende behandelt. Das Komprimieren beliebiger Daten VARBINARYbedeutet jedoch, dass Sie Platz sparen, jedoch einige Funktionen aufgeben. Zwar ist eine 20k-Zeichenfolge ohnehin nicht indizierbar, sie kann jedoch weiterhin in a verwendet werdenWHEREKlausel oder mit beliebigen String-Funktionen. Um irgendetwas mit einem benutzerdefinierten komprimierten Wert zu tun, müssten Sie ihn sofort dekomprimieren. Beim Komprimieren von Binärdateien (PDFs, JPEGs usw.) ist dies kein Problem, diese Frage war jedoch spezifisch für NVARCHARDaten.

— Solomon Rutzky
quelle