Сериализация В и Для Qt

Сериализация, Qt, JSON

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

Эта часть посвящена полезной нагрузке от сообщений и её оптимизации.

Существует множество методов сериализации объекта с помощью Qt . В первой части серии статей мы использовали JSON . Для этого вся информация о датчике хранится в QJsonObject , а QJsonDocument заботится о потоке значений в QByteArray.

QJsonObject jobject;

jobject[ "SensorID" ] = m_id;
jobject[ "AmbientTemperature" ] = m_ambientTemperature;
jobject[ "ObjectTemperature" ] = m_objectTemperature;
jobject[ "AccelerometerX" ] = m_accelerometerX;
jobject[ "AccelerometerY" ] = m_accelerometerY;
jobject[ "AccelerometerZ" ] = m_accelerometerZ;
jobject[ "Altitude" ] = m_altitude;
jobject[ "Light" ] = m_light;
jobject[ "Humidity" ] = m_humidity;

QJsonDocument doc( jobject );

return doc.toJson();

JSON имеет несколько преимуществ:

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

Однако этот подход имеет некоторые ограничения. Во-первых, создание сообщения JSON может быть тяжелой операцией, занимающей много циклов. Бенчмарк второй части тестирования показывает что сериализация и десериализация 10.000 сообщений занимает около 263 мс. Это может быть не похоже на значительное число сообщений, но в этом контексте время соответствует энергии. Это может существенно воздействовать на датчик который предназначен для его использования без зарядки длительное время.

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

внутри комментариев предыдущего поста рекомендовано использовать QJsonDocument : Compact (компакт), который уменьшает размер полезной нагрузки, в среднем до 290 байт

Как это можно улучшить?

Как большинство из вас знает, существует также двоичный JSON, который может уменьшить читаемость, но все другие аспекты по-прежнему актуальны. Главное в проведении бенчмарков  то,  что простой переключатель doc.toJson  в doc.toBinaryData удвоит скорость теста, сократив итерацию бенчмарка до 125 миллисекунд.

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

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

В случае если проект находится !в рамках мира Qt", весь поток данных определён и не изменяется QDataStream , является возможным вариантом .

Добавляем поддержку для  этого в класс SensorInformation, что требует добавления  двух операторов.

QDataStream &operator<<(QDataStream &, const SensorInformation &);
QDataStream &operator>>(QDataStream &, SensorInformation &);

Реализация довольно проста, ниже показан пример сериализации:

QDataStream &operator<<(QDataStream &out, const SensorInformation &item)
{
    QDataStream::FloatingPointPrecision prev = out.floatingPointPrecision();
    out.setFloatingPointPrecision(QDataStream::DoublePrecision);
    out << item.m_id
        << item.m_ambientTemperature
        << item.m_objectTemperature
        << item.m_accelerometerX
        << item.m_accelerometerY
        << item.m_accelerometerZ
        << item.m_altitude
        << item.m_light
        << item.m_humidity;
    out.setFloatingPointPrecision(prev);
    return out;
}

При использовании QDataStream время бенчмарка составило 26 миллисекунд, что почти в 10 раз быстрее чем текстовый JSON. Кроме того, средний размер сообщения составляет всего 84 байта по сравнению с 290. Следовательно, если вышеуказанные ограничения приемлемы, QDataStream, является хорошим вариантом решения поставленной задачи.

Если проект позволяет добавлять дополнительные сторонние компоненты, одним из наиболее известных решений сериализации является протокол буферов Google (protobuf).

Чтобы добавить protobuf в наше решение, нужно сделать пару изменений. Во-первых, protobuf использует IDL для описания структур данных или сообщений. Тогда, разработка сенсора информации:

syntax = "proto2" ;

package serialtest;

message Sensor {
    required string id = 1;
    required double ambientTemperature = 2;
    required double objectTemperature = 3;
    required double accelerometerX = 4;
    required double accelerometerY = 5;
    required double accelerometerZ = 6;
    required double altitude = 7;
    required double light = 8;
    required double humidity = 9;
}

Чтобы добавить генератор кода protobuf (протокол) в проект qmake, необходимо добавить дополнительный шаг компилятора, подобный этому:

PROTO_FILE = sensor.proto
protoc.output = $${OUT_PWD}/${QMAKE_FILE_IN_BASE}.pb.cc
protoc.commands = $${PROTO_PATH}/bin/protoc -I=$$relative_path($${PWD}, $${OUT_PWD}) --cpp_out=. ${QMAKE_FILE_NAME}
protoc.variable_out = GENERATED_SOURCES
protoc.input = PROTO_FILE
QMAKE_EXTRA_COMPILERS += protoc

Затем, чтобы иметь сопоставимый бенчмарк с точки зрения размера объекта, сгенерированна структура используемая в качестве члена для класса SensorInformationProto, который наследует QObject, как и для примера QDataStream и JSON

class SensorInformationProto : public QObject
{
    Q_OBJECT
    Q_PROPERTY( double ambientTemperature READ ambientTemperature WRITE 
    setAmbientTemperature NOTIFY ambientTemperatureChanged)
[...]

public :
    SensorInformationProto( const std::string &pr);
[...]

    std::string serialize() const ;
[...]

private :
    serialtest::Sensor m_protoInfo;
};

Функция сериализации proto Info генерируется протоколом, поэтому шаг создания передаваемой полезной нагрузки выглядит следующим образом:

std::string SensorInformationProto::serialize() const
{
    std::string res;
    m_protoInfo.SerializeToString(&res);
    return res;
}

Обратите внимание, что по сравнению с предыдущими решениями protobuf использует STD строку. Это означает, что вы теряете возможности QString, если строка не хранится в виде массива байтов (требуется ручное преобразование). Опять же, это замедлит весь процесс из-за разбора.

С точки зрения эффективности результаты контрольных показателей выглядят многообещающими. Бенчмарк с 10.000 элементов занимает всего 5 мс со средним размером сообщения 82 байта.

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

Размер полезной нагрузки

Время (мс)

JSON (текстовый)

346

263

JSON (двоичный)

338

125

QDataStream

84

26

Protobuf

82

5

Одной из перспективных альтернатив является CBOR, который в настоящее время реализуется Thiago Macieira для Qt 5.12. Однако, поскольку процесс разработки продолжается, еще слишком рано его включать его в эту статью. Из обсуждений результаты выглядят многообещающими,  со значительным производительностью по сравнению с JSON,  и со всеми его преимуществами.

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

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

Возврат 10% от суммы заказа отеля на Booking
Возврат 10% от суммы заказа отеля на Booking
Предлагаем ссылку с 10% возвратом от суммы заказа при бронировании отеля через Booking

Комментарии

Только авторизованные пользователи могут публиковать комментарии.
Пожалуйста, авторизуйтесь или зарегистрируйтесь
25 мая 2019 г. 16:20
Андрей Янкович

C++ - Тест 001. Первая программа и типы данных

  • Результат:93баллов,
  • Очки рейтинга8
m
19 мая 2019 г. 1:49
mahhaki

Qt - Тест 001. Сигналы и слоты

  • Результат:78баллов,
  • Очки рейтинга2
S
17 мая 2019 г. 13:14
SunBro

Qt - Тест 001. Сигналы и слоты

  • Результат:42баллов,
  • Очки рейтинга-8
Последние комментарии
21 мая 2019 г. 20:10
Дмитрий

Приветствую! Я думаю дойдёт и до этого, но пока изучать его у меня нет желания.
20 мая 2019 г. 19:20
Евгений Легоцкой

Добрый день! Вы не думали разместить репозиторий проекта на GitHub?
P.
18 мая 2019 г. 14:03
PELMYACH .

Спасибо большое! Вскоре буду разбираться!
18 мая 2019 г. 9:13
Евгений Легоцкой

Добрый день! Отнимать значение общего счётчика можно в деструкторе класса кнопки QDynamicButton::~QDynamicButton(){ ResID--;} При этом я бы ещё переустанавливал значения вс...
P.
14 мая 2019 г. 22:33
PELMYACH .

Здравствуйте!А не подскажите, как можно при удалении какой либо кнопки, у щётчика отнять значение?Дабы например четвёртой кнопке соответствовал ID 4, а не 5 скажем
Сейчас обсуждают на форуме
24 мая 2019 г. 6:48
Евгений Легоцкой

Если там будут только перечисления внутри namespace, то жа, достаточно будет заголовочного файла
24 мая 2019 г. 6:28
Андрей Янкович

работает любой http сервер, и можно использовать обсалютно любой портпример <RemoteRepositories> <Repository> <Url>http://178.124.160.6:3030/A/B&l...;
23 мая 2019 г. 14:40
Михаиллл

Попробовал сделать этот запрос по http и получил json файл. request.setUrl(QUrl("https://jsonplaceholder.typicode.com/todos/1")); Как Вы думаете, почему https не работает и как это и...
23 мая 2019 г. 10:42
Михаиллл

Спасибо, помогло.
23 мая 2019 г. 6:31
Евгений Легоцкой

Для задач и граф-то не нужен. Достаточно будет таблицы в локальной базе данных SQLite, в которой указывается задача, время и т.д. В этом разделе есть примеры по работа с базой д...

Для зарегистрированных пользователей на сайте присутствует минимальное количество рекламы

EVILEG
О нас
Услуги
Присоединяйтесь к нам
© EVILEG 2015-2019
Рекомендует хостинг TIMEWEB