Comment puis-je réduire les données dans une réplication SQL?

Question

Je souhaite répliquer des données d'un bateau vers un site onshore. La connexion est parfois via une liaison par satellite et peut être lente et avoir une latence élevée.

La latence dans notre application est importante, les gens à terre devraient avoir les données dès que possible.

Une table est en cours de réplication. Elle se compose d'un ID, d'un datetime et de certaines données binaires dont la longueur peut varier, généralement < 50 octets.

Une application offshore pousse constamment des données (mesures matérielles) dans la table et nous voulons ces données à terre aussi rapidement que possible. Y at-il des astuces dans MS SQL Server 2008 qui peuvent aider à réduire l'utilisation de la bande passante et à réduire la latence? Les tests initiaux utilisent une bande passante de 100 kB/s. Notre alternative est de rouler notre propre transfert de données et le prototypage initial utilise ici une bande passante de 10 kB/s (en transférant les mêmes données dans le même laps de temps). C'est sans aucun contrôle de fiabilité et d'intégrité donc ce nombre est artificiellement bas.

Answer 1

Vous pouvez essayer différents profils de réplication ou créer les vôtres. Différents profils sont optimisés pour différents scénarios de réseau/bande passante. MSDN parle de profils de réplication here.

Answer 2

Je suggérerais à la volée la compression/décompression en dehors de SQL Server. En d'autres termes, SQL réplique les données normalement, mais quelque chose se compresse dans la pile réseau, ce qui réduit considérablement la bande passante.

Je ne connais rien, mais je suis sûr qu'ils existent.

Ne plaisantez pas directement avec les fichiers SQL. C'est de la folie sinon impossible.

Answer 3

Vous attendez-vous toujours à ce qu'une seule table soit répliquée? Y a-t-il beaucoup de mises à jour, ou juste des insertions? La réplication est implémentée en appelant un sproc d'insertion/mise à jour sur la destination pour chaque ligne modifiée. Une optimisation bon marché consiste à forcer le nom du sproc à être petit. Par défaut, il est composé à partir du nom de la table, mais IIRC vous pouvez forcer un nom de sproc différent pour l'article. Étant donné une insertion d'environ 58 octets pour une ligne, l'enregistrement de 5 ou 10 caractères dans le nom du sproc est significatif.

Je suppose que si vous mettez à jour le champ binaire, il s'agit généralement d'un remplacement complet? Si cela est incorrect et que vous pourriez en changer une petite partie, vous pouvez lancer votre propre mécanisme de correction de diff. Peut-être une deuxième table qui contient une série chronologique d'octets change-t-elle aux originaux. Ça a l'air d'être pénible, mais il pourrait y avoir d'énormes économies de bande passante en fonction de votre charge de travail.

Les inserts sont-ils généralement réalisés en lots logiques? Si tel est le cas, vous pouvez stocker un lot d'insertions en tant qu'un blob personnalisé dans une table répliquée et disposer d'un processus secondaire qui les décompresse dans la table finale avec laquelle vous souhaitez travailler. Cela réduirait les frais généraux de ces petites lignes qui traversent la réplication.

Answer 4

Avez-vous envisagé d'acquérir un accélérateur WAN? Je suis trop nouveau ici pour poster un lien, mais il y en a plusieurs disponibles. Essentiellement, l'appareil à l'extrémité de l'envoi comprime les données sortantes, et l'extrémité de réception les décompresse, à la volée et de manière totalement invisible.Cela a l'avantage d'augmenter la vitesse apparente du trafic et ne vous oblige pas à modifier vos configurations de serveur. Cela devrait être entièrement transparent.