Всем добрый день. Есть один теоретический вопрос. Есть определенный класс задач, где нужно одновременно поменять множество значений по какой-то логике. Самым лучшим примером такой задачи можно назвать услуги пользователя в биллинговой системе. Тоесть задача в общем виде звучит так, есть 500 тыс записей в базе, образно говоря uid и sid, айди пользователя и тарифа, при наступлении нового месяца надо обработать "одномоментно" всех этих пользователей - кому надо переключить тариф, у кого надо отключить тариф вообще, или же просто оставить такой же тариф. Вопрос про баланс, логирование и прочие вещи неинтересен. Тоесть задача тупо загрузить одну/две колонки в память, пробежать по ним и быстро все поменять как надо, по какой-то логике.
Здесь нельзя использовать кх. Кх для неизменяемых данных в первую очередь. Возьмите postgresql
Господа, а пробовал ли кто-нибудь менять TTL на materialized view? На самой вьюхе поменять нельзя, но зато получается поменять TTL для таблицы, которая хранит данные вьюхи (ну та, которая ".inner.view_name". Но самое забавное, что при этом SHOW CREATE TABLE мне показывает разные TTL для вьюхи и .inner. таблицы. Кто знает, почему так и будет ли вообще такая схема работать?
Есть вопрос, по которому необходимо развеять сомнения. В КХ хранятся таблицы с одинаковой схемой данных для выполнения запросов с разным поисковым критерием по таблицам. Правильно ли я понимаю, что если хочется избавиться от дублирующей таблицы, то мне в данном случае необходимо создать индекс дополнительный и дропнуть дублирующую таблицу после создания индекса и исполнения optimize в оригинальной? В документации вроде бы написано, что можно создавать индекс, если критерий поисковой (условие запроса в WHERE) отличается (если я правильно улавливаю мысль)...
Есть вопрос, по которому необходимо развеять сомнения. В КХ хранятся таблицы с одинаковой схемой данных для выполнения запросов с разным поисковым критерием по таблицам. Правильно ли я понимаю, что если хочется избавиться от дублирующей таблицы, то мне в данном случае необходимо создать индекс дополнительный и дропнуть дублирующую таблицу после создания индекса и исполнения optimize в оригинальной? В документации вроде бы написано, что можно создавать индекс, если критерий поисковой (условие запроса в WHERE) отличается (если я правильно улавливаю мысль)...
доп Индексы очень специфичная штука и помогают только в определенных случаях, вариант с несколькими таблицами и сортировками может быть лучше