#sql #sql-server #tsql #linked-server #wan
#sql #sql-сервер #tsql #linked-server #глобальная сеть
Вопрос:
Я нахожусь в офисе-спутнике, которому необходимо извлечь некоторые данные из нашего главного офиса для отображения в нашей интрасети. Мы используем MS SQL Server в обоих расположениях, и мы планируем создать связанный сервер в нашем вспомогательном офисе, указывающий на главный офис. Я полагаю, что соединение между ними — это VPN-туннель (правильно ли это звучит? Что я знаю, я программист!)
Я обеспокоен генерированием большого трафика через потенциально медленное соединение. Мы получим доступ к представлению SQL на сервере главного офиса. После выполнения запроса select данных становится немного (~ 500 записей), но представление становится огромным (~ 30000 записей) без запроса.
Я предполагаю, что выполнение запроса на связанном сервере вернет только результаты по сети (а не все представление, которое будет запрошено локально). В этом случае основным узким местом, скорее всего, является само соединение, предполагающее, что представление проиндексировано, и т.д. Есть ли какие-либо другие ошибки или потенциальные узкие места (возможно, основанные на том, как я структурирую запросы), о которых я должен знать?
Комментарии:
1. Извините, я не знаю сразу, какими будут узкие места. Если база данных используется интенсивно и у вас возникают проблемы, вы можете попробовать создать локальную копию и использовать репликацию базы данных вместо связанного сервера.
2. Я определенно держу это в уме как план B. Однако было бы неплохо иметь возможность передавать эти данные в режиме реального времени.
Ответ №1:
Из того, что вы объяснили, ваше соединение, вероятно, будет узким местом.
Кроме того, вы могли бы также рассмотреть возможность кэширования данных в местоположении satellite.
Решение будет зависеть от следующего:
— сколько строк и как часто обновляются данные в основной базе данных
— как часто вам нужно загружать один и тот же набор данных в спутниковом местоположении
Два граничных примера:
-
Данные статичны или относительно статичны — вставляются только в основную базу данных. В спутниковом местоположении пользователи часто запрашивают одни и те же данные снова и снова. В этом случае имело бы смысл кэшировать данные локально в спутниковом местоположении.
-
Данные изменчивы, много обновлений или / и удалений. Пользователи в спутниковом местоположении редко запрашивают данные, и когда они это делают, это всегда другое условие where. В этом случае кэширование не имеет смысла. Если соединение медленное и часто происходят изменения, вы можете в конечном итоге никогда не синхронизироваться с основной базой данных.
Еще одним преимуществом кэширования является то, что вы можете реализовать сжатие данных, что уменьшит отрицательный эффект медленного соединения.
Если вы решили кэшировать в локальном расположении, есть много вариантов, но это, я полагаю, будет другой темой.
[Править]
О сжатии: Вы можете использовать доставку журнала транзакций в сжатом виде. В SQL 2008 сжатие поддерживается только в Enterprise edition. В SQL 2008 R2 он доступен начиная со стандартной версии. http://msdn.microsoft.com/en-us/library/bb964719.aspx .
Вы можете реализовать пользовательское сжатие перед отправкой журналов транзакций, используя любую библиотеку сжатия, которая вам нравится.
Комментарии:
1. Спасибо! Есть ли встроенные в SQL параметры сжатия или кэширования, которые не требовали бы большой настройки на стороне главного офиса? Я могу управлять только вспомогательной стороной и, возможно, у меня не так много опций на стороне главного офиса.