Откуда у нас столько, как бы не обвинили в сексизме, разнообразия? В кубернетесе вон только одна Алиса, и та мужик.

Эффект бабы в поле?

Либо админы)

Покажешь нам cql? :)

насколько адекватный запрос, судя только по нему без схемы в плане трудоемкости без экономии на спичках ? SELECT DATE_FORMAT(created, '%Y-%m-%d') AS date, SUM( CASE status WHEN 'active' THEN 1 WHEN 'finished' THEN 1 ELSE 0 END ) AS subscriptions, SUM( CASE LEFT(phone,4) WHEN 'temp' THEN 1 ELSE 0 END ) AS temp FROM users WHERE created BETWEEN '2017-08-15' AND '2017-08-26' AND project_domain = 'example.net' GROUP BY date

индекс на status и project_domain и created отдельные

насколько адекватный запрос, судя только по нему без схемы в плане трудоемкости без экономии на спичках ? SELECT DATE_FORMAT(created, '%Y-%m-%d') AS date, SUM( CASE status WHEN 'active' THEN 1 WHEN 'finished' THEN 1 ELSE 0 END ) AS subscriptions, SUM( CASE LEFT(phone,4) WHEN 'temp' THEN 1 ELSE 0 END ) AS temp FROM users WHERE created BETWEEN '2017-08-15' AND '2017-08-26' AND project_domain = 'example.net' GROUP BY date

Что ты понимаешь под "адекватный"?

я написал

Нет

ещё раз прочитай)

Может быть ты и написал, но ЛЮДЯМ НЕПОНЯТНО!

Да я и с первого раза прекрасно всё понимаю.

смешной ты

Ну, в плане трудоёмкости — очень простой запрос, такой пишется за 5 минут

индекс на status и project_domain и created отдельные

лiл

оставляй индекс по времени

а остальные дропай

один хуй не будут работать

в проекте не один этот запрос

это дополняющая инфа

@MasterZiv интересно по каким параметрам ты класифицировал запрос как простой

индекс на status и project_domain и created отдельные

Это вопрос или утверждение ? Где там status? На status индекс не нужен Далее моё утверждение: надо либо составной индекс, (created, project_domain), либо только (created) . Как лучше — зависи от данных.

@MasterZiv интересно по каким параметрам ты класифицировал запрос как простой

По сложности

Это вопрос или утверждение ? Где там status? На status индекс не нужен Далее моё утверждение: надо либо составной индекс, (created, project_domain), либо только (created) . Как лучше — зависи от данных.

это цитата афтара

любой запрос можно повесить, зависит от размера данных,

А, сори не догадался. Ты Reply жми, тогда будет всё понятно.

он бы еще по каждой паре полей индексы создал и по тройке в разном порядке

по поводу составного ключа - да, но я ожидал услышать как оптимизировать between

ну а че. а вдруг?

по поводу составного ключа - да, но я ожидал услышать как оптимизировать between

BETWEEN оптимизировать индексом по полю, по которому between.

Будет ли индекс работать, зависит от количества данных, попадающих в данный конкретный диапазон.

Я так понимаю, у тебя будут пользователи, зарегестрированные в период порядка полутора двух недель. По идее , это должно быть немного.

3кк, но бывает больше данных

2-3с between работает

3кк, но бывает больше данных

Это я не понимаю.

2-3с between работает

Так всё-таки ты о ПРОИЗВОДИТЕЛЬНОСТИ, а не о ТРУДОЁМКОСТИ....

одно из другого не следует?

Нет

по делу давай

тебя слишком много

Короче, индекс на (created, project_domain), если доменов в таблице много (тыщи), либо (created) если доменов в таблице мало (десятки).

спасибо, я сделал связный

доменов не тыщи, но ускорило в 3 раза

доменов 20

Запросы вроде select created, project_domain, count(*) /(select count(*) from users) as sel from users group by created, project_domain order by count(*) desc limit 20 помогут тебе оценить селективность. Если она проценты и менее (т.е. менее 0.01) — индекс стоит. Если больше — не стоит.

мне предлагали избавиться от betwen и отрефакторить дату как таймштамп

я бы хотел это попробовать в последнюю очередь

интересует, что можно сделать ещё, т.к. дата типа datetime

мне предлагали избавиться от betwen и отрефакторить дату как таймштамп

Как это ?

Какая разница, какого типа данных это время ?

интересует, что можно сделать ещё, т.к. дата типа datetime

Какая СУБД?

интересует, что можно сделать ещё, т.к. дата типа datetime

Особенно ничего. Это — главное.

mysql 5.5.50

Можно ещё попробовать в составной индекс добавить ещё поле date. Но это надо смотреть.

Какая разница, какого типа данных это время ?

поиск инта в чистом виде быстрее наверное

поиск инта в чистом виде быстрее наверное

Абсолютно по барабану

timestamp — это не int к тому же

Хотя щаз гляну...

Да, я прав.

bigint можно

3кк, но бывает больше данных

Расшифруй всё же...

3 000 000 строк в таблице

пол таблицы попадает под ограничение даты

в таблице строк сколько — по барабану, сколько строк приходится на это твоё конкретное условие between этих двух конкретных дат

ERROR: S client not available

пол таблицы попадает под ограничение даты

Тогда индекс можно выкинуть. А запрос будет всегда работать достаточно долго.

Агрегация 1.5 млн записей — ну, согласись, непросто

И чё. за две недели полтора миллиона пользователей ?

ага

потенциальных пользователей

если быть точнее

Короче выполни запросик со статистикой, только дату там приведи именно к дате, т.е. отбрось время. Можно также сгруппировать по дням, неделям и другим периодам, когда ты будешь считать этот запрос примерно. Если в группах будет много записей — индексы бесполезно создавать.

Ну и поскольку других SARG-ов нет, то запрос обречён.

видимо тут нужна другая БД, аналитическая

Можно там только память под кэш выделять больше, сортбуфера больше делать и прочее, чтобы он быстрее считало, но это будет в разы, а не на порядки.

видимо тут нужна другая БД, аналитическая

Ну, если будет columnstore то да, ей такие объёмы как семечки.

Но ты же не будешь от одного запроса всё СУБД менять.

возможно нужно будет проект переписывать, думаю на будущее если только

вот я с этим не связывался, не знаю как делать выборки, где нужно связать две разные БД, сджоинить

С чем?

ну вот тот же mysql и clickhouse

Нормально, если запрос 2-3 секунды работает, и хрен с ним, пусть потормозит.

clickhouse врядли тебе подойдёт. Там просто SQL немного не поддерживается...

т.е. взять кусок данных из mysql и кусок данных из ch и на уровне какой-то из бд связать эти данные , отфилтровать и получить результат нельзя?

"кусок данных из ch " — это что?

т.е. взять кусок данных из mysql и кусок данных из ch и на уровне какой-то из бд связать эти данные , отфилтровать и получить результат нельзя?

А, понял. Я не знаю, но с кликхаузом в плане использования под общие нужды лучше не связываться.

ну например в mysql у нас пользователи, а в CH информация подробная по каждому из них для статистических запросов, иногда нужно получить данные по конкретному пользователю и получить данные одновремено из обеих баз данных

Тем более изза запроса, выполняющегося 2 секунды. (или минуты ? Я забыл )

2 сек

Ну это вообще шикарное время.

чё тебе не нравится ? Для такого убитого запроса-то...

Тебе 2 секунды не подождать ?

интересно теоретически, есть вероятность что нужно будет что-то делать

Вот и что мне на это отвечать ?

ну может есть инфа где-то , как делают в таких ситуациях

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