D
Сколько угодно, лишь бы не одна) и чтобы была какая то закономерность, чтобы инсерты хоть как то фильтровали партиции
ну сделайте тогда 2 партиции и проблемы не будет ))))
Size: a a a
2020 May 26
DC
поправили настройки parts_to_throw_insert и parts_to_delay_insert и пока больше не повторялось
хм, наверное надо увеличить background_pool_size чтобы было больше одновременных мержей
DC
добрый день! подскажите пожалуйста, как правильнее осуществить миграцию данных в случае изменения сортировочных ключей у таблицы?
нет никакого правильного варианта, все зависит от ваших условий, я например предлагаю не переливать данные, а соединить новую и старую таблицы движком merge
DC
Сколько угодно, лишь бы не одна) и чтобы была какая то закономерность, чтобы инсерты хоть как то фильтровали партиции
>чтобы инсерты хоть как то фильтровали партиции
чего-чего? инсерты фильтровали?
чего-чего? инсерты фильтровали?
N
нет никакого правильного варианта, все зависит от ваших условий, я например предлагаю не переливать данные, а соединить новую и старую таблицы движком merge
это как? что он может соединять 2 таблицы?
DC
Nikolay
это как? что он может соединять 2 таблицы?
да. см Вариант2 в engine=Merge
KG
нет никакого правильного варианта, все зависит от ваших условий, я например предлагаю не переливать данные, а соединить новую и старую таблицы движком merge
это как? ссылочку можно?
DC
это как? ссылочку можно?
см пример 2 в engine=Merge
C
>чтобы инсерты хоть как то фильтровали партиции
чего-чего? инсерты фильтровали?
чего-чего? инсерты фильтровали?
селекты* 🤦♂
DC
селекты* 🤦♂
и что фильтруют? как вы селекты пишете? where.... ?
DT
Привет, подскажите, у меня есть таблица, например с SerialID товара, ID покупателя, ID действия (заказ, оплата, доставка) пользователя и временем timestamp действия . Таблица большая около 200 Гб. Мне нужно для каждого пользователя выгрузить данные и посчитать аггрегаты на клиенте. Запрос на действия по каждому пользователю будет слишком дорогим. Как бы мне сделать быстро, не нагружая сильно КХ.
сделать запрос сразу для всех пользователей, все зависит от того в каком виде вам нужно выгрузить данные
KG
ситуация следующая:
Всплывает ошибка «too many open files»
Судя по логам, это связано с таблицей, в которой 120млн записей. Её ключ сортировки: ORDER BY (timestamp, fieldname1, fieldname1, fieldname1, id)
Помимо этой таблицы есть 5 похожих, с аналогичным ключом сортировки. К ним идет много динамичных select-запросов
Как вы думаете, проблема в первой таблице или во всех 6?
Правильно ли я понимаю, что замена ключа на (timestamp, id) решит проблему?
Всплывает ошибка «too many open files»
Судя по логам, это связано с таблицей, в которой 120млн записей. Её ключ сортировки: ORDER BY (timestamp, fieldname1, fieldname1, fieldname1, id)
Помимо этой таблицы есть 5 похожих, с аналогичным ключом сортировки. К ним идет много динамичных select-запросов
Как вы думаете, проблема в первой таблице или во всех 6?
Правильно ли я понимаю, что замена ключа на (timestamp, id) решит проблему?
DC
ситуация следующая:
Всплывает ошибка «too many open files»
Судя по логам, это связано с таблицей, в которой 120млн записей. Её ключ сортировки: ORDER BY (timestamp, fieldname1, fieldname1, fieldname1, id)
Помимо этой таблицы есть 5 похожих, с аналогичным ключом сортировки. К ним идет много динамичных select-запросов
Как вы думаете, проблема в первой таблице или во всех 6?
Правильно ли я понимаю, что замена ключа на (timestamp, id) решит проблему?
Всплывает ошибка «too many open files»
Судя по логам, это связано с таблицей, в которой 120млн записей. Её ключ сортировки: ORDER BY (timestamp, fieldname1, fieldname1, fieldname1, id)
Помимо этой таблицы есть 5 похожих, с аналогичным ключом сортировки. К ним идет много динамичных select-запросов
Как вы думаете, проблема в первой таблице или во всех 6?
Правильно ли я понимаю, что замена ключа на (timestamp, id) решит проблему?
вы вообще все неправильно поняли. too many open files не из-за этого.
на каком запросе у вас too many open files ?
на каком запросе у вас too many open files ?
YA
сделать запрос сразу для всех пользователей, все зависит от того в каком виде вам нужно выгрузить данные
Для всех пользователей очень дорого, потому что по факту где то 2/3 пользователей будет отфильтровано. Каких пользователей брать берется из другой БД (postgres)
DT
Для всех пользователей очень дорого, потому что по факту где то 2/3 пользователей будет отфильтровано. Каких пользователей брать берется из другой БД (postgres)
сколько у вас пользователей, можете подключить postgresql как словарь и так отфильтровать
DC
Для всех пользователей очень дорого, потому что по факту где то 2/3 пользователей будет отфильтровано. Каких пользователей брать берется из другой БД (postgres)
и еще вы можете этот список положить в engine=Set / memory или в external data
YA
пользователей около 6 млн
DC
пользователей около 6 млн
для where in это не проблема, там хеш
YA
и еще вы можете этот список положить в engine=Set / memory или в external data
кстати, спасибо, я об этом тоже думал. Только вопрос в том, что их количество растет каждый день на 0,5-1%
YA
для where in это не проблема, там хеш
простите, всех пользователей в where in?