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

Keywords: databases, database management system, data warehouses, decision support systems, analytical data processing, structural query languange, data mining, transactional queries, analytic queries.

Зустріч у Асіломарі 1998 року

Системи управління базами даних у стилі “plug and play”. У зв'язку зі зростанням відносної вартості людського фактора в комп'ютерних системах потрібно, щоб майбутні комп'ютерні системи стали повністю автоматичними: автоінстальованими, автокерованими, авторемонтованими та автопрограмованими. У тому числі потрібно забезпечення самонастроювання систем баз даних, тобто видалення маси параметрів налаштування продуктивності, які мають визначати користувачі у поточних продуктах. Зокрема, мають з'явитись методи автоматичного вибору індексів.

Важливість проблеми самонастроювання систем баз даних у XXI столітті усвідомлюється всіма великими вендорами SQL-орієнтованих СУБД. Очевидно, першою компанією, у якій почалися масштабні дослідження у цьому напрямі, була “Microsoft” (проект AutoAdmin під керівництвом Сураджита Чаудхарі розпочався 1996 р. [6, 7]).

На початку цього проєкту було розроблено засіб Index Tuning Wizard, який аналізував поточне робоче навантаження СУБД (операції вибірки даних, вставки, модифікації та видалення рядків таблиць) та встановлювало, за якого набору індексів на відповідних таблицях набір операцій міг би оброблятися СУБД найбільш ефективно. При аналізі робочого навантаження вже використовувалися методи data mining. Надалі у цьому засобі почали враховуватися як індекси, а й матеріалізовані уявлення та інші об'єкти бази даних, наявність чи відсутність яких впливає на ефективність оброблення операцій.

Засоби самоналаштування, наявні сьогодні в передових СУБД, здебільшого спрямовані на те, щоб допомогти адміністраторам баз даних налаштувати фізичну схему бази даних, щоб вона найкраще відповідала особливостям поточного середовища використання. Крім того, в системи широко впроваджуються засоби моніторингу, результати яких дозволяють адміністраторам розпізнати як власні недоліки при налаштуванні бази даних, так і слабкі місця СУБД (наприклад, оптимізатор запитів). Крім робіт, які ведуть фахівці “Microsoft”, у цій галузі помітні зусилля дослідників і розробників компанії “Oracle” [8].

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

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

Це твердження співзвучне назві статті [1] “Кінець архітектурної епохи, або настав час повністю переписувати системи управління даними”. Та й вийшла ця стаття в 2007 р., якраз до кінця першого десятиліття XXI століття. Однак не можна стверджувати, що автори пропонують повністю переосмислені архітектури СУБД. Вони переосмислюють їх у зв'язку з переходом від архітектур універсальних СУБД до архітектур спеціалізованих систем. Компоненти архітектур залишаються відомими та традиційними.

Та загалом і підстав для повного перегляду архітектури у 2000-х роках не було. Тоді відбувались переважно кількісні, а не якісні зміни (суттєво збільшені розміри основної пам'яті, кластери з дуже великою кількістю вузлів тощо.). Незмінною залишалася опора SQL-орієнтованих СУБД на жорсткі диски з рухомими головками. (Цитата зі звіту щодо зустрічі в Асіломарі: “У майбутньому можуть виявитися недоречними архітектури, що “приховують наявність рухливих магнітних головок”, такі як RAID 5” - з позицій оптимізації запитів розробникам СУБД завжди були підозрілі пристрої зовнішньої пам'яті, які приховують свою організацію.)

Нижче наведено перелік того, що, на думку авторів, може справді вплинути на архітектуру майбутніх СУБД (нові апаратні можливості представлено в порядку зростання їхнього впливу на архітектуру СУБД).

Флеш-пам'ять та твердотільні диски. Твердотільна зовнішня пам'ять (solid- state disk, SSD) має інші характеристики, ніж традиційна дискова пам'ять на дискових пристроях з рухомими головками (hard disk, HD). Основною відмінністю є те, що у пристроїв SSD відсутні магнітні головки, що механічно переміщаються, і вони дійсно є пристроями прямого доступу - час доступу до будь-якого блоку даних в SSD є однаковим. І навіть без урахування часу переміщення головок HD SSD показують час обміну, в кілька разів менший, ніж HD.

Раніше SSD програвали HD за максимально доступним обсягом, вартістю в розрахунку на гігабайт даних та зносостійкістю. Наразі вже доступні SSD ємністю в кілька терабайт. Показники вартості та зносостійкості поки що поступаються HD, але згодом і вони будуть покращені.

Звичайно, виникає бажання перевести наявні СУБД на платформу SSD, але такі роботи не виконуються. Особливості SSD змушують розробників переглянути алгоритми, які застосовують у багатьох компонентах SQL-орієнтованих СУБД, а можливо й архітектуру СУБД загалом. Наприклад, при переході від SSD до HD перестають ефективно працювати методи кешування блоків бази даних в основній пам'яті [9], що вимагає їх принципового перероблення.

Безумовно, перехід до SSD вимагає значної обробки оптимізатора запитів, починаючи, мабуть, з евристик “відсіювання” свідомо непридатних планів запитів. Більше того, у наборі планів для цього запиту можуть з'явитися плани, які взагалі не генерувалися під час використання HD. Цілком змінюється компонент оцінки вартості плану, оскільки тепер обміни із зовнішньою пам'яттю коштуватимуть набагато дешевше, і ця вартість не залежатиме від розташування блоку даних у зовнішній пам'яті.

Основні вендори SQL-орієнтованих СУБД побоюються цих змін, що зачіпають внутрішні частини СУБД, і тому використовують SSD, в основному нехтуючи їх відмінностями від HD.

Енергонезалежна основна пам'ять. Цей вид пам'яті, яка називається non-volatile memory (довготривала, або енергонезалежна, пам'ять), а також storage class memory (пам'ять класу зберігання даних), нарешті стають доступними. Ще 30 років тому використання енергонезалежної пам'яті передбачалося у проекті системи зберігання Postgres [10]. Майкл Стоунбрейкер хотів використати таку пам'ять (у невеликому обсязі) для зберігання частини кешу блоків бази даних і журналу. Але енергонезалежна пам'ять ще не існувала ні тоді, ні в наступні десятиліття - вона з'явилась тільки в останні роки.

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

Зрозуміло, що використання енергонезалежної пам'яті у СУБД забезпечує значні переваги. Сьогодні досить популярними є СУБД, що зберігають дані у традиційній основній пам'яті (in-memory DBMS). Але такі системи не можуть працювати без дискової пам'яті, і оскільки всі транзакції змінюють дані, повинна забезпечуватися гарантована безпека результатів (durability), тобто ці результати так чи інакше мають бути відображені у зовнішній пам'яті. Через це системи in-memory зазвичай забезпечують істотно більшу продуктивність, ніж традиційні СУБД, для транзакцій, які включають тільки читання. Винятком є масивно-паралельна архітектура H-Store/VoltDB [2, 3], в якій тривалість транзакцій підтримується за рахунок реплік.

Масивно-мультипотокові архітектури комп'ютерів. Сьогоднішні комп'ютери розраховані на те, що виконувані в них програми дотримуються принципу локальності. Це означає, що у будь-який момент виконання будь-якого процесу йому достатньо забезпечити деякий обмежений набір команд і даних (робочий набір), причому якщо процес має робочий набор WS в момент часу T, то з великою ймовірністю цей робочий набір збережеться і в момент часу T+t для певного значення t. Принцип локальності дозволяє підтримувати в процесорах апаратний кеш, і саме наявність цього кешу дає можливість згладити розрив у швидкості між процесором і основною пам'яттю.

Проте є класи додатків, у яких програмам не властивий принцип локальності (додатки біоінформатики, аналізу соціальних мереж та ін.). При роботі таких програм наявність кешу ніяк не сприяє ефективності, і вони працюють фактично зі швидкістю основної пам'яті. Ідея апаратної архітектури для підтримки таких програм з'явилася наприкінці минулого десятиліття в компанії “Cray Inc.” [13].

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

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

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

архітектура технологія управління база даний

Зустріч у Бекманському університетському центрі 2013 року

У центрі уваги учасників Бекманської зустрічі була проблема “великих даних”.

Фахівці в галузі баз даних мають унікальні можливості для вирішення проблеми “великих даних” і величезний потенціал для революційного впливу на створення технологій збирання та оброблення структурованих і неструктурованих даних із різних джерел. Для реалізації цього потенціалу потрібно звернути особливу увагу на п'ять галузей досліджень:

- масштабовані інфраструктури великих/швидких даних;

- подолання різнорідностей ландшафту управління даними;

- наскрізне оброблення та інтерпретація даних;

- хмарні служби;

-управління різними ролями людей у життєвому циклі даних.

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

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

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

Висновки

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

У статті зроблено спробу здійснити ретроспективний погляд у багаторічну історію баз даних після першої зустрічі дослідників у 1988 р. у Лагуна-Біч. Роздуми авторів суб'єктивні, і з ними не обов'язково потрібно погоджуватися.

За результатами проведеного аналізу можна спрогнозувати напрями подальших досліджень у галузі баз і сховищ даних:

1. Підтримка мультимедійних об'єктів

1.1 Третинна пам'ять

1.2 Нові типи даних

1.3 Якість обслуговування

1.4 Запити з нечіткими критеріями

1.5 Підтримка інтерфейсів користувача

2. Розподіл інформації

2.1 Ступінь автономності

2.2 Облік та розрахунки

2.3 Безпека та конфіденційність

2.4 Реплікація та узгодження даних

2.5 Інтеграція та перетворення даних

2.6 Вибірка та виявлення даних

2.7 Якість даних

3. Нові застосування баз даних

3.1 Інтелектуальний аналіз даних

3.2 Сховища даних

3.3 Репозитарії

4. Управління потоками робіт та транзакціями

4.1 Управління потоками робіт

4.2 Альтернативні моделі транзакцій

5. Простота використання

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

Список використаних джерел

1. Кузнецов С.Д. MapReduce: внутри, снаружи или сбоку от параллельных СУБД? // Труды ИСП РАН. 2010. Т. 19. С. 35-40.

2. Stonebraker M., Madden S., Abadi D. J., Harizopoulos S., Hachem N., Heiland P. The End of an Architectural Era (It's Time for a Complete Rewrite) // Proceedings of VLDB. 2007. P. 1150-1160.

3. Vertica Accelerator. The Fastest Analytics and Machine Learning - from Start to Finish.

4. Stonebraker M., Јetintemel U. “One Size Fits All”: An Idea Whose Time Has Come and Gone // ICDE `05, Proceedings of the 21st International Conference on Data Engineering, April 5-8, 2005. P. 2-11.

5. Chaudhuri S., Narasayya V. AutoAdmin “what-if” index analysis utility // SIGMOD `98, Proceedings of the 1998 ACM SIGMOD international conference on Management of data, Seattle, Washington, USA, June 1-4, 1998. P. 367-378.

6. Bruno N., Chaudhuri S., Kцnig A. C., Narasayya V., Ramamurthy R., and Syamala

M. AutoAdmin Project at Microsoft Research: Lessons Learned // Bulletin of the Technical Committee on Data Engineering. 2011. Vol. 34. No 4. P. 12-19.

7. Belknap P., Beresniewicz J., Dageville B., Dias K., Shaft U., Yagoub K.A Decade of Oracle Database Manageability // Bulletin of the Technical Committee on Data Engineering. 2011. Vol. 34. No 4. P. 20-27.

8. Кузнецов С.Д., Прохоров А.А. Алгоритмы управления буферным пулом СУБД при работе с флэш-накопителями // Труды ИСП РАН. 2012. Т. 23. С. 173-194.

9. Stonebraker M. The Design of the POSTGRES Storage System // VLDB `87, Proceedings of the 13th International Conference on Very Large Data Bases, September 01-04, 1987. P. 289-300.

10. DeBrabant J., Arulraj J., Pavlo A., Stonebraker M., Zdonik S. B., Dulloor S. A Prolegomenon on OLTP Database Systems for Non-Volatile Memory // ADMS 2014, Fifth International Workshop on Accelerating Data Management Systems Using Modern Processor and Storage Architectures, September 1, 2014. P. 57-63.

11. Oukid I., Lehner W. Towards a Single-Level Database Architecture on Non-Volatile Memory (Presentation Abstract) // 8th Annual Non-Volatile Memories Workshop 2017, University of California, San Diego - Price Center Ballroom East, March 12-14, 2017.

12. Tumeo A., Secchi S., and Villa O. Designing Next-Generation Massively Multithreaded Architectures for Irregular Applications // Computer. 2012. Vol. 45. No 8. P. 53-61.

13. Schцning H. Tamino - A DBMS Designed for XML // ICDE `01, Proceedings of the 17th International Conference on Data Engineering, April 02-06, 2001. P. 149.

14. Fomichev A., Grinev M., Kuznetsov S. Sedna: A Native XML DBMS // Lecture Notes in Computer Science. 2006. Vol. 3831. P. 272-281.

15. Franklin M., Halevy A., Maier D. From Databases to Dataspaces: A New Abstraction for Information Management // SIGMOD Record. 2005.Vol. 34. No 4. P. 27-33.

16. Virparia P.V., Buch S.H., Parabia R.F. Trade and Tricks: Traditional vs. Virtual Data Warehouse // An International Journal of Advanced Engineering & Applications. 2010. Vol. 2. No 3. P. 225-239.

17. Inmon B. The Elusive Virtual Data Warehouse, March 19, 2009.

18. Gadepally V., Chen P., Duggan J., Elmore A., Haynes B., Kepner J., Madden S., Mattson T. Stonebraker M. The BigDAWG Polystore System and Architecture // Proceedings of 2016 IEEE High Performance Extreme Computing Conference (HPEC). P. 1-6.

19. Pandis I., Johnson R., Hardavellas N., Ailamaki A. Data-oriented transaction execution // Proceedings of the VLDB Endowment. 2010. Vol. 3. P. 928-939.

20. Кузнецов С.Д. Управление данными: 25 лет прогнозов // Труды Института системного программирования РАН. 2017. Т. 29. Вып. 2. С. 117-160.

References

1. Kuznetsov S.D. (2010). MapReduce: vnutri, snaruzhi ili sboku ot parallelnyih SUBD? [MapReduce: within, outside, or on the side-by-side with parallel DBMSs?]. Trudy ISP RAN- Proceedings of the Institute for System Programing ofthe Russian Academy of Sciences, 19, 35-40 [in Russian].

2. Stonebraker M., Madden S., Abadi D.J., Harizopoulos S., Hachem N., & Helland P. (2007). The End of an Architectural Era (It's Time for a Complete Rewrite). Proceedings of VLDB, 1150-1160.

3. Vertica Accelerator. The Fastest Analytics and Machine Learning - from Start to

4. Stonebraker M. & Јetintemel U. (2005). “One Size Fits All”: An Idea Whose Time Has Come and Gone. ICDE `05, Proceedings of the 21st International Conference on Data Engineering, 2-11.

5. Chaudhuri S., & Narasayya V. (1998). AutoAdmin “what-if” index analysis utility. SIGMOD `98, Proceedings ofthe 1998ACMSIGMOD International Conference on Management of Data, 367-378.

6. Bruno N., Chaudhuri S., Kцnig A.C., Narasayya V., Ramamurthy R., & Syamala M. (2011). AutoAdmin Project at Microsoft Research: Lessons Learned. Bulletin ofthe Technical Committee on Data Engineering, vol. 34, issue 4, 12-19.

7. Belknap P., Beresniewicz J., Dageville B., Dias K., Shaft U., & Yagoub K. (2011). A Decade of Oracle Database Manageability. Bulletin of the Technical Committee on Data Engineering, vol. 34, issue 4, 20-27.

8. Kuznetsov S.D., & Prokhorov А.А. (2012). Algoritmyi upravleniya bufernyim pulom SUBD pri rabote s flesh-nakopitelyami [Algorithms for control of DBMS buffer pool in handling flash drives]. Trudy ISP RAN - Proceedings of the Institute for System Programing of the RAS, 23, 173-194.

9. Stonebraker M. (1987). The Design of the POSTGRES Storage System. VLDB `87, Proceedings of the 13th International Conference on Very Large Data Bases, 289-300.

10. DeBrabant J., Arulraj J., Pavlo A., Stonebraker M., Zdonik S. B., & Dulloor S. (2014). A Prolegomenon on OLTP Database Systems for Non-Volatile Memory. ADMS 2014, Fifth International Workshop on Accelerating Data Management Systems Using Modern Processor and Storage Architectures, 57-63.

11. Oukid I., & Lehner W. (2017). Towards a Single-Level Database Architecture on Non-Volatile Memory (Presentation Abstract). 8th Annual Non-Volatile Memories Workshop 2017, University of California.

12. Tumeo A., Secchi S., & Villa O. (2012). Designing Next-Generation Massively Multithreaded Architectures for Irregular Applications. Computer, vol. 45, issue 8, 53-61.

13. Schцning H. (2001). Tamino - A DBMS Designed for XML. ICDE `01, Proceedings of the 17th International Conference on Data Engineering, p. 149.

14. Fomichev A., Grinev M., & Kuznetsov S. (2006). Sedna: A Native XML DBMS. Lecture Notes in Computer Science, 3831, 272-281.

15. Franklin M., Halevy A., & Maier D. (2005). From Databases to Dataspaces: A New Abstraction for Information Management. SIGMOD Record, vol. 34, issue 4, 27-33.

16. Virparia P.V., Buch S.H., & Parabia R.F. (2010). Trade and Tricks: Traditional vs. Virtual Data Warehouse. An International Journal of Advanced Engineering & Applications, 2010, vol. 2, issue 3, 225-239.

17. Inmon B. (2009). The Elusive Virtual Data Warehouse, March 19.

18. Gadepally V., Chen P., Duggan J., Elmore A., Haynes B., Kepner J., et al. (2016). The BigDAWG Polystore System and Architecture. Proceedings of 2016 IEEE High Performance Extreme Computing Conference (HPEC), 1-6.

19. Pandis I., Johnson R., Hardavellas N., & Ailamaki A. (2010). Data-oriented transaction execution. Proceedings ofthe VLDB Endowment, vol. 3, 928-939.

20. Kuznetsov S.D. (2017). Upravlenie dannyimi: 25 let prognozov [Data management: 25 years of forecasts]. Trudy ISP RAN - Proceedings of the Institute for System Programing of the Russian Academy of Sciences, 2017, 29(2), 117-160 [in Russian].

Размещено на allbest.ru