Где узкое место / каковы ошибки при выборе записей с удаленного (связанного) сервера SQL? - PullRequest
Новая
       7

Где узкое место / каковы ошибки при выборе записей с удаленного (связанного) сервера SQL?

4 голосов
/ 07 мая 2011

Я нахожусь в спутниковом офисе, который должен получить некоторые данные из нашего главного офиса для отображения в нашей интрасети.Мы используем MS SQL Server в обоих местах, и мы планируем создать связанный сервер в нашем вспомогательном офисе, указывающем на главный офис.Я считаю, что соединение между ними - это VPN-туннель (это звучит правильно? Что я знаю, я программист!)

Я беспокоюсь о том, чтобы генерировать много трафика через потенциально медленное соединение,Мы будем получать доступ к представлению SQL на сервере главного офиса.Это не много данных (~ 500 записей) после выполнения запроса select, но представление огромно (~ 30000 записей) без запроса.

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

1 Ответ

2 голосов
/ 07 мая 2011

Исходя из того, что вы объяснили, ваше соединение может быть узким местом.

Кроме того, вы можете также рассмотреть возможность кэширования данных в местоположении спутника.
Решение будет зависеть от следующего:
-сколько строк и как часто данные обновляются в основной базе данных
- как часто вам нужно загружать один и тот же набор данных в местоположении спутника

Два крайних примера:

  1. Данные статические или относительно статические - вставляются только в основную БД.В спутниковом местоположении пользователи часто запрашивают одни и те же данные снова и снова.В этом случае имеет смысл кэшировать данные локально в местоположении спутника.

  2. Данные изменчивы, много обновлений и / или удалений.Пользователи в спутниковом местоположении редко запрашивают данные, и когда они делают, это всегда отличается, где условие.В этом случае нет смысла кэшировать.Если соединение медленное и часто происходят изменения, вы можете никогда не синхронизироваться с основной БД.

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

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

[Редактировать]

О сжатии: Вы можете использовать сжатую доставку журнала транзакций.В SQL 2008 сжатие поддерживается только в редакции Enterprise.В SQL 2008 R2 доступна стартовая Стандартная версия.http://msdn.microsoft.com/en-us/library/bb964719.aspx.

Вы можете реализовать пользовательское сжатие перед отправкой журналов транзакций, используя любую библиотеку сжатия, какую пожелаете.

...