Суровая оптимизация работы с market data для криптобиржи



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

1. REST-интерфес;
2. WEBSocket broadcast subscription.

Метод REST зачастую используется для получения исторических данных, в то время, как по WEBSocket рассылается актуальная информация в режиме online. В некоторых случаях WEBSocket вообще не используется, а обновление происходит регулярными запросами через REST.

И вроде все довольны. Но, при более детальном рассмотрении, становится очевидными огромные накладные расходы на такую концепцию. Их основная масса ложится на REST. Для обеспечения функционирования REST-интерфейса мы должны создать backend отвечающий требованиям высоконагруженных систем. Естественно, тут можно выбирать различные варианты решения от PHP до нынче модного Golang.

Также требуется создать высокодоступную инфраструктуру, реализовать такие мелочи как CI/CD для сервисов, обеспечить все это нужными спецами по разработке, сопровождению, и т.д., и т.п.

При этом, именно историческая маркет-дата занимает основной объем дискового пространства. Хранится она обычно в БД. Это с одной стороны, позволяет решить вопрос кластеризации, но при критических размерах, становится невыносимой тяжестью и ставит перед командой DevOps и разработчиков нетривиальные задачи.

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

Отдельно нужно заметить особенность маркет-даты. Она всегда накапливается (прирастает). Т.е. говоря языком программиста БД мы всегда инсертим и потом селектим. Но не делитим. Т.е. замечательная функциональность БД по систематизации, оптимизации и т.п. хранимых данных становится маловостребованной.

Еще одним важным свойством маркет-даты является ее четко определенная структура. Например свеча в графике имеет всего восемь параметров:

1. Момент времени;
2. Экспозиция;
3. Максимальная цена;
4. Минимальная цена;
5. Цена открытия;
6. Цена закрытия;
7. Объем;
8. Средняя цена.

Тоже можно сказать о сделках.

Опираясь на эти предпосылки, а также вооружившись опытом, я достаточно быстро пришел к выводу, что правильнее рассматривать маркет-дату как структурированный поток.

Например, поток со свечами, можно рассмотреть как массив бинарных структур:

moment: int32
exposition: int32
min: float64
max: float64
open: float64
close: float64
volume: float64
average: float64


Итого: 56 байт.

Для примера, такая свеча в JSON будет описана так:

{
"date":1501004700, 
"high":0.08053391,
"low":0.08020004,
"open":0.08030001,
"close":0.0803542,
"volume":48.62169347,
"weightedAverage":0.08038445
}

Итого: 167 байт.

Профит по размеру очевиден. А это меньше трафик, выше скорость доставки до клиента.

И тут, конечно, приходит на ум BSON. Но он не решает проблемы необходимости наличия backend и в общем-то не решает проблему в корне. К тому же, он не поддерживается браузерами нативно.

Я посмотрел в иную сторону. В сети есть масса ресурсов работающих с потоками. Это аудио и видео ресурсы. Они демонстрируют все те признаки, которые необходимы:

  1. работают с большими объемами данных;
  2. прекрасно справляются с высокой нагрузкой;
  3. способны в online поставлять контент, но при этом, дают возможность обращаться к историческим данным.

Я слегка углубился в потоковое видео, что позволило кардинально решить все вышеозначенные проблемы по маркет-дате. Вся магия, как выяснилось, скрывается в технологии Content-Range которая из коробки поддерживается, например, Nginx. Она позволяет обращаться к любой области статического ресурса (файлу на сервере) не используя backend. В целом, это происходит так: вы обращаетесь к URL указывая в заголовке экспозицию, которую хотите вернуть. Например: range: 100-200. Не буду останавливаться на тонкостях, все нюансы технологии вы можете найти в профильных статьях. Суть думаю понятна.

Фактически, теперь, на стороне фронта можно организовать обращение к необходимому участку файла, например, содержащего свечи. А так как, точно известно сколько байт занимает одна свеча (56 байт), мы легко можем определить нужное нам смещение. Правда, мы еще должны знать момент времени, с которого график начинается. И это весьма легко решается добавлением к файлу заголовка, размер которого также является константой.

Т.е. первым делом, фронт обращается к файлу с нулевой позиции, и получает
заголовок. Одновременно с этим nginx отдаст размер файла. Это позволит определить общее количество свечей в файле и момент начала отсчета.

Теперь, зная начальную точку времени, имея четкое представление о количестве свечей, мы можем получить любое их количество за любой промежуток времени из фронта, не используя backend.

Ах, да… еще момент… у нас есть такой параметр как экспозиция свечи. Тут решение тоже простое — мы держим сразу несколько файлов для разных экспозиций. Как дополнительный мелкий бонус, сокращается размер структуры свечи еще на 4 байта.

В целом, решение уже было достаточно интересным для реализации, но выяснились еще, не постесняюсь сказать — очень крутые профиты. Дело в том, что браузеры умеют кэшировать данные полученные методом range. Т.е. при очередном запросе фронта к серверу, если этот участок файла был получен браузером ранее, он не полезет к вам на сервер, а возьмет его из кэша.

Но даже это не все. Используя CDN, кеширование может быть настроено еще и его средствами. Т.е. по итогу, можно получить систему, которая в состояние отдавать большие объемы маркет-даты минимально нагружая инфраструктуру и сервера.

Нужно ли говорить, что сомнений в верности идеи уже не было? Теперь остались сущие мелочи… нужно сделать генерацию этих самых файлов.

Как уже было сказано выше, обычно, биржа эксплуатирует два средства доставки маркет-даты: REST и WEBSocket. Последний транслирует online актуальную маркет-дату. Обычно это отдельный сервис. Как показала практика, доработка этого сервиса для того, чтобы он дописывал данные в необходимые файлы не представляет труда и решается буквально парой часов работы разработчика. Можно сказать, что он одновременно с рассылкой ведет лог.

Вопрос доставки файлов на ноды — классическая проблема синхронизации файловой системы. Команда DevOps решает ее легко и непринужденно. Например используя rsync.

Вот теперь, можно смело сказать — БИНГО!

Возможно, возникнет вопрос — а почему все крипто-биржи делают иначе? На этот вопрос у меня нет достоверного ответа. Но есть мысли:

  1. биржи создавались сочувствующим крипте девелоперами. Возможно, они не имели представления о работе классических бирж, не учитывали их опыт и пользовались легкодоступными решениями, чтобы получить быстрый результат. А это, шаблонные решения: тот самый REST и сопутствующий JSON;
  2. как говорят в народе — Работает? Не трогай. — Т.к. ключевыми биржами уже были созданы технологические тренды, вновь возникающие биржи заимствовали их.

Если тема окажется интересной сообществу, продолжу статьями о других нестандартных решениях внедренных на нашем проекте. Как это работает на практике, можно посмотреть на сайте биржи (см. мой профиль). Особо предлагаю обратить внимание на работу графика, который наглядно демонстрирует все профиты данной технологии.
Ads
AdBlock has stolen the banner, but banners are not teeth — they will be back

More

Comments 96

    +1
    В классическом случае маркет-дата распространяется

    Через udp multicast :)

      0
      Речь идет о специфике приптобирж. А они используют фронт реализованный на браузерах. Что не подразумевает использование низкоуровневых сетевых протоколов. Поэтому, все же WEBSocket;)
        0

        Кто же спорит. Просто со стороны забавно выглядит, когда потом народ пишет про hft и lowlatency в этом контексте.


        Второй момент — ваше "стало лучше" выглядит странно без замеров. Точно стало то? Что стало лучше? Latency? Throughput? Насколько? Для какого процента запросов? Как замеряли?


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

          0
          В целом я с Вами согласен, что сухие цифры это очень здорово как сравнительный анализ. Но все же, в данном случае в этом нет необходимости просто потому, что это слишком очевидно. Это как сравнивать черепаху с зайцем и приводить статистику в скорости бега. Отказ от бэкенда это отказ от тонкого места априори. Отказ от лишних финансовых затрат. А включение в цепочку реквеста/респонса CDN с кешированием делает этот алгоритм, ну… в какой-то степени просто неубиваемым по производительности, фактически ограничивая производительность ресурсами CDN. И это при учете того, что браузер не будет сам кешировать. А он будет… В общем, просто не хочется на это тратить время. Лучше я его направлю на следующие статьи, где если это будет необходимо обязательно снабжу статистикой, когда будут сравниваются сравнимые вещи.
            0

            Слишком очевидно, это слишком общие слова. Которые, на деле ещё могут оказаться и неправдой. Ладно нам то, но вдруг вы себе врёте?

              0
              Я с уважением отношусь к Вашим сомнениям, но при этом, сам уверен в своей правоте. При желании, Вы можете самостоятельно перепроверить мои выводы и дать оценку. Я гарантирую, что в таком случае, включу ее в статью как внешний, значимый, статистический анализ. Если возникнет почва для дискуссии ее можно будет продолжить.
                +1

                Оптимизация суровая. Что-то, наверное, оптимизировалось. Так и запишем.

                  +1

                  Резковато получилось, но это для гиперболы. Для сравнения:
                  Мы увеличили время отклика на 1000% и сейчас я расскажу вам как.


                  Звучит гораздо весомее как для клиентов, так и для конкурентов. Про разработчиков, которые обязательно нагуглят эту статью, когда вы захотите нанять людей и говорить нечего.

                    0
                    Ok. Я учту. Это не посыл в долгий ящик :) Честно. Учту, постараюсь найти ресурсы для анализа.
              0

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

                0
                Криптобиржи и классически биржи не поддаются сравнению. Классическая биржа не транслирует историческую маркет-дату трейдерам. Этим занимаются брокеры. Которые, имеют сервера рядом с самой биржей и реализуют собственную инфраструктуру по хранению и доставке маркет-даты их клиентам. И именно брокеры, т.е. квалифицированные участники рынка, относятся к тем, кто имеет право на равноправие (смешно звучит :)). Клиенты брокера же, это забота брокера. Как и когда он предоставит доступ своему клиенту к исторической маркет-дате, также его проблемы. Криптобиржа, в противовес, является совокупностью устройств и механизмов, необходимых и достаточных как для принятия инвестиционного решения, так и для его исполнения. Доступ трейдера к биржам, осуществляется не через шлюзы, а через API. Ну конечно плюс/минус. В общем это другая физика и философия.
                  0

                  Т.е. задумка в том, что бы выпилить брокеров и hftшников? В принципе, звучит интересно, кому они нужны лишние посредники то.


                  Но вопрос о равенстве участников торгов по идее всё равно остаётся.

                    0
                    Я бы на сказал, что это задумка. Иак исторически сложилось. Была крипта и была идея как-то ей обмениваться. Назвали биржей, а сделали по своему. Я сейчас в принципе о криптобиржи как понятии. Над ней не стоят регуляторы, а следовательно любая биржа может реализовывать любую понравившуюся ей стратегию и механику. Поэтому, вопрос равенства, я бы сказал, невозможно проверить. Но… что касается актуальной маркет-даты, вы можете ее получать по WebSocket. И это происходит одновременно для всех. Т.е. тут полное равенство. И по сути, именно она нужна для принятия решений, скажем ботами. Историческая нужна для технического анализа. И если даже обновление кеша задержит на минуту… это не критично для анализа и определения тренда.
                      0

                      Про равенство тут можно спорить долго, но при количестве клиентов n, где n * ${время посылки данных} >= ${время посылки пакета по websocket} уже не подходит простая очередь, если говорить о равенстве строго.


                      Вполне допускаю, пока никто из мэйнстрима этим не озаботился, трейдеры будут кушать что дают.


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


                      Ещё маленькое замечание — у вас много ошибок в склонении существительных например:


                      о криптобиржи

                      По идее — спелчекер должен это решить.

                        0
                        Я очень надеюсь, что Вы правы. Я сам с большой надеждой смотрю на развитие технологий в криптотрейдинге. На сегодня он никак не дотягивает до классических бирж. Это, в целом, «детские поделки» в сравнении с ними. Но с другой стороны, таковыми, сегодня они являются потому, что нет иных потребностей.
                        Спасибо за замечания по синтаксису. В будущем постараюсь привлекать редактора. Сказываются не совсем русские корни ;)
                        0
                        Извините за опечатки. С телефона комментировал.
          +2
          Какая же жесть. Мы не будет использовать БД. Просто создадим файлики. А как у вас работает когда нужно достать график за год? Качаете все точки графики даже если они каждую минуту?

          Посмотрите в сторону хороших решений для графиков. time series db — clickhouse|influxdb и много подобного. Работают быстро. Отлично шардятся.
            0
            Достать график за год не представляется проблемным. Совсем.
              0
              56 байт на точку. Одна точка на минуту же? 1440 точек за сутки. 525600 точек за год. У вас есть реализация где это можно увидеть без тормозов?
              29Мб данных для одного графика за год? А если нужно сравнение 2-4 графиков на одном канвасе?
                0
                Не точка, а свеча Реализация конечно есть, ссылка на нее дана в самой статье. Т.е. на сайте проекта (см мой профиль). График загружает как общее представление за весь период (снизу), так и отображает выбранную экспозицию (сверху).
                И напомню, что мы имеем дело со сравнением технологий. Задайте себе вопрос — сколько это будет «весить» в JSON?
                  0
                  При работе с tsdb вам не надо доставать ~500к свечей для графика за год. Можно достать свечи достаточной точности (за час/день/неделю) полученные агрегацией по времени из свечей за минуту. И такой JSON будет весить пару десятков килобайт.

                  Глянув код на сайте — вижу что вы создаете разные файлики для разных периодов свечей? т.е у вас заложен способ агрегации данных и при его изменении(добавлении или изменении чего-то) — только перегенерировать все свечи за 1h/4h/1d? Минимальная свеча у вас 15 минут?
                    0
                    Еще раз обращу внимение на то, что основная мысль заключается в возможности полностью избавиться от backend при запросах. Весь функционал перекладыватся на фронт. Это сокральная истина. Далее, идут важные и хорошие профиты. Но это профиты. Предложенный алгоритм позволяет выдерживать очень большую нагрузку в объеме запросов. Очень.
                    Что касается файлов — да, именно так. Это отражено в статье. А агрегация с иными экспозициями просто не требуется. Есть принятые экспозиции свечей. Если хочется получить RAW марет-дату, просто берите файл сделок. Он содержит все сделки за весь период. Функционирует на том же принципе.
                      0
                      Согласен. Использование принципа «отрезать все не нужно и сделать решение только под нашу стратегию использования», очень оправданно как оптимизация. Суровая оптимизация. Но это не очень удобно для развития сервиса.

                      Рассматривали решение с генерацией таких же ответов (charts/btc_eur/15m) на бекенде в апи и последующим кешированием в nginx? Заголовками передавать время жизни кеша (старые свечи за день можно кешировать на долгие месяцы). Период конечно придется задавать гет-параметром, но это не проблема для кеширования. По сути будут так же файлики с данными. Но создаются динамически и апи всегда из может создать из бд. Кеш nginx может хранить в memcache или просто на ram-диске.
                      Как бонус для ускорения разработки и тестирования можно установитьменьшее/нулевое время кеша.
                        0
                        Рассматривали решение с генерацией таких же ответов (charts/btc_eur/15m) на бекенде в апи и последующим кешированием в nginx?

                        Рассматривали. И отказались. Я уже дважды отметил то, что предложенный алгоритм не требует backend. Именно это и круто. Он экономит не только время, трафик, но и реальные деньги на специалистов, инфраструктуру. Не нужны memcache, базы данных и т.п. Все просто, практически весь стек поддерживается нативными средствами стандартной связки nginx + browser. Просто не нужно ничего изобретать и усложнять.
                          0
                          Ну хорошо. Ничего не будем усложнять.
                          Что будет если содержимое файлика как-то повредится? Практика работы с amazons3 говорит что такое возможно, при частом изменении файла. Вы ведь регулярно что-то дописываете в конец.
                          Каким образом и как быстро вы об этом узнаете? Может ли такой поврежденный файл попасть в бекап?
                            0
                            Я бы назвал это уже — дуть на холодную воду :))) Даже если он повредится, это совсем не критические данные. Они восстанавливаются из подсистемы учета биржи. Таковая в любом случае существует для внутренних нужд, расчета комиссий, позиций и т.п. Что касается самого инцидента, то он отслеживается комплексом мониторинга. А чтобы это не произошло, инфраструктура проектируется соответствующим образом. Если же все наши усилия окажутся тщетными и во всех локациях отрубится электричество… значит мы пересоздадим файлы.
              +1
              Это не жесть, это решение проблемы, когда у нас есть неизменяющиеся данные, которые нужно отдавать по частям.

              Ничего эффективнее статических файлов для неизменяющихся данных нет. Ничего эффективнее nginx для отдачи файликов нет, там один сервер может статику раздавать сотням тысяч клиентов.

              Зачем мучать базу данных, когда данные статические? Я знаю, есть люди, которые картинки в базе данных хранят, но ведь общество их порицает, не так ли? База данных нужна только чтобы какие-то хитрые выборки делать, а если у нас единственная выборка — временной диапазон, то почему бы Content-Range сюда не прикрутить?

              В итоге бекенд занимается более полезными делами, а все исторические данные клиентам раздаются практически бесплатно.

              В минусе только то, что неудобно пользоваться человекам, так ведь не для них же делается, а для скрипта на фронтенде.

              Удивляюсь, человек нашёл изящный хак, эффективно решающий конкретную задачу, позволяющий сэкономить кучу ресурсов, а его велосипедом стращают и готовые решения использовать посылают. Забыли люди, что программирование — это про эффективное решение задач, а не про «использование хороших решений».
                0
                Это не жесть, это решение проблемы, когда у нас есть неизменяющиеся данные, которые нужно отдавать по частям.

                иногда меняются, и вот конкретно этот момент мне не понятен, как доставить клиенту изменившиеся данные, пока не протух кеш
                  0
                  Как коллега с той же отрасли, отмечу, что — в таких системах есть еще парралельные каналы доставки данных и можно сигнализировать через них о перезагрузке. Кроме того, исторические данные и их изменение — крайне редкая и исключительная ситуация, в общем-то.
                    0
                    Кристально! Мы используем WEBSocket. Плюс пулим, если подсистема консистентности сигнализирует о рассинхронке.
                      0
                      Исключительная, от того и зафиксить надо как можно быстрее.

                      Альтернативные способы доставки это хорошо, но вот то, что один из каналов не является самодостаточным мне видится недостатком. Если такое скрыто за бекендом — норм, если если же клиенту для получения актуальных данных надо сначала слазить в два места по двум разным протоколам — странно с т.з архитектуры.
                      все имхо

                      ps
                      rpiontik, это используется только вашим клиентом или сторонними клиентами тоже?
                        0
                        Что «это»? несколько каналов? Это необходимость. Так устроена среднестатистическая, хорошая, криптобиржа. Криптобиржи попроще используют просто пулинг. В этом случае, как вы считаете правильным — канал один. Только интерактивности никакой.
                        Если вы про саму технологию раскрытую в статье, то я не знаю иных реализаций кроме нашей площадки. Проведенный ресерч на момент внедрения не выявил таких.
                0
                Профит по размеру очевиден. А это меньше трафик, выше скорость доставки до клиента

                А почему бы тогда не закодировать эти числа более эффективно, а потом сжать. Например, можно выбрать другое основание — не 2, а кодировку ответа сервера. Затем сжать, например, с помощью дельта-кодирования. И закодировать в новом основании. Получается 6 букв, каждую можно прочитать как response[I]
                  0
                  Вы совершенно правы. Float не лучший способ хранения. Тут пример с float приведен исключительно для наглядности.
                  +1
                  Финансовые данные как float? Вот уже действительно:
                  они не имели представления о работе классических бирж, не учитывали их опыт и пользовались легкодоступными решениями, чтобы получить быстрый результат.
                    –1
                    Я бы не назвал это финасовыми данными. И как ответил выше, float взят для простоты понимания идеи.
                      0
                      А как хранить цену? дробное число с большим количеством знаков после запятой… както флоат напрашивается сам собой…
                        0
                        Но точно не во float. Это вроде всем известная вещь про float и money.
                        husobee.github.io/money/float/2016/09/23/never-use-floats-for-currency.html
                          0
                          спасибо, изучу. я для своих роботов храню в даблфлоат, в обычной mysql. таблицы по 150 млн записей. классическая финдата- только на чтение используется… пока тормозов нет даже на старом пролианте пятого поколения. но пока и данных немного.
                            0
                            float дает ошибку, но в целом, для принятия решений роботом она чаще всего не существенна. Все же не зря этот тип данных придуман. Это скорее для конечного представления является проблемой. С другой стороны, правильнее хранить все в целочисленных значениях. По меньшей мере, это ускоряет обработку данных. Для этого достаточно знать максимальное количество знаков после запятой для конкретного инструмента и умножать цену на 10 в степени равной количеству знаков после запятой. Например, мы знаем, что минимальная цена инструмента 0.0001 тогда мы умножаем цену на 10^4 и получаем 1. Если мы возьмем цену 2.1234 то получим уже 21234.
                              0
                              у меня вопрос, как вы отображаете цену на графике? с фиксированной точностью или на клиенте уже есть информация о точности цены конкретного инструмента?
                                0
                                Обязательно есть. Для каждого инструмента.
                          0
                          Сложите два таких числа, и сразу все станет все понятно ;)
                            0
                            поддержу
                            сложить два может оказаться недостаточно, а вот если по таким данным посчитать комиссии, профитлос, да по нескольким позициям, то расхождение в значащих цифрах получить получить уже реально
                              0
                              Мы не используем float в реальности. Это наглядный пример. Иначе пришлось бы еще абзац в статье посвятить отдельно кодированию цены. Тем более, вычисление комиссии — это отдельный алгоритм, который имеет трудности в граничных значениях. Короче и без float трудностей хватает.
                        0
                        Да я смотрю в финтехе модно изобретать велосипеды. Помню тоже видел вакансию где искали сишника для обработки вот таких же файлов с историческими финансовыми данными. А базы данных их не устраивали потому что
                        Данные очень большие (день до 10ГБ)
                        .
                          0
                          Ну, положим, мы уже знали, где стоит велосипед, оттуда и взяли:)
                          0
                          Очень красивое решение
                            0
                            Спасибо!
                            0

                            Тут как всегда, каждый оптимизирует с оглядкой. Насколько я понял, вы, с оглядкой на максимальную совместимость с nginx.


                            Есть готовое решение для хранения таких данных в бинарном формате http://discretelogics.com/teafiles/.


                            Я для той же цели пробовал (понравилось) PostgresSQL+TimescaleDB, исключительно из-за полной совместимости с SQL. Оно, кстати умеет собирать данные по периодам. То есть имея минутные свечи, можно попросить собрать их с точностью 5 минут, 60 и как угодно.

                              0
                              С оглядкой на максимальную простоту и производительность. Вы вновь предлагаете создать backend со всеми его минусами, просто иными средствами. А мы от него отказались. Он не нужен. Экспозиция свечей — предопределенные параметры. Поэтому, нет необходимости иметь возможность их группировать нестандартно. Они заранее складываются в соответствующий файл (дописываются). Ровно поэтому и нет необходимости в любой БД. Она избыточна и более того, создает проблемы с масштабированием.
                              +1
                              Это, видимо какой-то очень узкий случай когда все, что волнует это просто (но быстро) достать свечи за период времени. Тут, конечно можно и файлов нагенирить и доставать их через nginx, если так уж хочется избежать написания своего бекенда. Однако, во всех реальных случаях работы с market data что я видел/участвовал, подобный уровень сервиса очень быстро перестает быть достаточным и любое новое требование плохо укладывается в описанную схему.

                              Например, может возникнуть желания перегенрации свечек «на лету» по вполне банальным причинам — не отдавать клиентру слишком много данных. Или, например, поддерживать (для отображения не клиенте) несколько типов интервалов. Такие реагргегации, если их ограничить, можно тоже генерить файликами, однако количество этих видов будет нарастать. Ну а в момент, когда понадобится доставать эти свечи каким-то нетривиальным образом для анализа, наример «взять 10 минутный интервал вокруг daily high price для определенного инструмента», или «вернуть свечи за интервал но отфильтровать по определеному минимальниому vwap» такая схема просто не будет работать.

                              Воможно, все эти дополнительные возможности и не нужны для работы с крипто-биржами и все что надо это быстро отдавать свечки. Для настощих бирж я видел несколько решений где разработчики пытались оптимизировать хранение market data в наборе своих велосипедных файлов, но все эти решения со временем превращались в свой собственный типа-nosql с индексами, кэшами, распределенностью и прочим, а начальное желания «поменьше бэкенда, сделаем просто на коленке» скоро забывалось и порождало трудно-понимаемых самописных монстров.
                                0
                                Вы уже поднимаете вопрос аналитического сервиса. Это задача другого класса и решается она через аналитические кубы. Подобную задачу мы будем решать чуть позже. И для ее решения, действительно, есть свой ассортимент велосипедов.
                                  0
                                  > и решается она через аналитические кубы

                                  Она решается разными способами. Однако, ее решение, в общем случае, плохо совместимо с предложенной схемой хранения и доступа. Я вполне могу представть случай, когда свечи хранятся за долгий период в какой-то оптимизированной форме, а данные для аналитики хранятся другим образом (за меньший период) и доступаются через другой бэкенд. У меня все примерно так и делается, однако идея хранить десятки тысяч candle файлов за каждый день (количество инструментов * на количество видов свечей) не вызывает оптимизма в мире, где торгуются множественные сущности. Кроме того, становится непонятным главный вопрос — а зачем это было надо? Ответ про меньше размер сам по себе недостаточен (можно не менее эффективно хранить в нормальном сторе) остается только часть «не будет бэкенда», что тоже лукаво, т.к. вместо разработки своего сервиса по отдаче будет настройка nginx на такую отдачу, т.е. nginx будет вполне себе бэкендом который где-то бежит и кем-то мониторится/контролирруется.

                                  Тут выше спрашивали про бечмарки, которые могли бы хоть намекнуть какую проблему это решение пыталось покрыть. Я с трудом себе представляю суровые трбебования для забора даже минутных свечек, т.е. их просто надо показать так, чтоб было достаточно быстро на стороне UI. С этой задачей справится что угодно, практический любой стор сможет их вернуть быстро хоть в виде бинарных данных, хоть в виде json/proto/bson/msgpack/…
                                    0
                                    У меня есть богатый опыт создания систем учета, а также аналитических модулей, модулей compliance и т.д. для классического трейдинга. Я прекрасно понимаю о чем Вы пишите. Но если мы вспомним даже классические средства трейдинга, то это трейдинговый терминал (Quik например), который отображает все то же — простой свечной график. Элементы технического анализа вынесены в отдельные модули и более того — продукты. Поэтому, как и там, так и тут, одного стрима для одного инструмента (пары) вполне достаточно. А подписываясь на стрим с различной экспозицией свечей, вы получаете различную дискретность формирующегося тренда.
                                    Мы решили проблему наличия backend для трейдингового терминала криптобиржи и полностью решили вопрос высокой нагрузки при обращении к маркет-дата.

                                    остается только часть «не будет бэкенда», что тоже лукаво, т.к. вместо разработки своего сервиса по отдаче будет настройка nginx на такую отдачу, т.е. nginx будет вполне себе бэкендом который где-то бежит и кем-то мониторится/контролирруется.

                                    При всем уважении, комментировать нет смысла. Если вы backend и nginx ставите на один уровень.
                                      +2
                                      т.е. это не про оптимизацию вовсе, но про желание избежать написание backend сервера. Во всяком случае такое мое понимание из текста и ответов, т.к. никаких намеков на что именно тут оптимизировалось еще, я не нашел.

                                      А из чего следует, что «полностью решили вопрос высокой нагрузки при обращении к маркет-дата»? Что такое, в этом контексте, «высокая нагрузка» и как это решение масштабируется горизонтально? Как, в такой схеме, достигается надежность и отсутствие единой точки отказа? Куда кладутся все это файлы вообще, если не на локальную FS? В тексте упоминается «классическая проблема синхронизации файловой системы. Команда DevOps решает ее легко и непринужденно. Например используя rsync.», т.е. видимо таки локальная FS. Однако сказать, что задача «решается лего» это сильное упрощение, ну а при чем тут devops я вообще не понял.

                                      На мой взгляд, это решние непонятной мне проблемы «как приготовить и распределить данные так, чтоб от бэкенда остался только nginx». Оно, как мне кажется, неопраданно усложняет процесс подготовки данных, прибивает реализацию к nginx гвоздями и критично к любым проблемам на этапе этой подготовки, типа rsync не смог доставить данных, процесс подготовки файлов на мастере завис/упал, да и вообще этот мастер, что файлы строит — это единая точка отказа. Работа с двумя/несколькими мастерами требует каких-то дополнительных решений. Попытки решить все эти проблемы (если они для вас являются проблемами) усложнят систему еще более, возможно до такого уровня, что уже станет понятно — с традиционным бэкендом было бы проще. Ну, например, как этот кластер заставить выбрасывать серверы, на которые не смогли доставить свежие файлы и/или на которых оказались поврежденные файлы? Видимо для этого нужны еще какие контрольные файлы чтоб их использовать для проверок здоровья. И так далее…
                                        –1
                                        Оптимизация расходов на содержание избыточной инфраструктуры, избыточного стека технологий, ведущего к избыточному штату. Оптимизация расходов на инфраструктуру и трафик.
                                        Как, в такой схеме, достигается надежность и отсутствие единой точки отказа?

                                        Я отдельно потратил время на изучение Вашего профиля. У Вас высокая карма. Я уверен, что Вы дельный человек и не мне Вас учить. Поэтому, прошу самостоятельно обратиться к вопросу «что такое CDN?» например Cloudflare.
                                        На мой взгляд, это решние непонятной мне проблемы «как приготовить и распределить данные так, чтоб от бэкенда остался только nginx». Оно, как мне кажется, неопраданно усложняет процесс подготовки данных, прибивает реализацию к nginx гвоздями...

                                        И опять прошу прощение, мне кажется, Вы немного плаваете в WEB-технологиях. Со всем уважением, но именно статика является сакральным камнем и идеалом любого высоконагруженного WEB-сервиса. Как только Вы погрузитесь в тему глубже, Вы сможете понять почему отказ от backend это круто. Со своей стороны, приведу простой аргумент — любой backend это прикладное кастомизированные решение, в то время, как nginx это универсальный продукт известного, надежного вендора.
                                        Еще раз, я уверен, что наш диспут возник просто потому, что в частном случае, у Вас просто нет достаточного опыта. Я с удовольствием готов вернуться к нему когда Вы погрузитесь в вопрос высоконагруженных WEB-приложений чуть глубже.
                                          +5
                                          Если собеседник (я) не согласен с предложенным решением и/или пытается понять, как и насколько это решение адкватно и, самое главное, что именно оно пытается оптимизировать — это вовсе не значит что собеседник не в теме и у него «просто нет достаточного опыта». Это, например, может означать что решение ему кажется неадкеватным задаче, или что решение описано таким образом, когда понять его трудно.

                                          Посылать меня изучать «что такое CDN» в надежде, что это добавить ясности как ваш внутренний процесс доставки через rsync, который «решает ее легко и непринужденно» вместо ответа на вполне резонные технические вопросы тоже не добавляет уверенности и, даже, вызывает определенные опасения.
                                            –2
                                            Ну, что мне сказать… ok… и все же, мой офер остался актуальным. Действующую реализацию Вы можете увидеть, проверить сами. Возможно я не в силах понять глубину Ваших вопросов. Тогда прошу прощение. Возможно, в этом случае, мне нужно время на их осознание. В любом случае, спасибо за Ваши комментарии! Я с удовольствием их прочитал.
                                              0
                                              пытаюсь найти ссылку на код и что-то не нахожу в тесте.
                                                0
                                                Ну хабр запрещает ссылки в статье. Посмотрите «сайт» в подписе к статье. Если не найдете, могу через личку написать. Не знаю… допустимо ли в комментариях давать ссылки…
                                                  0
                                                  сайт я вижу, но вопрос про код. Очевидно, не про тот код, что со стороны клиента, но тот код о котором мы говорили, т.е. подготовки данных. Иначе я просто не понимаю что именно я могу увидеть и/или проверить.
                                                    –2
                                                    Код, естественно, не будет опубликован. Мы создаем надежный трейдерский интерфейс. Вот его и можно проверить.
                                            +2
                                            послать umputun учить матчасть это круто, ахахаха :D
                                            кстати, при поиске информации о человеке советую пробывать искать в google по никнейму
                                              0
                                              Спасибо за совет. Но я складываю свое представление о человеке в общении с ним. У меня создалось то впечатление, которое я выразил. Воспринимать это как «посыл» не верно. Я общаюсь с большим количеством прекрасных специалистов, с которыми спорю. Иногда они вступают в спор слегка не подготовленными. Тогда мы его откладываем и возвращаемся к нему позже. Это не меняет мое высокое мнение о специалистах, как специалистах.
                                            0
                                            Так backend есть — просто он результат отдаёт не пользователю по его запросу, а превентивно считает и пишет в файл.
                                              0
                                              Видимо, есть проблема интерпретации, что такое backend. В классическом представлении backend это именно серверная часть. Причем аппаратно-программная. Но общепринятым представлением в WEB, когда говорят о backend, говорят о прикладном коде. В то время, как сервис WEB-сервера, отдает, т.н. статику. Говоря о том, что мы отказались от backend при трансляции марект-даты, я говорю от том, что мы не имеем прикладного кода транслирующего ее. Таким образом мы избавляемся от дополнительной точки отказа, поддержки и узкого места одновременно.
                                                0
                                                Транслирующий код — это middleware. Транслятор HTTP GET в SQL SELECT, а обратно таблицу в json.

                                                Охрененная экономия! И жутчайшая точка отказа! (сарказм)
                                                  0
                                                  Вы можете ответить на простой вопрос — зачем делать эти контроллеры, когда можно обойтись без них получив все выше описанные профиты?
                                                  +1
                                                  Backend — это то, что не frontend. А если оперировать твоими определениями, то nginx.conf — это DSL, тот код, который ты пишешь, чтобы твой backend заработал, так же как ты пишешь Java код (~nginx.conf), используя JVM (~nginxd). А ы случае чтения с файлами, файлы это твоя append-only Database. Operation System это Database backend, который, при помощи кеширования файлов, предоставляет тебе быстрый доступ к чтению. Поэтому разницы между backend как Java+JVM+SQL и nginx.conf+nginx+disk я особо тоже не вижу. Есть только ограничения самих тулов, что ты можешь и не можешь с этим сделать.

                                                  Признаюсь честно, я твою статью не читал полностью, только пробежался, чтобы понять о чем спор. В целом, у тебя простое и интересное решение. Но есть недостатки. Опять же, зависит от твоих требований к системе. Но я бы задумался, что будет, когда формат нужно будет поменять (добавить field), что будет если в случае corrupted files. Первое решается при помощи custom кода, второе при помощи DB, которые скажут тебе, когда с данными что-то не так. А с nginx — это ты как раз и будешь тем самым пользователем nginx, который будет на lua или javascript писать плагины для nginx, чтобы уметь добавлять или удалять поля при выдачи.

                                                  Я бы, так же, как и многие, поспорил бы с этим решением. Но опять же, у меня нет точных требований. В случае internal-only системы, может быть, хорошее решение.

                                                  Насчет umputun — многие, конечно, путают религию с уважением. Он тоже может ошибаться. Но, на сколько я знаю, он в последние десятки лет работает именно над trade systems, и связанное с этим. В своем подкасте он нарасказывал много про то, как многие компании отдают ему данные, и, предположу, натерпелся он многого. Увидив такое как клиент системы, я бы тоже не обрадывался.

                                                  И у тебя есть шанс стать известным. Если умеешь общаться на технические темы в живую, свяжись с umputun, надеюсь ему интересно будет пригласить тебя в выпуск подкаста radio-t.com и обсудить эту тему. Только будь подготовлен, ребята там с опытом.
                                                    +1
                                                    Спасибо за коммент! Испытал удовольствие читая его. Без преувеличения. Давайте поступательно:
                                                    1. В целом, я не против принят иную терминологию, нежели устоявшаяся в моем окружении. Это не меняет сути решения. Я даже рассматривал идею изменить статью для однозначного понимания того, что я продвигаю. Но не стал, по причине того, что кому бы я не показывал ее из своих знакомых, все прекрасно понимали о чем я написал. Хотя, после Вашего комментария, я еще раз обдумаю необходимость более полно раскрыть понятие «backend» в моем понимании;
                                                    2. Я уже задавал вопрос относительно того, что нет разницы между стеком с использованием прикладного кода + БД на backend (классика) и без него (предложенное решение). Прошу последовательно парировать приведенные в статье аргументы. Я ж старался, писал… А самый простой из них таков: любой backend это прикладное кастомизированные решение, в то время, как nginx это универсальный, надежный продукт известного, надежного вендора. В статье также приведены иные предпосылки для раскрытого решения. Странно, что люди с замахом на экспертное мнение, строят свою критику не на база последовательного опровержения приведенных в статье аргументов. Если собрать предпосылки в емкий второй вопрос, сформулирую его так — а какие требования к серверу, инфраструктуре и команде у решения со стеком, например PHP + MySQL + nginx, с учетом использования его в высоконагруженной системе? Наша нода фронта разворачивается на самой «дохлой» vps. Потому, что там кроме самого nginx нужен только linux. Мне кажется, разница очевидна.
                                                    3. Действительно, жаль, что люди не читают статью перед ее критикой. К моему большому сожалению, я отметил множество «грязных» комментариев, которые изобличают меня в поверхностном восприятии (к слову не тут, а там где мне даже шанс не предоставлен парировать) и т.д. Не удосужившись даже вникнуть в решение. Попытаться выразить его недостатки так как сделали это, например, Вы. А ведь это решение потребовало гораздо большего погружения в существующие технологии, чем «тупое копирование известных». Результат этой работы можно проверить, наглядно убедившись в реальности всех выводов. Просто возьмите для сравнения известную платформу TradingView и наш график. Посмотрите скорость работы того и другого при подгрузке данных.
                                                    4. Есть ли мысли как быстро вышла статья после внедрения этого решения? Решению уже год. Год. Я думаю, этот период можно считать достаточным, чтобы говорить, что оно проверено временем. Моя публикация вызвана не желанием стать известным или популярным. Я искренне верю, что криптобиржи с их парадигмой работы предоставления маркет-даты могут взять за основу это решение и получить массу профитов.
                                                    5. Изменение формата данных крайне маловероятно. Это устоявшийся формат. Именно это является коренной предпосылкой такого решения. Это красной нитью отражено в статье. Я не понимаю, почему в комментариях вновь и вновь люди возвращаются к этому вопросу. Но! Даже при его смене проблем нет. Как это не смешно, после предыдущего предложения, но мы формат меняли :) Правда по причине изменения разрядности полей. Почти уверен, что к удивлению для многих, в некоторых случаях, это проще чем с backend. Как так? Да очень просто. Когда вы меняете формат в backend может так статься, что отдаваемая структура несовместима в прошлой. А учитывая то, что мы используем еще и PWA технологию, наш фронт может быть закеширован на устройствах. И в случае такого изменения он просто будет падать намертво. Как решается вопрос с backend в этом случае? Самый простой способ, что я знаю, это версионирование API. Но… тогда мы раздуваем код и вынуждены увеличивать объем тестирования. А что же с файлами? Думаю, Вы уже поняли, что для этого достаточно просто «старые» файлики положить в папочку с прошлой версией и просто про них забыть. «Старые» версии фронта будут ходить к ним до обновления. Все. Неужели это не дает представление насколько экономится ресурс как в разработке, так и в продакшене?
                                                    6. Я не адепт ngnix. Я не адепт PHP, Java, Redis и т.п. Я считаю себя адептом разумного и релевантного решения. Внедряемые решения у нас на бирже проходят селекцию. Ни одно из них не внедряется просто потому, что кто-то имел положительную практику с ним или потому, что он «знает как нужно». Я например знаю MUMPS и считаю его лучшим, что произошло с миром :))
                                                    7. Corrupted… друзья, почему есть мнение, что этот сценарий нужно рассматривать как высокорисковый? Вероятность такого сценария низка. Почему? Я позволю тут переспросить вас — а какие причины могут быть к этому? И я готов каждую из них покрыть сценарием противодействия, которые у нас рассматриваются в рамках DRP стратегии.
                                                    8. Я готов спорить с решением, только, друзья, погрузитесь в тему криптобирж, их работы. Это не классические биржи. И нужно четко выделять понятие «торговый терминал» из всего трейдерского ассортимента продуктов. Именно для него, для этого частного решения и частного представления маркет-даты (график свечей) и релевантно данное решение
                                                    9. Как я уже сказал, я посмотрел на профиль umputun прежде чем писать свой ответ. У меня нет собственного мнения о его компетентности в вопросах классического фондового рынка. Я его не составил. Но те вопросы которые им поднимались, все же, имеют достаточно стандартные решения. И то, что их мне нужно объяснить… заставляет меня считать, что знаний именно в этой области, возможно, у него недостаточно. Ну невозможно знать все. Пожалуй, что интересно — а смотрел ли он на мой профиль? Все дело в том, что я конечно не в Чикаго, но создавал в свое время, если можно так назвать, ERP-систему для инвестиционной управляющей компании, входившей в TOP десятку по СЧА в России. В целом, мне кажется, мне известны все тяготы и лишения, с которыми он сталкивается. И создавая решения на проекте нашей биржи, я руководствуюсь полученным там опытом. Возможно, поверхностное восприятие статьи, пришедшей из «песочницы», сыграло плохую шутку.
                                                    10. Известным? У меня слишком много дел для того, чтобы быть известным:))) Я не против более детально раскрыть технологию, если это кому-то окажется интересным. Но мотиватор мой иной — желание создать что-то новое и интересное в мире криптобирж.

                                                    Еще раз большое спасибо за Ваш пост!
                                                      0
                                                      Как ты, возможно, заметил, я не упоминал свою особую компетенность и задавал, как мне кажется, вполне резонные технические вопросы исходя из описанного решения и его заявленных целей, которые может задать любой читатель этой статьи, вне особого опыта с конкретной бизнесс областью. Я вполне ценю желание сделать проще и приветствую инициативу не вводить лишних сущностей сверх необходимого, однако в описанном случае мне это простота видится кажущейся, перекладывающей сложость «на потом» и игнорирующей проблемы, которыми надо заниматься если речь идет о продашен системе, которая больше чем POC, MVP или демо.

                                                      В этом разрезе вопросы о том, что может пойти не так (попроченные файлы, упавший процесс подготовки, потеря сервера подготовки данных, потенциальная синхронизация и/или share диски, варианты с необходимость пере-аграгации свечей ...) — это все не из желания написать «грязный комментарий» (что бы оно для автора не означало) но от вполне резонных сомнений в качестве этого решения. А ответы «это не случится… маловероятно… что может пойти не так ...» мне видятся плохими и неприемлимыми в любом серьезном проекте.

                                                      Вся эта тема меня затронула от того, что много лет назад я и сам внедрил нечто подобное, когда market data (для обычных бирж) сохранялась в бинарных файлах (в моем случае это были записи сериализованные protobuf) и доступалась очень тонким слоем backend. Именно негативный опыт и трудность поддержки такого решения и вызвали мои вопросы к предложенному способу.

                                                      Я не просто так задавал вопросы о том, что это решение оптимизирует и какую проблему оно решает, т.к. это корень в понимании того, насколько принятые trade-offs адекватны, а не попытка поймать собеседника на противоречиях.

                                                      Ну и вообще, я не понимаю при чем тут моя личность и профили. Тут, в этой статье, речь шла о техническом решеннии и, как мне казалось, обуждать стоило именно это решение а не личную историю участников дискуссии. Попытка послать несогласных с решением… «погуглить что таке CDN» и прочие «учить современные WEB технологии» мне видится негодным способом ведения технических дискуссий.
                                                        0
                                                        … однако в описанном случае мне это простота видится кажущейся, перекладывающей сложость «на потом» и игнорирующей проблемы, которыми надо заниматься если речь идет о продашен системе, которая больше чем POC, MVP или демо.

                                                        Пожалуйста, услышь меня. Это частный случай для трейдерского терминала. Для графика свечей и списка сделок. Посмотри плз на «наших конкурентов». Не сравнивай классику с криптобиржами. В крипте инструментов ограниченное количество. Токены «рождаются» и «мрут» как мухи. Какие ты видишь еще возможные проблемы в будущем? Это будущее меняется по 40 раз на дню.

                                                        … но от вполне резонных сомнений в качестве этого решения.

                                                        Надежности решения? Хорошо, давай рассмотрим не нас, некую криптобиржу, а иные ресурсы, которые используют эту технологию. Я говорю по www.youtube.com к примеру. Как ты считаешь, все ли у них в порядке с надежностью? Да, мы не они. Но тоже в курсе о том, что такое высокодоступные сервисы. Да, в рамках DRP определяется риск выхода из строя сервиса. Определяются методы противодействия возможным сценариям. Самым жестким из которых является — перегенерация файлов. Время на эту операцию выделено 5 минут. Т.е. в случае потери сервиса целиком. В иных случаях, работают две ноды которые одновременно генерируют файлы. Они одновременно синкают файлы на фронты в разные папки. Фронт нода же смотрит на «живую» папку по симлинку. В случае если хартбит одной из нод «протух», что контролируется балансером, включается скрипт, который переключает на прод сервере симлинк на «живую» папку. Причем, это переключение не роняет даже кэши во всем стеке. Но не кажется ли тебе, что это не относится вообще к рассматриваемой сути технологии? Это лишь классическая проблема синхронизации файловой системы которой уже 100 лет. не уж-то есть сомнения в том, что подобные задачи успешно решаются и нужно тут ее вообще рассматривать?

                                                        Вся эта тема меня затронула от того, что много лет назад я и сам внедрил нечто подобное, когда market data (для обычных бирж) сохранялась в бинарных файлах (в моем случае это были записи сериализованные protobuf) и доступалась очень тонким слоем backend. Именно негативный опыт и трудность поддержки такого решения и вызвали мои вопросы к предложенному способу.

                                                        Так может рассмотрим именно твои, неудавшиеся сценарии применительно к маркет-дате криптобиржи? Я не троллю. Серьезно. Возможно я что-то не вижу, а может ты просто переоцениваешь потребности задачи.

                                                        Я не просто так задавал вопросы о том, что это решение оптимизирует и какую проблему оно решает, т.к. это корень в понимании того, насколько принятые trade-offs адекватны, а не попытка поймать собеседника на противоречиях.

                                                        Ну я несколько раз уже ответил. Если хочешь, могу нарисовать… главное, чтобы это не оказалось впустую. Помимо экономии на инфраструктуре, о которой я оскомину набил, это еще и поддержка технологии на всех слоях стека WEB. Что позволяет минимизировать код и переложить (да, я в курсе, что это перекладывания, в этом и соль) по кешированию данных на CDN, и конечного клиента. Конечно, помимо этого и свой nginx можно накрутить по кэшу. Думаешь можно включить кеширование запросов к API? Ну так нет… точнее включить их можно, просто возникнет такая интересная ситуация, когда два запроса с пересекающимися данными будут кешироваться отдельно. Т.е. скажем я сделаю запрос API с интервала 01.03.18 до 30.03.18 а потом с 02.03.18 до 25.03.18 это будет 2 разных запроса. И два разных кеша. Они закешируются на nginx и cloudflare. Но при этом объем таких кешей, как я думаю, понятно, ограничен. В варианте с content-range, второй запрос не будет выполняться к серверу. Этот кусок браузер возьмет из своего кэша. Не профит ли это?

                                                        Ну и вообще, я не понимаю при чем тут моя личность и профили.

                                                        Ну уж… :)))

                                                        Попытка послать несогласных с решением… «погуглить что таке CDN» и прочие «учить современные WEB технологии» мне видится негодным способом ведения технических дискуссий.

                                                        Я просил и прошу еще раз — не нужно воспринимать это как посыл. Ты же пишешь откровенно? Вот и я пишу откровенно. Мне вопросы показались неуместными, просто потому, что запрашиваемые решения очевидны. И если эти вопросы задаются, стоит их просто прояснить для себя. CDN это, Content Delivery Net, ничего нового. Он создан для того, чтобы с одной стороны снизить время доступа к контенту, с другой, для повышения надежности. Что такое единая точка отказа в этой связи? Я могу настроить CDN так, что завалившийся сервис он даже не заметит. Да, графики будет притормаживать. Но минимальная дискретность свечи у нас 15 минут. За эти 15 минут я биржи подниму с нуля. Единая точка отказа в сервисах? Ну неужели есть шанс, что криптобиржа создает сервисы без дублирования? Точка отказа в логическом сбое? Для этого есть порядок релиза на прод, чтобы избежать всего означенного, а также порядок отката, в случае обнаружения сбоя. Какая еще точка? Ты же сам знаешь, уверен, знаешь, что даже самый классный софт не будет работать на плохой инфраструктуре. Это две составные части успешного решения. И нельзя, просто нельзя перекладывать все проблемы на софтовую реализацию. Уж тем более, пытаться подобные проблемы заткнуть собственными «гениальными» решениями в PHP, Java, Golang и т.д. Так, что я должен был тебе ответить? Это?

                                                        Я также уже упоминал, и еще раз упомяну, и еще раз — это частное решение для трейдерского терминала. Отказались ли мы полностью от REST API? Нет конечно. Это как стрелять себе в ногу. Вот, пожалуйста — www.cryptonit.net/en/api Это публичные API. Они работают по REST. Почему? А потому, что так принято. Мы должны снизить порог вхождения для наших клиентов. Но если ты и в них посмотришь, и не только в наши, ты увидишь интересную особенность — запросы к графикам все так же выполняются в разрезе пары и экспозиции. А знаешь, что самое прикольное? Посмотри на SLA у бирж по работе с API. Там дичайшие ограничения. Это нонсенс для классики. Почему? Думаю вопрос риторический.

                                                        Я надеюсь, что в этот раз я ответил на все твои вопросы.

                                                          0
                                                          Посмотри плз на «наших конкурентов».

                                                          Как же я на них посмотрю, если даже на описанное тобой решение посмотреть невозможно т.к. "Код, естественно, не будет опубликован."


                                                          Это будущее меняется по 40 раз на дню.

                                                          Вот именно. А эта модель из всех, что мне приходят в голову, наименне гибкая и категорически не готовая к самым минимальным изменениям.


                                                          В варианте с content-range, второй запрос не будет выполняться к серверу. Этот кусок браузер возьмет из своего кэша. Не профит ли это?

                                                          Возможно профит, а возможно и нет, все зависит от того по каким параметрам мы оптимизируем решение и для чего это делаем. Если цель это экономить размер кеша на серверной стороне, то вполне себе профит. Если на клиенте — то нет. Другой вопрос а надо ли его вообще эконномить в этом конкретном случае? Т.е. что именно было/предполагалось не так при попытке использования традиционных подходов к кешированию? И насколько это важно в данном случае.


                                                          CDN это, Content Delivery Net, ничего нового.
                                                          Ох, опять. Мои вопросы ничего общего с CDN не имееют. Выброси на минуту CDN из этой картины, логику работы CDN перед твоими нодами никак не меняет.

                                                          Но не кажется ли тебе, что это не относится вообще к рассматриваемой сути технологии? Это лишь классическая проблема синхронизации файловой системы которой уже 100 лет. не уж-то есть сомнения в том, что подобные задачи успешно решаются и нужно тут ее вообще рассматривать?

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


                                                          В случае если хартбит одной из нод «протух», что контролируется балансером ...

                                                          Все, что LB может понять в контектсе "протух" это недоступность определенного файла на nginx или timeout запроса, т.к. кроме статики тут ничего нет. Т.е. все что можно отловить это ситуацию полной потери ноды. При традиционном подходе вместо всей этой "включается скрипт, который переключает на прод сервере симлинк на «живую» папку", нода смогла бы отдать статус "временно недоступен" сама исходя из проверок целостности и актуальности данных, состояния ноды и прочее что недоступно из голого nginx. Ну и кроме того, вся эта техника с включением скриптов она несомненно часть того, что я бы назвал backend и который тут никуда не делся. Он просто стал… нетрадиционным.


                                                          Единая точка отказа в сервисах? Ну неужели есть шанс, что криптобиржа создает сервисы без дублирования?

                                                          Да откуда мне знать, как именно в вашей компании пишут системы. Это был первый ответ из всех комментов, который хоть что-то сказал по этому поводу.


                                                          Как я уже сказал, я ничего не имею против упрощния и движения в строну "все отдадим файлами или их частями". Я даже это горячо приветствую и сам подобный подход применяю, где он мне кажется адекватным. Например, в построении сайтов где можно обойтись исключительно статикой. Скажу больше — мы даже как-то в подкасте обсуждали возможность пре-генерации комментариев (в статику на s3) в моей системе remark42 и я вокруг этой идеи эксперементировал пока не убедился, что потеря гибкости не оправдывает подобного изменения.


                                                          Возращаясь к сути — если бы моя цель в подобном проекте была бы в категорическом отказе от своего бэкенда, т.е. то, что сейчас называют serverless, то я бы копал в сторону хранения данных вне ноды (s3, dynamo, aurora, elastic cache ...) и элементарной лямбды с "контроллером". Перед этим всем был бы ALB и, при необходимости географической близости к клиенту, CDN. При этом я бы хранил только один набор свечек с минимальной дискретностью и строил бы свечки другого размера на лету (или отдавал бы из кеша/редиса, если они уже там). Скорее всего я бы не завязывался на такой суровый бинарный формат и отдавал чем-то более гибким. При том, что подобная инфраструктура кажется более сложной с одной стороны, она позволяет избежать большую часть того, что сейчас приходится делать в batch режиме и не городить свои скрипты для обеспечения адекватной надежности и, в сухом остатке, вполне может оказаться даже проще чем предложенная техника надежного построения и отдачи свечей.

                                                            0
                                                            Взял «патроны» калибра 3х0.5… теперь писать буду :)

                                                            Как же я на них посмотрю, если даже на описанное тобой решение посмотреть невозможно т.к. «Код, естественно, не будет опубликован.»

                                                            Ну так ты просто открой две биржи и сравни отзывчивость интерфейса. Сначала на компе, потом на мобиле. Поиграйся графиками. Если сильно хочется, я ж не смогу тебе запретить и нагрузочное дать? И что в коде ты хочешь найти? Это просто append в файл очередной свечи. Что там еще может быть?

                                                            Вот именно. А эта модель из всех, что мне приходят в голову, наименне гибкая и категорически не готовая к самым минимальным изменениям.

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

                                                            Вот о опять. Очевидным является то, что мы не можем влиять на кэш браузера. Это его задача, определять что для него и пользователя лучше. Поэтому думать о сем нужно как о профите. А уж с CDN разберемся.

                                                            Другой вопрос а надо ли его вообще эконномить в этом конкретном случае? Т.е. что именно было/предполагалось не так при попытке использования традиционных подходов к кешированию?

                                                            Я же пример привел… вроде наглядный. У тебя при REST запросах 1000 клиентов может выжрать всю память на кэши из-за дублирования данных.

                                                            И насколько это важно в данном случае.

                                                            Нужно ли? Правда? Я должен ответить на этот вопрос? Хорошо… я предлагаю решение для трансляции маркет-даты для высоконагруженных систем. Т.е. систем, обрабатывающих большое количество запросов. Т.е. в самой концепции статьи это заложено.

                                                            Конечно есть сомнения и конечно относится к сути технологии. То что «запрос возьмет готовые данные по смещению» переводит ту часть, что эти данные готовит и распределяет по нодам краеугольным камнем предложенной техники.

                                                            Не думаю. Это частное решение которое можно выполнить разными методами. Каждый волен его выбрать сам. И если, что совсем не обязательно средствами linux. Если уж загоняться. Поэтому, прямого отношения к предложенной технологии это не имеет. И должно рассматриваться вне рамок этой статьи.

                                                            Ну а что касается «классическая проблема синхронизации файловой системы» то эта проблема решается не сама, но десятком способов. Твой вариант с симлинками вовсе не единственный, да и вообще это не такая простая задача если ее решать аккуратно.

                                                            Тааак… ну… значит аккуратно… в чем проблема то? Ее решали, решают и будут решать. Это также не может являться камнем преткновения или дискуссии в рамках этой статьи. Это просто очередное решение.

                                                            Все, что LB может понять в контектсе «протух» это недоступность определенного файла на nginx или timeout запроса, т.к. кроме статики тут ничего нет. Т.е. все что можно отловить это ситуацию полной потери ноды.

                                                            Знаешь, ты мне идею подал. Я наверное попробую другой вариант — будем просто по крону запускать на ноде скрипт который будет симлинк перебрасывать туда, где фал больше размером ;) Как считаешь это сложно? А хартбит оставлю только для мониторинга.

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


                                                            Это система восстановления работы сервисов. Так можно и балансер уже к backend отнести. Что уж мелочиться то…

                                                            Да откуда мне знать, как именно в вашей компании пишут системы. Это был первый ответ из всех комментов, который хоть что-то сказал по этому поводу.

                                                            Ну лично я, стараюсь, верить в лучшее.

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

                                                            Можешь привести требования к развертыванию такой инфраструктуры? К компетенции персонала? Давай сравним.
                                                              0
                                                              Ну так ты просто открой две биржи и сравни отзывчивость интерфейса.

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


                                                              Эта модель уже год работает на нашей бирже. Никаких требований на горизонте еще 1 год на изменение нет.

                                                              это хорошо что нет. если есть такая уверенность в стабильности требований (в моей области такое практически не встречается) то это приятно.


                                                              Очевидным является то, что мы не можем влиять на кэш браузера.

                                                              эээ… что? С каких это пор? Мы очень даже можем влиять на то, что в этот кеш попадет и как оно там будет себя вести.


                                                              Можешь привести требования к развертыванию такой инфраструктуры? К компетенции персонала? Давай сравним.

                                                              Я выше уже привел пример. Какие еще требования нужны? И как сравнивать относительно стандартную инфраструктуру с набором самописных инфраструктурных кусков типа "будем просто по крону запускать на ноде скрипт ...". Мне трудно что-то пояснить в таком ключе если тебе кажется что это просто и вообще вся система это "просто append в файл очередной свечи". Даже из твоих не очень подробных пояснений видно, что нет — это не просто append, но ты почему-то отделяешь ту часть, что зовешь девопс в нечто, что к системе не относится.


                                                              Так можно и балансер уже к backend отнести. Что уж мелочиться то…

                                                              Можно, особенно если он с разным партизанством внутри. Вообще бекенды разными бывают, например вся твоя подготовкa свечек это вполне себе backend processor. Вместо некорретного "избавится от бэкенда" я бы сказал, что решение пыталось избавится от реализации своего rest/rpc/whatever части бэкенда.

                                                                0
                                                                Посылать меня тыкать в конкурентов это неконструктивное предложение.

                                                                Отнюдь. Это объективный взгляд на вещи. Иное, это субъективный взгляд на код. Мои замеры, любые, это не академически выверенный эксперимент. А следовательно, не имеющий ценности для большинства. Отсюда опять, простой вывод — личное исследование является единственным весомым фактом в пользу и или против.

                                                                эээ… что? С каких это пор? Мы очень даже можем влиять на то, что в этот кеш попадет и как оно там будет себя вести.

                                                                Открой мне тайну… как?

                                                                Какие еще требования нужны?

                                                                Обычные. Требования к развертыванию инфраструктуры. Которые выражаются в совокупность действий и необходимых ресурсов для достижения ожидаемого результата. Вот мне достаточно виртуалки с 512mb ОЗУ и 5Гб на диске при одном виртуальном процессоре. А, ну и еще ~1 девопсо-час (с ansible так еще меньше) на подключение очередной ноды.
                                                                Мне трудно что-то пояснить в таком ключе если тебе кажется что это просто и вообще вся система это «просто append в файл очередной свечи».

                                                                Это просто append. Я те слово даю.

                                                                Можно, особенно если он с разным партизанством внутри.

                                                                Ok. Значит это backend. Но скажи мне честно, ты то понимаешь о чем я говорю? ;) А назвать мы «это» можем как угодно. Как тебе хочется. Я, лично, не требователен к терминологии. Главное, чтобы люди друг друга понимали.
                                                                  0
                                                                  нет, мы решительно не понимаем друг друга. Как можно отметать бенчмарки и «оценивать субьективно» в чем-то, где есть требования по производительности и чем-то больше чем хобби проект на выходной — это никак не поддается моему пониманию.

                                                                  Как это «просто append. Я те слово даю» на фоне того, что уже вроде выяснили, что вокруг этого навороченно скриптов с кронами и прочим — тоже. Видимо мы говорим совсем об очень разном видении организации систем. В моем понимании все, что я услышал это любопытный способ доступа к данным, обещающий скорость и простоту. Однако по поводу скорости никаких данных (кроме «пойди потыкай в страничку»), по поводу простоты — я пытался понять есть ли она, и не убедился в этом.
                                                                    0
                                                                    Как можно отметать бенчмарки и «оценивать субьективно» в чем-то, где есть требования по производительности и чем-то больше чем хобби проект на выходной — это никак не поддается моему пониманию.

                                                                    Прости, но создается впечатление, что ты «сливаешься» :) Неужто ты не можешь оценить систему по внешним показателям? Интерфейсы тебе открыты. Что «под капотом» это не важно;) Если, что нужно, я подскажу по внешнему взаимодействию.

                                                                    Как это «просто append. Я те слово даю» на фоне того, что уже вроде выяснили, что вокруг этого навороченно скриптов с кронами и прочим — тоже. Видимо мы говорим совсем об очень разном видении организации систем. В моем понимании все, что я услышал это любопытный способ доступа к данным, обещающий скорость и простоту. Однако по поводу скорости никаких данных (кроме «пойди потыкай в страничку»), по поводу простоты — я пытался понять есть ли она, и не убедился в этом.

                                                                    Я тебе слово дал? Хочешь проверить мое слово? Не вопрос — подпиши NDA ;) Ты же наверное понимаешь, что любая строчка кода это ключ к безопасности. Лично я не вижу в ней проблему. Но это общее требование. Общее. Нарушать это требование нельзя. Но, повторюсь, я почти уверен, что, если ты подпишешь NDA, мы сможем тебе дать больше инфы, на взаимовыгодных условиях.
                                                                    Скажи, разве это звучит глупо?;) Ну, в рамках классической биржи.
                                                                    P.S. Сдается мне, что там бы и NDA не предложили подписать ;)
                                                                      0
                                                                      > Прости, но создается впечатление, что ты «сливаешься»… Что «под капотом» это не важно

                                                                      Какой-то детский сад. Да, я такого рода «технические дискуссии» вести не умею. Не важно — вот и славно, мне больше спрашивать тут нечего.
                                                                        0
                                                                        Ну… вот… я ж предупредил. У меня «патроны» калибра 0.5 :))) Скидку делай :)))

                                                                        При всем при этом, было классно пообщаться! Знаешь, у меня есть выражение — если его не знает моя бабушка, я его тоже не знаю. Ну так вот, я расскажу о тебе своей бабушке ;)
                                                                        Еще раз — спасибо за дискуссию!

                                                                        P.S. Не поверишь, я бы даже лайки ставил твоим постам, только мне карму снесли… отгадай кто?;)
                                                                  0
                                                                  Я конечно не блогер и звук вышел… не очень. Но думаю, даже такое сравнение будет наглядным для конечного пользователя
                                                                  www.youtube.com/watch?v=9o9KbQn3c9Y&feature=youtu.be
                                                0
                                                > При всем уважении, комментировать нет смысла. Если вы backend и nginx ставите на один уровень.

                                                эээ… а что тут не так? оба варианта требуют управления этими процессами. Никакой мистической сложности в таком бекенде (в его разработке) не будет и основное, чем надо будет заниматься в операционном плане (логи, мониторинг, метрики, дистибуция ...) будет отличаться мало чем. Вот если из этого варианта вообще исключить свой server side и обойтить без nginx, то тогда это было бы разного уровня.
                                                  0
                                                  Со своей стороны, приведу простой аргумент — любой backend это прикладное кастомизированные решение, в то время, как nginx это универсальный продукт известного, надежного вендора.

                                                  В котором все выше означенные проблемы решены.
                                        • UFO just landed and posted this here
                                            0
                                            Актуальные (online) данные отдаются через WEBSocket. Обращение к историческим данным идет через content-range.
                                            • UFO just landed and posted this here
                                                0
                                                Такой вариант мы тоже рассматривали, но это все же дополнительный стек и дополнительные плейбуки. Редис хочет места, хочет память. А предложенная концепция в качестве фронт-сервера может использовать самую дохлую vps, конечно, прикрытую CDN.
                                                • UFO just landed and posted this here
                                                    0
                                                    Не вижу «протечки», т.к. вам придется делать то же — рисовать крайнюю свечу через WEBSocket. Ну не пулить же вы ее будете? С удовольствие услышу иное решение. По сути, последняя свеча, это тикер за выбранный интервал.
                                              0
                                              Текущей свечки не существует.
                                              Допустим, у вас часовая экспозиция у всего графика. А последний элемент, внезапно, имеет экспозицию сначала минуту, потом две, потом три. Это категорически неверно — смешивать размерности. Можно считать, что у этих данных даже природа разная — начало «текущей» свечи по сути шум.
                                                0
                                                Хм… а если торги резко прервутся? Биржа упадет. И за последний час будет только одна минута. Это будет часовая свеча? Думаю, это уже как-то философски. В любом случае, даже в вашем представлении никакой «протечки» нет, т.к. график обновляется после прохождения заданного интервала. Я очень часто наблюдал решение отображения формирующейся свечи. Не нахожу в этом какой-то проблемы. Но, конечно, Вы верно заметили — у каждого свои фломастеры на вкус :)
                                              0
                                              Вариант хранения очень прикольный и имеет свои плюсы и минусы, но удивляет меня желание отказаться от бэкенда, при том что описанное решение это один-два контролера с парой-тройкой методов…
                                              Отказ от баз данных(которые есть под любую задачу) ставит Вас в позицию больших исследований по организации своего решения и лишает гибкости, написанных библиотек и массы готовых подходов.
                                                0
                                                Спасибо! Пара контроллеров, которые будут создавать ровно столько обращений к БД, сколько запросов на них придут. Т.е. если у люди начнут «скролировать» график со свечами, сколько запросов ко мне придет? А теперь внимание — сколько из них будут «зомби»? Ну т.е. он то отправлен, только уже не нужен, т.к. график уже отскролирован далеко в глубь. Кеширование? Ну да… давайте включим кеширование где? На CDN? На nginx? И что получим? Использование памяти? Давайте рассмотрим и аргумент в пользу готовых решений. Готовых каких? Я буду благодарен, если Вы скажите в каком случае понадобится нам, бирже, больше чем отдавать свечной график за интервал времени в трейдинговом терминале. Как я писал выше, для добавления ноды в рамках нашего решения подходит самая дохлая vps. Просто потому, что там будет только nginx и статика. Т.е. горизонтальное масштабирование нам стоит очень, очень дешево. Что потребуется в случае с парой контроллеров + БД?
                                                  0
                                                  а сколько у вас всего данных?(Гигабайт)
                                                  и сколько запросов в секунду надо держать?
                                                    0
                                                    Есть вещи, которые, к сожалению, я не могу сказать точно (в абсолютных цифрах). Это в рамках NDA и безопасности. Но, вопрос — «сколько запросов держать нужно?» очень актуальный. Дело в том, что криптобиржи излюбленный объект DDoS атак. Данное решение, практически всецело, перекладывает эту проблему на CDN. Скажу так — то, что у нас проходит атака на маркет-дату, мы узнаем от CDN. При этом, на наших серверах (оборудованных мониторингом, конечно) даже высокой нагрузки не отмечается. Для конечного пользователя она вообще проходит незамеченной. Кстати, следующей статьей я отчасти раскрою эту проблему.

                                              Only users with full accounts can post comments. Log in, please.