Реферат за темою випускної роботи

Зміст

Вступ

В даний час ні один веб-сайт або серйозне додаток не може обійтися без використання баз даних. Вони використовуються для зберігання, систематизації та групування даних, завдяки чому забезпечується простота доступу до даних і цілісність інформації. Для створення, управління, адміністрування і використання баз даних використовуються спеціалізовані програми або групи програм системи управління базами даних (DBMS – Database Management System).

Розвиток СУБД почався в середині 60-х років XX століття при розробці космічних програм. Першою повноцінною СУБД стала ієрархічна система IMS (Information Management System). Дана система в наші дні також використовується в якості основної ієрархічної СУБД на високопродуктивних серверах. IMS є безпечним, надійним програмним забезпеченням з високою пропускною здатністю для обробки онлайн-транзакція і пакетної обробки.

1. Актуальність теми

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

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

2. Мета і задачі дослідження та заплановані результати

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

Основні завдання дослідження:

  1. Дослідження характеристик розподілених систем обробки даних.
  2. Вивчення основних завдань, що входять в процес проектування розподілених баз даних.
  3. Дослідження задач фрагментації БД, розміщення фрагментів в вузлах обчислювальної мережі.
  4. Формування стратегії виконання запитів.
  5. Вибір і обгрунтування критерію ефективності розподіленої БД.
  6. Розробка алгоритмів, що описують методи фрагментації і розміщення фрагментів. Формування архітектури розподіленої БД.
  7. Впровадження розподіленої БД в програмний комплекс.

Об'єкт дослідження : розподілена база даних.

Предмет дослідження : моделі та алгоритми програмного комплексу, призначені для опису методики децентралізації бази даних.

В рамках магістерської роботи планується отримання актуальних наукових результатів за наступними напрямками:

  1. Формування завдання проектування розподіленої бази даних, яка враховує особливості фрагментації БД і розміщення отриманих фрагментів.
  2. Формування стратегії виконання запитів.
  3. Вибір і обгрунтування критерію ефективності розподіленої БД, що враховує вплив фізичних параметрів системи на швидкість обробки запитів і коефіцієнт готовності транзакції.

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

3. Огляд досліджень та розробок

3.1 Огляд міжнародних джерел

Створення розподіленої СУБД передбачає не тільки розробку функціональних модулів, як таких, а й формальне математичний опис моделі зберігання даних і маніпулювання з ними. При проектуванні розподілених СУБД найбільш широко застосовуються методи алгебри опису операцій. Серед них можна виділити роботи Е. Кодда по реляційній алгебрі [1] і формальний опис БД як об'єктно-орієнтованої системи, запропоноване К. Бири [2].

Слід зазначити статті Б. Талхайма [3], присвячені проектування СУБД засобами многосортность алгебри з використанням інших методів алгебри, таких як HERM-алгебра, заснована на машині абстрактних станів Ю . Гуревича. Використання алгебраїчних підходів дозволяє провести формальний опис логічного плану виконання запиту (рівень мови запиту), його трансляцію в фізичний план виконання (рівень внутрішньої обробки запитів) і, як наслідок, мати можливість проведення аналізу його оптимізації та виконання по Мікрооперацій фізичного плану [4].

Також широко застосовується класифікація М. Стоунбрейкера для багатопроцесорних обчислювальних комплексів (МВК) [5-7].

3.2 Огляд національних джерел

У зв'язку з постійним збільшенням обсягу даних в даний час гостро стоїть питання про необхідність модернізації застарілих систем. Шалтуновіч А.В. [10] у своїй науковій статті відображає проблему великих даних щодо систем управління базами даних і розподілених інформаційних систем, що стала на сьогоднішній день ключовий в ІТ-індустрії.

Одним з найбільш пріоритетних вимог, висунутих під час проектування будь-яких сучасних систем, є збереження і цілісність даних. Бєлоусов В.Є. [9] в своїй роботі описується систематизацію підходів до виконання реплікації даних, пропонує алгоритм виконання реплікації по поточному стану.

Розподілені системи обробки даних мають ряд особливостей. Найповніше дані особливості описані в статті Цвєткова В.Я., Алпатова О.Н [8]. Також в статті розкриваються поняття розподіленої системи і розподіленої інформаційної системи. Дається класифікація розподілених систем. Зокрема, за типом наданих ресурсів: розподілені обчислювальні системи, розподілені інформаційні системи, семантичний Грід.

3.3 Огляд локальних джерел

У Донецькому національному технічному університеті розроблялися наукові статті, присвячені оптимізації запитів до серверів розподіленої бази даних, підходи до оптимізації розподілу даних. У статті Баранової С.С. [12] наводиться спосіб оптимізації роботи розподіленої бази даних шляхом оптимізації розподілу даних по вузлах комп'ютерної мережі. Заславський В.А. [13] в своїй статті застосовує мурашиний алгоритм для вирішення задачі оптимізації запитів.

4. Фрагментація баз даних

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

Прийнято порівняти горизонтальне секціонування з вертикальним. У таблиці з вертикальним секціонуванням цілі стовпці поділяються і поміщаються в окремі таблиці. Дані, що містяться в одному вертикальному розділі, що не залежать від даних у всіх інших таких розділах, кожен з них містить як окремі рядки, так і окремі стовпці. На малюнку 1 продемонстрований процес горизонтального і вертикального секціонування таблиці.

Процес горизонтального і вертикального секціонування таблиці

Малюнок 1 – Процес горизонтального і вертикального секціонування таблиці

(анімація, розмір – 57KB, 7 слайдів)

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

сегментована бази даних приклад архітектури без загального доступу. Це означає, що всі сегменти автономні; вони не використовують одні і ті ж дані або обчислювальні ресурси. У деяких випадках, однак, може мати сенс копіювати певні таблиці в кожен сегмент, щоб використовувати їх для довідки. Наприклад, є база даних для програми, яка залежить від фіксованих коефіцієнтів перерахунку для вимірювань ваги. Репліціруя таблицю, яка містить необхідні дані про коефіцієнт конверсії, в кожен сегмент, можливо надати кожному сегменту всі дані, необхідні для запитів.

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

4.1 Переваги фрагментації БД

Основна перевага шардінга полягає в тому, що він може спростити горизонтальне масштабування (scaling out). Горизонтальне масштабування це додавання нових машин до існуючого стеку, що дозволяє розподілити навантаження і швидше обробляти більший обсяг трафіку. Ця практика часто порівнюється з вертикальним масштабуванням (scaling up), яке включає в себе оновлення апаратного забезпечення існуючого сервера, зазвичай шляхом додавання більшого обсягу ОЗУ або ЦП.

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

Іншою причиною, по якій деякі вибирають архітектуру фрагментованою БД, є скорочення часу відповіді на запит. При відправці запиту до НЕ фрагментованою базі даних пошук виконується по кожному рядку в таблиці, перш ніж буде знайдений набір шуканих результатів. У додатку з великою монолітною базою даних запити можуть оброблятися дуже повільно. У сегментированной таблиці при пошуку проглядається меншу кількість рядків, а результати повертаються набагато швидше.

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

4.2 Недоліки фрагментації БД

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

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

Проблема, з якою іноді стикаються після фрагментації бази даних, полягає в тому, що сегменти в кінцевому підсумку сильно різняться в розмірах. Припустимо, у вас є база даних з двома окремими сегментами: один для клієнтів, чиї прізвища починаються з літер від А до М, а другий для тих, чиї прізвища починаються з літер від Н до Я. Однак додаток обслуговує дуже багато користувачів, чиї прізвища починаються з літери Г. Відповідно, перший сегмент поступово накопичує більше даних, ніж другий. Це призводить до уповільнення роботи програми при обслуговуванні значної частини ваших користувачів. У цьому випадку будь-які переваги фрагментації бази даних зводяться нанівець уповільненнями і збоями. Швидше за все, базу даних необхідно буде відновити і переналаштувати, щоб забезпечити більш рівномірний розподіл даних.

4.3 Види фрагментованих архітектур

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

4.3.1 Фрагментація по інтервалах

Фрагментація по інтервалах має на увазі сегментування даних на основі діапазонів заданого значення. Припустимо, у вас є база даних, в якій зберігається інформація про всі продукти в каталозі. Ви можете створити кілька різних сегментів і відокремити інформацію про кожному продукті залежно від цінового діапазону, в який вони потрапляють (малюнок 2).

Приклад фрагментації по інтервалах

Малюнок 2 – Приклад фрагментації по інтервалах

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

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

4.3.2 Фрагментація по каталогам

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

Приклад сегментування по каталогам

Малюнок 3 – Приклад сегментування по каталогам

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

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

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

Висновки

В рамках даної роботи були розглянуті основні способи сегментування бази даних, були виявлені особливості кожного із способів. Надалі планується застосування одного з описаних методів сегментування БД в рамках діючого проекту по онлайн продажу квитків.

Магістерська робота присвячена актуальній науковій задачі дослідження методів створення продуктивних СУБД. В рамках проведених досліджень виконано:

  1. Розглянуто методи фрагментації баз даних.
  2. На підставі аналізу літературних джерел виділено структура побудови продуктивних СУБД.
  3. Сформовано і проаналізовані вимоги до продуктивних СУБД.
  4. Формування стратегії виконання запитів.
  5. Вибір і обгрунтування критерію ефективності розподіленої БД.
  6. Розробка алгоритмів, що описують методи фрагментації і розміщення фрагментів. Формування архітектури розподіленої БД.
  7. Впровадження розподіленої БД в програмний комплекс.

Подальші дослідження спрямовані на наступні етапи:

  1. Проектування і реалізація розподіленої бази даних, яка враховує особливості фрагментації БД.
  2. Формування стратегії виконання запитів.
  3. Обгрунтування обраного критерію ефективності розподіленої БД.

При написанні даного реферату магістерська робота ще не завершена. Остаточне завершення: червень 2020 року. Повний текст роботи і матеріали по темі можуть бути отримані у автора або його керівника після зазначеної дати.

Перелік посилань

  1. Codd E.F. A Relational Model of Data for Large Shared Data Banks – Journal Communications of the ACM, Vol. 13, no. 6., 1970, pp. 377—387.
  2. Berri C. A sophisticates introduction to database normalization theory – 4th Conf. of Very Large Databases, 1978, pp. 113-124.
  3. Thalheim B. The HERM Algebra – Book Entity-Relationship Modeling: Foundations of Database Technology Reading, Department of Computer Science Brandenburg University of Technology, Germany, 2013, pp. 223-244.
  4. Gurevich Yu. Logic and the challenge of computer science – Current Trends in Theoretical Computer Science (Borger E). Computer Science Press, 1988, pp. 1–57.
  5. Stonebraker M., Aoki P.M., Litwin W., Pfeffer A., Sah A., Sidell J., Staelin C., Yu A. Mariposa: A wide-area distributed database system – The VLDB Journal the International Journal on Very Large Data Bases, no. 5, 1996, pp. 48–63.
  6. Hellerstein J.M., Stonebraker M. Clustering of database systems – Readings in Database Systems, 4th edition, London, 2005, pp. 651-653.
  7. Цветков В.Я., Алпатов А.Н. Проблемы распределенных систем – Журнал Перспективы науки и образования №6(12), Москва, 2014, стр. 31-35.
  8. Белоусов В.Е. Алгоритмы репликации данных в распределенных системах обработки информации – Автореферат к рукописи, Пенза, 2005 // [Электронный ресурс]. — Режим доступа: https://static.freereferats.ru/...
  9. Шалтунович А.В. Нереляционные системы хранения в условиях проблемы больших данных и распределенных вычислений – Журнал Вестник Нижневартовского государственного университета, Нижневартовск, 2013, стр. 31-35.
  10. Баранова С.С. Динамическая оптимизация распределения данных по узлам вычислительной сети // Тезисы доклада на конференции Современные информационные технологии, Донецк, 2007.
  11. Заславский В.А., Савкова Е.О. Оптимизация выполнения распределённых запросов // Материалы II всеукраинской научно-технической конференции студентов, аспирантов и молодых учёных – Донецьк, ДонНТУ – 2011, с. 269-273.