Синхронізація даних

До цих пір в цьому розділі ми розглядали питання, повязані з підключенням мобільних додатків до реляційних баз даних 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://msdnmicrosoftcom/library/defaultaspurl=/library/en-us/ dnppcgen/html/desktop_device_tools_sql_mobileasp

Web-служби

Середа NET Compact Framework 20 має вбудовану підтримку виклику 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 с : Ил – Парал тит англ

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*