Объём файлов истории
Давно напрягает тот факт, что МТ жрёт неоправданно много места на диске под хранение истории. В случае с МТ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-диски, чтобы так нерационально использовать их объём.
Давно напрягает тот факт, что МТ жрёт неоправданно много места на диске под хранение истории. В случае с МТ4 это ещё можно понять. Но вот с МТ5, в котором якобы что-то оптимизировано, это очень странно. Везде говорится о том, что история хранится в .hcc файле в "запакованном" виде. Однако толку от такой запаковки почти нет.
Вы путаете запаковку при передаче по сети и распакованный результат хранения на локальном диске.
При передаче по сети ради экономии трафика мы используем экстремально эффективную упаковку, вплоть до битов. А вот на диске нам нужна полностью распакованная и доступная для мгновенного обращения история чартов. Потому что на стороне клиента приоритет за скоростью доступа, а не за минимизацией места. Распакованные кеши периодов лежат в подкаталоге /Cache у каждого символа.
Странно жаловаться на объем исторической базы, когда вы работаете с машинкой по перемалыванию и визуализации исторических данных.
Потому что на стороне клиента приоритет за скоростью доступа, а не за минимизацией места. Распакованные кеши периодов лежат в подкаталоге /Cache у каждого символа.
Странно жаловаться на объем исторической базы, когда вы работаете с машинкой по перемалыванию и визуализации исторических данных.
Странно слышать от вас такое. Любой знает, что самое медленное звено системы - это дисковые операции, особеннно если стоит обычный медленный HDD. Время затраченное на загрузку с диска будет несоизмеримо выше, чем затраты на распаковку тех же данных на лету. Речь не шла о каких-то сложных алгоритмах кодирования. Я показал, что достаточно даже самых элементарных действий, чтобы получить экономию места как минимум в 2.5 раза. А если по-нормальному, то в 5-6 раз. И никаких задержек это не вызовет. Я сам давно храню свои архивы истории (не МТ) в упакованном виде (кодируются приращения котировок), и всё нормально, задержек нет. Повторюсь, не нужны всякие экстремальные битовые упаковки, достаточно простых.
На чём основано ваше утверждение о том, что "на стороне клиента приоритет за скоростью доступа, а не за минимизацией места"? Вы проводили какие-либо исследования, опросы?
Вот я клиент, и заявляю вам обратное. Если не верите, можете сделать опрос на форуме, что людям важнее: экономия нескольких гигабайт места на диске, или экономия нескольких миллисекунд при обращении к файлу истории (которое происходит лишь изредка). Складывается ощущение, что вы безнадёжно оторваны от трейдерских реалий. У многих терминалы стоят на VPS, где объём жёсткого диска существенно ограничен. А ваши миллисекунды никому погоды не сделают. Тем более что эти миллисекунды вообще спорные. На обычном HDD так наоборот будет проигрыш во времени по сравнению с распаковкой.
), миллисекунды важнее конечно
Ага, а когда каждый терминал жрет несколько гигов и установлен не один экземпляр терминала, то потом вдруг начинает заканчиваться место на диске и речь о секундах уже вообще не идет - все накрывается медным тазом. ;-)
При нормальном подходе к проектированию терминала можно было бы добавить опцию для определения приоритетов конкретного пользователя - оптимизация по месту или по скорости.
Меня вот с самого начала знакомства с МТ (уже много лет прошло) поразило то, что я не могу указать, с какого года мне нужна история. Я например никогда больше 1 года назад не анализирую. Нафик мне эти лишние гиги?
По шагам:
- На разнородных (оцените размах даблов) данных с разной глубиной точности(не думайте про фиксированный форекс) простейшая упаковка не сработает. Вылезает навороченная побитовая вариабельная, что требует немало ресурсов как на сжатие, так и на чтение. Плюс расход памяти выше
- У нас есть очень эффективное сжатие побитовое, но его использовать в обычной работе с историей противопоказано. Особенно затратно пережимать при сбросе файлов на диск.
- Так как простейшее сжатие даст в лучшем случае в 2 раза экономию, то это не перевесит ни выигрыш от уменьшения чтения диска, ни потери от расжатия, ни потери памяти. Память терять по любому придется, так как читать нужно максимально большими кусками для получения максимальной скорости линейного чтения и лишь потом разворачивать в целевой буфер. А в нашем случае это делать не надо - читаем на максимальной скорости большими кусками сразу в целевой буфер.
- Простота форматов и прямой доступ выгоднее навороченных сложностей
- Никаких гигантских расходов диска нет. Сказки про десятки гигабайт оказываются обычно логами экспертов, которые запускаются незадачливыми трейдерами, не имеющими понятия о наличии оных.
- Если же речь идет о VPS, то просто не надо жадничать и покупать 5-10 долларовые тарифы, а потом пытаться впихнуть туда массу терминалов.
По шагам:
- На разнородных (оцените размах даблов) данных с разной глубиной точности(не думайте про фиксированный форекс) простейшая упаковка не сработает. Вылезает навороченная побитовая вариабельная, что требует немало ресурсов как на сжатие, так и на чтение. Плюс расход памяти выше
- У нас есть очень эффективное сжатие побитовое, но его использовать в обычной работе с историей противопоказано. Особенно затратно пережимать при сбросе файлов на диск.
- Так как простейшее сжатие даст в лучшем случае в 2 раза экономию, то это не перевесит ни выигрыш от уменьшения чтения диска, ни потери от расжатия, ни потери памяти. Память терять по любому придется, так как читать нужно максимально большими кусками для получения максимальной скорости линейного чтения и лишь потом разворачивать в целевой буфер. А в нашем случае это делать не надо - читаем на максимальной скорости большими кусками сразу в целевой буфер.
- Простота форматов и прямой доступ выгоднее навороченных сложностей
- Никаких гигантских расходов диска нет. Сказки про десятки гигабайт оказываются обычно логами экспертов, которые запускаются незадачливыми трейдерами, не имеющими понятия о наличии оных.
- Если же речь идет о VPS, то просто не надо жадничать и покупать 5-10 долларовые тарифы, а потом пытаться впихнуть туда массу терминалов.
И как же удовлетворить всем запросам пользователей не используя ключевое слово "сборка", а?
Сборка для ручной торговли с усиленной графикой.
Сборка лайт-терминала для ВПС.
Сборка программерская для удобной отладки на выбранном историческом участке тиковых данных.
Сборка для быстрой оптимизации.
Сборка ... сборка ...
Популярность той или иной сборки покажет MQ куда прикладывать наибольшие усилия, чего допиливать в первую очередь.
ЗЫ вот кстати движение в эту сторону с вашей стороны https://www.mql5.com/ru/articles/994 , но это полумеры, вы сами сделали лайт-сборку, а нужна возможность пользовательской сборки, те нужно менять философию.
- 2014.10.01
- MetaQuotes Software Corp.
- www.mql5.com
Меня вот с самого начала знакомства с МТ (уже много лет прошло) поразило то, что я не могу указать, с какого года мне нужна история. Я например никогда больше 1 года назад не анализирую. Нафик мне эти лишние гиги?
а это не подходит:
а это не подходит:
По шагам:
- На разнородных (оцените размах даблов) данных с разной глубиной точности(не думайте про фиксированный форекс) простейшая упаковка не сработает. Вылезает навороченная побитовая вариабельная, что требует немало ресурсов как на сжатие, так и на чтение. Плюс расход памяти выше
Глубина точности тут не имеет значения. Речь ведь идёт о биржевых котировках, а не просто о числах. Все котировки имеют фиксированный размер шага (тика). Хоть форекс, хоть биржа, везде правила одинаковые. Соответственно все ценовые изменения можно выразить целым числом, равных количеству тиков. А потом уже домножить на размер тика.
Никаких гигантских расходов диска нет. Сказки про десятки гигабайт оказываются обычно логами экспертов, которые запускаются незадачливыми трейдерами, не имеющими понятия о наличии оных
Отличить .hcc от .log мы уж как-нибудь умеем. Ничего фантастического в таком объёме нет: открыто несколько терминалов, в каждом по 20 символов с 15-летней историей. Итого на каждый терминал приходится около 4 Gb. Посчитайте сами, если не верите. Да и необязательно несколько терминалов. Может быть история от нескольких брокеров в одном терминале.
А по поводу "не надо жадничать" - это вообще какой-то нелепый аргумент. Таким макаром можно оправдывать любое неэффективное решение: "программа тормозит? а не надо было жадничать на топовый проц" и т.д.
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Вы принимаете политику сайта и условия использования
Давно напрягает тот факт, что МТ жрёт неоправданно много места на диске под хранение истории. В случае с МТ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-диски, чтобы так нерационально использовать их объём.