Я створюю систему, яка опитує пристрої для отримання даних про різні показники, такі як використання процесора, використання диска, температура тощо на (певно) 5-хвилинних інтервалах, використовуючи SNMP. Кінцевою метою є надання візуалізації користувачеві системи у вигляді графіків часових рядів.

Я раніше розглядав використання RRDTool, але відхилив його, оскільки зберігання захоплених даних нескінченно є важливим для мого проекту, і мені хочеться більш високого рівня та більш гнучкого доступу до захоплених даних. Отже, моє запитання справді:

Що краще, реляційна база даних (наприклад, MySQL або PostgreSQL) або нереляційна або база даних NoSQL (наприклад, MongoDB або Redis) щодо продуктивності при запиті даних для графіків.

Реляційний

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

Поля: id fk_to_device fk_to_metric metric_value timestamp

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

SELECT metric_value, timestamp FROM data_instances
    WHERE fk_to_device=1 AND fk_to_metric=2

Кількість рядків у цій таблиці складе:

d * m_d * f * t

де dце кількість пристроїв , m_dє накопичувальним кількість метрик записуються для всіх пристроїв, fє частотою , з якою дані опитуванням для і tце загальна кількість часу , система збирає дані.

Для користувача, який записує 10 метрик на 3 пристрої кожні 5 хвилин протягом року, ми мали б трохи менше 5 мільйонів записів.

Покажчики

Без індексів fk_to_deviceта fk_to_metricсканування ця таблиця, що постійно розширюється, зайняла б занадто багато часу. Тому індексація вищезазначених полів, а також timestamp(для створення графіків з локалізованими періодами) є обов'язковою умовою.

Нереляційний (NoSQL)

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

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

Не визначився

Чи зменшиться реляційне рішення з правильним індексуванням до сканування протягом року? Або структура базованих на колекції підходів NoSQL (яка відповідає моїй ментальній моделі збережених даних) дає помітну перевагу?

Однозначно реляційні. Необмежена гнучкість та розширення.

Два виправлення, як в концепції, так і в застосуванні, з подальшим підвищенням.

Корекція

1. Це не "фільтрація непотрібних даних"; це вибір лише необхідних даних. Так, звичайно, якщо у вас є індекс для підтримки стовпців, визначених у пункті WHERE, це дуже швидко, і запит не залежить від розміру таблиці (захоплення 1000 рядків з таблиці в 16 мільярдів рядків миттєво) .

2. Ваш стіл має одну серйозну перешкоду. З огляду на ваш опис, фактичний ПК (Device, Metric, DateTime). (Будь ласка, не називайте це TimeStamp, це означає щось інше, але це незначна проблема.) Унікальність рядка визначається за допомогою:

      (Device, Metric, DateTime)
   

   • IdКолонка нічого не робить, це цілком і повністю надлишковими.

     • IdКолона ніколи не ключ (повторювані рядки, які заборонені в реляційної базі даних, повинні бути попереджені з допомогою інших засобів).

     • У Idстовпці потрібен додатковий індекс, який очевидно перешкоджає швидкості INSERT/DELETEта додає до використовуваного дискового простору.

     • Ви можете позбутися від нього. Будь ласка.

Підняття

1. Тепер, коли ви усунули перешкоду, ви, можливо, не розпізнали його, але ваша таблиця знаходиться у шостій нормальній формі. Дуже висока швидкість, лише один індекс на ПК. Для розуміння прочитайте цю відповідь із розділу Що таке шоста нормальна форма? прямуючи вперед.

   • (У мене є лише один індекс, а не три; для Non-SQL можуть знадобитися три індекси).

   • У мене точно така ж таблиця (без Id«ключа», звичайно). У мене є додаткова колонка Server. Я віддалено підтримую кількох клієнтів.

     (Server, Device, Metric, DateTime)

   Таблицю можна використовувати для перекидання даних (тобто Devicesвгорі та Metricsвниз збоку або поворотів), використовуючи абсолютно той самий SQL-код (так, переключення комірок). Я використовую таблицю для зведення необмеженої кількості різноманітних графіків і діаграм для клієнтів, що відносять їх продуктивність на сервері.

   • Моніторна модель даних статистики .
     (Занадто велика кількість для вбудованого рядка; деякі веб-переглядачі не можуть завантажувати вбудований текст; натисніть посилання. Крім того, це застаріла демо-версія. Зі зрозумілих причин я не можу показати вам комерційний продукт DM.)

   • Це дозволяє мені створювати подібні діаграми , шість натискань клавіш після отримання від клієнта файлу статистики моніторингу, використовуючи одну команду SELECT . Помічайте сумішшю; ОС і сервер на одному графіку; різноманітність півотів. Звичайно, немає кількості матриць статистики, а отже, і діаграм. (Використовується з доброго дозволу замовника.)

   • Читачі, які не знайомі зі Стандартом моделювання реляційних баз даних, можуть вважати Повідомлення IDEF1X корисним.

І ще одна річ

І останнє, але не менш важливе, SQL є стандартом IEC / ISO / ANSI. Безкоштовна програма - насправді Non-SQL; використовувати термін SQL недобросовісно, ​​якщо вони не надають Стандарт. Вони можуть надати "додаткові", але вони відсутні.

Знайшли дуже цікаві наведені відповіді. Спробуйте додати ще пару міркувань.

1) Старіння даних

Управління тимчасовими рядами зазвичай потребує створення політики старіння. Типовий сценарій (наприклад, CPU сервера моніторингу) потребує збереження:

• 1-секундні сировинні зразки протягом короткого періоду (наприклад, протягом 24 годин)

• 5-хвилинна деталізація сукупних зразків за середній період (наприклад, 1 тиждень)

• 1-годинна деталізація над цим (наприклад, до 1 року)

Хоча реляційні моделі дозволяють точно (моя компанія впровадила масивні централізовані бази даних для деяких великих клієнтів із десятками тисяч серій даних) для належного управління ним, нова порода сховищ даних додає цікавих функцій, які слід вивчити, як:

• автоматична чистка даних (див. команду Redis 'EXPIRE)

• багатовимірна агрегація (наприклад, зменшення робочих місць a-la-Splunk)

2) Колекція в режимі реального часу

Ще важливіше, що деякі нереляційні сховища даних по своїй суті є розподіленими і дозволяють набагато ефективніше збирати дані в реальному часі (або майже в реальному часі), що може стати проблемою для RDBMS через створення точних точок (управління індексуванням при вставці в єдину таблицю). Ця проблема в просторі RDBMS, як правило, вирішується поверненням до процедур пакетного імпорту (ми керували цим таким чином у минулому), тоді як технології no-sql досягли успіху в масовому збиранні та агрегації в реальному часі (див., Наприклад, Splunk, згаданий у попередніх відповідях) .

У вашій таблиці є дані в одній таблиці. Тож реляційна проти нереляційна не є питанням. В основному вам потрібно прочитати багато послідовних даних. Тепер, якщо у вас є достатня кількість оперативної пам’яті для зберігання даних на рік, то нічого подібного до використання Redis / MongoDB тощо.

Переважно бази даних NoSQL зберігатимуть ваші дані в одному місці на диску та в стисненому вигляді, щоб уникнути багаторазового доступу до диска.

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

Такі інструменти, як Splunk, використовують серверні файли NoSQL для зберігання даних часових рядів, а потім зменшення карт для створення агрегатів (що може бути тим, що ви хочете пізніше). Тому, на мою думку, використовувати NoSQL - це варіант, оскільки люди вже пробували це для подібних випадків використання. Але чи мільйон рядків приведе базу даних до сканування (можливо, ні, з гідним обладнанням та належною конфігурацією).

Створіть файл, назвіть його 1_2.data. набридла ідея? що ви отримуєте:

• Ви економите до 50% місця, оскільки не потрібно повторювати значення fk_to_device та fk_to_metric для кожної точки даних.
• Ви економите ще більше місця, тому що вам не потрібні індекси.
• Збережіть пари (timetamp, metric_value) у файлі, додавши дані, щоб ви отримали замовлення за часовою міткою безкоштовно. (якщо припустити, що ваші джерела не надсилають дані про замовлення для пристрою)

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

якщо вам це подобається ще більш оптимізовано, починайте думати про поділ ваших файлів;

• 1_2_january2014.дані
• 1_2_february2014.дані
• 1_2_march2014.дані

або використовувати kdb + від http://kx.com оскільки вони все це роблять для вас :), орієнтований на стовпці - це те, що може вам допомогти.

Вискочить хмарне рішення, орієнтоване на хмарну колонку, тож ви можете ознайомитись з цим: http://timeseries.guru

Якщо ви дивитесь на пакети GPL, RRDTool є хорошим для погляду. Це хороший інструмент для зберігання, вилучення та графіки даних часових рядів. Ваш регістр використання схожий на дані часових рядів.

Це проблема, яку нам довелося вирішити на ApiAxle. Ми написали допис у блозі про те, як ми це зробили за допомогою Redis. Він там не дуже давно, але він виявляється ефективним.

Я також використав RRDTool для іншого проекту, який був відмінним.

Я думаю, що відповідь на подібне запитання в основному має стосуватися того, як ваша база даних використовує сховище. Деякі сервери баз даних використовують оперативну пам’ять та диск, деякі використовують лише оперативну пам’ять (необов'язково диск для постійності) тощо. Найбільш поширені рішення бази даних SQL використовують пам'ять + дискове зберігання та записують дані у макет на основі рядків (кожен вставлений вихідний файл записується в однаковий фізичне розташування). Для магазинів, що займаються тимчасовим виробництвом, у більшості випадків навантаження є чимось на зразок: відносно низький інтервал масивної кількості вставок, тоді як зчитування базуються на колонках (у більшості випадків потрібно прочитати діапазон даних із конкретного стовпця, що представляє собою метрику)

Я знайшов Columnar Бази даних (google це, ви знайдете MonetDB, InfoBright, parAccel тощо) роблять приголомшливу роботу для часових рядів.

Що стосується вашого питання, яке особисто я вважаю дещо недійсним (як і всі дискусії з використанням помилкового терміна NoSQL - IMO): Ви можете використовувати сервер бази даних, який може говорити SQL з одного боку, що робить ваше життя дуже легким, оскільки всі знають SQL для багатьох років, і ця мова вдосконалювалась знову і знову для запитів даних; але все-таки використовувати оперативну пам’ять, кеш процесора та диск в колонно-орієнтованому вигляді, завдяки чому ваше рішення найкраще відповідає часовій серії

5 мільйонів рядків - це нічого для сьогоднішніх проливних даних. Очікуйте, що дані потраплять до туберкульозу або ЛБ лише через кілька місяців. На даний момент RDBMS не підходить до завдання, і нам потрібна лінійна масштабованість баз даних NoSql. Ефективність буде досягнута для стовпчастого розділу, який використовується для зберігання даних, додаючи більше стовпців і менше рядків типу концепції для підвищення продуктивності. Використовуйте роботу відкритого TSDB, виконану поверх HBASE або MapR_DB тощо.

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

Ви повинні заглянути в базу даних часових рядів . Він був створений для цієї мети.

База даних часових рядів (TSDB) - це програмна система, оптимізована для обробки даних часових рядів, масивів чисел, індексованих часом (датою або діапазоном дат).

Популярний приклад бази даних часових рядів InfluxDB