@clickhouse_ru

Страница 522 из 723
Гаврилов
10.05.2018
10:47:43
все очень просто

сдаешь toefl на 100

и заводишь трактор

Daniel
10.05.2018
10:48:00
и в Канаду

Google
Alex
10.05.2018
10:48:05
коллеги, подскажите пожалуйста как заставить кликхаус забыть про партицию если ее давно не находилось в живых репликах? в частности щас в логи сыпется (StorageReplicatedMergeTree): DB::Exception: No active replica has part 20180413_5419_5517_12 or covering part, я знаю что это партиции уже скорее всего не найти нигде ( КХ в облачном окружении и партиция потерялась при изменении конфигурации)

Alex
10.05.2018
10:53:54
но может есть опция

чтоб кх сам такой мусор чистил

просто у меня изменения конфигурации могут происходить с некоторой периодичностью

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

Michal
10.05.2018
11:02:47
Мне сейчас сдавать курсач на третьем курсе (!) НА АКСЕСЕ (!). Говорить что-то хорошее о квалификации специалистов после такой программы я думаю нереально. Лично мне пофиг, я кликхаус сижу изучаю, на нем курсач сделаю. Если в кратце, не с кем работать будет мне и Вам через 2-3 года. Сорян за оффтоп, выговорился от имени половины потока.
Я бы сказал что для обучения базам данных Кликхаус - не лучший выбор. Т.к. очень много вещей сделано не в соответсвтии со стандартами, а для удобства, иногда для удобства использования, иногда для удобства реализации. Кроме того на Кликхаусе нет довольно важных с образовательной точки зрения триггеров, хранимых, процедур, транзакций, update/delete и некоторых других важных элементов "полноценной RDBMS". Если изучить Кликхаус как "первую базу" то потом пересеть на что-то другое будет трудно, т.к. многих вещей не будешь уметь, а некотоые будешь уметь делать в кликхаус-стиле. В свою очередь пересеть с практически любой базы данных на кликхаус - довольно тривиально, просто нужно ознакомиться с ограничениями и дополнительными доступными функциями диалекта SQL. В общем MS Access - конечно так себе кандидат для обучения, но и Кликхаус - это база данных для практического использования во вполне конкретной и довольно узкой предметной области, это не база данных общего назначения, и не база данных для обучения работы с базами данных.

Google
Daniel
10.05.2018
11:04:36
Я бы сказал что для обучения базам данных Кликхаус - не лучший выбор. Т.к. очень много вещей сделано не в соответсвтии со стандартами, а для удобства, иногда для удобства использования, иногда для удобства реализации. Кроме того на Кликхаусе нет довольно важных с образовательной точки зрения триггеров, хранимых, процедур, транзакций, update/delete и некоторых других важных элементов "полноценной RDBMS". Если изучить Кликхаус как "первую базу" то потом пересеть на что-то другое будет трудно, т.к. многих вещей не будешь уметь, а некотоые будешь уметь делать в кликхаус-стиле. В свою очередь пересеть с практически любой базы данных на кликхаус - довольно тривиально, просто нужно ознакомиться с ограничениями и дополнительными доступными функциями диалекта SQL. В общем MS Access - конечно так себе кандидат для обучения, но и Кликхаус - это база данных для практического использования во вполне конкретной и довольно узкой предметной области, это не база данных общего назначения, и не база данных для обучения работы с базами данных.
NoSQL шагает по планете, и Clickhouse хорош для изучения как отличный представитель columnstore баз.

Kirill
10.05.2018
11:05:22
Хотите учиться берите PostgreSQL

Анатолий
10.05.2018
11:05:56
Я бы сказал что для обучения базам данных Кликхаус - не лучший выбор. Т.к. очень много вещей сделано не в соответсвтии со стандартами, а для удобства, иногда для удобства использования, иногда для удобства реализации. Кроме того на Кликхаусе нет довольно важных с образовательной точки зрения триггеров, хранимых, процедур, транзакций, update/delete и некоторых других важных элементов "полноценной RDBMS". Если изучить Кликхаус как "первую базу" то потом пересеть на что-то другое будет трудно, т.к. многих вещей не будешь уметь, а некотоые будешь уметь делать в кликхаус-стиле. В свою очередь пересеть с практически любой базы данных на кликхаус - довольно тривиально, просто нужно ознакомиться с ограничениями и дополнительными доступными функциями диалекта SQL. В общем MS Access - конечно так себе кандидат для обучения, но и Кликхаус - это база данных для практического использования во вполне конкретной и довольно узкой предметной области, это не база данных общего назначения, и не база данных для обучения работы с базами данных.
Будь я проектным менеджером кликхауса, я бы в словах "Сложно перейти на использование других баз" увидел бы больше плюсов, чем минусов.

Michal
10.05.2018
11:06:01
+1
+1 :)

Egor
10.05.2018
11:08:18
Будь я проектным менеджером кликхауса, я бы в словах "Сложно перейти на использование других баз" увидел бы больше плюсов, чем минусов.
Кликхаус заточен на определенный круг задач, поэтому у него есть определенные компромиссы. Логично сначала изучать общую область СУБД, что бы понять как оно все пюсоздавалось и для чего. Нормализация, ACID, только тогда будет понятно почему кликхаус именно такой какой есть и какие ограничения он накладывает. Что, в итоге, позволит принять решение можно ли его применять для определенной задачи.

Ivan
10.05.2018
11:08:37
Ivan
10.05.2018
11:09:39
а что, поддерживается еще какой то диалект?

Daniel
10.05.2018
11:12:20
Michal
10.05.2018
11:16:17
NoSQL шагает по планете, и Clickhouse хорош для изучения как отличный представитель columnstore баз.
По планете чего уж только не шагало :) А реляционная аглебра, кортежи, нормальные формы и т.п. известны уже лет 40-50 - и живы-живёхоньки :) Если эти темы и стандартные RDBMS общего исключения исчерпаны и (вдруг) осталось время и желание - тогда можно переключиться на изучение конкретных баз специализированного назначения - NoSQL, колоночные, document-storage, graph-databases и т.п.

Ivan
10.05.2018
11:30:46
<шутка>жду появления NoTuring языков программирования, они такие же как обычные (Not Only Turing), но выполнимость никто не проверял(или не смог)</шутка>

Michal
10.05.2018
11:31:03
Будь я проектным менеджером кликхауса, я бы в словах "Сложно перейти на использование других баз" увидел бы больше плюсов, чем минусов.
Чтобы быть проектным менеджером в Яндексе - нужно сначала пройти собеседование при трудоустройстве в Яндексе :D Без знаний основ (некоторые из которых отсутствуют в Кликхаус, как я писал выше) это может быть сложно. ;)

Анатолий
10.05.2018
11:33:59
я вот с access'а начинал, и ничего... правда это было в 9-м классе, и задачи внезапно были вполне production - у мамы на работе половина бухгалтерии на access работала)
Времена сейчас не те. Когда у Вас задачи были сведение бухгалтерии у мамы на работе, у меня стоят задачи анализа тысячей событий в минуту.

Alexey
10.05.2018
11:39:32
Времена сейчас не те. Когда у Вас задачи были сведение бухгалтерии у мамы на работе, у меня стоят задачи анализа тысячей событий в минуту.
Так это всего N*16 событий в секунду, миллионы строк в сутки. Это можно grep-ом анализировать. P.S. АВТФу привет от примата.

Google
Michal
10.05.2018
11:42:42
Времена сейчас не те. Когда у Вас задачи были сведение бухгалтерии у мамы на работе, у меня стоят задачи анализа тысячей событий в минуту.
Кликхаус реально полезен когда тысячи в секунду :) С тысячами в минуту вполне справится постгрес. :)

Анатолий
10.05.2018
11:45:14
Кликхаус реально полезен когда тысячи в секунду :) С тысячами в минуту вполне справится постгрес. :)
Я это прекрасно понимаю и мне понадобятся такие возможности в рамках той же самой задачи.

Michal
10.05.2018
11:46:15
Примат?
Прикладная математика же ж. PS. А вы точно в универе учитесь? :)

Анатолий
10.05.2018
11:49:55


Все научные публикации, где принимал участие и все остальное там есть

Tima
10.05.2018
11:53:01
Граждане, ну офтоп же, вы тут не одни

Michal
10.05.2018
11:53:54
Это была шутка, если что: обычно студенты знают кто такие приматы в универе. ЗЫ. Роботы симпатишные :)

Daniel
10.05.2018
11:57:12
Это была шутка, если что: обычно студенты знают кто такие приматы в универе. ЗЫ. Роботы симпатишные :)
Нет, закончил БГУИР пару лет тому. Была высшая математика. Приматы - на факультете прикладной математики и информатики БГУ.

Kirill
10.05.2018
12:02:53
А у меня в школе по информатике 3 было )

Mike
10.05.2018
12:56:38
Коллеги, подскажите плиз как раздебажить "<Error> ServerErrorHandler: Poco::Exception. Code: 1000, e.code() = 104, e.displayText() = Connection reset by peer, e.what() = Connection reset by peer" - в логах начали сыпаться, достаточно много. Рядом в логах обычные информационные записи, ничего необычного. Версия 1.1.54380

Michal
10.05.2018
12:59:56
Клиент "вешает трубку" в середине разговора. Может какие-то таймауты на клиенте срабатывают?

Oleksandr
10.05.2018
13:02:42
Или через туннели если трафик бегает. Бывает фрагментация бьет пакеты.

Michal
10.05.2018
13:08:12
ЕМНИП, "Connection reset by peer" значит что пришел специальный пакет от клиента мол, "мне все надоело, больше не хочу, Auf Wiedersehen!". Т.е. клиент (или кто-то посередине между сервером и клиентом) целенаправлено разъединяется.

Mike
10.05.2018
13:08:59
Спасибо, будем искать негодяя с клиентской стороны

Michal
10.05.2018
13:12:42
тут аккуратнее варианты описаны: https://stackoverflow.com/a/1434592/1555175

George
10.05.2018
14:21:31
Скажите, а почему для MergeTree надо обязательно Date, и нельзя DateTime?

Tima
10.05.2018
14:22:36
Скажите, а почему для MergeTree надо обязательно Date, и нельзя DateTime?
С недавних пор можно, ищите по слову PARTITION BY

Stanislav
10.05.2018
14:23:23
Версию, где сделали, не припомните? А то у товарища может быть что-то старое и неумеющее.

Google
Tima
10.05.2018
14:27:35
Сложно сказать, пусть пробует, либо пройдёт, либо нет. Да и плюс один повод обновиться

Denis
10.05.2018
14:33:17
Скажите, а почему для MergeTree надо обязательно Date, и нельзя DateTime?
с datetime партиций будет слишком много, либо я не понял что хранится в datetime

George
10.05.2018
14:34:28
Та же дата, но с секундами. Партиционирование как было, просто хранить date, а рядом datetime только ради mergetree странно.

Denis
10.05.2018
14:34:49
в новом синтаксисе можно написать так CREATE TABLE test.test (a Datetime, ......) ENGINE = MergeTree Partition by (toStartOfMonth(a)) Order by (a .... , , ,, ) не будет хранения два раза

LeiDruid
10.05.2018
14:37:08
Товарищи, а как повлиять на Too many parts (310). Merges are processing significantly slower than inserts ?

По ресурсам, кмк, ещё запас хороший

Tima
10.05.2018
14:37:59
Товарищи, а как повлиять на Too many parts (310). Merges are processing significantly slower than inserts ?
Остановить запись и дождаться когда фоновые мерджы просруться

LeiDruid
10.05.2018
14:38:36
А, может, как-то потюнить сам мерджинг ?

Tima
10.05.2018
14:38:51
Конролировать их можно так SELECT * FROM system.merges

Wolf
10.05.2018
14:39:21
А, может, как-то потюнить сам мерджинг ?
делайте реже вставки и пачками побольше

Kirill
10.05.2018
15:05:08
т.е. колонка nullable(Float32) и при чтении из mysql ни ifNull, ни coalesce не спасают. DB::Exception: Cannot read floating point value: Cannot parse Float32 from String.

Stanislav
10.05.2018
15:09:23
Коллеги, может кто сталкивался с подобной задачей: закачиваем статистику по yandex.direct, содержащую большое кол-во строк. Периодически возникает ситуация когда на стороне директа происходит корректировка данных, и их нужно обновить в КХ. Столкнулись с проблемой скорости обновления данных - получается что сначала нужно перебрать все полученные от яндекса строки чтобы определить, поменялась ли в ней данные (select из КХ для каждой строки), и если данные изменились - вставить новую строку с sign=1 и старую с sign=-1. Движок таблицы - collapsingmergetree. Кол-во строк - порядка 50к за 1 цикл. Может есть какой-то более быстрый способ обновить данные за прошлые даты?

Александр
10.05.2018
15:15:48
Наткнулся на ту же проблему, но не нашёл ответ. Решение было найдено ?
Неа. Пока остановил работы в этом направлении. Приоритеты изменились.

Tima
10.05.2018
15:17:02
А какие вообще планы на ближайшее будущее? Как изменился роадмап?

Alexey
10.05.2018
15:26:41
Коллеги, может кто сталкивался с подобной задачей: закачиваем статистику по yandex.direct, содержащую большое кол-во строк. Периодически возникает ситуация когда на стороне директа происходит корректировка данных, и их нужно обновить в КХ. Столкнулись с проблемой скорости обновления данных - получается что сначала нужно перебрать все полученные от яндекса строки чтобы определить, поменялась ли в ней данные (select из КХ для каждой строки), и если данные изменились - вставить новую строку с sign=1 и старую с sign=-1. Движок таблицы - collapsingmergetree. Кол-во строк - порядка 50к за 1 цикл. Может есть какой-то более быстрый способ обновить данные за прошлые даты?
Примерно такая же ситуация, мы заливаем данные раз час за прошедшие 7 дней (~40 млн строк), в ReplacingMergeTree, в скрипте после заливки каждого дня запускается OPTIMIZE TABLE PARTITION FINAL, проблем пока нет.

вообще ничего не селектим, просто последние 7 дней сверху льем и хлопаем дубли

Дима
10.05.2018
15:33:44
т.е. колонка nullable(Float32) и при чтении из mysql ни ifNull, ни coalesce не спасают. DB::Exception: Cannot read floating point value: Cannot parse Float32 from String.
Дико плюсую. Есть какие-то варианты избежать обработки null значений до передачи их в селект?

Kirill
10.05.2018
16:34:53
Google
Kirill
10.05.2018
16:37:16
Но это какие-то костыли ?

Alexandr
10.05.2018
16:38:37
@milovidov_an Алексей, есть ли план починить критический баг https://github.com/yandex/ClickHouse/issues/2273, он пристуствует в свежем master, но также во многих версиях до этого. Точно известно, что бага нет в v1.1.54342.

Denis
10.05.2018
16:47:55
кстати играюсь с партиционированием Partition by (account_id,toStartOfMonth(access_day)) Order by (другие поля) запрос PREWHERE account_id = 1183161 and access_day >= '2018-05-01'; ┌─count()─┐ │ 673 │ └─────────┘ 1 rows in set. Elapsed: 1.368 sec. Processed 1.33 billion rows, 13.30 GB (971.67 million rows/s., 9.72 GB/s.) все варианты where и prewhere и с toStartOfMonth я уже перебрал. вместо одной партиции с 673 строками, сканируется вся таблица. version 1.1.54327

Александр
10.05.2018
17:11:34
Denis
10.05.2018
17:15:22
WHERE (account_id = 1183161) AND (access_day = '2018-05-01') ┌─count()─┐ │ 20 │ └─────────┘ 1 rows in set. Elapsed: 0.086 sec. Processed 102.95 million rows, 1.03 GB (1.19 billion rows/s., 11.93 GB/s.)

хм WHERE (account_id = 1183161) AND (access_day = '2018-05-02') ┌─count()─┐ │ 17 │ └─────────┘ 1 rows in set. Elapsed: 1.221 sec. Processed 1.33 billion rows, 13.26 GB (1.09 billion rows/s., 10.86 GB/s.)

WHERE (account_id = 1183161) AND (toStartOfMonth(access_day) = '2018-05-01') ┌─count()─┐ │ 673 │ └─────────┘ 1 rows in set. Elapsed: 1.181 sec. Processed 1.33 billion rows, 13.30 GB (1.13 billion rows/s., 11.26 GB/s.)

Kirill
11.05.2018
05:54:39
Подскажите пожалуйста - у vertica при загрузке данных в случае ошибки есть возможность получить дамп тех данных, которые не были вставлены. В той или иной степени это позволяет на стороне приложения реализовать обработку такой ошибки. Как с этим обстоит дело у ch? Где можно прочитать про обработку ошибок при вставке?

Александр
11.05.2018
05:57:08
Даже если данные вставились и приложение получило ошибку и повторно вставило данные, то такой блок данных будет выброшен как дубль

Но приложение получит корректный ответ от сервера

Kirill
11.05.2018
05:58:16
Спасибо! А в мануале это есть где-то?

Александр
11.05.2018
05:58:19
Случаев частичной вставки я не встречал

Спасибо! А в мануале это есть где-то?
Не уверен, но думаю, что в описании http интерфейса есть упоминания

Kirill
11.05.2018
05:59:43
Еще раз спасибо!

Tomazov
11.05.2018
06:08:23
Добрый день. проследил этап развития функции CityHash вижу что у гугла есть приемник FarmHash https://opensource.googleblog.com/2014/03/introducing-farmhash.html и новый HighwayHash https://opensource.googleblog.com/2016/03/new-algorithms-may-lower-cost-of-secure.html

Атата
11.05.2018
06:24:39
Спасибо! А в мануале это есть где-то?
Это фича distributed таблиц, если мне не изменяет память

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