Comment puis-je minimiser datatables dans une réplication SQL

Je veux reproduire datatables d'un bateau au large d'un site terrestre. La connection est parfois via une binding par satellite et peut être lente et avoir une latence élevée.

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

Il y a une table en cours de réplication, composée d'un ID, d'un datetime et de certaines données binarys dont la longueur peut varier, généralement <50 octets.

Une application off-shore pousse datatables (mesures matérielles) dans la table en permanence et nous voulons ces données à terre aussi vite que possible.

Existe-t-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 (tout en transférant les mêmes données dans le même laps de time). C'est sans aucun contrôle de fiabilité et d'intégrité donc ce nombre est artificiellement bas.

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 ici .

Avez-vous envisagé d'acheter un accélérateur WAN? Je suis trop nouveau ici pour postr un lien, mais il y en a plusieurs disponibles.

Essentiellement, l'appareil à l'extrémité émetsortingce compresse datatables sortantes, et l'extrémité récepsortingce les décompresse, toutes à 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 server. Cela devrait être entièrement transparent.

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

Je ne sais rien mais je suis sûr que ceux-ci existent.

Ne plaisante pas avec les files SQL directement. C'est de la folie sinon impossible.

Pensez-vous que ce soit toujours une seule table qui est 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 optimization 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'logging de 5 ou 10 caractères dans le nom du sproc est significatif.

Je suppose que si vous mettez à jour le champ binary, il s'agit généralement d'un rlocation 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 que blob personnalisé dans une table répliquée et disposer d'un process 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.