Сохранение данных в ThingWorx
ThingWorx предоставляет сущности и методы для сохранения данных. Данные можно хранить в таблицах данных, свойствах вещей, потоках, потоках значений и таблицах конфигурации.
При разработке решения необходимо учитывать, как ThingWorx обрабатывает хранилище данных. Очень важно выбрать правильное хранилище данных, поскольку оно влияет на результат проекта, его масштабируемость и надежность, а также на взаимодействие с пользователем.
В следующем разделе описаны опции сохранения в модели ThingWorx.
Таблица данных
◦ Используйте, если строк данных меньше 100 000.
◦ Используйте для статических наборов данных и статических таблиц подстановки. Для высокодинамичных и очень больших наборов данных используйте реляционную базу данных, которая присоединяется с помощью шаблона вещи Database.
 |
Для сложных запросов и соединений используйте реляционную базу данных.
|
◦ Для запросов и хранилищ на основе ключа, а также для упрощения обновления и удаления используйте ключи на базе основного ключа.
Например, можно сохранять информацию о запасах интеллектуально подключенного торгового автомата, в котором каждая позиция в запасах определяется основным ключом. Можно также использовать таблицы данных для хранения информации о программах орошения, доступных для устройства управления растениеводством, в которых каждая программа орошения представляется строкой с основным ключом.
◦ Чтобы управлять строками данных или запрашивать их по отдельности, используйте таблицы данных.
◦ Используйте индексы при работе с таблицами данных.
Свойство вещи
Свойства вещи используются для того, чтобы сохранять данные о вещи в ThingWorx. Свойства имеют следующие опции хранения данных:
◦ Только для чтения - используйте опцию только для чтения для статических значений, которые не должны изменяться во время выполнения. Однако при желании можно изменить значение по умолчанию.
◦ Хранится - используйте эту опцию, если требуется, чтобы значение свойства сохранялось даже после перезапуска сервера ThingWorx, и если значение свойства может изменяться во время выполнения.
◦ Регистрация - используйте опцию регистрации для свойств, значения которых постоянно обновляются. Это данные временного ряда, которые могут сохраняться в потоках значений.
|
|
Не используйте явные свойства для хранения исторических данных. Вместо этого используйте потоки или потоки значений.
|
Поток
Используется для регистрации управляемых во времени событий процессов или задач, связанных с устройствами.
Например, создайте поток для регистрации проблем, связанных с задачами устройства, или для записи времени, когда устройство отсоединяется от платформы ThingWorx и повторно присоединяется к ней. Потоки оптимизированы для высокоскоростной записи и имеют конфигурируемую систему кэширования.
Поток значений
Используется для хранения данных временного ряда, получаемых из свойств вещи.
С помощью потоков создаются таблицы данных. При использовании потоков значений можно избежать создания разреженных таблиц данных.
Ориентированный на вещь доступ к ее данным в потоке значений обеспечивает встроенную поддержку большого числа клиентов.
Если вы используете RDMS (PostgreSQL, MSSQL, H2), все записи, даже из различных потоков значений для различных вещей, записываются в одну и ту же таблицу базы данных.
При использовании PostgreSQL в таблице для потока значений в базе данных PostgreSQL каждая строка содержит запись только для одного свойства. Это означает, что поток значений отслеживает изменение значения каждого свойства независимо. После использования сервиса QueryPropertyHistory он проверяет поток данных для каждого свойства в вещи и собирает все последние обновления (у каждого из них имеется другое время обновления) в одну результирующую таблицу данных.
В следующей таблице представлена информация о главных различиях между потоками и потоками значений. Используйте эту информацию, чтобы определить тип сущности, который будет использоваться для хранения данных временного ряда в решении.
|
Потоки
|
Потоки значений
|
|---|---|
|
В потоках могут сохраняться любые типы данных временного ряда.
|
В потоках значений могут сохраняться данные временного ряда из свойства вещи.
Потоки значений привязаны к свойствам вещи.
|
|
Можно запрашивать данные из потоков непосредственно с помощью их собственных сервисов. Результатом запроса является вся строка данных.
|
Невозможно запрашивать данные непосредственно из потоков значений. Вместо этого используйте для запроса данных из потока значений сервисы, определенные для вещи. Например: QueryPropertyHistory
|
|
Чтобы добавить строку данных в поток, используйте сервис WritePropertiesToStream.
|
Чтобы добавить данные в поток значений, установите для свойства флажок Зарегистрирован.
|
|
В потоках могут сохраняться контекстные данные. Например, при инициировании определенного события можно добавить значения других свойств. Это полезно при анализе данных.
|
Потоки значений не могут сохранять контекстные данные.
|
Когда использовать потоки или потоки значений?
◦ Используйте потоки значений и потоки для сохранения и загрузки данных временного ряда. В зависимости от объема данных, которые необходимо сохранить, выбирайте подходящую опцию сохранения данных.
◦ Потоки используются, когда требуется запрашивать данные только в пределах небольших временных интервалов.
◦ Разбивайте вещи по нескольким потокам значений для повышения быстродействия индексирования.
Таблица конфигурации
Используется для построения настраиваемых приложений, которые можно безопасно обновлять в ThingWorx Platform.
Можно добавить таблицу конфигурации в сущность мэшапа на основе предопределенной структуры данных. Это упрощает процесс построения мэшапов расширений, которые можно настраивать, по-прежнему поддерживая обновления на местах, поскольку значения таблицы конфигурации переносятся во время обновления расширения.
Восстановление после отключения базы данных для поставщиков данных
Если при перезапуске или сбое в базе данных не удалось сохранить потребляемые данные в поставщиках данных, можно настроить систему на повторение этих операций во избежание потери данных, задав следующие конфигурируемые свойства для требуемых поставщиков хранилищ данных в файле platform-settings.json:
• acquireRetryAttempts - определяет для ThingWorx доступное число попыток получить новое соединение с базой данных.
• acquireRetryDelay - время (в миллисекундах) между попытками получить соединение, в течение которого ThingWorx выполняет ожидание.
Соответственно, ThingWorx будет повторять до acquireRetryAttempts раз с задержкой acquireRetryDelay между каждой попыткой в соответствии со сконфигурированными настройками. (Например, если требуется, чтобы ThingWorx ожидал 5 секунд возвращения базы данных в интерактивный режим, задайте acquireRetryAttempts= 5 и acquireRetryDelay= 1000.)
Если все повторные попытки окажутся безуспешными, в Журнале приложениябудет зарегистрировано следующее сообщение об ошибке, указывающее, что записи не удалось сохранить: Failed to connect to persistence provider after retrying 5 times in 10 seconds.
|
|
Не рекомендуется задавать отрицательное значение acquireRetryAttempts, так как приложение будет пытаться неограниченно сохранять записи, что может привести к зависанию платформы в случае длительного отключения базы данных.
|
При использовании InfluxDB в качестве дополнительного поставщика хранилища данных необходимо сконфигурировать DatabaseWriteRetryAttempts, чтобы повторить операции с базой данных заданное число раз.
|
|
Для часто изменяющихся сохраненных и регистрируемых свойств могут возникать неизбежные незначительные потери данных из-за пакетной обработки. В таких случаях в Журналы приложения будут записаны следующие сообщения:
Для сохраненного свойства: BatchUpdateException error occurred executing batch update of persistent properties.
Для приема зарегистрированных свойств или потока значений: Error executing batch.
|
|
|
Размеры очереди должны быть соответственно сконфигурированы для хранения данных в зависимости от скорости приема.
|
Дополнительные сведения о быстродействии см. в разделе Отчет о производительности.
Рекомендации по обработке моделирования, ориентированного на данные
Для обработки ориентированного на данные моделирования в ThingWorx используйте следующие общие оптимальные методы:
• Если есть данные, которые не будут изменяться или будут перезаписываться при следующем изменении или загрузке, и они связаны с вещью, создайте для этой вещи свойство infotable и назначьте подходящую структуру данных. Таким образом можно получить доступ к данным с помощью вещи. Можно также использовать таблицы конфигурации или для больших объемов данных применять таблицу данных.
• Используйте кэширования данных максимально возможным образом.
Например, вместо запроса базы данных при каждом событии DataChange реализуйте кэш в виде таблицы данных, которая обновляется через заданные интервалы времени.
• Архивируйте данные, которые больше не нужны.
При конструировании решения необходимо понять, какие данные часто используются. Эти данные можно сохранять в базе данных решения. Как можно раньше перемещайте старые данные на внешний сервер, например на федеративный экземпляр ThingWorx или на сервер базы данных.
• Указывайте параметры даты начала и окончания для методов запроса, чтобы ограничить объем данных, загружаемых запросом. Это сокращает время обработки и повышает производительность.
• Для сценариев с получением большого количества данных (больше объемов, указанных в руководстве ThingWorx Platform Sizing Guide (Руководство по размерам ThingWorx Platform) (на английском языке)) рассмотрите возможность создания нескольких поставщиков хранилища данных, подключенных к отдельным экземплярам базы данных. Это гарантирует, что данные помещаются в различные таблицы базы данных. При добавлении нескольких баз данных поставщики хранилища данных могут указывать на конкретные базы данных. В этом случае потребуется перенос данных.
• Убедитесь, что в таблицах данных меньше 100 000 строк.
• Запросы данных из таблиц данных и потоков должны занимать лишь несколько секунд. Если эти таблицы данных и потоки содержат более 100 000 строк, запросы выполняются медленно.
• Убедитесь, что вы запланировали способы выполнения очистки старых данных. Очистка данных важна, поскольку помогает повысить производительность решения.