Зберігання величезної кількості даних із сенсорного масиву

Мені поставлено завдання реалізувати рішення (додаток та db) для зберігання зразків даних з величезного масиву датчиків. Наразі масив складається з близько 20 000 датчиків, але це незабаром зросте, до 100 000 датчиків. Кожен датчик надсилає вибірку даних кожні 10 секунд, а кожен зразок має розмір 28 байт.

Таким чином, отримання сум призводить до:

• 8640 проб на датчик на день
• 242 кБ даних на датчик на день
• 864 мільйони проб на день

Тепер мені цікаво, що найкращим способом було б зберігання / отримання даних? Я "приєднався" до цього проекту після того, як програмне забезпечення вже було визначено, тому його потрібно реалізувати на платформі Windows за допомогою SQL Server.

Поточне рішення в моїй голові - створити БД з двома таблицями для зберігання зразків даних. Перший служить своєрідним індексом, другий зберігає зібрані зразки у двійковому полі щодня на основі датчика:

Table 1:

  RecordID - BigInt - Identity
  SensorID - BigInt - Primary Key
  Date - DateTime - Primary Key (yyyy-mm-dd)

Table 2:

  RecordID - BigInt - Primary Key (from an insert into Table 1)
  Data - Binary 

В основному я записую зразки з усіх датчиків у тимчасові файли (1 на датчик). Після закінчення кожного дня я буду створювати запис у Таблиці 1, використовувати згенерований RecordID та скидати файл у поле Дані в Таблиці 2.

Таким чином я закінчую лише 100 000 записів до таблиці, а не 864 мільйони записів. Дані повинні бути доступними в локальній мережі або високошвидкісному WAN, тому отримання даних датчиків на цілий день буде прийнятним.

Хоча всі дані потрібно зберігати, більшість з них, ймовірно, ніколи не будуть прочитані. Таким чином, кількість прочитаних на таблиці (их) не буде значно більшою, ніж кількість записів.

Я знаю, що я міг би щось реалізувати за допомогою файлової системи, просто зберігаючи шлях до файлів даних, але я прочитав, що SQL Server перевершує NTFS, тоді як ваші бінарні поля менше дякують 256 КБ. (Сіра зона існує між 256 КБ і 1 МБ, тоді як NTFS набагато перевершує SQL Server для двійкових розмірів> 1 Мб).

Я також злегка насторожено зберігаю дані зі 100 000 датчиків у власних файлах, не викликаючи проблем у файловій системі, або маючи величезну кількість файлів у папці, або маючи складну структуру дерева з кількома файлами у кожній папці, при цьому не навіть враховуючи фрагментацію файлів.

1. Хто-небудь може запропонувати мені кілька практичних порад / коментарів до сказаного?

2. Чи є явні підводні камені, в які я збираюся потрапити?

3. Дані вибірки стискаються досить непогано. Файл 242 кБ стискається приблизно до 85 КБ. Чи можу я проте реалізувати певний тип стиснення на рівні бази даних, щоб зразкові дані (стовпець) стискалися автоматично?

4. Чи явно неправильний вибір SQL Server для цього проекту?

5. Чи розумне моє оформлення двох столів, чи я можу так само добре поєднати його в єдину таблицю, яка все ще буде такою ж "ефективною", як і дві таблиці?

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

Наприклад, скажімо, що ви хочете "скатити" дані про найдавніші місяці через два роки. У вашому дизайні вам доведеться видати DELETE заяву проти великого великого столу. Це, ймовірно, буде дещо повільним, залежно від кількості ваших індексів. Крім того, це призведе до фрагментації індексу, і єдиним способом виправити це буде відновлення або реорганізація індексів на цій дуже великій таблиці, що також спричинить проблеми з продуктивністю. Існує ціла низка інших питань з великим дизайном одного типу таблиці. Наприклад, з великою єдиною таблицею ви не можете робити резервні копії на базі FILEGROUP , а це означає, що якщо ви хочете мати повне резервне копіювання вашої бази даних, це буде BIG, і для завершення знадобиться ВЕЛИКИЙ час.

Яке рішення? Розбиття таблиці. Прочитайте про це глибоко, у скільки завгодно місць. В основному, розділення дозволяє розділити ваші дані на "таблиці всередині таблиць" - кожен розділ поділяє ту саму схему та доступ до нього через об'єкт таблиці, але може індексуватися та підтримуватися по-різному. Перегородки - це в основному таблиці, вирізані корисним ключем. У вашому випадку це, швидше за все, дата. Їх можна скидати так само, як і (і так само швидко), як це означає, що якщо ви розділите свої великі таблиці даних за датою, ви можете просто викинути старі розділи миттєво, не впливаючи на індекси на будь-який з інших розділів. Ви можете розміщувати розділи на різних групах файлів, а це означає, що старі розділи можна скачувати або перетягувати на дешевше зберігання товарів, якщо це звичайно не використовується. І останнє, але не менш важливе: у SQL 2012 вина старих розділах , доступних лише для читання , при цьому інша, більш орієнтована на вставку схема індексації на активному розділі, куди ви вставляєте всі дані датчика.

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

PS: О, і я забув ваш список запитань ... Відповіді 1, 2 і 5. Див. Вище. Відповідь 3: У SQL Server ви можете стискати на розділі на основі розділу, тому агресивно стискайте свої старі розділи за допомогою стиснення PAGE. Але я вважаю, що ваші позарядкові великі типи даних не будуть стискатися, якщо ви це зробите - знову ж таки, ви можете полегшити цю проблему, нормалізуючи значення датчика. Відповідь 4: Абсолютно ні, але якщо все, що ви хочете, це зберігати статичні дані по днях і ніколи не шукати в них інший спосіб, стислі плоскі файли можуть бути набагато простішим способом.

PPS: О, і інша справа. Вам не потрібно рішення настільного столу, щоб все це працювало. Великі дані бінарних датчиків повинні мати тип VARBINARY (MAX), оскільки його значення можуть зберігатися " поза рядом ", але все ж бути стовпцем в одній таблиці (див. Документацію sp_tableoption ). Можливо, ви хочете розглянути можливість нормалізації деяких даних датчиків з бінарних даних, що є у таблиці, оскільки ваша база даних не буде корисною для того, щоб витягнути час від часу, коли ви цього не отримаєте.

Розглянемо рішення Hadoop. 2 Тб / день швидко накопичується. Також врахуйте реєстрацію лише дельта-записів, тобто значення intial, і то лише тоді, коли відбувається зміна.