Комментарии 7

Перечитал статью дважды и не понял как все это применить в жизни. Успешно решаем работу с временными рядами средствами ClickHouse (тиковые биржевые данные). В чем преимущество вашего решения и прямых выборок из кликхауза?

средствами ClickHouse

Ээээ… Ну принципиальных отличий два: Vela — это in-memory решение. Паттерн использования примерно такой: запускаем процесс на каждую пару валют (или на любой параметр временно́го ряда) и этот процесс держит актуальный кеш в стейте. Не нужны никакие 3rd-party базы. У нас примерно 20К пар, курсы по каждой приходят примерно 10 раз в секунду; 200 000 записей в ClickHouse в секунду — это так себе вариант, особенно учитывая, что хранить курсы нам особо не требуется. Подключим еще десять провайдеров — это число утроится. С решением выше я просто добавлю в OTP кластер ±2 машины.


В чем преимущество вашего решения

  • работает из коробки без дополнительного стораджа (раньше у нас был Riak для KV)
  • быстрее, чем любой сторонний сторадж (ClickHouse я не пробовал, но я сильно сомневаюсь, что он покажет результаты лучше Riak и/или mnesia)
  • очень гибкий механизм валидирования до сохранения и в момент извлечения, который можно менять на лету
  • очень прозрачный код бизнес-логики, который абсолютно изолирован от кода возни с time series, мы просто в любой момент времени получаем самый актуальный курс по нескольким параметрам.

Есть и недостатки:


  • если процесс упал, прогрев кеша займет какое-то время (на моей памяти пока такого не случалось),
  • сам по себе кеш ничего не хранит, если нужно эти time series сохранять — KV придется прикрутить отдельно,
  • рестарт в докере сопряжен с некоторыми танцами вокруг hot-upload, чтобы не потерять кеш, но этим занимается другая библиотека — Cloister.

Такой себе специализированный Tarantool. :)
Спасибо за ответ. По количеству записей в кликхауз сделаю ремарку — пакетные записи в него очень быстрые — думаю вы понимаете, что тиковые данные на фьючерсном рынке по 20 инструментам генерируют намного большие объёмы данных. Это не для полемики — просто для информации.

пакетные записи в него очень быстрые

Это я понимаю. Но я не до конца понимаю, как я соберу этот пакет. А кроме того, у меня совсем не read-only, мне еще придется оттуда читать, потому что мне надо адекватно отреагировать на каждую пришедшую единицу данных, и это некоторая арифметика, не очень сложная, но все же не if x > 0, do: spawn(). Когда мы получаем новый курс, нам нужно сравнить его по нескольким параметрам со шлейфом последних, и или выбросить, или запихнуть в самый конец кеша, или в начало — и использовать для создания нескольких новых ивентов.


У нас паттерны принципиально разные, похоже. Мы пришли к тому, что используя OTP — надо использовать OTP. Процесс знает только про свою пару валют, и оперирует только ей. Если процесс крашится — отваливается только эта пара (там есть защитная прослойка, но это совсем вне темы).


Как я соберу пакет из 20К разных процессов из разных нод кластера? Кроме того, быстрое-то оно быстрое, но нуждается в дополнительном обслуживании. Ну и, в конце концов, я вообще очень далек от мысли сравнивать memory-cache с полноценным KV. Просто есть задачи (и описанная мной — как раз из таких, и у нас есть еще похожие) — куда совсем не хочется тащить KV (вокруг которого, повторюсь, придется понастроить логики, которая будет проверять, сортировать, правильно извлекать, и т. д., сиречь все эти запросы будут мозолить глаза прямо в приложении, а если похожих приложений несколько —  то и в каждом из них.

Не хватает функции коррекции помещаемого в кэш значения вместо его отсева. Тогда на этом механизме можно сразу сделать, например, ФНЧ, и записывать тренды в отдельные последовательности, питаясь такими же исходными данными, как и моментальные курсы ;)

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