Wie kann ich die Daten in einer SQL-Replikation minimieren?

Question

Ich möchte Daten von einem Boot Offshore zu einem Onshore-Standort replizieren. Die Verbindung erfolgt manchmal über eine Satellitenverbindung und kann langsam sein und eine hohe Latenz haben.

Latenz in unserer Anwendung ist wichtig, die Leute on-shore sollten die Daten so bald wie möglich haben.

Es wird eine Tabelle repliziert, bestehend aus einer ID, datetime und einigen Binärdaten, die in der Länge variieren können, normalerweise < 50 Bytes.

Eine Anwendung off-shore schiebt Daten (Hardware-Messungen) ständig in die Tabelle und wir wollen diese Daten so schnell wie möglich on-shore.

Gibt es Tricks in MS SQL Server 2008, die helfen können, die Bandbreitenauslastung zu verringern und die Latenz zu verringern? Der erste Test verwendet eine Bandbreite von 100 kB/s.

Unsere Alternative ist unsere eigene Datenübertragung zu übertragen und das erste Prototyping verwendet hier eine Bandbreite von 10 kB/s (während die gleichen Daten in der gleichen Zeitspanne übertragen werden). Dies erfolgt ohne Zuverlässigkeits- und Integritätsprüfungen, so dass diese Anzahl künstlich niedrig ist.

Answer 1

Sie können verschiedene Replikationsprofile ausprobieren oder eigene erstellen. Verschiedene Profile sind für verschiedene Netzwerk-/Bandbreiten-Szenarien optimiert.

MSDN spricht über Replikationsprofile here.

Answer 2

Ich würde on-the-fly-Komprimierung/Dekomprimierung außerhalb von SQL Server vorschlagen. Das heißt, SQL repliziert die Daten normal, aber etwas im Netzwerkstapel komprimiert, so dass es viel kleiner und bandbreiteneffizient ist.

Ich weiß nichts, aber ich bin sicher, dass diese existieren.

Machen Sie sich nicht direkt mit den SQL-Dateien herum. Das ist Wahnsinn, wenn nicht unmöglich.

Answer 3

Erwarten Sie, dass immer nur eine Tabelle repliziert wird? Gibt es viele Updates oder nur Inserts? Die Replikation wird implementiert, indem ein Einfüge-/Aktualisierungs-Sproc für jede geänderte Zeile auf dem Ziel aufgerufen wird. Eine günstige Optimierung besteht darin, den Namen des Sprocs klein zu halten. Standardmäßig besteht es aus dem Tabellennamen, aber IIRC können Sie einen anderen Sproc-Namen für den Artikel erzwingen. Bei einer Einfügung von etwa 58 Byte für eine Zeile ist das Speichern von 5 oder 10 Zeichen im Namen des Sprocs von Bedeutung.

Ich würde vermuten, dass, wenn Sie das Binärfeld aktualisieren, es in der Regel ein vollständiger Ersatz ist? Wenn das falsch ist und Sie möglicherweise einen kleinen Teil ändern, können Sie Ihren eigenen Diff-Patching-Mechanismus auslösen. Vielleicht eine zweite Tabelle, die eine Zeitreihe von Byte-Änderungen zu den Originalen enthält. Klingt wie ein Schmerz, könnte aber enorme Bandbreitenänderungen je nach Arbeitslast haben.

Werden die Einsätze in der Regel in logischen Stapeln ausgeführt? Wenn dies der Fall ist, können Sie einen Stapel von Einfügungen als einen benutzerdefinierten Blob in einer replizierten Tabelle speichern und einen zweiten Prozess ausführen, der sie in die endgültige Tabelle entpackt, mit der Sie arbeiten möchten. Dies würde den Overhead dieser kleinen Zeilen reduzieren, die durch die Replikation fließen.

Answer 4

Haben Sie darüber nachgedacht, eine WAN-Beschleuniger-Appliance zu erhalten? Ich bin hier zu neu, um einen Link zu posten, aber es sind mehrere verfügbar.

Im Wesentlichen das Gerät auf der Senderseite komprimiert die ausgehenden Daten und die Empfangsseite dekomprimiert sie alle im Fluge und völlig unsichtbar.Dies hat den Vorteil, dass die scheinbare Geschwindigkeit des Datenverkehrs erhöht wird und Sie Ihre Serverkonfigurationen nicht ändern müssen. Es sollte völlig transparent sein.