Хранение огромных объемов данных из массива датчиков

Мне было поручено реализовать решение (app и 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 , что означает, что если вы хотите создать полную резервную копию своей базы данных, она будет БОЛЬШОЙ, и для ее завершения потребуется ДЛИННОЕ время.

Какое решение? Разделение таблицы, Прочтите об этом подробно, в максимально возможном количестве мест. По сути, секционирование позволяет разделить данные на «таблицы в таблицах» - каждый раздел использует одну и ту же схему и доступен через объект таблицы, но может индексироваться и обслуживаться по-разному. Разделы - это, в основном, таблицы, разрезанные по некоторым полезным ключам. В вашем случае это, скорее всего, будет дата. Они могут быть удалены так же, как (и так же быстро), как таблицы, что означает, что если вы разбиваете свои таблицы больших данных по дате, вы можете просто отбросить старые разделы мгновенно, не оказывая негативного влияния на индексы любого из других разделов. Вы можете размещать разделы в разных файловых группах, что означает, что старые разделы могут быть удалены или перенесены в более дешевое хранилище, если оно не используется. И последнее, но не менее важное: в SQL 2012 вына старых разделах , предназначенных только для чтения , при этом в активном разделе, где вы вставляете все данные датчика, используется другая, более ориентированная на вставку схема индексации.

Надеюсь это поможет. У вас есть много исследований, посвященных разделам и схемам разделов, но, надеюсь, теперь вы знаете направление, в котором вам нужно искать.

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

PPS: Да, и еще одна вещь. Вам не нужно ваше решение за двумя столами, чтобы все это работало. Большие двоичные данные датчика должны иметь тип VARBINARY (MAX), потому что его значения могут храниться « вне строки », но все же быть столбцом в одной таблице (см. Документацию sp_tableoption ). Возможно, вы захотите рассмотреть вопрос о нормализации некоторых ваших данных датчиков из двоичных данных, которые у вас есть в таблице, потому что ваша база данных не будет полезна для чего-то большего, чем извлечение порций данных датчиков по времени, если вы этого не сделаете.

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