Скачать MetaTrader 5

Объём файлов истории

Авторизуйтесь или зарегистрируйтесь, чтобы добавить комментарий
Интересует активность в Маркете? Заходи и отслеживай!
Alexey Navoykov
3988
Alexey Navoykov 2014.10.01 07:12 

Давно напрягает тот факт, что МТ жрёт неоправданно много места на диске под хранение истории.  В случае с МТ4 это ещё можно понять. Но вот с МТ5, в котором якобы что-то оптимизировано, это очень странно. Везде говорится о том, что история хранится в .hcc файле в "запакованном" виде.  Однако толку от такой запаковки почти нет.

Рассмотрим простейший пример. Есть символ EURUSD c 4-значными котировками, реальные объёмы отсутствуют (везде нули).  Файл .hcc с годовой минутной историей по нему занимает в среднем 14 МБ.  А теперь считаем на пальцах:

- цены OHLC:   разделив на известный размер тика, получаем целые значения вида 13000-14000,  для хранения которых хватает двух байт, причём с запасом.  Итого:  8 байт.

- время:   4 байта

- тиковый объём:   в 99.9% случаев - это 1 байт (для минуток), но возьмём с запасом:  2 байта

- реальный объём:   0 байт

- спред:  1 байт.

Итого получаем:  (8+4+2+1) * 1440 * 260 = 5 616 000 байт.      Это в 2.5 раза меньше того, что получается у разработчиков.

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

Таким образом, более 80% используемого дискового пространства расходуется впустую.  С этим надо что-то делать.

Если бы речь шла о сотне мегабайт, то я бы не поднимал эту тему.  Но речь идёт о гигабайтах.  У меня уже скоро перевалит за 10, и это совершенно не устраивает.  Я не для того покупаю дорогие SSD-диски, чтобы так нерационально использовать их объём.

Alexey Busygin
6437
Alexey Busygin 2014.10.01 10:15  
meat:

Давно напрягает тот факт, что МТ жрёт неоправданно много места на диске под хранение истории.  В случае с МТ4 это ещё можно понять. Но вот с МТ5, в котором якобы что-то оптимизировано, это очень странно. Везде говорится о том, что история хранится в .hcc файле в "запакованном" виде.  Однако толку от такой запаковки почти нет.

Рассмотрим простейший пример. Есть символ EURUSD c 4-значными котировками, реальные объёмы отсутствуют (везде нули).  Файл .hcc с годовой минутной историей по нему занимает в среднем 14 МБ.  А теперь считаем на пальцах:

- цены OHLC:   разделив на известный размер тика, получаем целые значения вида 13000-14000,  для хранения которых хватает двух байт, причём с запасом.  Итого:  8 байт.

- время:   4 байта

- тиковый объём:   в 99.9% случаев - это 1 байт (для минуток), но возьмём с запасом:  2 байта

- реальный объём:   0 байт

- спред:  1 байт.

Итого получаем:  (8+4+2+1) * 1440 * 260 = 5 616 000 байт.      Это в 2.5 раза меньше того, что получается у разработчиков.

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

Таким образом, более 80% используемого дискового пространства расходуется впустую.  С этим надо что-то делать.

Если бы речь шла о сотне мегабайт, то я бы не поднимал эту тему.  Но речь идёт о гигабайтах.  У меня уже скоро перевалит за 10, и это совершенно не устраивает.  Я не для того покупаю дорогие SSD-диски, чтобы так нерационально использовать их объём.

Да, да! У меня тоже была такая ситуация, долго не мог понять от чего переполняется диск, удалял все что можно, теневые копии, программы, пока не нашел 2ва файла в терминале, один на 40 ГБ другой на 36ГБ.
MetaQuotes
Админ
24947
Renat Fatkhullin 2014.10.01 10:36  
meat:

Давно напрягает тот факт, что МТ жрёт неоправданно много места на диске под хранение истории.  В случае с МТ4 это ещё можно понять. Но вот с МТ5, в котором якобы что-то оптимизировано, это очень странно. Везде говорится о том, что история хранится в .hcc файле в "запакованном" виде.  Однако толку от такой запаковки почти нет.

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

При передаче по сети ради экономии трафика мы используем экстремально эффективную упаковку, вплоть до битов. А вот на диске нам нужна полностью распакованная и доступная для мгновенного обращения история чартов. Потому что на стороне клиента приоритет за скоростью доступа, а не за минимизацией места. Распакованные кеши периодов лежат в подкаталоге /Cache у каждого символа.

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

Alexey Navoykov
3988
Alexey Navoykov 2014.10.01 12:06  
Renat:
 

Потому что на стороне клиента приоритет за скоростью доступа, а не за минимизацией места. Распакованные кеши периодов лежат в подкаталоге /Cache у каждого символа.

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

Странно слышать от вас такое. Любой знает, что самое медленное звено системы  - это дисковые операции, особеннно если стоит обычный медленный HDD.  Время затраченное на загрузку с диска будет несоизмеримо выше, чем затраты на распаковку тех же данных на лету.  Речь не шла о каких-то сложных алгоритмах кодирования. Я показал, что достаточно даже самых элементарных действий, чтобы получить экономию места как минимум в 2.5 раза. А если по-нормальному, то в 5-6 раз.  И никаких задержек это не вызовет. Я сам давно храню свои архивы истории (не МТ) в упакованном виде (кодируются приращения котировок), и всё нормально, задержек нет.  Повторюсь, не нужны всякие экстремальные битовые упаковки, достаточно простых.

На чём основано ваше утверждение о том, что "на стороне клиента приоритет за скоростью доступа, а не за минимизацией места"?  Вы проводили какие-либо исследования, опросы?

Вот я клиент, и заявляю вам обратное.  Если не верите, можете сделать опрос на форуме, что людям важнее: экономия нескольких гигабайт места на диске, или экономия нескольких миллисекунд при обращении к файлу истории (которое происходит лишь изредка).  Складывается ощущение, что вы безнадёжно оторваны от трейдерских реалий.  У многих терминалы стоят на VPS, где объём жёсткого диска существенно ограничен.  А ваши миллисекунды никому погоды не сделают.  Тем более что эти миллисекунды вообще спорные.  На обычном HDD так наоборот будет проигрыш во времени по сравнению с распаковкой.

Alexandr Bryzgalov
27509
Alexandr Bryzgalov 2014.10.01 12:14  
meat:

), миллисекунды важнее конечно
Stanislav Korotky
17910
Stanislav Korotky 2014.10.01 12:25  
sanyooooook:
), миллисекунды важнее конечно

Ага, а когда каждый терминал жрет несколько гигов и установлен не один экземпляр терминала, то потом вдруг начинает заканчиваться место на диске и речь о секундах уже вообще не идет - все накрывается медным тазом. ;-)

При нормальном подходе к проектированию терминала можно было бы добавить опцию для определения приоритетов конкретного пользователя - оптимизация по месту или по скорости.

Меня вот с самого начала знакомства с МТ (уже много лет прошло) поразило то, что я не могу указать, с какого года мне нужна история. Я например никогда больше 1 года назад не анализирую. Нафик мне эти лишние гиги?

MetaQuotes
Админ
24947
Renat Fatkhullin 2014.10.01 12:56  

По шагам:

  1. На разнородных (оцените размах даблов) данных с разной глубиной точности(не думайте про фиксированный форекс) простейшая упаковка не сработает. Вылезает навороченная побитовая вариабельная, что требует немало ресурсов как на сжатие, так и на чтение. Плюс расход памяти выше
  2. У нас есть очень эффективное сжатие побитовое, но его использовать в обычной работе с историей противопоказано. Особенно затратно пережимать при сбросе файлов на диск.
  3. Так как простейшее сжатие даст в лучшем случае в 2 раза экономию, то это не перевесит ни выигрыш от уменьшения чтения диска, ни потери от расжатия, ни потери памяти. Память терять по любому придется, так как читать нужно максимально большими кусками для получения максимальной скорости линейного чтения и лишь потом разворачивать в целевой буфер. А в нашем случае это делать не надо - читаем на максимальной скорости большими кусками сразу в целевой буфер.
  4. Простота форматов и прямой доступ выгоднее навороченных сложностей
  5. Никаких гигантских расходов диска нет. Сказки про десятки гигабайт оказываются обычно логами экспертов, которые запускаются незадачливыми трейдерами, не имеющими понятия о наличии оных.
  6. Если же речь идет о VPS, то просто не надо жадничать и покупать 5-10 долларовые тарифы, а потом пытаться впихнуть туда массу терминалов.
Требования Метатрейдера к железу очень низки и вести речь про его тормоза или ресурсоемкость вообще смешно. Ну а если идет речь об VPS и максимизации количества установок, то это вопрос не к нам, а к самому трейдеру.
Nikolay Demko
12465
Nikolay Demko 2014.10.01 13:23  
Renat:

По шагам:

  1. На разнородных (оцените размах даблов) данных с разной глубиной точности(не думайте про фиксированный форекс) простейшая упаковка не сработает. Вылезает навороченная побитовая вариабельная, что требует немало ресурсов как на сжатие, так и на чтение. Плюс расход памяти выше
  2. У нас есть очень эффективное сжатие побитовое, но его использовать в обычной работе с историей противопоказано. Особенно затратно пережимать при сбросе файлов на диск.
  3. Так как простейшее сжатие даст в лучшем случае в 2 раза экономию, то это не перевесит ни выигрыш от уменьшения чтения диска, ни потери от расжатия, ни потери памяти. Память терять по любому придется, так как читать нужно максимально большими кусками для получения максимальной скорости линейного чтения и лишь потом разворачивать в целевой буфер. А в нашем случае это делать не надо - читаем на максимальной скорости большими кусками сразу в целевой буфер.
  4. Простота форматов и прямой доступ выгоднее навороченных сложностей
  5. Никаких гигантских расходов диска нет. Сказки про десятки гигабайт оказываются обычно логами экспертов, которые запускаются незадачливыми трейдерами, не имеющими понятия о наличии оных.
  6. Если же речь идет о VPS, то просто не надо жадничать и покупать 5-10 долларовые тарифы, а потом пытаться впихнуть туда массу терминалов.
Требования Метатрейдера к железу очень низки и вести речь про его тормоза или ресурсоемкость вообще смешно. Ну а если идет речь об VPS и максимизации количества установок, то это вопрос не к нам, а к самому трейдеру.

И как же удовлетворить всем запросам пользователей не используя ключевое слово "сборка", а?

Сборка для ручной торговли с усиленной графикой.

Сборка лайт-терминала для ВПС.

Сборка программерская для удобной отладки на выбранном историческом участке тиковых данных.

Сборка для быстрой оптимизации. 

Сборка ... сборка ...

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

ЗЫ вот кстати движение в эту сторону с вашей стороны https://www.mql5.com/ru/articles/994 , но это полумеры, вы сами сделали лайт-сборку, а нужна возможность пользовательской сборки, те нужно менять философию.

Подготовка торгового счета к миграции на виртуальный хостинг
Подготовка торгового счета к миграции на виртуальный хостинг
  • 2014.10.01
  • MetaQuotes Software Corp.
  • www.mql5.com
Клиентский терминал MetaTrader идеально подходит для автоматизации торговых стратегий. Для разработчиков торговых роботов в нем есть всё ‒ мощный язык программирования MQL4/MQL5 на основе C++, удобная среда разработки MetaEditor, многопоточный тестер стратегий с поддержкой распределенных вычислений в MQL5 Cloud Network. В этой статье вы узнаете, как перенести свой клиентский терминал со всеми разработками в виртуальную среду.
Alexandr Bryzgalov
27509
Alexandr Bryzgalov 2014.10.01 13:34  
marketeer:

Меня вот с самого начала знакомства с МТ (уже много лет прошло) поразило то, что я не могу указать, с какого года мне нужна история. Я например никогда больше 1 года назад не анализирую. Нафик мне эти лишние гиги?

а это не подходит:


Stanislav Korotky
17910
Stanislav Korotky 2014.10.01 13:35  
sanyooooook:

а это не подходит:


Нет. На диск терминал грузит все равно всю историю.
Alexey Navoykov
3988
Alexey Navoykov 2014.10.01 13:39  
Renat:

По шагам:

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

Глубина точности тут не имеет значения.  Речь ведь идёт о биржевых котировках, а не просто о числах. Все котировки имеют фиксированный размер шага (тика). Хоть форекс, хоть биржа, везде правила одинаковые.  Соответственно все ценовые изменения можно выразить целым числом, равных количеству тиков.  А потом уже домножить на размер тика.

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

Отличить .hcc от .log мы уж как-нибудь умеем.  Ничего фантастического в таком объёме нет:  открыто несколько терминалов, в каждом по 20 символов с 15-летней историей.  Итого на каждый терминал приходится около 4 Gb. Посчитайте сами, если не верите.  Да и необязательно несколько терминалов.  Может быть история от нескольких брокеров в одном терминале.

А по поводу "не надо жадничать" - это вообще какой-то нелепый аргумент.  Таким макаром можно оправдывать любое неэффективное решение:   "программа тормозит? а не надо было жадничать на топовый проц" и т.д.

123456
Авторизуйтесь или зарегистрируйтесь, чтобы добавить комментарий