и монотоно возрастает, кстати

В монге хорошо сделано - id это текущее время+id машины клиента+счётчик

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

А монотонно возрастающий счетчик позволяет не только данные отличить одни от других, но и последовательность вставки отследить.

ну да

если нужна сортировка по времени - сойдет и по object id

Последнее — отслеживание послеовательности вставки — ни кому кроме Алексея не надо?

Я правильно понимаю, что о нужности уникального ID ни кто не спорит? Вопрос в том, должен ли он быть целым монотонно возрастающим числом или подойдет псевдоуникальный UUID?

насколько понимаю, спор ведется не о уникальном идентификаторе объекта, а его позиции при добавлении

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

https://docs.mongodb.com/v3.2/reference/method/ObjectId/

не, если у вас 5 джобов загрузки в 10 таблиц, то никто не мешает, если 300 джобов и 2 тыс таблиц и до тучи еще 4 ETL зоопарк, то веселуха

Можешь пояснить "для чайников" — зачем тебе отслеживать последовательность распределенной вставки данных (многими агентами) в распределенное же хранилище?

ну хорошо, будет опциональный ключ

если уж отслеживать -- то последовательность вставки в систему-источник

Вот там и отслеживайте

А если какой-нибудь SAP наплодил таблиц, так у них и так везде UUID

В монге хорошо сделано - id это текущее время+id машины клиента+счётчик

Я, если честно, не вижу преимуществ перед простым рандомом

Я, если честно, не вижу преимуществ перед простым рандомом

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

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

По рекомендациям разработчиков, в ЯКХ данные нужно вставлять данные "редко" — ну грубо говоря не чаще 1 раза в секунду на 1 ноду. В таких условиях уникальным ключем вставки может быть комбинация id ноды и таймстемп, а сиквенсом просто таймстемп.

По рекомендациям разработчиков, в ЯКХ данные нужно вставлять данные "редко" — ну грубо говоря не чаще 1 раза в секунду на 1 ноду. В таких условиях уникальным ключем вставки может быть комбинация id ноды и таймстемп, а сиквенсом просто таймстемп.

вставлять? о_0

а что с ними еще делать?

вроде я видел ограничение только на запросы

не удалять же %)))

а не на вставку

можно ссылку?

нет, там именно вставка. че-т типа большими инсертами >1000 строк

вставлять? о_0

Поручик Ржевский, молчать! :)

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

блин, серьезно?

не слишком, если честно

Производительность при вставке данных. Данные рекомендуется вставлять пачками не менее 1000 строк или не более одного запроса в секунду.

https://clickhouse.yandex/reference_ru.html#Производительность

whatever

ClickHouse является хранилищем данных ?

витрина ?

насчет проще сделать не спорю, я решение с Вертики привел, там синхронизируемый каталог между нодами, не репликация, поэтому там сложнее выходит, они вынуждены синхронизацию каталога между нодами делать в единой транзакции

Я видел такой костыль еще для MySQL - внешний сервис выдающий уникальный I'd по запросу, из пула.

Я видел такой костыль еще для MySQL - внешний сервис выдающий уникальный I'd по запросу, из пула.

Тарантул? :) Даешь импортозамещение!

Последнее — отслеживание послеовательности вставки — ни кому кроме Алексея не надо?

это все нужно когда разгребаешь инциденты при умножении данных на кривые справочники. тут вроде уже реклмендовали всем переходить на 6 нормальную форму )

Тарантул? :) Даешь импортозамещение!

В том случаи самописный сервис был, ибо решение ооочень старое.

В том случаи самописный сервис был, ибо решение ооочень старое.

Я пошутил. Просто недавно в этом чатике проскакивал вопрос о том, чем ЯКХ от Тарантула отличается и каковы у них области применения. Вот неплохой пример — узкая, но важная задача — генерить уникальные сиквенсы для интеграционных процессов.

Как вариант :)

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

Вот, я про это и начал, как воркэраунд для отсутствия tailable cursor :)

вопрос. много узлов к одному внешнему диску . взлетит ?

вопрос. много узлов к одному внешнему диску . взлетит ?

Работать будет, но этот вариант не оптимален.

Работать будет, но этот вариант не оптимален.

вторая попытка ): Жесткий диск- это enterprise решение

#запрос_на_доработку в клиенте нужно сделать настраиваемым ограничение на количество выводимых строк - по умолчанию 1000

почему не 10к?

вторая попытка ): Жесткий диск- это enterprise решение

?

#запрос_на_доработку в клиенте нужно сделать настраиваемым ограничение на количество выводимых строк - по умолчанию 1000

Есть в Pretty-формате в интерактивном режиме.

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

И в настройках тоже есть - max_result_rows.

о, проглядел, значит :) спасибо!

не, это не то

❯ echo 'SELECT * FROM system.numbers LIMIT 100000 FORMAT PrettyCompact;' | clickhouse-client --max_result_rows=10000 Received exception from server: Code: 158. DB::Exception: Received from localhost:9000, 127.0.0.1. DB::Exception: Limit for result rows exceeded: read 65536 rows, maximum: 10000.

имелось в виду, именно выводимых на экран одновременно

А здесь при попытке забрать больше эксепшн

Т.е. хочется, я так понимаю, возможность изменять максимальное кол-во отображаемых Pretty-форматами в интерактивном режиме строк А еще в идеале пейджер ))

Понятно.

вопрос по использованию массивов в качестве значения поля. Есть ограничения ? какие предельные размерности ?

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

в доках писали, что многомерные массивы - на свой страх и риск

> Многомерные массивы не рекомендуется использовать, так как их поддержка довольно слабая (например, многомерные массивы нельзя сохранить в какую-либо таблицу кроме таблиц типа Memory).

вопрос про view и union all . поддерживает ли оптимизатор чтение выделенных секционированных данных через по след . признаку seleсt '1' as e, bb.* from ff_1 where e='1' union all select '2' as e, bb.* from ff_2 where e='2' .. т.е. если я обращусь к view c условием e='2' прочитаются все или только таблица ff_2 ?

в доках писали, что многомерные массивы - на свой страх и риск

однострочные массивы ?

в доках писали, что многомерные массивы - на свой страх и риск

ок. я понял. буду без них)

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

минимальная - 1970-01-01 (которая может быть видна как 0000-00-00) максимальная - 2038-01-19 (toDate(24855)) при попытке сделать SELECT toDate(24855) + 1; получится 0000-00-00

кстати, документация, похоже, неактуальна > В качестве исключения, если делается преобразование из числа типа UInt32, Int32, UInt64, Int64 в Date, и если число больше или равно 65536, то число рассматривается как unix timestamp :) select toDate(toInt64(24856)); 0000-00-00 это баг или лучше исправить документацию?) казалось бы, можно использовать даты до 32768

Всем привет! А где можно прочитать про внутреннюю архитектуру click house в сравнении с другими аналогами такими как impala, drill и так далее?

Всем привет! А где можно прочитать про внутреннюю архитектуру click house в сравнении с другими аналогами такими как impala, drill и так далее?

По поводу impala: это надстройка над Hadoop, поэтому ее архитектуру сравнивать с CH бессмысленно, т.к. в последнем вообще не map reduce модель вычислений. Drill - это "свободный от хранилища" аналитический движок, созданный с целью хоть что-то разумное посчитать в зоопарке всяческих schema-free NoSQL, т.е. вообще ПО другой категории. Можно, кстати, CH в него интегрировать, если очень хочется. Архитектура ClickHouse хорошо описана тут: https://github.com/yandex/ClickHouse/blob/master/doc/developers/architecture.md

Impala не надстройка, а отдельный инструмент. Там не используется парадигма map reduce

Ссылку за архитектуру спасибо

А, интересно. Просто определение "native database for Hadoop", видимо, сбило с толку в свое время. Почитаю тогда о ней побольше. Спасибо.

Чуть позже скину хорошую статью про неё

Спасибо. Пока нашел вот это: http://www.cidrdb.org/cidr2015/Papers/CIDR15_Paper28.pdf

Да, это именно она

Классно было бы иметь подобную статью по CH в каком-нибудь цитируемом журнале

Классно было бы иметь подобную статью по CH в каком-нибудь цитируемом журнале

Это вопрос лишь денег . Задайте вопрос своим маркетологам

Это вопрос лишь денег . Задайте вопрос своим маркетологам

Нормальные научно-технические журналы печатают за просто так, главное, чтобы статья была по тематике. Как говорил @milovidov_an на встрече в понедельник, главное "совершить насилие над собой и потратить на это драгоценное время" (за точность цитаты не ручаюсь).

вопрос про view и union all . поддерживает ли оптимизатор чтение выделенных секционированных данных через по след . признаку seleсt '1' as e, bb.* from ff_1 where e='1' union all select '2' as e, bb.* from ff_2 where e='2' .. т.е. если я обращусь к view c условием e='2' прочитаются все или только таблица ff_2 ?

Lookup будет в обе таблицы. Если e - первый столбец ключа, то lookup в той таблице, где нет такого значения, будет простым, но всё-равно потребуется прочитать один небольшой блок данных.

Lookup будет в обе таблицы. Если e - первый столбец ключа, то lookup в той таблице, где нет такого значения, будет простым, но всё-равно потребуется прочитать один небольшой блок данных.

ну да при скорости чтения с узла 3 Gb/sec можно и прочитать лишний блок ))

А что делает all right join? Его нет в документации, а результат отличается от all left join со сменой таблиц местами

ну да при скорости чтения с узла 3 Gb/sec можно и прочитать лишний блок ))

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

iotop?

atop

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

atop

с кластера ?

хз. atop просто лучше показывает инфу чем iotop

я тут просто мимо проходил

хз. atop просто лучше показывает инфу чем iotop

Я просто о том что на кластере померить физическое чтение одного запроса будет еще той задачкой.

ээээ. я не следил за темой...

Я просто о том что на кластере померить физическое чтение одного запроса будет еще той задачкой.

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

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

а можно ссылку на эту тулзу ? )

А что делает all right join? Его нет в документации, а результат отличается от all left join со сменой таблиц местами

Да, это RIGHT JOIN. Результат такой же, как если таблицы для LEFT поменять местами. Но способ выполнения не симметричен. Рассмотрим подробнее: LEFT JOIN выполняется так: - результат правого подзапроса засовываем в хэш-таблицу в оперативке; - сканируем левую таблицу и делаем лукапы. RIGHT JOIN выполняется так: - результат правого подзапроса засовываем в хэш-таблицу в оперативке; - сканируем левую таблицу и делаем лукапы; при этом отмечаем флажками, какие строки справа были использованы; - добавляем в результат то, что не было использовано справа. То есть, в обеих случаях, левая таблица читается потоково, а по правой формируется хэш-таблица в оперативке. Независимо от того, LEFT или RIGHT JOIN.

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

Проще всего dstat. Но iostat, iotop тоже подойдут :)

Алексей, спасибо! Теперь понятно)