Как я могу минимизировать данные в репликации SQL

Question

Я хочу скопировать данные с лодки на море на береговой участок. Соединение иногда осуществляется через спутниковую связь и может быть медленным и иметь большую задержку.

Задержка в нашем приложении важна, люди на берегу должны иметь данные как можно скорее.

Существует одна реплицируемая таблица, состоящая из идентификатора, даты и времени и некоторых двоичных данных, длина которых может варьироваться, обычно <50 байтов. </p>

Прикладное оффшорное приложение постоянно помещает данные (аппаратные измерения) в таблицу, и мы хотим, чтобы эти данные были максимально быстрыми.

Есть ли в MS SQL Server 2008 какие-либо хитрости, которые могут помочь уменьшить использование полосы пропускания и уменьшить задержку? При первоначальном тестировании используется полоса пропускания 100 кБ / с.

Наша альтернатива состоит в том, чтобы развернуть нашу собственную передачу данных, и при первоначальном прототипировании здесь используется полоса пропускания 10 кБ / с (при передаче тех же данных за один и тот же промежуток времени). Это без каких-либо проверок надежности и целостности, поэтому это число искусственно мало.

Answer 1

Рассматривали ли вы получить ускорительное устройство WAN? Я слишком новичок, чтобы опубликовать ссылку, но есть несколько доступных.

По сути, устройство на передающей стороне сжимает исходящие данные, а принимающая сторона распаковывает их, все на лету и совершенно незаметно. Это дает преимущество в увеличении кажущейся скорости трафика и не требует изменения конфигурации вашего сервера. Это должно быть полностью прозрачным.

Answer 2

Вы можете попробовать разные профили репликации или создать свой собственный. Различные профили оптимизированы для разных сценариев сети / полосы пропускания.

MSDN говорит о профилях репликации здесь .

Answer 3

Ожидаете ли вы, что это всегда будет только одна таблица, которая реплицируется? Много ли обновлений или просто вставок? Репликация осуществляется путем вызова sproc вставки / обновления в месте назначения для каждой измененной строки. Одна дешевая оптимизация - заставить имя sproc быть маленьким. По умолчанию он составлен из имени таблицы, но IIRC вы можете использовать другое имя для статьи. Учитывая, что в строку вставлено около 58 байт, сохранение 5 или 10 символов в имени sproc имеет большое значение.

Я бы предположил, что если вы обновите двоичное поле, то это, как правило, полная замена? Если это неверно и вы можете изменить небольшую часть, вы можете запустить свой собственный механизм исправления различий. Возможно, вторая таблица содержит временные ряды байтовых изменений в оригиналах. Звучит как боль, но может значительно сэкономить на изменении пропускной способности в зависимости от вашей рабочей нагрузки.

Вставки обычно выполняются в логических пакетах? Если это так, вы можете сохранить пакет вставок как один настроенный большой двоичный объект в реплицированной таблице и получить дополнительный процесс, который распакует их в финальную таблицу, с которой вы хотите работать. Это уменьшит накладные расходы этих небольших строк, проходящих через репликацию.

Answer 4

Я бы предложил на лету сжатие / распаковку вне SQL Server. Таким образом, SQL реплицирует данные в обычном режиме, но что-то в сетевом стеке сжимается, так что оно намного меньше и эффективно использует пропускную способность.

Я ничего не знаю, но я уверен, что они существуют.

Не связывайтесь с файлами SQL напрямую. Это безумие, если не невозможно.