@clickhouse_ru

Страница 595 из 723
M
20.07.2018
15:56:29
вродь на старых версиях клика такого не наблюдал...

Alexey
20.07.2018
16:06:42
подскажите почему может появляться ошибка Code: 23, e.displayText() = DB::Exception: Cannot read from istream, e.what() = DB::Exception? Есть шард с двумя репликами. На одной реплике где то 1.5Т данных. На другой реплике данных нет. То есть организовали репликацию. Канал между репликами 10Гбит/с. Я почти уверен, что проблем с железом нет (не наблюдаю не ошибок, ничего). Данные начинают перетикать. В какой то момент трафик вырастает до 8Гбит/с и так это работать может дня два.. толку нуль. На дисках наблюдаю работу как при репликации на других шардах (на двух шардах репликация завершилась успешно в пределах полудня, данных так же 1.5Т). В system.replication_queue вижу очередь с типом GET_PART. Получается данные идут, но крайне мелкими порциями… Есть идеи?
Посмотрите https://github.com/yandex/ClickHouse/blob/master/CHANGELOG_RU.md#%D0%98%D1%81%D0%BF%D1%80%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5-%D0%BE%D1%88%D0%B8%D0%B1%D0%BE%D0%BA - первая ошибка - наверное как раз этот случай.

Denis
20.07.2018
16:42:12
Добрый день. Клик 1.1.54394. Делаю insert select без группировок, сортировки. только выборка по условию день + поле в ключе. Выборка и вставка в distributed таблицу. Лимит по памяти стоит 40 гб ( настройки max_memory_usage / max_memory_usage_for_all_queries) На сервере 52 гб Наблюдаю картину - запрос на протяжении выполнения потребляет примерно 4 гб в пике. Смотрю в htop и контролирую free -m (данные совпадают) смотрю в system.processes наблюдаю что peak_memory_usage / memory_usage для процесса вставки ВСЕ ВРЕМЯ растет вверх. и по факту, через некоторое время, запрос падает с ошибкой DB::Exception: Memory limit (for query) exceeded, хотя памяти завалом. Других запросов на сервере не выполняется. distributed_aggregation_memory_efficient выставлен в 0 Подскажите, это в текущей версии неверный подсчет памяти идет? Или потребление памяти считается по другому?
>Лимит по памяти стоит 40 гб ( настройки max_memory_usage / а там точно 40? может опечатка на порядок?

M
20.07.2018
16:44:08
Нет. Проверил несколько раз

Google
Alexey
20.07.2018
16:49:20
вродь на старых версиях клика такого не наблюдал...
Суть проблемы: Вычисляемое ClickHouse потребление памяти при INSERT SELECT больше, чем на самом деле. Мы наблюдали такое поведение в разных версиях ClickHouse. Это объясняется тем, что иногда выделение памяти делается в контексте запроса, а освобождение памяти - в другом контексте. При INSERT SELECT выделяется память для индексов новых вставляемых кусков, а освобождается эта память во время фоновых слияний - вне контекста запроса. Конечно подсчёт памяти на запрос при этом получается ошибочным, и если запрос INSERT SELECT выполняется долго, то накапливается большая разница. В этом случае нормально просто увеличить лимит для одного запроса.

M
20.07.2018
16:51:38
Максим
20.07.2018
17:05:25
Добрый день. Настройки из users.xml считываются на лету. А настройки серверные из config.xml ? тоже на лету?

M
20.07.2018
17:05:26
Ошибки будут на удалённых серверах, куда будет производить вставку Distributed таблица.
Не понимаю почему. Если вставка в дистрибьютед идет локально. В папке с data будут уже кусочки на отправку. Конечный сервер будет только получать данные которые принадлежат ему. И на этом же сервере мерджи будут идти по плану. То есть там не будет запроса. Почему там могут быть ошибки?

Alexey
20.07.2018
17:10:32
Добрый день. Настройки из users.xml считываются на лету. А настройки серверные из config.xml ? тоже на лету?
Большинство настроек из config.xml не применяется налету. Исключение - параметры логгирования и конфигурация кластеров.

Alexey
20.07.2018
17:11:46
спасибо! а когда можно ждать новый релиз?
Сейчас в тестировании. Может быть сегодня или в начале следующей недели.

Максим
20.07.2018
17:26:29
отлично. возвращаясь к предыдущему вопросу - мы можем каким-либо образом из клиента узнать сервеные настройки?

Google
Alexey
20.07.2018
17:30:06
SELECT * FROM system.settings

Konstantin
20.07.2018
19:12:35
Посмотрите https://github.com/yandex/ClickHouse/blob/master/CHANGELOG_RU.md#%D0%98%D1%81%D0%BF%D1%80%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5-%D0%BE%D1%88%D0%B8%D0%B1%D0%BE%D0%BA - первая ошибка - наверное как раз этот случай.
версия ...385. делал optimize двух проблемных партиций. возможно таки были проблемы с сетью, хотя не заметил их. еще забыл сказать что на исходной реплике была версия 385, на конечной 394. хотя на других шардах было точно так же и сработало без проблем. хотя тож были эти ошибки. возможно помогло бы увеличить тайм аут http, как советовали выше. но проверить не успел. склоняюсь к тому что optimize помог.

Saprow
20.07.2018
19:47:04
Задам овертупой вопрос, а в этом году следует ожидать привычной для обывателей вроде меня реализации Delete, Update. Никто не владеет подобной информацией ?

Dmitry
20.07.2018
19:58:01
А есть такие, кто пробовал на основе клика реализовать мессенджер ? =)

Alexey
20.07.2018
19:59:36
А есть такие, кто пробовал на основе клика реализовать мессенджер ? =)
Непосредственно реализовать мессенджер - вряд ли. Анализ данных мессенджера (базы сообщений) - хороший вариант.

Dmitry
20.07.2018
20:01:37
Ну у нас получилось, в целом очень хороший потенциал, правда пока не без косяков, это дело времени

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

Timur
21.07.2018
01:21:59
ALTER TABLE on cluster для distrinbuted не поддерживается?

ALTER TABLE [Distributed table] on cluster [name] ADD COLUMN xx_ms UInt32 DEFAULT 0 AFTER x;

для replicatedmergetree прошло

371 │ An error occured before execution: Code: 371, e.displayText() = DB::Exception: Table [Distributed table name] isn\'t replicated, but shard #2 is replicated according to its cluster definition, e.what() = DB::Exceptio

может быть я не прав что создал distributed таблицы на всех узлах кластера: идея писать в любую из нод а ditributed сама разрулит данные по шардам

Wolf
21.07.2018
02:37:15
ALTER TABLE [Distributed table] on cluster [name] ADD COLUMN xx_ms UInt32 DEFAULT 0 AFTER x;
Не поддерживает изменение колонок, надо удалить и потом создать заново таблицу

Timur
21.07.2018
02:37:40
Сделал alter

На каждой ноде

Отдельно

Wolf
21.07.2018
02:38:30
Ну если кластер небольшой то да

Timur
21.07.2018
02:38:48
Угу

Google
Александр
21.07.2018
12:25:24
бота бы который таких бани

lenar
21.07.2018
13:22:02
есть бот терминатор, даёт вопрос и если за Х мин не ответишь, то банит

Dmitry
21.07.2018
13:23:52
причем вопросы про clickhouse

Daniel
21.07.2018
13:30:23
есть бот терминатор, даёт вопрос и если за Х мин не ответишь, то банит
это бесполезно, многие уже это обходят, например, читают N последних сообщений и отвечают исходя из языка чата что-нибудь типа "добрый вечер"

Dmitry
21.07.2018
13:32:14
бота бы который таких бани
А какую цель они преследуют, но добавились в чат, а дальше

Александр
21.07.2018
13:34:02
А какую цель они преследуют, но добавились в чат, а дальше
Ну мы читаем его рекламу когда он добавился

Maksim
21.07.2018
13:57:09
Казалось бы, ограничить в клиентах количество символов в сообщении о добавлении в группу

1~2 строки и уже не поспамишь

lenar
21.07.2018
18:00:24
тут в некоторых чатах эта херня уже по несколько раз в день идёт. а последние два дня во все чатах прям наплыв ботов

Alex
22.07.2018
03:03:55
подскажите как ускорить пагинацию, запросы такие select * from log where client_id_ = 11 order by time_ desc limit 100000, 10 CREATE TABLE IF NOT EXISTS log ( EventDate Date default toDate(time_), ...... client_id_ UInt32, ...... time_ DateTime ) ENGINE = MergeTree(EventDate, (client_id_), 8192) колинки все числовые, строк нет

Wolf
22.07.2018
03:10:18
Возможно включить тайм в индекс поможет

Kirill
22.07.2018
06:05:13
подскажите как ускорить пагинацию, запросы такие select * from log where client_id_ = 11 order by time_ desc limit 100000, 10 CREATE TABLE IF NOT EXISTS log ( EventDate Date default toDate(time_), ...... client_id_ UInt32, ...... time_ DateTime ) ENGINE = MergeTree(EventDate, (client_id_), 8192) колинки все числовые, строк нет
Никак, но я бы на вашем месте просто не стал бы запрашивать по 10 записей, а выбырал бы, например, по 10к чтоб не мучать КХ и строил бы пагинацию на клиенте.

Можно, конечно, попробовать сделать "уникальный" ID для каждой строчки лога и положить его в индекс и выбирать что-то вроде SELECT * FROM logs WHERE client_id_ = 11 AND ID IN (SELECT ID FROM logs WHERE client_id = 11 ORDER BY time_desc LIMIT 1000000, 10), но тут проверять надо, да и, на мой взгляд, это перебор )

Andrei
22.07.2018
12:54:50
А в чем проблема с составным PK? На эффективность выборки по client_id это никак не влияет, но гарантирует сортировку по второму полю, что все сильно упрощает. Если нет возможности менять основную таблицу, то можно materialized view

Андрей
22.07.2018
14:08:25
Достаточно большое число соединений на 9000 порт между нодами КХ - это нормально? Везде разное при этом: 100-400-900 открытых соединений (ноды всего 4: 2 мастера, 2 слейва).

Andrei
22.07.2018
15:06:50
@alex09x да именно. Тогда sort by можно убрать из запроса

Alex
22.07.2018
15:09:52
Первичный ключ не гарантирует такую же сортировку результатов запроса.

Подходящее выражение первичного ключа могло бы ускорять выполнение соответствующего ORDER BY в запросе, но эта оптимизация ещё не реализована.

Google
Andrei
22.07.2018
15:16:42
Я так понимаю нет гарантий для последних вставок? Со смердженными партициями или же при использовании final должно быть ок?

Alex
22.07.2018
15:29:49
Из-за того, что запрос читает данные в несколько потоков, вообще гарантий нет. В особых условиях (чтение в 1 поток, все партиции приведены к 1 куску с помощью OPTIMIZE FINAL, сортировка по ключу партиционирования согласована с сортировкой по первичному ключу) данные будут выдаваться в нужном порядке, но закладываться на это нельзя.

Для ускорения пагинации можно вот такое попробовать: действительно добавить time_ в первичный ключ, в запросе оставить ORDER BY, но добавить условие (time_ >= что-то), где "что-то" выбрано так, чтобы все нужные строки заведомо попали. Хотя конечно легко ошибиться и не все нужные строки выбрать.

Daniel
22.07.2018
21:40:25
Кто-нибудь может подсказать вариант standby резервирования сервера с кликхаусом ? Чтобы без встроенной репликации можно было обойтись. Чтения с сервера-копии не нужны.

Denis
22.07.2018
21:50:32
Можно просто исходные данные вставлять сразу в два или в n кх.

Daniel
22.07.2018
21:52:47
Вариант очевидный, хотя хотелось бы с 1 IP по vrrp работать...

Dmitry
22.07.2018
22:04:32
Никто не сталкивался с такой проблемой, есть некая таблица в которой роле заполняется функцией generateUUIDv4(). Я делаю запрос на выборку этого значения через HTTP-интерфейс и почему то получаю UUID с символом переноса строки в конце

Причём через cli возвращается нормальный uuid

Aleksandr
23.07.2018
07:24:38
Здравствуйте. Подскажите пожалуйста можно ли как то сделать поиск по Array(String) like без arrayJoin?

Dmitry
23.07.2018
07:48:20
has(Array, value) ?

Александр
23.07.2018
07:55:17
Здравствуйте. Подскажите пожалуйста можно ли как то сделать поиск по Array(String) like без arrayJoin?
Можно arraFilter применить и сделать что-то типа length(arrayFilter(x -> x LIKE '%search query%'), arrayColum) = 1

Aleksandr
23.07.2018
07:55:59
has(Array, value) ?
has ищет точное значение

Александр
23.07.2018
07:56:48
На выходе будет UInt8 где 0 - совпадений в массиве нет, либо больше одного, 1 - есть только одно совпадение

Если поменять = 1 на >= 1, то будет просто говорить о наличии вхождений и не важно одно там вхождение или больше

Aleksandr
23.07.2018
07:58:05
отлично, то что нужно, спасибо большое

Michal
23.07.2018
09:56:07
v18.1.0-testing - аж 18? :) Или это будет год выпуска?

prll
23.07.2018
11:16:06
Количество багов ?

Artem
23.07.2018
11:27:50
http://calver.org

Oleg
23.07.2018
11:31:00
Подскажите, пожалуйста, как быть: есть таблица вида 'a', [1, 2] 'a', [2, 3] надо получить на выходе 'a', [1, 2, 3] можно, конечно, через arrayjoin и group by получить 'a', 1 'a', 2 'a', 3 и потом их в питоне в массив засунуть, но нет ли возможности прямо в кх это сделать?

Google
papa
23.07.2018
11:34:43
SELECT a, groupUniqArrayArray(b) AS c FROM ( SELECT 'a' AS a, [1, 2] AS b UNION ALL SELECT 'a', [2, 3] AS b ) GROUP BY a ┌─a─┬─c───────┐ │ a │ [2,1,3] │ └───┴─────────┘

Страница 595 из 723