да точно tuple(Array(tuple(IPV6))) так сразу в PG и заработает 🙂

всем привет, есть ли нормальные практики как лучше заливать в в clickhouse данные, через очереди или … как лучше это делать? Суть в том, что я агрегирую данные для аналитики с MYSQL по крону раз в X минут,  и пушу их на ClickHouse просто прям в порт ClickHouse. Не  так давно поймал проблему, что записи дублировались, ну заходили по две, ранее такого не было, по сути ошибка больше в логике. И задался вопросом о каких то нормальных практиках решения задач как у меня.
Спасибо!

ещё можно сделать replicatedMT и тогда если вставляющая логика всегда батчит одинаково, повторные инсерты не будут иметь эффекта

Коллеги, крайне дилетантский вопрос, у меня есть опыт с vertica и условно ожидаю того же от ch. В vertica если ноду ввели в кластер она автоматически получает настройки пользователей, квоый и естественно часть данных. А как это выглядит в ch? Есть replicated таблицы, а если ли полная кластеризация, чтоб скажем системные таблицы и данные отреплицировать с каким-то фактором репликации? Или надо на все делать replicated таблицы?

Коллеги, крайне дилетантский вопрос, у меня есть опыт с vertica и условно ожидаю того же от ch. В vertica если ноду ввели в кластер она автоматически получает настройки пользователей, квоый и естественно часть данных. А как это выглядит в ch? Есть replicated таблицы, а если ли полная кластеризация, чтоб скажем системные таблицы и данные отреплицировать с каким-то фактором репликации? Или надо на все делать replicated таблицы?

На старте мобильного приложения  нет доступа к некоторым параметрам(например - не проинициализированы некоторые SDK). Ждать полной инициализации мы не можем себе позволить, т.к. речь идет про первые секунды запуска и эти данные очень важны особенно когда мы выясняем причины не загрузок. Конечно с помощью подзапросов можно решить эту ситуацию, но не во всех вариантах получается хорошая производительность.  
Совсем частный случай - на старте приложения не доступен рекламный идентификатор пользователя, который у нас используется как primary key. Мы также генерируем свой идентификатор и по нему мы можем соотнести из будущих данных и дополнить. Использовать же свой идентификатор в  качестве primary key совсем не оптимально, т.к. все другие источники данных с которыми выполняются join дают только рекламный идентификатор и неплохо иметь именно его в качестве primary key.
Варианты решения конечно есть разной степени не удобства, поэтому интересовался возможностью просто выполнить update

Коллеги, крайне дилетантский вопрос, у меня есть опыт с vertica и условно ожидаю того же от ch. В vertica если ноду ввели в кластер она автоматически получает настройки пользователей, квоый и естественно часть данных. А как это выглядит в ch? Есть replicated таблицы, а если ли полная кластеризация, чтоб скажем системные таблицы и данные отреплицировать с каким-то фактором репликации? Или надо на все делать replicated таблицы?