1. Это ведь речь именно про таблицу (та таблица, по

Question

1. Это ведь речь именно про таблицу (та таблица, по

которой делается подзапрос, если есть)?

3. Т.е. слева должна быть таблица, которую фильтруем, а справа ANY INNER JOIN - таблица с фильтрацией (как у меня в данном случае - с группировкой и max() )? Не получилось. Всё равно Memory limit. Видимо, из-за того, что я не знаю, насколько мне лимитировать левую, фильтруемую таблицу (для правой-то известно).

Т.е. получается в моём случае (фильтрация по той же таблице) мне проще убрать JOIN и дедуплицировать на клиенте данные, полученные из простого запроса ценой небольшой некрасивости для данных, которые затрагивают недавние порции)?

#backend #clickhouse #database #devops #programming #russian

0

13.01.2020

1 ответов

18 просмотров

Artem Zuikov · Accepted Answer

1. речь про таблицу или сабселект который join-им. таблица (или сабселект) слева от join стримится, справа - помещается в память. Обычно нужно следить только за правыми таблицами в join 3. я слегка про другой кейс, не уверен, что можно адаптировать его к вашей задаче. если мы хотим джойнить какую-то таблицу на уникальные значения в ReplacingMergeTree нам достаточно ANY JOIN без догруппировки или final. по задаче - не готов сказать как лучше. Если есть возможность разделить старые (точно уникальные) и новые (потенциально перетирающие старые) данные - можно попробовать вытянуть незатертые данные по ANTI JOIN старых и новых (выдаст старые, точно отсутствующие в новых), а потом объединить их с новыми через UNION ALL. Новых должно быть мало - должны влезать в память. Новые при этом селектить с final Под разделить имеется в виду например, что есть дата до которой точно сделан optimize на таблицу и там данные домержились, а все новые данные вставлены с датами новее

184 похожих чатов

1. Это ведь речь именно про таблицу (та таблица, по

1 ответов

Похожие вопросы