мплектом інструментальних засобів, а набір добре інтегруються блоків, кожен з яких вирішує конкретну задачу обробки даних (наприклад, кешування, розподіл навантаження, компресія даних, передача по мережі і т. д.), не є самодостатнім і вимагає надбудови високорівневих модулів. Це дозволить максимально враховувати специфіку збережених даних і оброблюваних запитів.
Сучасні реляційні СУБД включають в себе всі необхідні підсистеми управління даними (накопичення, контроль цілісності, кешування, оптимізація і виконання запитів, реплікація і т. д.). Після злиття SQL з NoSQL нові СУБД надаватимуть лише «низькорівневі» модулі роботи з даними, а все інше (наприклад, розпаралелювання складних запитів або стратегія кешування) программист повинен або налаштувати самостійно, або використовувати типову конфігурацію. В результаті для кожного застосування створюватиметься цільова СУБД. Вже зараз для багатьох практичних завдань (повнотекстовий пошук, зберігання словників) набагато ефективніше реалізувати власне вузькоспеціалізоване рішення замість використання СУБД.
NoSQL в роботі
Всі датчики з завдання попередньої врізки дають свідчення разів на секунду, тому можна зробити наступне. По-перше, замість показань часу використовувати номер секунди, що пройшла з початку місяця. По-друге, використовувати його не як ключ асоціативного масиву, а як індекс одновимірного масиву показань датчика за місяць.
Кожен датчик змінює своє значення плавно, і послідовність його свідчень має сенс зберігати за аналогією з інвертованими індексами в пошукових системах. Так, історія показань розбивається на дні, а для кожного дня зберігається початкове показання датчика і послідовність дельт. У підсумку за один день буде накопичуватися 24 x 60 x 60=86400 чисел, але 86399 з них виявляться близькі до нуля (так як датчик змінює значення плавно) і будуть дуже добре стискатися. Якщо стиснення буде 10-кратним, то для зберігання свідчень одного датчика за один день знадобиться 24 x 60 x 60=86400 чисел, що потребують приблизно 350 Мбайт без стиснення і 35 Мбайт зі стисненням. Відповідно, вся база буде займати близько 10 Гбайт, при цьому її можна розбити на файли, що містять свідчення набору датчиків за деякий проміжок часу. Це дозволяє підібрати оптимальні параметри розбиття бази на файли і домогтися читання інформації в інтерактивному режимі.
Для прискорення швидкості аналізу потрібно зберігати додаткову бітову матрицю, рядки якої відповідають датчикам, а стовпці - моментів часу. Елемент матриці дорівнює 1, якщо в даний момент часу даний датчик змінює своє значення більше ніж на зазначену фіксовану порогову величину. Сумарно вся матриця складатиметься з 2592000 x 10 000 осередків, що потребують 3 Гбайт пам'яті, але оскільки датчики змінюють своє значення плавно і рідко, то матриця буде сильно розрідженій і при стисканні займе не більше 300 Мбайт.
При поданні в пам'яті бітову матрицю можна розгорнути по рядках або по стовпцях. У першому випадку матриця розпадеться на набір бітових векторів, кожен з яких відповідає одному датчику, а його окремі біти - моментів часу. Для визначення того, змінюють своє значення два датчики одночасно, необхідно виконати операцію побітового «І» відповідних їм векторів. У другому випадку матриця розпадеться на набір бітових векторів, кожен з яких відповідає одному моменту часу, а окремі біти - датчикам. При такому способі зберігання дуже ефекти...
