вно реалізується алгоритм Apriory для пошуку датчиків, одночасно змінюють своє значення. Обидва розглянутих підходи мають свої переваги, але ніщо не заважає зберігати в пам'яті обидва подання матриці. Також ніщо не заважає завести аналогічні матриці для дослідження інших ознак.
З точки зору реалізації буде раціональним розділити бітові матриці на блоки (один блок відповідає набору датчиків і деякому проміжку часу), зберігати їх в пам'яті і не виробляти операції введення / виводу. Тоді швидкість роботи даної цільової СУБД буде залежати тільки від швидкодії процесора. Оскільки потрібні для цього алгоритми добре распараллелівать, то можливо добитися роботи системи в інтерактивному режимі.
Разом з тим даний приклад наочно демонструє, що зазначене завдання поки нездатні ефективно вирішити і існуючі NoSQL СУБД-ця технологія знаходиться ще на етапі становлення, і їй ще належить пройти довгий шлях до того, як стати промисловим стандартом, відповідним для вирішення широкого кола практичних задач . Однак концепція цільових СУБД хоча і покриває розглянуте рішення, але перебуває в ще більш зародковому стані.
Примітно, що оптимізаторів запитів в нових СУБД взагалі не потрібно, тому що кількість типів подаються системі запитів відомо заздалегідь і програміст зможе самостійно вказати всі особливості оптимального виконання кожного з них. Оскільки система орієнтована на роботу з великими обсягами інформації, то під час її експлуатації навряд чи варто очікувати значної зміни статистичних закономірностей у базі, і, отже, навряд чи доведеться коригувати оптимальний план виконання запиту. Замість планувальників запитів будуть затребувані різні засоби моніторингу розробляється або вже використовуваної системи - мета їх роботи полягає в знаходженні «вузьких» місць і виробленні рекомендацій щодо поліпшення системи.
Логічним завершенням підходу побудови цільових СУБД замість використання класичних серверних архітектур є рух у бік RAD (Rapid Application Development), при якому програміст формально описує якісні та кількісні вимоги до створюваної СУБД, отримує попереднє рішення, а потім оптимізує його окремі елементи аж до самостійної реалізації окремих блоків. Створена таким чином цільова СУБД може бути згодом розгорнута на будь інфраструктурі, включаючи і хмари.
За принципом створення і застосування цільові СУБД чимось нагадують інструменти ETL для завантаження даних в інформаційні сховища. Зараз ці інструменти не готові для виклику з програм, але дозволяють створити, налагодити, оптимізувати і багаторазово використовувати саму процедуру ETL. Приблизно за тією ж схемою працюють генератори запитів, і приблизно за тією ж схемою можуть працювати СУБД типу SQL + NoSQL.
***
Два напрямки розвитку СУБД - SQL і NoSQL - багато в чому протиставляються, хоча і підкоряються єдиним законам і рухаються назустріч один одному. Поки цей рух майже непомітно, але воно активізується в міру появи необхідності в засобах побудови високонавантажених систем, в результаті чого відбудеться злиття цих напрямків. Утворені таким чином СУБД можуть виявитися занадто громіздкими для використання на практиці, тому, можливо, відбудеться відмова від поточної архітектурної концепції СУБД у бік появи СУБД, що представляють собою набір «кубиків» для побудови цільової системи, яка має характеристиками, необхідними для конкретних високонавантажених додатків.
Список літератури <...
