Главная » Microsoft SQL Server, Базы данных » Синхронизация данных

0

До сих пор в этой главе мы рассматривали вопросы, связанные с подключением мобильных приложений к реляционным базам данных SQL Everywhere. В этой главе будет показано, как SQL Everywhere может служить автономным кэшем данных в отношениях синхронизации с SQL Server. Как уже говорилось, SQL Everywhere поддерживает две различные, но одновременно мощные, технологии синхронизации данных: доступ к удаленным данным (RDA) и

репликацию слияния. Концепция репликации слияния, скорее всего, хорошо знакома администраторам SQL Server. В то же время технология RDA специфична для синхронизации данных с мобильными устройствами. В этом разделе мы рассмотрим обе эти технологии и еще одну дополнительную — Web-службы .NET.

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

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

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

?               уровень логического разделения данных среди больших популяций мобильных пользователей;

?               частота подключений и синхронизации:

?               срок жизни батареи устройства;

?               объем данных;

?               полоса пропускания сети;

?               шлюзы системы безопасности;

?               требования к разрешению конфликтов.

Принимая все это во внимание, рассмотрим, какая технология лучше подходит для каждого из сценариев.

Удаленный доступ к данным

Удаленный доступ к данным (далее RDA) можно представить себе как модель доставки- отправки при синхронизации данных. RDA позволяет мобильному приложению доставлять все данные или их часть из одной или нескольких таблиц из SQL Server в SQL Everywhere, а затем включать в последнем отслеживание изменений в этих данных. Следует заметить, что в момент инициализации доставки таблица не должна существовать — она и ее схема создаются в SQL Everywhere в процессе каждой доставки. Затем SQL Everywhere отправляет данные назад на сервер, и все отслеженные изменения применяются к базе данных SQL Server. Процесс RDA можно запускать с отключенным отслеживанием изменений; в этом случае отправка данной таблицы не выполняется. RDA также предлагает механизм повторной отправки на сервер любой инструкции SQL для выполнения до тех пор, пока она не вернет какие-либо строки. Это простейший способ выполнения быстрого обновления на сервере в обход SQL Everywhere.

Используя ту же архитектуру синхронизации, доставку и отправку можно организовать с помощью агента сервера SQL Everywhere в Internet Information Server. Службу удаленного доступа к данным проще запускать, чем репликацию слияния, в то же время он требует большего объема программирования в мобильном приложении (хотя этот код повторяемый и хорошо документированный). Отмечу, что все аспекты RDA управляются программным путем из мобильного приложения.

RDA является отличным решением для загрузки классификаторов (например, почтовых индексов или таблиц заказчиков), а также больших объемов данных для заполнения таблиц SQL Everywhere. Данные при перемещении сжимаются, в результате чего скорость их передачи значительно выше, чем в репликации слияния. Метод отслеживания изменений также удобен для отправки данных, введенных на мобильном устройстве, назад на сервер, с такой же высокой скоростью.

Существует один важный аспект RDA, который следует учитывать в архитектуре синхронизации данных, — это оптимистическая конкуренция. RDA использует оптимистическую конкуренцию, однако с чуть более смешенным определением, чем SQL Server. В данном случае оптимистическая конкуренция предполагает, что когда изменения отправляются назад на сервер, они применяются к серверным таблицам, даже если те же данные уже были на нем изменены с момента их доставки на данное устройство. Разумеется, это делает непригодным метод RDA для мобильных приложений, в которых промежуток времени между доставкой и отправкой велик, а данные на сервере и других мобильных устройствах изменяются часто.

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

Репликация слияния

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

Репликация слияния предполагает создание на сервере SQL Server 2000 или 2005 публикаций, в каждой из которых определены одна или несколько статей (в репликациях SQL Everywhere они лимитированы таблицами, столбцами, индексами, ключами и ограничениями), содержащих строки данных, которые затем фильтруются по вертикали или по горизонтали. Сервер рассматривается как издатель, а база данных SQL Everywhere — как подписчик. Подписка на публикации добавляется в базу данных SQL Everywhere и синхронизируется с публикациями. Эта синхронизация организована в виде двустороннего диалога между подписчиком и издателем, предназначенного для обработки изменений строк и схемы данных на обоих концах диалога.

Новым в SQL Server 2005 и SQL Everywhere является введение отслеживания изменений на уровне столбцов для репликации слияния. В качестве примера рассмотрим таблицу

SurveyAnswers, являющуюся частью публикации. Эта таблица состоит из пятнадцати столбцов, один из которых имеет тип image и содержит подпись или другое цифровое изображение (этот столбец может быть очень широким). Если все изменения в строке с момента последней синхронизации происходили в столбце типа nvarchar, то только это значение при репликации будет передано на сервер. В репликациях SQL СЕ и SQL Server 2000 в данном случае на сервер была бы отправлена вся строка, включая неизмененное изображение.

Мобильные реализации на больших предприятиях получат выигрыш не только в виде расширенных возможностей синхронизации, но и от набора административных средств на стороне сервера. В корпоративном центре данных администратор может использовать монитор репликаций, входящий в состав утилиты Management Studio, для проверки состояния всех мобильных подписчиков, времени их последней синхронизации, достигнутой при этом пропускной способности, а также конфликтов, которые могли возникнуть в процессе синхронизации. Администратор также может повторно инициализировать любую мобильную подписку, чтобы заставить подписчика получить новый снимок публикации с сервера. Снимком называют представление схемы всех статей публикации, сценариев создания этих статей в SQL Everywhere, а также исходного набора данных, наполняющего подписку в SQL Everywhere. SQL Agent на сервере генерирует снимки, которые агент сервера SQL Everywhere знает, где найти, основываясь на конфигурации публикации для Web-репликации в SQL Everuwhere.

Полноценный пример создания приложения Compact Framework, подключенного к базе данных SQL Everywhere, связанной репликацией слияния с базой SQL Server, вы найдете на сайте:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ dnppcgen/html/desktop_device_tools_sql_mobile.asp

Web-службы

Среда .NET Compact Framework 2.0 имеет встроенную поддержку вызова Web-служб и синтаксического разбора XML. Фраза “Разработка стратегии синхронизации данных, основанной на Web-службах” может звучать устрашающе, однако на самом деле в хороших мобильных сценариях эта стратегия может быть реализована гораздо меньшими усилиями, чем конфигурирование репликации слияния. Вот несколько признаков того, что подход с применением Web-служб имеет смысл использовать в конкретной мобильной архитектуре.

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

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

?               Объем данных, которыми мобильный пользователь обменивается с сервером, в среднем меньше 1 Мбайт.

?               Существует типичный сценарий подключения устройства к серверу, в котором задействован Интернет и данные проходят через множество брандмауэров и/или прокси-серверов.

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

?               Существуют серверные базы данных, отличные от SQL Server, с которыми нужно выполнять синхронизацию.

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

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

?               Объем данных в одном вызове Web-службы с мобильного устройства не превышает 1 Мбайт.

?               Для гарантии отсутствия отклоненных синхронизируемых записей используется стратегия полной замены в соединении с наличием выходного буфера на устройстве. Например, если существует таблица Orders, в которой мобильные пользователи обновляют или вставляют данные, первичный ключ идентификатора GUID каждой новой, изменяемой или удаляемой записи помещается в простую таблицу Orders_Outbox (выходной буфер). Таблица Orders_Outbox имеет два столбца: столбец идентификатора GUED записи таблицы Orders, с которой проводилась работа, и столбец даты-времени, чтобы применять множество изменений данной записи в правильном порядке.

?               Для получения данных с SQL Server и помещения их туда используются простые Web- методы. В любом из направлений переправляется объект DataSet с одним или несколькими объектами DataTable, соответствующими конкретным таблицам в базе данных SQL Everywhere.

?               Когда приходит время синхронизации SQL Everywhere с сервером, создается объект DataSet с одним объектом DataTable для каждого выходного буфера, описанного выше. Каждая из таблиц заполняется полными строками данных исходной таблицы, соответствующими идентификаторам GUTO в выходном буфере. Этот объект DataSet отправляется на сервер, откуда возвращается объект DataSet с тем же набором объектов DataTable, однако на этот раз таблицы заполнены идентификаторами отправленных строк и кодами состояния, указывающими на успех или неудачу операции. Идентификаторы GUED записей, которые были успешно обработаны, удаляются из соответствующего выходного буфера. Те же записи, которые не были обработаны, остаются в буфере для повторной отправки при последующих синхронизациях.

?               При доставке данных с сервера, если не существует видимых записей в выходном буфере таблицы, эта таблица может быть сжата и заменена результатами вызова Web- службы. Например, вы можете использовать Web-метод с заголовком DataSet Get- NamedTable (string TableName), который возвращает объект DatSet с одним объектом DataTable, заполненным строками из запрошенной таблицы сервера. На мобильном устройстве эти строки могут быть применены к соответствующей таблице SQL Everywhere с помощью метода прямой замены. Довольно часто в этом случае применяют критерии фильтров (предложения WHERE) и концепцию сравнения даты для доставки с сервера только новых и измененных записей, начиная с некоторого момента времени.

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

Источник: Нильсен, Пол. Microsoft SQL Server 2005. Библия пользователя. : Пер. с англ. — М. : ООО “И.Д. Вильямс”, 2008. — 1232 с. : ил. — Парал. тит. англ.

По теме:

  • Комментарии