луз
3. если вин - выплата
все это в редисе.
как только билетик закончил свою жизнь - кладем в ClickHouse.
иногда юзер может попросить все его билетики - тогда лезем в CH за ними.
вот меня запрос: “достать все билетики пользователя” в кликхауз беспокоит, в части производительности.
также, хочется понять, подходит ли CH для этой задачи или шарды в монге мой путь?
Если вы обозначили сомнительный кейс, оставив за скобками аналитику и всякие обобщения, то, может, и подходит. А если этот кейс и есть единственный, то выбор CH вряд ли удачен. Так или иначе CH про небольшой поток сложных запросов. Выше вам задали правильные вопросы.
что такое Q?
аналитику планировал делать уже после, на самом клике. в клик летят уже агрегированные данные
Q = query. Оно же rps. Если аналитика будет, то вполне можно думать в строну CH.
на первоначальном этапе планируется 10-20к за 3-4 секунды, но и 30к в секунду не исключены. аналитика будет, но не сложная.
Это многовато для CH. Прямо сильно многовато.
10к за 4 секунды это много, да?
Если речь идёт про запись - нормально это если писать через buffer таблицу. Единственный момент если все в онлайн надо перед перезагрузкой ноды, надо останавливать загрузку и заливать данные из буфера в основную таблицу
планирую в NATS отправлять 10к билетов за 3 секунды и каждые 3 секунды флашить эти данные в CH.
а буферная таблица (та в которую прилетают данные из кафки/nats), если нода CH упадет, то я потеряю данные из этой таблицы или они персистенты?
Обсуждают сегодня