Лекція 11. Структурована сховище даних Windows Azure Table (2016 р.)

Лекція 11. Структурована сховище даних Windows Azure Table

Будь-який додаток незалежно від способу його розміщення має десь зберігати дані. При цьому дані можуть зберігати локально, або віддалено. "Хмарний" спосіб зберігання даних пропонує дещо інший спосіб. Звернувши увагу на такі особливості, які необхідно враховувати при перенесенні традиційної реляційної структури даних в Table Storage в "хмарі":

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

• Table Storage підходить для зберігання реляційних даних, але саме по собі дане сховище реляційним не є. Це означає, то при перенесенні реляційної структури даних в "хмара", управляти обмеженнями між суб'єктами зберігання потрібно буде користувачеві.

арактеристики

Windows Azure Table підтримує:

• LINQ

• ADO.Net Data Services

• REST

• необмежене число таблиць і сутностей, без обмеження розмірів

• цілісність кожної сутності

• блокування оновлень і вилучень

• можливість повернення часткових результатів запитів перерваних за часом очікування, при цьому є можливість продовжити подальше виконання запиту.

Модель даних

Для доступу до Windows Azure Table у додатки повинна бути обліковий запис. Після створення облікового запису, користувачеві надається секретний ключ, який використовується для аутентифікації.

Ключовими поняттями Table Storage є:

• Таблиця - містить набір сутностей.

• Сутність - логічно є рядком в таблиці. Основний елемент даних. що зберігаються в таблиці. Містить набір властивостей.

• Властивість - Значення, що зберігається по суті.

Як ми вже відзначали раніше, проводячи аналогії з реляційним підходом, отримаємо наступне: під таблицею розуміється колекція сутностей (Entities), подібних кортежам в реляционном підході. Сутність же являє собою набір властивостей (Properties). Властивість же є парою "ім'я (name) - збірне значення (typed value)". Суті можна співвіднести з полями в таблиці в реляционном сховище.

• ключ секції - властивість ключа таблиці. Використовується для розподілу по вузлах зберігання сутностей таблиці.

• ключ рядки - властивість ключа таблиці, унікальний ідентифікатор сутності.

• тимчасова мітка - система зберігає різні версії однієї і тієї ж сутності, для їх розрізнення використовується тимчасова мітка.

• секція - набір сутностей з однаковими ключами секції.

• порядок сортування - в CTP версії надано тільки один індекс, сортують спочатку по ключу секції, потім - по ключу рядки.

Обмеження таблиць, сутностей і їх властивостей:

1. Імена властивостей таблиць повинні складатися тільки з букв і цифр.

2. Ім'я таблиці не повинно починатися з цифри.

3. Імена таблиць розрізняють регістри.

4. Довжина імені таблиці повинна бути в межах від 3 до 63 символів

5. Сутність може мати не більше 255 властивостей

6. Властивості "ключ секції" і "ключ рядки" не можуть бути більше 1Кб розміром.

7. Властивість "тимчасова мітка" є ReadOnly.

8. Windows Azure Table не зберігає схем, тобто значення властивостей сутностей однієї таблиці можуть ставитися до різних типів даних.

Секціонування

Частково секціонування було нами пояснено в попередній частині цієї лекції. Розглянемо його більш детально.

Масштабованість системи зберігання даних залежить від розподілу секцій по вузлах зберігання.

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

Крім того, зберігання сутностей однієї секції разом дозволяє підвищити ефективність кешування і інших методів підвищення продуктивності.

Додаток може здійснювати кілька операцій створення, оновлення та видалення для набору сутностей сформувавши один пакетний запит до системи, в разі, якщо операції здійснюються над сутностями однієї таблиці і секції. При виконанні операції відбувається ізоляція моментального знімка, незалежно від результату самої операції, таким чином всі наступні операції, що виконуються в цей же час, здійснюються над знімком, зробленим до початку операції. Результат транзакції стає доступним тільки після її успішного завершення.

Особливості вибору ключа секції

Вибір ключа секції - завдання, яке складніше ніж здається. З одного боку, розміщення сутностей в одній секції дозволяє оптимізувати виконання запитів, з іншого - чим більше секцій в одній таблиці, тим простіше для WAT розподілити суті за місцями зберігання, забезпечуючи масштабованість таблиці.

1. Якщо планується використовувати запити над групами сутностей, необхідно підбирати ключ секції таким чином, щоб всі сутності беруть участь в запиті перебували в одній секції, тобто необхідно групувати суті, беруть участь в одному запиті.

2. У найбільш частих і важливих запитах, крім іншого слід вказувати і ключ секції, оскільки при його відсутності необхідні суті будуть відбиратися переглядом всіх секцій таблиці.

3. Перевірка масштабованості: тестування навантаження секції таблиці з метою перевірки можливості забезпечення секцією необхідної продуктивності.

Список додаткових матеріалів для самостійного вивчення

Огляд Windows Azure Table

1. http://blogs.msdn.com/b/jnak/archive/2010/01/06/walkthrough-windows-azure-table-storage-nov-2009-and-later.aspx

Windwows Azure Table - детальний огляд

1. http://msdn.microsoft.com/ru-ru/library/ee872426.aspx
2. http://www.bandgap.cs.rice.edu/classes/comp410/resources/Using%20Azure/Using%20Azure%20Table%20Storage.aspx

(Для ознайомлення з повним текстом статті необхідно залогінитись)