DC
Подскажите пожалуйста - есть ли какая-то возможность повлиять на то в каком порядке кликхаус читает данные с диска(порядок чтения партиций)?
Проблема в чем, есть запрос:
Именно в таком варианте оно работает, но нет понимания есть ли гарантия повторяемости результатов - any join при параллельном чтении выдает результаты того потока который первее нашел пару для правой части, верно?
Нужно получить гарантированное поведение данного запроса, а именно - чтоб к каждому элементу малого множества клеялась либо самая старая запись(самая старая партиция) либо самая новая. Хотя бы какой-то один из этих вариантов.
Добавляя какую-либо сортировку в very_big_query - сразу вылетаем по памяти( (здесь кстати не понятно почему - если сортируем по ключу партиционирования - все равно вылетает - хотя казалось бы выдавай партици по очереди и ок).
Срезав кол-во потоков через max_threads=1 можно убрать параллелизм и судя по логам вроде как чтение идет в один поток и в порядке партиций от меньшей к большей. Т.е. выглядит как подходящий вариант, но нигде не могу найти подтверждения этой теории - гарантирован ли в данном варианте повтор результата на одних и тех же данных, может кто-нибудь подсказать?
Ну и может есть рычаг заставить читать партиции в обратном порядке? тогда при условии того что предыдущий абзац верный - можно было бы получить вариант _join с самым свежим_.
Проблема в чем, есть запрос:
insert select * from <very_big_table> any inner join <medium_table> using id
Именно в таком варианте оно работает, но нет понимания есть ли гарантия повторяемости результатов - any join при параллельном чтении выдает результаты того потока который первее нашел пару для правой части, верно?
Нужно получить гарантированное поведение данного запроса, а именно - чтоб к каждому элементу малого множества клеялась либо самая старая запись(самая старая партиция) либо самая новая. Хотя бы какой-то один из этих вариантов.
Добавляя какую-либо сортировку в very_big_query - сразу вылетаем по памяти( (здесь кстати не понятно почему - если сортируем по ключу партиционирования - все равно вылетает - хотя казалось бы выдавай партици по очереди и ок).
Срезав кол-во потоков через max_threads=1 можно убрать параллелизм и судя по логам вроде как чтение идет в один поток и в порядке партиций от меньшей к большей. Т.е. выглядит как подходящий вариант, но нигде не могу найти подтверждения этой теории - гарантирован ли в данном варианте повтор результата на одних и тех же данных, может кто-нибудь подсказать?
Ну и может есть рычаг заставить читать партиции в обратном порядке? тогда при условии того что предыдущий абзац верный - можно было бы получить вариант _join с самым свежим_.
У вас any join и левую таблицу обрабатывает distinct. Надо либо включить настройку any_join_distinct_right_table_keys
либо использовать semi join
либо использовать semi join