евеликої величини. Вона добре стискається алгоритмами ентропійної компресії (наприклад, алгоритмом Лемпеля - Зива-Велч), в результаті чого значно скорочується обсяг введення / виводу, прискорюється завантаження інформації з диска і в кінцевому рахунку зростає швидкість повнотекстового пошуку.
Завдання не для реляційної СУБД
Є набір з 10 тис. датчиків, один раз в секунду відправляють показники (речові числа). Показники датчиків стабільні і змінюються плавно. Необхідно в інтерактивному режимі аналізувати місячні дані і визначати, чи приводить різка зміна одного показника більше ніж на фіксовану порогову величину до зміни іншого показника більше ніж на іншу порогову величину. Бажано використовувати звичайний ПК, не привертаючи спеціальні рішення (RAID-масиви і т. п.).
Якщо кожен датчик генерує значення разів на секунду, то за місяць обсяг даних складе 96 Гбайт, і якщо використовувати РСУБД, то буде потрібно приблизно такий же обсяг дискового простору плюс витрата на зберігання індексів «час -> показники датчиків », кількість яких залежить від логічної структури бази. Якщо буде потрібно зберігати дані за кілька місяців, то реляційна СУБД вже не підходить.
Показання датчиків можна представити у вигляді матриці: рядки відповідають моментам часу, а стовпці - номерам датчиків. Проектування реляційної бази зводиться до подання цієї матриці у вигляді реляційних таблиць. Найпростішим і логічним з точки зору реляційного підходу способом організації є використання таблиці з полями «час - код датчика - значення», але це рішення не застосовується на практиці через величезного розміру таблиці (2592000 секунд x 10 тис. значень).
Вказану матрицю можна «розгортати» в реляційні таблиці по горизонталі або по вертикалі. У першому випадку записи реляційних таблиць будуть відповідати моментів часу, а поля реляційних таблиць - номерам датчиків. Для оцінки зміни значення датчика потрібно взяти запис, що відповідає даному моменту часу, отримати запис для наступного моменту і обчислити різницю значень в одному і тому ж полі. Оскільки первинним ключем таблиці є значення часу, то перші два кроки будуть виконуватися досить повільно, і навіть пошук моментів, коли датчик змінив свої свідчення більше ніж на порогову величину, на практиці працювати не буде. Це пояснюється тим, що для кожної з 2592000 записів потрібно буде знайти «наступну» з тих же 2592000 записів. Якщо з метою оптимізації таблиці розбити по днях, то кожна з них буде містити 24 x 60 x 60=86400 записів, і, відповідно, потрібно буде робити 30 (кількість днів) пошуків, кожен з яких буде аналізувати 86400 записів і для кожної шукати «наступну» з 86400 записів.
Якщо матрицю показань розгортати по вертикалі, то записи реляційних таблиць будуть відповідати номерам датчиків, а поля - моментів часу. У загальній складності вийде сукупність з 2592000 полів, розбитих за таблицями. Очевидно, що працювати з такою базою дуже складно.
Таким чином, класичний реляційний підхід не дає ефективного вирішення завдання.
У розглянутих прикладах інформація хоч і представима в термінах реляційної моделі, але має специфікою, яку можна ефективно використовувати для оптимізації роботи реляційної СУБД. Однак у міру зростання обсягів бази рано чи пізно настає межа таких оптимізацій.
Основні концепції NoSQL
Важливою віхою для високонавантажених...
