AZ
Блин, ребята, запустилось всё, 4 часа правда данные потеряли( но хотя бы запустилось
Size: a a a
2021 January 20
AZ
Дима, Саша, спасибо вам от души
DT
Блин, ребята, запустилось всё, 4 часа правда данные потеряли( но хотя бы запустилось
Ну, могло быть и неприятнее.
Репликация, тесты на стейдже перед выкатом и вставка через Kafka вас ждет :)
Репликация, тесты на стейдже перед выкатом и вставка через Kafka вас ждет :)
AZ
Уже все, по-любому. Знаете же как оно, вот вот сделаем, еще пару фич и будем инфраструктуру строить. И не успели
AP
Тесты на стейдже это да. Мне 1 раза хватило чтобы их запилить 😀
KB
Привет.
Вопрос - есть поток событий:
(user_id, time, event)
нужно пользователю в UI быстро показывать события
Лучше, чем две отдельных таблицы с разными PK ведь не получится сделать для этого?
Вопрос - есть поток событий:
(user_id, time, event)
нужно пользователю в UI быстро показывать события
user_id=x и нам для аналитики уметь по time фильтровать.Лучше, чем две отдельных таблицы с разными PK ведь не получится сделать для этого?
(user_id, time)
(time, user_id)
DT
Привет.
Вопрос - есть поток событий:
(user_id, time, event)
нужно пользователю в UI быстро показывать события
Лучше, чем две отдельных таблицы с разными PK ведь не получится сделать для этого?
Вопрос - есть поток событий:
(user_id, time, event)
нужно пользователю в UI быстро показывать события
user_id=x и нам для аналитики уметь по time фильтровать.Лучше, чем две отдельных таблицы с разными PK ведь не получится сделать для этого?
(user_id, time)
(time, user_id)
Ну а сколько юников user_id, какие у вас обычно используются интервалы для фильтра по time
KB
сотни тысяч, могут быть и миллионы
KB
если бы uniq(user_id) исчислялся десятками можно было бы оставить как есть time, user_id ?
DT
Смотря сколько вообще записей в день
А так если десятки то
(user_id, time)
А так если десятки то
(user_id, time)
KB
понял о чем ты, спасибо
ВВ
Смотря сколько вообще записей в день
А так если десятки то
(user_id, time)
А так если десятки то
(user_id, time)
МНе вот кажется наоброт надо - time, user_id. дата же всегда нужна. Быстро показать события юзеру - ему ж наверняка надо или последние, или за период. За прошлый год ведь явно не надо?
DT
Вячеслав Владимиров
МНе вот кажется наоброт надо - time, user_id. дата же всегда нужна. Быстро показать события юзеру - ему ж наверняка надо или последние, или за период. За прошлый год ведь явно не надо?
Обычно есть партиционирование по месяцу, те уже больше месяца не будет выбрано.
Плюс селективность по user_id будет лучше чем по datetime.
Плюс селективность по user_id будет лучше чем по datetime.
KB
для аналитики все равно пользуемся разрешением месяц и больше
KB
нам главное чтобы за 5 лет не читал
ВВ
Обычно есть партиционирование по месяцу, те уже больше месяца не будет выбрано.
Плюс селективность по user_id будет лучше чем по datetime.
Плюс селективность по user_id будет лучше чем по datetime.
т.е. при наличии партиц по вреени КХ и без индекса справится?
DT
Вячеслав Владимиров
т.е. при наличии партиц по вреени КХ и без индекса справится?
Ну партишн прунниг должен отбросить партиции которые за пределом временного интервала, да
ВВ
интересный вариант. Допилили бы уже explain - сколько бы вопросов отпало сразу )))))
DT
Вячеслав Владимиров
интересный вариант. Допилили бы уже explain - сколько бы вопросов отпало сразу )))))
Так есть же, даже в 20.8