between last и last - 24h ?

ребят привет, подскажите, как выбрать за последний доступный день? если выбрать event_date=today(), а данных не было пару дней, то я их не увижу. Хочется выбрать за последний доступный день, такое возможно?

сам себе отвечу. выборку делаем через туже выборку, но с лимитом в еденицу: select * from base where event_date = (select event_date from base where ... ORDER BY event_time DESC limit 1) ORDER BY event_time DESC

between last и last - 24h ?

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

изменил сообщение, забыл сортировку по времени

в мануале не нашел конструкции готовой для выборки последнего доступного дня

походу про ласт это я вообще с потолка ) извиняюсь

бывает)) не страшно, хоть кто-то ответил, уже приятно))))

max походу а не last

нет под рукой консоли чтобы проверить что скажет select max(event_date)

потому что мне кажется что вот эту конструкцию select event_date from base where ... ORDER BY event_time DESC limit 1 как раз и можно поменять на max()

сделал зеркало документации http://clickhouse.xyz

кому лень открывать впн и прокси)

А что случилось с http://clickhouse.yandex ?

потому что мне кажется что вот эту конструкцию select event_date from base where ... ORDER BY event_time DESC limit 1 как раз и можно поменять на max()

ООО, спасибо, щас проверю!

Не подумал я чтото про эту функцию, а ещё математик называется)))))

ООО, спасибо, щас проверю!

не подходит, функция аггрегирующая, необхоимо группировка, немного не то, что требуется)

SELECT * FROM base WHERE ... AND event_date = (select max(event_date) from base where ... )

хотя так выглядит изящнее

А что случилось с http://clickhouse.yandex ?

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

А... Тады github в помощь, там тоже есть.

А... Тады github в помощь, там тоже есть.

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

С подключением ODBC источников может быть много особенностей. Чтобы не ломалось, можно добавить больше конфигураций в интеграционные тесты. У нас уже есть интеграционный тест с подключением Postgres-а, но получается, что он не покрывает ваш случай. Сможете описать конфигурацию (хоть текстом), чтобы мы воспроизвели неработающее подключение у себя?

https://github.com/yandex/ClickHouse/issues/3360 что то еще нужно добавить?

можно закинуть pr со ссылкой вот сюда: https://github.com/yandex/ClickHouse/blob/master/docs/en/interfaces/third-party_client_libraries.md

можно закинуть pr со ссылкой вот сюда: https://github.com/yandex/ClickHouse/blob/master/docs/en/interfaces/third-party_client_libraries.md

Спасибо за совет - отправил proposal

Причем здесь это вообще? Какая разница, человек школьник или ему по работе нужно? Зачем давать плохие советы?

Поддерживаю.

да-да, не промоушен, а случайность)

подскажите, можно ли в уже созданную таблицу добавить SAMPLE BY ?

НЕТ

@kshvakov Кирилл добрый день ! В продолжении нашего вчерашнего вечернего разговора, хотел уточнить. У меня есть конфигурация в API: [clickhouse]host(s)=10.10.10.83:9000, 10.10.10.88:9000, database=testdb, username=admin [clickhouse][dial] secure=false, skip_verify=true, strategy=random, ident=1, server=0 -> 10.10.10.83:9000 [clickhouse][connect=1][hello] -> Golang SQLDriver 1.1.54213 [clickhouse][connect=1][hello] <- ClickHouse 18.10.54405 (UTC)

Когда приложения обращается к ClickHouse

оно всегда обращается на первую ноду

на вторую ноду ни разу не обратилось за 5 запросов

строка подключения такая: click_house_conn = "tcp://10.10.10.83:9000?username=admin&password=password&debug=true&database=testdb&alt_hosts=10.10.10.88:9000"

Почему не ходит на вторую ноду ?

То что запросы всегда уходят на первую ноду проверил через tcpdump

Такое ощущение что по умолчание не random используется, а in_order

сервер на котором расположено API телнетит обе ноды

Если мне не измеяет память, alt_hosts - отрабатывает, если первая нода перестала отвечать, чтобы устроить load balance нужен - балансер. прим chproxy

in_order - это про другое

это настройка проксирования запросов от distr_table в реплики одного и того же шарда

Вчера @kshvakov писал что Драйвер сам умеет балансировать. Можно покрутить таймауты, но ситуация интересная, такое бывает, надо смотреть что у вас с сеткой.

я имею ввиду что он написал что драйвер сам умеет балансировать

я имею ввиду что он написал что драйвер сам умеет балансировать

хмм, ок, даже не думали об этом.

может балансировка работает при параллельных запросах? а при последовательных - нет? мы никогда не наблюдали балансировку в этом драйвере, но у нас все запросы идут последовательно - батчами.

Почему не ходит на вторую ноду ?

На вторую пойдет в новом подключении - это либо параллельные запросы, либо если время жизни соединения закончилось (откроется второе к новой ноде)

in_order - это про другое

in_order - подключаться к первой рабочей из списка

Каждый раз какой бы тип балансировик не указывал в этой строке [clickhouse][dial] secure=false, skip_verify=true, strategy=random, ident=1, server=0 -> 10.10.10.88:9000 стратегия всегда рандом

даже когда ставлю in_order

strategy=random - это тип балансировки ?

strategy=random - это тип балансировки ?

Да, только параметр называется connection_open_strategy

интересно почему независимо от того, что я прописываю, random или in_order всегда отображается рандом

может я не правильно указываю ?

интересно почему независимо от того, что я прописываю, random или in_order всегда отображается рандом

Сейчас посмотрю

&alt_hosts=10.10.10.88:9000&balancing=in_order"

&alt_hosts=10.10.10.88:9000&balancing=in_order"

connection_open_strategy=in_order

Вот оно что, попробую сейчас спасибо !

Товарищи, а как канонично вкатывать обновления схемы (добавление колонок) в ReplicatedMT ?

Distributed на них отсутствует

выкатываешь альетр тейбл адд колумн он кластер

потом удаляешь и создаешь снова дистрибьютед таблицу

@kshvakov Пуляю запросы через Postman в API, оно всегда кидает на первую ноду Не зависимо от того, стоит random или in_order. Пробовал ждать 2 минуты между пулянием запроса в API. Складывается такое ощущение что хоть и указана стратегия рандом, оно всегда работает как in_order. Только после выключение первой ноды, запросы пошли на вторую

выкатываешь альетр тейбл адд колумн он кластер

Так нет же ни кластера, ни distributed

ну а как без кластера может быть репликейтед ?

Так не нужен же кластер для реплики

Только ЗК

@kshvakov может в нашей версии драйвера (Golang SQLDriver 1.1.54213) некорректное поведение балансировщика ?

Так не нужен же кластер для реплики

ну делайте руками тогда добавление колонки на каждом

@kshvakov может в нашей версии драйвера (Golang SQLDriver 1.1.54213) некорректное поведение балансировщика ?

Оно с самого начала не менялось, только in_order для CF добавилось

ну делайте руками тогда добавление колонки на каждом

А что в этот момент будет с репликацией ?

Попробую

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

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

Вот у меня как раз нет уверенности что все именно так и произойдет

А что в этот момент будет с репликацией ?

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

Т.е на реплике повторять этот запрос не нужно ?

@kshvakov после выключения первой ноды, я ее включил, но запросы все идут все равно на вторую ноду. Вызвал паралельно выполнение нескольких запросов, все равно все выполняется только на второй ноде теперь.

Т.е на реплике повторять этот запрос не нужно ?

нет

нет

спасибо

@kshvakov после выключения первой ноды, я ее включил, но запросы все идут все равно на вторую ноду. Вызвал паралельно выполнение нескольких запросов, все равно все выполняется только на второй ноде теперь.

так у вас открыто соединение только к одной ноде

закройте и откройте соединение и будут разные ноды

@kshvakov после выключения первой ноды, я ее включил, но запросы все идут все равно на вторую ноду. Вызвал паралельно выполнение нескольких запросов, все равно все выполняется только на второй ноде теперь.

Вы постманом вряд ли сможете запросы паралельные сделать

У меня для тестов есть два запроса, один запрос выполняется 10 секунд, другой 1 секунду. Я сначала вызываю выполнение 10 секундного запроса, а потом 5 раз выполняю запрос который выполняет по 1 секунде

Все я понял

спасибо

наши разработчики сказали что они держат открытым соединение после выполнения запроса

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

А это зачем ?

так если 2 реплики, не логичнее ли пул из 2 соединений держать?

а прерывать - какой смысл? на другую ноду перейти?

Я думаю смысла прерывать нет

2 ноды только на одном стейджинге

есть где 4 ноды

наши разработчики сказали что они держат открытым соединение после выполнения запроса

Что они там делают? Соединение открыто всегда если только не указано SetConnMaxLifetime (его стоит указать, тогда оно будет "незаметно" переоткрыто)