Оптимизация загрузки диска

В этой главе рассказывается о том, как оптимизировать использование дискового пространства сервером AggreGate.

Высоконагруженный сервер AggreGate получает и сохраняет сотни тысяч образцов данных в секунду. Эти образцы данных обычно поступают в виде событий устройств или значений переменных устройств, которые также преобразуются в события и сохраняются в базе данных. Сокращение объема дискового пространства, используемого историей событий, крайне важно для сред с высокой нагрузкой.

Существует несколько методов, которые могут значительно уменьшить дисковое пространство, занимаемое историей временных рядов:

• Отключение хранения менее важных параметров событий

• Использование сжатия на уровне базы данных

• Использование интеллектуальной фильтрации потока событий

• Ограничение времени хранения истории

• Использование агрегирования значений

Эта опция предполагает, что массовые события перемещаются в специальное хранилище событий, которое сопоставлено с отдельной таблицей базы данных.

Каждое хранилище событий позволяет выполнять тонкую настройку хранимых параметров события, таких как контекст события, имя, уровень, разрешения, количество найденных дубликатов, подтверждения, обогащения и многое другое.

Отключение сохранения всех этих параметров приведет к тому, что на диск будут записываться только основные данные события (то есть «полезная нагрузка»), что значительно сократит использование дискового пространства.

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

Например, база данных Cassandra предлагает несколько методов сжатия, которые оцениваются по степени сжатия и скорости сжатия/декомпрессии.

Обратите внимание, что методы сжатия с более высоким коэффициентом сжатия, как правило, имеют более низкую скорость сжатия/декомпрессии и более высокую нагрузку на процессор.

Интеллектуальная фильтрация потока значений предполагает, что некоторые значения, полученные от устройств, должны быть исключены из обработки и/или хранения. Вот несколько примеров:

• Все значения с плохим или неизвестным качеством OPC могут сохраняться с полной скоростью чтения/приема, в то время как только каждое N-ое значение с хорошим качеством может отправляться на хранение.

• Если ПЛК измеряет частоту тока каждые 100 миллисекунд, каждое показание может быть сохранено в периоды, когда она отклоняется от референсного значения 50/60 Гц более, чем на определенный процент. Нормальные значения частоты могут сохраняться, например, один раз в секунду.

• Вновь считанные/полученные значения могут сохраняться только в том случае, если их разница с предыдущим значением превышает определенный абсолютный или относительный порог. Это позволяет сохранять все значения при их быстром изменении (например, при развитии аварийной ситуации), в то время как большинство значений исключается их хранения в ходе обычного технологического процесса.

Существует два параметра синхронизации настроек устройства, которые влияют на постоянное хранение значений:

• Параметр Режим записи истории - это простой способ исключить значения с определенным качеством

• Параметр Фильтр позволяет использовать расширенную фильтрацию на основе выражений

Параметр Время хранения истории опций синхронизации настроек устройства управляет периодом хранения исторических значений. Убедитесь, что вы настроили его таким образом, чтобы не сохранять историю дольше, чем это требуется по требованиям проекта/продукта.

Значения, которые превысили время хранения, навсегда удаляются из базы данных, эффективно уменьшая ее размер.

Для старых исторических значений часто достаточно сохранить только статистически ценную информацию, например, почасовые минимумы/максимумы или среднеминутные значения.

Используйте Статистику или Грануляцию, чтобы предварительно агрегировать значения для долгосрочного хранения истории.

Оба этих механизма гораздо более эффективны с точки зрения занимаемого дискового пространства по сравнению с хранением необработанной истории.

Вы также можете комбинировать хранение сырой истории для краткосрочной истории и хранение агрегированной истории для долгосрочной истории, постепенно уменьшая уровень доступных деталей истории.

Некоторые устройства, подключенные к AggreGate Server, могут производить миллиарды событий или обновлений значений в день или сотни тысяч обновлений в секунду. AggreGate Server способен обрабатывать и даже постоянно хранить такое большое количество событий/обновлений. Однако некоторые параметры сервера и учетной записи устройства должны быть точно настроены, чтобы достичь хороших показателей производительности.

• Убедитесь, что AggreGate Server использует NoSQL-базу данных для хранения событий и конфигураций.

• Если в качестве основного хранилища исторических данных используются магнитные (не твердотельные) диски, настройте параметры базы данных NoSQL так, чтобы директория Commitlog и директория хранилища располагались на разных физических дисках. Чтобы обеспечить высокую производительность, убедитесь, что commitlog и основное хранилище расположены на твердотельных дисках (SSD).

• Откройте диалоговое окно свойств учетной записи устройства и установите расширенный параметр Режим кэширования настроек на Память (временный кэш). Если используется тип База данных (постоянный кэш) по умолчанию, каждое обновление переменной настройки устройства записывается на диск дважды: как постоянно кэшируемое текущее значение настройки и как событие обновления исторического значения. Текущая производительность системы значительно снижается.

• Большинство коммуникационных протоколов, разработанных для обеспечения высокой производительности, позволяют устройствам отправлять асинхронные обновления значений, что не требует опроса со стороны сервера. Примерами таких протоколов являются OPC или IEC 60870-5-104. Если драйвер вашего устройства поддерживает асинхронное обновление значений, установите Период синхронизации на большее значение (например, один день), чтобы предотвратить неэффективный опрос.

Was this page helpful?

Tell us more

Send

Thank you!