Оптимізація реляційних баз даних



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

Чим краще ви розумієте вашу систему, тим простіше вам буде знайти підходи для подібних оптимізацій. Переконайтеся, що ви збираєте всі метрики, які можуть вам допомогти. Мова йде не тільки про системні метриках начебто CPU usage і RAM usage або метриках конкретної БД, а й про application-level метриках додатки, яке зав'язане на оптимізованій базі даних. Скільки запитів в секунду у різних типів операцій? Яке у них час відгуку? Який розмір вхідних і вихідних даних? Саме за цими метрик ви зможете судити про успішність проведених оптимізацій. Навряд чи вам потрібна оптимізація, яка трохи знизить CPU usage на сервері БД, але при цьому збільшить час відгуку вашого застосування в десять разів.

Рисунок 3.1 – Графік швидкості відгуку БД при оптимізації

 

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

Основна мета метрик в разі проекту по оптимізації – краще зрозуміти вашу базу даних і знайти найкращі частини БД. Немає сенсу витрачати купу часу і зусиль на оптимізацію запитів, що становлять менше 1% від вашого профілю навантаження. Такими оптимізаціями на стороні коду вдається зняти близько 15% CPU usage з 80% споживаного БД.

 

Існуючі застосування теорії графів в реляційних базах даних

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

Рисунок 3.2 – М-арне дерево

 

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

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

 


ВИСНОВКИ

 

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

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

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

 


СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ

1. Організація баз даних: практичний курс : Навч. посіб. для студ. / А. Ю. Берко, О. М. Верес; Нац. ун-т "Львів. політехніка". - Л., 2003. - 149 c. - Бібліогр.: 8 назв.;

2. Фундаментальні алгоритми на C. Аналіз / Структури даних / Сортування / Пошук / Алгоритми на графах: Пер. з англ. / Роберт Седжвік - СПб: «ДиаСофтЮП», 2003;

3. Моделювання ієрархічних структур в реляційних базах даних. Прилади й системи. Управління, контроль, діагностика. Л.Г. Блинскій, В.Ю. Курганов. 2003 № 9;

4. Проектування каталогу. Максим Рябенко. // Відкриті системи. 2002 № 2.

5. Дмитро Палій. Моделювання квазіструктурірованних даних. // Відкриті системи. 2002 № 9;

6. Уявлення ідентифікованих складних об'єктів у реляційній базі даних. Євген Григор'єв. // Відкриті системи. 2000, № 1-2.

 

 


Дата добавления: 2019-03-09; просмотров: 328; Мы поможем в написании вашей работы!

Поделиться с друзьями:






Мы поможем в написании ваших работ!