11238
Обсуждаем ClickHouse
Чем лучше? Тоже самое и будет, только геммороя больше
Читать полностью…
1. Важно не злоупотреблять DELETE/UPDATE. Запускайте их батчами и нечасто. IN PARTITION - это правильно. Вот специально для того что вы спрашиваете и придумали.
2. Пора уже заканчивать с извращениями типа ALTER UPDATE/DELETE и переползать на PATCH UPDATE/DELETE
В данный момент update, но, если правильно помню, delete так же себя ведёт.
Читать полностью…
а это у вас alter table update или alter table delete?
Читать полностью…
Казалось бы, поменять местами действия - проверку и клонирование - и вот. Но чужую работу оценивать легко, да. Буду ждать. Спасибо.
Читать полностью…
in partition достаточно удобно. Просто странно, зачем и почему кликхаус пытается резервировать место под парты, которые гарантированно не содержат нужных данных.
Читать полностью…
ну в общем ваше дело, просто выбрать из пяти плохих опций, минимально плохую
* макс. размер куска был например 30ГБ
* mdraid
* s3
* не делать мутации
* использовать in partition (найдя нужные партиции)
s3 (150-200Mb/s) - это время выполнения запроса "никогда". К старым данным бывают обращения.
То, что можно - на s3 копируется и дропается.
на тестах чего? мои кадры просто смотрят как "на тестах кх рвёт в пг в чистую", и у них формируется в голове картина, что это такой современный быстрый пг.
потом с удивлением узнают, что транзакций нет, атомарности нет, гарантий нет. потом выясняется, что если дёргать из клика по десять строк много много раз в секунду, то он работает медленнее чем постгрес. очередь с задачками на кликхаусе у них тоже как-то почему-то не очень летит.
ну и конечно надо тупо mdraid делать на все диски, вместо использования кх disks
Читать полностью…
Ну, само - не появится(у нас много дисков по 16 Тб), приходится или держать запас на каждом по х2 от самого жирного куска, или гонять их по дискам туда-сюда.
Читать полностью…
это ожидаемое поведение, не надо с этим бороться, место появится со временем, и ретраи успешно завершатся
Читать полностью…
Есть табличка на merge tree, partition by toYYYYMM(timestamp).
Если применять к ней ALTER TABLE ... WHERE toYYYYMM(timestamp) = <конкретный месяц>, тем не менее создаётся мутация для каждой партиции за всю историю.
Те, в которых нет нужного таймстемпа, пролетают быстро, но выделение места при этом обязательно должно произойти. Если на диске нет нужного резерва - оно ретраится с ошибкой.
Вопрос: можно с этим бороться чем-то, кроме IN PARTITION? В партах с другим toYYYYMM(timestap) ведь никогда не может быть данных с неправильным месяцем.
Потому что даже в пг в связи все равно не смогут. Акхем
Читать полностью…
если речь про партицию, то не лучше ли взять ее целиком в другую таблицу, изменить, а потом присоединить обратно?
Читать полностью…
да, но для delete можно по логике заюзать soft delete, а потом просто в момент, когда вы точно знаете, что резерв дисков есть, запускать apply deleted mask
Читать полностью…
объясните им один раз разницу между oltp и olap, сэкономите себе и им кучу времени и списки обманутых ожиданий в будущем )
Читать полностью…
так в том то и проблема, что клонирование безусловно обязательный шаг, даже если менять парт не надо, и мы знаем заранее что менять не надо.
т.е. скорее можно резервировать место как-то более умнее, лениво, и возможно ронять мутацию текущего парта, потому что места на самом деле нет (оно закончилось на ходу из-за того что идет мутация другого парта).
но тут тоже проблема, начались 10 тяжелых мутаций, дошли до середины, все упали.
а он не знает заранее, что там не нужных данных, так мутации устроены, и по другому не сделать для просто mergetree таблиц (точнее можно сделать, но алгоритм слишком сложен, и там pr уже 3 года не могут доделать)
Мутируют все парты, резервируется место, парт клонируется используя хардлинки, мутация начинает проверять какие файлы надо поменять, меняет если надо, присоединяет новый парт, убирает старый парт.
Я в курсе, спасибо. Пойнт не в том что кто-то из них плох или хорош, а в том что для каждого дела свой инструмент.
Читать полностью…
А вы не путайте тесты с эксплуатацией) на самом деле в пг тоже есть специфика, всякие статистики, вакумы. Надо просто пожить с этим👍
Читать полностью…
а не проще s3 использовать для старых партиций если у вас aws?
Читать полностью…
Из mdraid выкидывать диски при освобождении не очень удобно. И для aws ebs кажется избыточным.
Читать полностью…
ну поставьте тогда чтобы макс. размер куска был например 30ГБ
Читать полностью…
и IN PARTITION кстати работает только для replicated таблиц
Читать полностью…
А если без toYYYYMM, просто timestap>=дата and timestap<дата
Читать полностью…