Фон
У мене є мережа приблизно з 2000 датчиків, кожен з яких має близько 100 точок даних, які ми збираємо на 10-хвилинних інтервалах. Ці точки даних є типово значеннями int, але деякі - це рядки та поплавці. Ці дані повинні зберігатися протягом 90 днів, якщо це можливо, ще ефективніше.
Дизайн баз даних
Первісно поставивши завдання цього проекту, я написав додаток C #, який писав файли, розділені комами для кожного датчика. У той час їх було не так багато, коли хтось захотів подивитися на тенденції, ми відкриємо csv в Excel і графікуємо за потребою.
Все зросло, і ми перейшли до бази даних MySQL. Я створив таблицю для кожного датчика (так я знаю, багато таблиць!); він працює добре, але має деякі обмеження. З такою кількістю таблиць, очевидно, неможливо написати запит, який знайде дані серед усіх датчиків при пошуку певного значення.
Для наступної версії я перейшов на Microsoft SQL Server Express і перемістив усі сенсорні дані в одну велику таблицю. Це також працює, і дозволяє нам робити запити, щоб знайти значення серед усіх цікавих датчиків. Однак я зіткнувся з обмеженням 10 Гб для версії Express і вирішив перейти на MySQL, а не інвестувати в стандарт SQL Server.
Питання
Я задоволений продуктивністю та масштабованістю MySQL, але впевнений, що найкраще дотримуватися підходу «всі дані в одному столі». 10 Гб в одній таблиці, схоже, вимагають іншого дизайну. Я мушу зазначити, що необхідність запиту даних для графіки все ще існує, і я переживаю, що виникнуть проблеми з виконанням запиту, який графікує, наприклад, дані про температуру для одного датчика протягом 90 днів. (Іншими словами, графік повинен бути швидким для створення, не чекаючи, коли SQL розбереться через купи даних лише для того, щоб виділити цікавий датчик.)
Чи слід розділити цю таблицю якимось чином для підвищення продуктивності? Або не незвично мати такий великий стіл?
У мене є індекси на стовпчиках Sensor і Timestamp, що в значній мірі визначає межі для будь-якого запиту. (тобто отримати дані для датчика X час від часу А до часу В).
Я читав трохи про заточування та розбиття, але не вважаю, що це доречно в цьому випадку.
Редагувати:
На основі зауважень та відповідей, деякі додаткові відомості можуть бути корисними:
Не невизначене зберігання: На даний момент я не зберігаю дані за останні 90 днів. Щодня я запускаю запит, який видаляє дані старші 90 днів. Якщо це стане важливим у майбутньому, я буду зберігати більше, але поки це достатньо. Це допомагає підтримувати розмір перевірки та високої продуктивності (er).
Тип двигуна: в оригінальній реалізації MySQL використовується MyISAM. Цього разу створюючи таблиці для нової реалізації (одна таблиця даних замість багатьох), вони встановили дефолт у InnoDB. Я не вірю, що у мене є вимога до того чи іншого.
Нормалізація: Окрім таблиці збору даних, звичайно, є й інші таблиці. У цих таблицях підтримки зберігаються такі речі, як мережева інформація для датчиків, інформація про вхід для користувачів тощо. Нормалізувати не багато (наскільки я знаю). Причина, що в таблиці даних є стільки стовпців, полягає в тому, що існує багато змінних від кожного датчика. (Багаторазові температури, рівень освітлення, тиск повітря і т. Д.) Нормалізація для мене означає, що немає зайвих даних або повторюваних груп. (Принаймні для 1NF.) Для даного датчика для зберігання всіх значень у певний час потрібен один ряд даних, і там немає жодних зв’язків 1: N (що я бачу).
Я міг би розбити таблицю функціонально, зробивши (наприклад) всі значення температури, що знаходяться в одній таблиці, і всі значення тиску повітря в іншій. Хоча це може підвищити ефективність того, хто робить запит лише на температуру, я все одно повинен вставити всі дані відразу. Однак підвищення ефективності може бути корисним для операцій SELECT. Очевидно, мені було б краще розділити таблицю вертикально, виходячи з того, як часто користувачі запитують дані. Можливо, це все, що я повинен зробити. Я гадаю, що задаючи своє запитання, я шукаю підтвердження того, що робити це було б варто.
Редагувати 2:
Використання даних: Зрештою, велика частина даних ніколи не переглядається і не потрібна, оскільки ми зазвичай зосереджуємось лише на елементах, що мають проблеми. Але, намагаючись знайти проблеми, ми використовуємо різні інструменти для пошуку даних та визначення того, які елементи можна збільшити.
Наприклад, ми помітили співвідношення між значенням обсягу використання пам'яті (власна програмна програма для клієнта) та перезавантаженням / збоєм. Один із даних, які я збираю, стосується цього використання пам’яті, і я зміг переглянути історичні дані, щоб показати, що пристрої стають нестабільними після перевищення певного використання пам’яті. Сьогодні для підмножини пристроїв, на яких працює це програмне забезпечення, я перевіряю це значення і видаю команду перезавантаження, якщо вона занадто висока. Поки це не було виявлено, я не вважав, що збір цих даних має значення.
З цієї причини я стверджував, що близько 100 точок даних збираються та зберігаються, навіть якщо значення є сумнівним. Але при звичайному щоденному використанні користувачі, як правило, вивчають, можливо, десяток цих параметрів. Якщо користувач зацікавиться певним географічним районом, він може (використовуючи програмне забезпечення) генерувати графіки або електронні таблиці даних, можливо, на кілька десятків датчиків. Не рідкість дивитися на 30-денний графік з двома-трьома сюжетними лініями, що показують такі речі, як температура, тиск повітря та рівень освітлення. Для цього буде запущений запит, подібний до цього:
SELECT sensor_id, location, data_timestamp, temp1, air1, light1
FROM data
WHERE data_timestamp >= '2012-02-01'
AND sensor_id IN (1, 2, 3);
(У оригінальній версії MySQL, де у кожного датчика була своя таблиця, було б видано три окремі запити, але результати об'єднані в програмне забезпечення для створення графіка.)
Оскільки в dataтаблиці міститься стільки рядків (~ 10 мільйонів), незважаючи на індекси idта data_timestamp, продуктивність помітно гірша, ніж сценарій з декількома таблицями (4500 рядків повернулися за 9 секунд на відміну від менш ніж однієї секунди з цим прикладом). Можливість знайти, які датчики відповідають певним критеріям, практично дорівнює нулю в схемі з декількома таблицями, і, отже, причина переходу до однієї таблиці.
Цей тип запиту може здійснюватися декількома користувачами швидко, оскільки вони вибирають різні групи даних і порівнюють графіки кожного результату. Зачекати майже 10 секунд на графік або електронну таблицю може бути дуже неприємно.
Дані відкидаються через 90 днів. Це може бути заархівовано, але наразі це не є вимогою.
Сподіваємось, ця інформація допомагає більш адекватно показати, як дані використовуються після збору та зберігання.