Комментарии 7
средствами 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.
пакетные записи в него очень быстрые
Это я понимаю. Но я не до конца понимаю, как я соберу этот пакет. А кроме того, у меня совсем не read-only, мне еще придется оттуда читать, потому что мне надо адекватно отреагировать на каждую пришедшую единицу данных, и это некоторая арифметика, не очень сложная, но все же не if x > 0, do: spawn(). Когда мы получаем новый курс, нам нужно сравнить его по нескольким параметрам со шлейфом последних, и или выбросить, или запихнуть в самый конец кеша, или в начало — и использовать для создания нескольких новых ивентов.
У нас паттерны принципиально разные, похоже. Мы пришли к тому, что используя OTP — надо использовать OTP. Процесс знает только про свою пару валют, и оперирует только ей. Если процесс крашится — отваливается только эта пара (там есть защитная прослойка, но это совсем вне темы).
Как я соберу пакет из 20К разных процессов из разных нод кластера? Кроме того, быстрое-то оно быстрое, но нуждается в дополнительном обслуживании. Ну и, в конце концов, я вообще очень далек от мысли сравнивать memory-cache с полноценным KV. Просто есть задачи (и описанная мной — как раз из таких, и у нас есть еще похожие) — куда совсем не хочется тащить KV (вокруг которого, повторюсь, придется понастроить логики, которая будет проверять, сортировать, правильно извлекать, и т. д., сиречь все эти запросы будут мозолить глаза прямо в приложении, а если похожих приложений несколько — то и в каждом из них.
Не хватает функции коррекции помещаемого в кэш значения вместо его отсева. Тогда на этом механизме можно сразу сделать, например, ФНЧ, и записывать тренды в отдельные последовательности, питаясь такими же исходными данными, как и моментальные курсы ;)
Vela → умный кеш для time series и не только