по дефолту там 9009

Спасибо?

Ну можно живой пример чтоб они этим хвастались?)

у меня были проекты на аэроспайке, вполне хорошее решение если внимательно читать доки ) многие проблемы фиксят так что обновляться стоит часто.

Я уже выше спрашивал - расскажите - как кладёте в КХ стату? на митапе даже вопрос озвучили)

Способ немного топорный, приходит запрос в php - там его раскладываем и кладем в list в redis, раз в 5 минут сливаем в КХ. Получаются пачки по 50-200к

https://github.com/yandex/ClickHouse/commit/5cf6f4d8c13005a12f6aed2285389b6f7a7a69e6

Спасибо! Будем ждать в stable.

Вопрос к разработчикам: В конфиге прописал interserver_http_host

SELECT hostName() ┌─hostName()─┐ │ CH-2-1 │ └────────────┘

хотя, как говорит комент к параметру конфига, то, он как раз таки и влияет на вывод функции hostName()

вывод которой используется при репликации

Доброе утро. Подскажите как лучше перелить данные из одного кластера в другой? Я думал из консоли через трубу две каманды select и insert Используя clickhouse-client

как раз этим и занимаюсь, только не с кластера в кластер, а с сингл инстанса в кластер

я прописал конфиг кластера на сингле

на сингле создал дистрибьютед таблицу

и через insert select переливаю данные из локальной таблицы в distributed

спасбо.

и через insert select переливаю данные из локальной таблицы в distributed

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

Привет! как эфективно хранить ipv6 адреса, если трафика от них почти нет?

FixedString(16) чем плохо? Пропуски должны хорошо пожаться, я думаю.

не знаю, может чем-то он плох...

FixedString(16) чем плохо? Пропуски должны хорошо пожаться, я думаю.

я не спец по CH - но даже в PostgreSQL хранить IP как строки плохая практика, если есть специальный бинарный формат а в CH я прямо уверен он есть

Хранить, конечно, надо в таких строках в бинарном виде, есть для этого специальные функции: https://clickhouse.yandex/reference_en.html#IPv6NumToString(x)

а может под это дело сделать бинартый тип данных? а не хранить это все в строке

Если для таблицы зада индекс EventDate, Timestamp, Country то запрос select * from table WHERE EventDate=toDate('2017-01-01') AND Country=RU будет использовать учитывать что данные уже упорядочены как надо? Или надо обязательно все поля индекса перечислять, даже если там любое значение подходит, например: WHERE EventDate()=toDate('2017-01-01') AND TimeStamp BETWEEN toDateTime('2017-01-01 00:00:00') AND toDateTime('2017-01-01 23:59:59') AND Country = 'RU'

Timestamp - это то же что EventDate, только с точностью до секунд, т.е. упорядоченность хронологическая.

А есть ли планы обновить юзера с metrika на clickhouse для Docker образов?

https://hub.docker.com/r/yandex/clickhouse-server/~/dockerfile/ <-- а-то вот тут до сих пор USER metrika

Если те же данные в том же порядке, то сработает. Для последних 100 кусков.

подскажите а об этом в документации говорится что бы почитать поподробнее?

подскажите а об этом в документации говорится что бы почитать поподробнее?

https://clickhouse.yandex/reference_ru.html#%D0%A0%D0%B5%D0%BF%D0%BB%D0%B8%D0%BA%D0%B0%D1%86%D0%B8%D1%8F%20%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85

Блоки данных дедуплицируются. При многократной записи одного и того же блока данных (блоков данных одинакового размера, содержащих одни и те же строчки в одном и том же порядке), блок будет записан только один раз. Это сделано для того, чтобы в случае сбоя в сети, когда клиентское приложение не может понять, были ли данные записаны в БД, можно было просто повторить запрос INSERT. При этом не имеет значения, на какую реплику будут отправлены INSERT-ы с одинаковыми данными. То есть, обеспечивается идемпотентность INSERT-ов. Это работает только для последних 100 вставленных в таблицу блоков.

я прошу прощения, а что понимать под блоком?

в доке, вроде написано что это такое. спасибо

хотя, как говорит комент к параметру конфига, то, он как раз таки и влияет на вывод функции hostName()

Этот параметр не влияет на вывод функции hostName() в кликхаусе. И наоборот, вывод этой функции не влияет на репликацию. В комменте там говорится, что если interserver_http_host не указать, то его дефолтное значение будет как вывод шелловской команды hostname -f

Товарищи, задача по типу фильтрации товаров на Яндекс Маркете.. Есть база около 1 млн товаров электротехнической продукции, там у каждого товара несколько десятков параметров. Как и на маркете это да/нет, диапазоны значений (вес, длина, допустимые токи и т.д.), перечисления по типу разрешения экранов мониторов.. Хотелось бы имеет возможность добавить все эти свойств в колонки и как можно быстрее делать фильтрацию этих товаров по свойствам.. Вобщем как на маркете. Изменять данные не нужно.. Добавляются один раз. Насколько я понимаю CH должен хорошо подходить под эту задачу? Волнует тот факт что нету null и не очень понятно как задать отсутствие определённого свойства у объекта. Прошу подтвердить или опровергнуть мои мысли)

Колонок вот только может получится несколько сотен возможно.. И тупые запросы в которых много where с and or и сортировка

Подойдет

>Волнует тот факт что нету null и не очень понятно как задать отсутствие определённого свойства у объекта. Сделать поле Int8 с тремя значениями

Понятно, спасибо! Попробую.. Эксперимент провести вроде бы должно быть легко!)

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

>Волнует тот факт что нету null и не очень понятно как задать отсутствие определённого свойства у объекта. Сделать поле Int8 с тремя значениями

вроде как они уже есть

вчера на митапе говорили

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

Ну ладно, нормально будет работать, просто не так быстро как для аналитики. Тем более если нужно много отфильтровать и мало показать PREWHERE поможет

вчера на митапе говорили

В любом случае если можно обойтись без null - лучше обходиться

null тоже не бесплатно

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

Достаточно лишь одного select id where и куча or and А дальше из key-value хранилища быстро можно получить сам товар со всеми свойствами

не поспоришь

для хранения bool все равно используется int8 или uint8 (1 байт), так что отсутсвующее значение можно легко добавить

Алексей говорил что null реализованы не доконца. лучше не использовать, хоть они и есть

и это тоже

с ними ещё бывают проблемы

Да, согласен.. Можно обойтись и без null. Но с ними как-то удобнее))

У нас есть больше сотни таблиц и везде мы обходимся без null

Хороший индикатор того, что можно не опасаясь использовать null-ы - когда они появятся в документации ;)

Спасибо за консультацию, будем пробовать!)

А сейчас там много неочевидного поведения, да и просто багов

как-то странно, на кластере выполняю запрос в distributed таблицу - запрос выполняется секунды 3, вижу только один прогрессбар, а не несколько

это нормально?

думаю да . у меня также версия CH 1.1.54164.

Вопрос по поводу наследования профилей https://clickhouse.yandex/reference_ru.html#%D0%9F%D1%80%D0%BE%D1%84%D0%B8%D0%BB%D0%B8%20%D0%BD%D0%B0%D1%81%D1%82%D1%80%D0%BE%D0%B5%D0%BA сказано, что могут наследоваться друг другом. Может ли один профиль наследовать настройки из нескольких других?

как-то странно, на кластере выполняю запрос в distributed таблицу - запрос выполняется секунды 3, вижу только один прогрессбар, а не несколько

А почему их должно быть несколько?

Когда впервые видел демо работы КХ на ютубе, там было несколько.

Нажимайте периодически на ENTER, будут появлятся новые прогрессбары (собственно, сам прогресс). Скорее всего вы видели именно это

Нажимайте периодически на ENTER, будут появлятся новые прогрессбары (собственно, сам прогресс). Скорее всего вы видели именно это

пересмотрел видео, походу так и было ? вопрос снят

Привет! как эфективно хранить ipv6 адреса, если трафика от них почти нет?

Да, FixedString(16). Причём можно сделать два столбца - один - только для IPv4 типа UInt32 (в случае IPv6 заполняется нулём), а другой - FixedString(16) - и для IPv4 и для IPv6. Если для отчёта нужен только IPv4, то использование столбца типа UInt32 будет эффективнее. Впрочем, это уже усложнение.

Ребята, а если большую ReplicatedMergeTree таблицу джойнить саму на себя с фильтрацией - нормальный кейс для КХ?

Товарищи, а КХ-клиент под винду не собирали?

Товарищи, а КХ-клиент под винду не собирали?

Какой именно?

Который консольный, красивый

Нет. И он не соберётся, так как для этого надо собрать весь КХ.

Понятно, спасибо!

/stat@combot

combot.org/chat/-1001080295593

@milovidov_an Боб Смит: Если для таблицы зада индекс EventDate, Timestamp, Country то запрос select * from table WHERE EventDate=toDate('2017-01-01') AND Country=RU будет использовать учитывать что данные уже упорядочены как надо? Или надо обязательно все поля индекса перечислять, даже если там любое значение подходит, например: WHERE EventDate()=toDate('2017-01-01') AND TimeStamp BETWEEN toDateTime('2017-01-01 00:00:00') AND toDateTime('2017-01-01 23:59:59') AND Country = 'RU' ?

Товарищи, если в КХ данные таблицы хранятся по колонкам, то верно ли что для всех колонок всегда есть уже построенный индекс?

Нет. Индекст есть только по PK

combot.org/chat/-1001080295593

Нет. Индекст есть только по PK

Понятно что по ПК. Тут получается что используется часть ключа. Читал в канале что кликхаус умеет использовать ключи с пропусками, но подробной информации об этом не нашел.

Т.е. сможет ли он использовать ключ эффективно именно в этом сценарии

что значит ключи с пропусками?

хочу странного: возможно ли выполнить detach таблицы и attach, но уже с другим PK?

что значит ключи с пропусками?

Наверно имеется в виду вот что: представим, что у нас дата вообще одинаковая во всех записях. Тогда можно указывать условие на второе поле индекса (пропустив первое), и индекс всё равно будет использоваться.

хочу странного: возможно ли выполнить detach таблицы и attach, но уже с другим PK?

Нет, ибо attach подразумевает что данные уже отсортированы по ключу и менять их не надо

Создать новую таблицу с нужным PR + insert from select - единственный способ?

да

Т.е. сможет ли он использовать ключ эффективно именно в этом сценарии

Индекс не будет использоваться (точнее, будет использоваться только для условия на date), даже если указать условие на timestamp. Скорее всего у вас с одинаковым timestamp совсем немного событий. От сортировки по country в таком случае мало толку, она не позволит отсечь большие диапазоны строк.

Вопрос - поддерживаются ли источник данных Postgres в словарях? MySQL, КХ, executable скрипт, http, файл - вижу есть. А постгрес?

ну либо odbc коннектор.

"или любой ODBC источник."

https://clickhouse.yandex/reference_ru.html#Внешние словари

для посгреса наверняка ODBC есть