что мешает писать и теги и в мастере держать стейбл? ?

Есть ряд workflow, в которых в master сливаются форки всего, что протестировано и вроде бы стабильно работает, но предназначено для следующего релиза.

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

вот да!

git - это наименее страшная штука, влияющая на уровень входа в разработку. Там вон https://github.com/yandex/ClickHouse/blob/master/doc/developers/style_ru.md есть.

А зачем вы запустили скрипт release?

А зачем вы запустили скрипт release?

вообщем .. да.. отложу я это дело до нового года .

git - это наименее страшная штука, влияющая на уровень входа в разработку. Там вон https://github.com/yandex/ClickHouse/blob/master/doc/developers/style_ru.md есть.

ну эти стайлгайды похожи на то что принтяо например в Qt :)

или kernel-style

Про ветку master и релизные теги. Сейчас добавлю в инструкцию, как сделать checkout последней стабильной версии. Про скрипт release. Для сборки пакетов без загрузки тега в репозиторий, можно написать: ./release —standalone Сейчас проверю, написано ли об этом хоть где-нибудь.

Про ветку master и релизные теги. Сейчас добавлю в инструкцию, как сделать checkout последней стабильной версии. Про скрипт release. Для сборки пакетов без загрузки тега в репозиторий, можно написать: ./release —standalone Сейчас проверю, написано ли об этом хоть где-нибудь.

в доке стоит все верно ./release —standalone - это я пропустил параметр...

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

я еще раз спрошу, а когда видео будет?

Мы не уверены что хорошо получилось и еще посмотрим стоит ли выкладывать. Там по большей части вопросы и ответы. Но если будет - то обычно на его подготовку уходит неделя-две.

Мы не уверены что хорошо получилось и еще посмотрим стоит ли выкладывать. Там по большей части вопросы и ответы. Но если будет - то обычно на его подготовку уходит неделя-две.

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

тыкдом

Тебя что-то смущает?

можно посмотреть что выдаст ? echo "DROP TABLE IF EXISTS myapptest2.testtable; CREATE TABLE myapptest2.testtable (pageURL String, pageRank UInt32, avgDuration UInt32) ENGINE = Log; SHOW CREATE TABLE myapptest2.testtable; SELECT * FROM myapptest2.testtable FORMAT TabSeparatedWithNames;" | clickhouse-client -n

SELECT * FROM myapptest2.testtable FORMAT TabSeparatedWithNames; SELECT * FROM myapptest2.testtable FORMAT TabSeparatedWithNames pageURL pageRank avgDuration Received exception from server: Code: 1000. DB::Exception: Received from localhost:9000, 127.0.0.1. DB::Exception: File not found: /opt/clickhouse/data/myapptest2/testtable/pageURL.bin. 0 rows in set. Elapsed: 0.096 sec.

SELECT * FROM myapptest2.testtable FORMAT TabSeparatedWithNames; SELECT * FROM myapptest2.testtable FORMAT TabSeparatedWithNames pageURL pageRank avgDuration Received exception from server: Code: 1000. DB::Exception: Received from localhost:9000, 127.0.0.1. DB::Exception: File not found: /opt/clickhouse/data/myapptest2/testtable/pageURL.bin. 0 rows in set. Elapsed: 0.096 sec.

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

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

echo "DROP TABLE IF EXISTS myapptest2.testtable; CREATE TABLE myapptest2.testtable (pageURL String, pageRank UInt32, avgDuration UInt32) ENGINE = Log; SHOW CREATE TABLE myapptest2.testtable; SELECT * FROM myapptest2.testtable FORMAT TabSeparatedWithNames;" | clickhouse-client -n --password qwerty CREATE TABLE myapptest2.testtable ( pageURL String, pageRank UInt32, avgDuration UInt32) ENGINE = Log pageURL pageRank avgDuration Received exception from server: Code: 1000. DB::Exception: Received from localhost:9000, 127.0.0.1. DB::Exception: File not found: /opt/clickhouse/data/myapptest2/testtable/pageURL.bin.

Есть резульаты по сравнению производитильности ES и CH? https://github.com/yandex/ClickHouse/issues/14

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

а чем тут дампы - то делаются?

а чем тут дампы - то делаются?

Я про дамп виртуалки (если у тебя там нет критичных данных)

их-то нет.

ща в личку кину

Есть резульаты по сравнению производитильности ES и CH? https://github.com/yandex/ClickHouse/issues/14

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

А можно как-то подписаться на обновление таблицы? Что-то типа tailable cursor прекрасно подошло бы :)

ах, это было бы прекрасно

А можно как-то подписаться на обновление таблицы? Что-то типа tailable cursor прекрасно подошло бы :)

Сейчас такого нет. Было только на уровне идеи. Сложность зависит от глубины проработки. Минимальный вариант - возможность сделать потоковый запрос (без GROUP BY, ORDER BY), который продолжает бесконечно отдавать новые строки. Более сложно - полноценная очередь, с возможностью запомнить место, до которого дочитали и потом читать дальше. Там много сложностей с репликацией.

Сделайте хотя бы относительно простые потоковые запросы, плиз! Без агрегатов уже будет хорошо.

А какой сейчас вариант, автоинкрементного айди хотя бы на уровне mysql тоже не имеется ведь, да?

Внешней системой нумеровать строки по порядку и читать от последнего номера +1?

Писатель только охренеет, а так — норм

А какой сейчас вариант, автоинкрементного айди хотя бы на уровне mysql тоже не имеется ведь, да?

autoincrement нет.

а аналог постгресового ctid, который физический указатель на место тапла в диске?

Была идея сделать глобальный row_number. Но это не дружит с master-master репликацией. Можно сделать только такой, который может меняться после вставки.

Была идея сделать глобальный row_number. Но это не дружит с master-master репликацией. Можно сделать только такой, который может меняться после вставки.

а если сделать общий каталог сивенседов, который реплицируется на все мастера, а каждый мастер получает свою границу пулов (например от 1 до 250 тыс, от 250001 до 500 тыс и т.д.)? когда у любого мастера кончается его выделенный резерв, он просто снова у каталога запрашивает себе новую границу в синхронном порядке общения, чтобы мастера в очередь становились за номерами. ну и как раз тогда CREATE SEQUENCE ... CACHE 250000 конструкция нормально смотрится и вполне страндартная для всех СУБД.

Идея понятна. Сделать sequence реально. Даже несколько проще, чем написано выше.

а если сделать общий каталог сивенседов, который реплицируется на все мастера, а каждый мастер получает свою границу пулов (например от 1 до 250 тыс, от 250001 до 500 тыс и т.д.)? когда у любого мастера кончается его выделенный резерв, он просто снова у каталога запрашивает себе новую границу в синхронном порядке общения, чтобы мастера в очередь становились за номерами. ну и как раз тогда CREATE SEQUENCE ... CACHE 250000 конструкция нормально смотрится и вполне страндартная для всех СУБД.

удалили узел кластера , добавили два других ?

ну и что ?

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

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

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

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

- с ними ушли ID , на которые подписана репликация

это просто NEXTVAL, как они могли уйти ?

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

ну не получат клиенты при вставке эту порцию 250 тыс номеров, в чем критикал ?

ну не получат клиенты при вставке эту порцию 250 тыс номеров, в чем критикал ?

ну если среди этих 250 тыс есть хоть одна запись от которой зависит чья-то премия... )

узел ушел, данные потерялись, если не были реплицированы куда то еще

IMHO надуманная проблема

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

можете сориентировать, зачем вообще нужны обсуждаемые счетчики?

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

ну обычные SEQENCE, очень даже нужны бывают

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

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

зашел в таблицу и сразу увидел новые записи

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

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

все наверное от области зависит задач ;)

хранилище данных без синт ключей может оказаться не удобным много где

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

существование системы Х само по себе не подтверждает необходимость той или иной функции в ней

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

если нужен уникальный идентификатор - то как правило используется uuid, но здесь же все идентификаторы должны быть внешними

по ууидам аналитикам мастер детайл просто замечательно искать руками в запросах :)

просто их мечта

все счетчики являются точкой лишней синхронизации узлов, а этого стоит избегать

а часто аналитикам надо искать _конкретные_ записи?

странно что ни одна коммерческая хд этого "не избежала"

ага, часто

я почему спрашиваю, потому что лично меня задолбало конвертировать FixedString(16) в человекопонятный UUID, и я в раздумьях между FixedString(36) и таки сжатым представлением

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

я же говорю, ключевое слово "разные задачи"

Ваш опыт "не часто" и "не нужно", мой противоположный

я почему спрашиваю, потому что лично меня задолбало конвертировать FixedString(16) в человекопонятный UUID, и я в раздумьях между FixedString(36) и таки сжатым представлением

при этом, такое требуется достаточно редко и в основном при разбирательствах, когда что-то где-то не так :)

генерируйте счетчики в ETL, кто мешает?

мешает MPP

вроде к тому и вернулись

ладно, Леша идею понял :) спор нужно или нет это с другой плоскости

и чем же он мешает?

зачем решать эту задачу в хранилище, если этого можно не делать? :)

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

можно и на ЕТЛ тогда уж агрегировать данные, чего уж там, хватает функционала

какая разница, сколько таблиц?

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

в распределенных системах расшаренное состояние - зло

зачем наступать на эти грабли, если можно не наступать