Я здорово апнулся в кликхаусе и полюбил его еще сильнее,

Question

Я здорово апнулся в кликхаусе и полюбил его еще сильнее,

но это родило проблему - от mysql теперь чувствую боль и жжение. Почти все участки приложения либо полностью переехали в CH, либо в процессе переезда, "правильные" запросы + replacing таблицы рулят большую часть возникших сложностей и неочевидностей.
Но есть две вещи, которые я пока не знаю как сделать правильно, раньше они были в числе всего остального, что решалось mysql и искушения избавиться от него полностью не возникало, сейчас же - ситуация поменялась и ради таких мелочей держать mysql совсем не хочется.
1. Одиночные выборки из двух таблиц, одна на 10млн строк, вторая на 100м. Планирую решить таблицей с низкой грануляцией и парой матвьюшек с order by по нужным полям. RPS не большой, вроде проблемы быть не должно, но как то не правильно это.
2. Локи. У меня есть несколько ситуаций, когда запускаются сложные просчеты, которые могут занять продолжительное время. В mysql я делал get_lock, проверял флаг запущенности операции, если запущено - ок, выходим, если не запущено - ставим флаг запущенности и считаем. В CH локов не видно и это первая часть проблемы.
3. Репликация силища! Но есть отставание реплик. Соответственно эти флаги запущенности из предыдущего пункта нельзя хранить в кликхаусе (вдруг поставили флаг на одной реплике, запрашиваем на второй, которая отстает на секунду, делаем ложный вывод о том, что над задачей еще не идет работа и дублируем эту работу)
И смотря на эти три штуки я прихожу к мысли, что нужно поставить редис. В нем будут кешироваться ответы из пункта 1 снижая нагрузку от неудобных одиночных запросов + вроде как у него есть механизм локов - второй вопрос так же решается, ну и с третим вопросом он тоже должен помочь. Может быть отговорите и укажите более истинный путь?

#backend #clickhouse #database #devops #programming #russian

0

21.09.2019