Обсуждение статьи "Персистентное хранилище "ключ — значение" в MQL5: Плоские файлы как легковесная база данных для хранения состояния советника"

Опубликована статья Персистентное хранилище "ключ — значение" в MQL5: Плоские файлы как легковесная база данных для хранения состояния советника:

Благодаря облегченной архитектуре системы сохранения данных торговые советники (EA) могут сохранять счетчики, флаги и временные метки между перезапусками терминала. Используя только средства MQL5, CPersistentStore записывает удобочитаемый файл формата key=value в папку MQL5/Files и обслуживает запросы на чтение из кэша со сквозной записью на основе CHashMap через типизированный API. В статье анализируются операции со сложностью O(1) и O(n), риски неполной записи и отсутствие блокировки файлов, проводится сравнение с глобальными переменными терминала (GlobalVariables) и SQLite, а также приводится демонстрационный пример с детерминированной повторной загрузкой состояния.

Торговые советники (EA) MetaTrader 5 работают в среде выполнения, полностью управляемой торговым терминалом. При закрытии терминала очищается всё временное состояние программы, существующее во время её работы, включая счётчики, флаги и временные метки сеанса. При инициализации советник возвращается к состоянию по умолчанию, заданному при компиляции. Такое поведение является стандартной особенностью управляемых сред выполнения, а не недостатком среды выполнения MQL5. Архитектурные уязвимости возникают, если советник хранит рабочее состояние только в глобальных переменных программы и не располагает независимым механизмом сохранения данных для восстановления этого состояния после завершения работы.

В условиях реальной эксплуатации отсутствие структурированного слоя сохранения данных обычно сказывается на нескольких критически важных аспектах работы:

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

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

Вместо использования SQLite, глобальных переменных терминала или внешних механизмов хранения данных в этой статье разрабатывается легковесный слой сохранения данных, полностью реализованный штатными средствами MQL5. Это решение сочетает понятный текстовый формат плоского файла с типизированным API, кэшем в оперативной памяти и модульной архитектурой хранения данных, которая обеспечивает сохранение состояния советника между перезапусками терминала. Его легко анализировать, расширять и интегрировать в существующие проекты.


Автор: Ushana Kevin Iorkumbul