Size: a a a

ClickHouse не тормозит

2020 August 04

АА

Алексей Артамонов... in ClickHouse не тормозит
Народ, а кто может подсказать как отключить sasl
источник

D

Denis in ClickHouse не тормозит
да, раз в день выгрузка всех существующих доменов (для доменной зоны)

каждый день соответственно нужно её парсить заново, обновляя то что изменилось
источник

АА

Алексей Артамонов... in ClickHouse не тормозит
в ЗК сделал getAcl /clickhouse а там sasl и джайдест, по этой причине КХ не может законнектится к ЗК
источник

pk

papa karlo in ClickHouse не тормозит
Denis
да, раз в день выгрузка всех существующих доменов (для доменной зоны)

каждый день соответственно нужно её парсить заново, обновляя то что изменилось
и вы хотите этой выгрузке сделать full outer join на предыдущее состояние, чтобы нагенерить дифф, и потом с одной стороны иметь такие диффы, с другой стороны еще и состояние (актуальное?) всех доменов, и при этом чтобы размер базы не рос на 60Гб в день?
источник

D

Denis in ClickHouse не тормозит
не столько даже диффы хранить хочется, сколько знать когда какой домен добавлен/удален/обновлен (его NS обновлены), но вообще получается - да, что-то вроде.
Нужно актуальное состояние на текущий день, чтоб я мог потом получить все измененные домены сегодня или все домены, которым поствлены какие-то NSы, или количество доменов, которые были удалены вчера (например).
И да, не хочется чтоб через месяц база превратилась 1.8ТБ )
источник

D

Denis in ClickHouse не тормозит
может мой кейс неподходящий для CH, вы скажите если что )
источник

pk

papa karlo in ClickHouse не тормозит
тут вопрос не в кейсе, а как организовать нормально. можно заливать в базу каждый день полный дамп (сколько это занимает времени?), потом оставлять его как актуальное состояние, считать дифф с предыдущим днем, диффы откладывать в еще одну табличку с датой в ключе. возможно залить первый дамп в диффы в виде добавлений, чтобы он тоже был,
это уже будет содержать примерно все нужные данные, и расти только на дифф. full outer join для диффа возможно работать не будет, тогда надо будет что-то изобретать, например посемплировать по хешу.
источник

D

Denis in ClickHouse не тормозит
сколько это может занимать времени для КХ - я не представляю, в pgsql это сейчас льётся больше суток )))

а на третий день как быть, диффать предыдущим днем, а то что было до этого - дропать? Но тогда у меня будет разница только между вчерашним и сегодняшним днем, а хочется чтоб можно было потом получить все домены за дату Х, которая была в прошлом (например, какой-то регистратор понизил цену на регистрацию доменов в период с Z по Y, я потом хочу проанализировать на сколько в эти дни больше доменов было зарегистрировано чем в обычное время)
источник

pk

papa karlo in ClickHouse не тормозит
изменения между днями надо сохранять.
источник

D

Denis in ClickHouse не тормозит
то есть условно нужно что-то вроде: каждый день вливаем все данные в таблицу А, получаем как-то через КХ разницу с таблицей Б, сохраняем это в таблицу В; дропаем А, Б и переименовываем В в таблицу Б?
источник

D

Denis in ClickHouse не тормозит
единственное что непонятно как разницу делать, там ведь в выгрузке дат нету, там только домен = [неймсервер1, ..., неймсерверN], а даты я сам генерировал получается (когда добавли домен проставлял = created_at, обновили - updated_at, удалили - deleted_at)
источник

pk

papa karlo in ClickHouse не тормозит
да, даты есть только в те моменты когда мы скачали дамп и наблюдали состояние.
источник

D

Denis in ClickHouse не тормозит
а как это всё организовать в терминологии кликхауса, чтоб я дальше пошёл раскуривать доку?
источник

D

Denis in ClickHouse не тормозит
если, конечно, это нормальный кейс мы описали и не стоит пробовать как-то по-другому через указанный выше ReplacingMergeTree)
источник

pk

papa karlo in ClickHouse не тормозит
replacing не факт, что подойдет для удаления того что надо удалить, во-первых потому что я не уверен что там можно что-то удалить (ладно, для этого у нас есть deleted_at), во-вторых, как понимать что в базе есть что-то, чего уже нет в новом дампе и потому это надо удалить.
также наверное стоит подумать над вопросом как из удаленного стать обратно не удаленным, насколько я понимаю, это не конечное состояние.
источник

D

Denis in ClickHouse не тормозит
да, тоже верное замечание - такое тоже каждый день происходит - сейчас я сбрасываю deleted_at снова в null и ставлю created_at текущим днем
источник

D

Denis in ClickHouse не тормозит
то есть саму строку я не удаляю никогда
источник

D

Denis in ClickHouse не тормозит
к слову, уже много различных онлайн-сервисов решали похожую задачу ( например, https://domainlists.io/gtld-domains/ ), но я нигде не смог найти чтоб они рассказывали как это делается 🙁
источник

D

Denis in ClickHouse не тормозит
> во-вторых, как понимать что в базе есть что-то, чего уже нет в новом дампе и потому это надо удалить.

да, к слову ещё стоит сказать, что сейчас "удаление" (простановка deleted_at) организована таким образом что перед обработкой последующей буквы домена - я беру все домены из её партиции и складываю в Redis, после того как текущая буква пропарсилась - в редисе остаются домены, это значит что они не были в текущем дампе, а значит они удалены из выгрузки
источник

D

Dj in ClickHouse не тормозит
Сохраняйте не меняя старые записи, не вижу проблемы если честно...
источник