Проектування і управління базами даних: як зробити правильно з першого разу, Інші СУБД, Бази даних, статті

У світі баз даних (БД) фраза “зробити правильно” звучить досить невизначено. Хто може судити, що таке насправді “правильно”? Чесно кажучи, назвати схему БД “поганий” або “неправильної” набагато простіше, ніж підтвердити її “правильність”. Дизайн схеми – це основа хорошої роботи БД. Якщо схема не враховує вимоги до продуктивності, адміністрування, резервного копіювання і відновлення БД, то багато можливостей роботи будуть недоступні.

Можливість


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


Переваги


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





РОЗДІЛ 1


Проблема: “правильний” дизайн


У світі дизайну БД фраза “зробити правильно” звучить досить невизначено. Хто може судити, що таке насправді “правильно”? У сьогоднішньому мінливому світі Інтернету традиційний “правильний” підхід, коли спочатку створювалася застаріла система, може бути неправильним. Справа ще більше ускладнюється тим, що може просто не виявитися способу зробити “неправильну” роботу ефективним і “правильним” способом з точки зору сьогоднішньої ситуації. Чесно кажучи, назвати схему БД “поганий” або “неправильної” набагато простіше, ніж підтвердити її “правильність”. “Правильна” БД означає, що вона добре працює, її ефективність висока, а продуктивність оптимальна. Крім того, вона забезпечує підтримку корпоративної місії, а організація володіє гнучкістю і розташовує в схемі БД основою для розвитку в потрібному напрямку.


“Неправильна” може означати що завгодно, починаючи з функціональних обмежень, що гальмують корпоративний ріст і розвиток, і закінчуючи конкретними транзакціями, які діють в БД. Коли мене просять дослідити “Неправильну” роботу, я намагаюся отримати глобальне уявлення про ситуацію. Дизайн схеми – це основа хорошої роботи БД. Але якщо не враховувати вимоги до продуктивності, адміністрування, резервному копіювання і аварійного відновлення БД, то я втрачу багато можливостей.


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


РОЗДІЛ 2


Можливість: ідентифікація існуючих проблем


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


Поганий дизайн записів буде жити вічно


Поганий формат записів існує з самого початку комп’ютерної ери. Записи, які містять занадто багато полів із занадто великою кількістю різних аспектів даних. Записи, які при повному заповненні виявляються довше блоку БД. Записи, які містять повторювані групи і які намагаються об’єднати докладні і підсумкові дані (наприклад, “Складський артикул”, “Продажі за понеділок”, “Продажі за вівторок “,” Продажі за середу “і т.д.). Всі ці умови швидко знизять продуктивність БД і зведуть нанівець цілісність даних.



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


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


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


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


Ясно, що в подібній ситуації ніяке потужне апаратне забезпечення, збільшення розміру блоку або будь-яку кількість додаткових індексів не врятувало б цих людей від проблем з ресурсами. Враховуючи, що в цій компанії були схильні розглядати їх реляційну СУБД як звичайний сервер з неструктурованим файлом, збільшення розміру блоку тільки загострило б їх проблеми з продуктивністю. Фізичний введення-виведення, напевно, є найбільш ресурсномісткою операцією на комп’ютері. І немає нічого, що могло б по затратності перевершити зчитування і запис одного запису при кожному фізичному або логічному введенні-висновку. Якщо б ці хлопці провели моніторинг своєї системи, вони б побачили виключно високу активність по запису і читання даних з жорстких дисків. Також вони б побачили “пробуксовку” – високий рівень звернення на читання і запис до файлу підкачки навіть при легкій або середній транзакційної навантаженні. Ці характеристики є симптомами проблем відповідно з фізичними і логічними операціями вводу-виводу. Такі проблеми треба вирішувати в джерелі, навіть якщо це означає переробку схеми працює БД. За допомогою найкращих методик щодо нормалізації даних розділіть дані на набори пов’язаних таблиць, виходячи зі змісту і функціональності. Зв’язки між таблицями необхідно реалізувати з використанням декларативною посилальної цілісності, і створити відповідні індекси. При необхідності створіть уявлення, які імітують старий формат запису. Це потрібно для підтримки існуючих програм, які запитують дані з БД. Одночасно слід переписати ці програми. Вони повинні використовувати що-небудь крім “Select *”. Якщо в початковому дизайні таблиць і записів є недоліки, що необхідно зробити деякі серйозні кроки з виправлення ситуації. Поганий дизайн записів – це головний приклад неправильних дій вже на початковому рівні. Від цього, як і від будь-яких інших початкових проблем, можна позбутися переробкою дизайну.



Погана продуктивність програми викликана недоліками в реалізації дизайну


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


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


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


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


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


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


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



Обмежений дизайн обмежує роботу організації


Щоб все зробити правильно з самого початку, потрібно розуміти бізнес-вимоги. Цього не було зроблено в одному проекті, який включав в себе повну переробку дизайну БД, яка підтримувала роздрібну торгівлю через Інтернет. В даному випадку у компанії було чотири веб-сайту для роздрібної торгівлі через Інтернет. Планувалося збільшити цю кількість і, можливо, розвивати бізнес в сторону франчайзингу. Чотири вузла для роздрібної торгівлі спільно використовували одну БД і основу коду програми. Через особливості схеми прийняті на ранньому етапі проектування БД рішення стримували зростання організації. Схема БД, спроектована сторонньою організацією, до цього справно служила компанії. Але вона не враховувала плани розширення бізнесу. Не будучи технічними фахівцями, керівництво ніколи не усвідомлювала ці недоліки дизайну. Тим часом дизайн жорстко обмежував кількість магазинів і тип послуг, які могла пропонувати компанія. Без фундаментальної реструктуризації БД і переписування програмного коду було неможливо розширити можливості та функціональність цієї системи для підтримки ініціатив з розвитку бізнесу.


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


У другу чергу потрібно в контрольному списку врахувати фізичну реалізацію, а особливо метод розміщення файлів БД на диску. Необхідно використовувати засіб завчасного контролю та управління БД. В даному випадку я використовувала профайлер для тестування продуктивності та швидкості виконання запитів до і після фізичного реструктуризації. Отримані мною перед реструктуризацією результати не були обнадійливими. У вихідній БД всі об’єкти зберігалися в одній групі файлів. Ця БД містила всі типи даних – як табличні (числа, текстові рядки, час і дату), так і тест із зображеннями (довгі описи продуктів і ДУЖЕ БАГАТО картинок). Єдина група файлів розміщувалася на одному фізичному / логічному диску. Така конфігурація несприятливо впливала на продуктивність і погіршувала роботу інтерфейсу для Інтернет-покупців. При реструктуризації подібної БД – яка містить великий обсяг двійкових зображень дуже довгих текстових рядків – найкращим виходом є відокремити текст і зображення від табличних даних. Збережіть текст і зображення в окремому наборі таблиць. Потім використовуйте відносини для зв’язку кожного зображення або довгою текстової рядки з відповідною табличній записом (Або записами). Також слід відокремити системні таблиці (каталог) від табличних даних і зображень. Кожен з цих трьох типів таблиць слід помістити в окрему групу файлів або табличний простір. Потім кожну з цих файлових груп помістіть на окремий диск. Використовуючи ці прості принципи фізичного дизайну, ви значно підвищите продуктивність БД.



Третім пунктом контрольного списку ставимо індексування для підвищення продуктивності. Якщо є відношення між двома таблицями виду “один до багатьох”, то на стороні “багатьох” зв’язку з цим буде зв’язок за зовнішнім ключу. У більшості систем БД первинний ключ індексується автоматично. Для зовнішнього ключа це не завжди так. Щоб забезпечити найкращу роботу об’єднань, обов’язково проіндексує кожен зовнішній ключ в БД. Наступний кандидат на індексацію – це будь-який стовпець, який буде використовуватися для сортування, тобто стовпець, який буде постійно використовуватися у виразі “order by” запиту на SQL. Також варто проіндексувати стовпці, які будуть використовуватися для обмеження повертається набору даних. Це, наприклад, ті стовпці, які постійно фігурують у виразах “where”.


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


РОЗДІЛ 3


Переваги правильного виконання


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



РОЗДІЛ 4


Висновок


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


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

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


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

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

Ваш отзыв

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

*

*