Ну тут уже дело техники - можно и в память и в какой-то буфер на диск.

Угу WAL лог + in-mem

На самом деле поставить Tarantool буфером перед КХ очень здравая идея, так можно и row-based security добавить и всякие enterprise-аутентификации.

Да, мы про это как раз думаем. Будет совместное решение - ClickTarantoolHouse :)

Tarantool -- как виртуальный сторадж файлов Клика?

Тут ещё вопрос про интеграцию с источниками данных встаёт. У многих это оракл.

Я опять же про kdb. Данные с диска всасываются через mmap. По сути они такие же как и в памяти.

Я опять же про kdb. Данные с диска всасываются через mmap. По сути они такие же как и в памяти.

вот только писать через mmap не получится

будут корапты

Денис, я чуток запутался :) Какой для вас целевой сценарий? Тарантул -- как слой виртуализации над КХ? Или Тарантул -- как сторадж под КХ, чтобы тот сразу агрегировал данные напрямую из тарантула?

вот только писать через mmap не получится

Да, менять то, что уже записано на диск очень тяжело.

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

с разделением на холодную и горячую часть

:)

Денис, я чуток запутался :) Какой для вас целевой сценарий? Тарантул -- как слой виртуализации над КХ? Или Тарантул -- как сторадж под КХ, чтобы тот сразу агрегировал данные напрямую из тарантула?

Как минимум Т как буфер перед кликом. Что особенно актуально, если данные в клик поступают из оракла или мускуля, тк тарантул умеет реплицировать из них

Т.е. update и delete по сути нет

Т.е. in-mem + WAL-лог, WAL-лог сбрасывается в клик

собственно я его буду +/- использовать именно так :)

Ну и сквозной LSN между кликом и демоном (тут надо подумать)

Как минимум Т как буфер перед кликом. Что особенно актуально, если данные в клик поступают из оракла или мускуля, тк тарантул умеет реплицировать из них

Спасибо. А для КликВью (не путать с КликХаус) вы тоже хоттите Тарантул использовать как источник данных, абстрагируя Клик от прочего. Или про КликВью это была оговорка по фрейду?

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

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

.... быстрее чем вью их может прочитать? :)

Звучит фантастически, но да

а почему? потому что "ClickHouse не тормозит" (с)

а почему? потому что "ClickHouse не тормозит" (с)

Быстрый зараза :)

Единственное сравнение с kdb, которое удалось обнаружить: http://tech.marksblogg.com/benchmarks.html

Единственное сравнение с kdb, которое удалось обнаружить: http://tech.marksblogg.com/benchmarks.html

Когда работал над проектом FXCM (высокочастотная торговля) лет 5-ть назад, то kdb показывала фантастические результаты (т.е. почти всегда упиралось в сеть). Но! Админить это было больно (благо это делали не мы). Плюс, язый Q - это жесть

2 + 2 * 2 = 8 - язык Q

Ну про язык Q я бы поспорил, так как это моя основная работа :) Про админить - тут тоже вопросы. Но я смотрю на CH как раз как на альтернативу kdb, ну и просто из интереса насколько его можно применить на стандартных для kdb задачах.

Прикольно :) Я за год так и не привык к Q - не мое

2 + 2 * 2 = 8 - язык Q

Просто нет приоритетов операторов.

угу

скобочки ...

Вспомнил аж переклинило

Тем не менее мне он кажется намного проще и даже эффективнее sql'я. Но это уже в оффтоп уходит.

А если хочешь kdb заменить

то советую tarantool

те же яйца

только в профиль

Но Free to use

и фич больше

а клик для историчиских данных

чтобы роботов обучать

Батчер нужен.

Все говорят про батчер и прочее. Многие говорят что делать http к кх и т.д. но хотелось бы как то оффиц батчер. А то получается как про блоху типа вот вам блоха а шкатулку под неё как хотите так и делайте....ну и или том подобное. Тем более http это не dbc и общение идёт не по оригинальному кх протоколу.

Все говорят о море (с)

я наоборот склонен говорить с CH в макисимально френдли ему форамте

чтобы по сто раз не делать sscanf/sprintf со всеми вытекающими

Так вот я про это. Если есть батчер как прослойка. То почему бы и нет. Входные json или sql неважно. Приспособимся. А выходные - CH.

capnp :')

Доброе утро ! Можно уточнить: есть таблица mergetree в ней 5 полей : дата , поле1,2,3 (поля 1,2,3 - это ключ) Вопрос: если мне надо искать по дате и полю2, нужно ли дату включать в ключ?

т.е. сейчас так mergetree date, (поле1,2,3) надо ли переделать на date, (date, поле1,2,3 )?

Как мне кажется нет. CH эффективно фильтрует по дате и так.

нужно

Как минимум Т как буфер перед кликом. Что особенно актуально, если данные в клик поступают из оракла или мускуля, тк тарантул умеет реплицировать из них

а есть где-нибудь хорошие доклады про Tarantool?

за этим можно сходить на канал татарнтула )

добрый день. подскажите пожалуйста по такой ошибке "Cannot drain connections: cancel first" возникает при простом селекте, в where первичный ключ, лимит 1 запрос делается со стороны бэкенда (go) с чем может быть связана эта ошибка?

господа, подскажите, пожалуйста, неофиту - каким образом быстрее всего можно залить в CH данных от 100 Гб?

Если данные рядом с clickhouse - clickhouse-client, если далеко - то через http-post на порт 8123(или какой у тебя указан в конфиге)

Есть вопрос про внешние словари. Подключаю по odbc постгрю. Как мне описать атрибуты для форматов postgres boolean и jsonи ? Кто сталкивался с использованием постгри как внешнего словаря?

Если данные рядом с clickhouse - clickhouse-client, если далеко - то через http-post на порт 8123(или какой у тебя указан в конфиге)

Спасибо! JDBC, как я понимаю, вариант так себе?

JDBC работает нормально. Нареканий к нему нет. Просто чтобы загрузить много файлов многопоточно в clickhouse - не обязательно использовать jdbc. Если данные рядом - то ls | xargs -P 20 | cat | clickhouse-client (ну это приблизительно на bash) и вот вам в 20 потоков загрузка

Есть вопрос про внешние словари. Подключаю по odbc постгрю. Как мне описать атрибуты для форматов postgres boolean и jsonи ? Кто сталкивался с использованием постгри как внешнего словаря?

попробуйте boolean в UInt8 json - может можно в строку загнать и потом visitParam* функциями забирать?

Игорь, спасибо! Главный вопрос как это в конфиге описать? могу ли я прям в конфиге преобразование типов делать или мне это нужно сделать на стороне postgres?

просто пока что кейс следующий - в спарке генерятся пачками фейковые данные, которые потом через JDBC засовываются в СН.

<attribute> <name>bool_val</name> <type>????????</type> <null_value>0</null_value> </attribute>

UInt8

<!-- Тип столбца. (Как столбец понимается при загрузке. В случае MySQL, в таблице может быть TEXT, VARCHAR, BLOB, но загружается всё как String) --> <type>String</type>

если не заработает - то на стороне постгри приводить, видимо

просто пока что кейс следующий - в спарке генерятся пачками фейковые данные, которые потом через JDBC засовываются в СН.

Я проходил это. Совет. Если Вы использеуте спарк-стриминг - делайте окна перед sinkFunction. Нужно либо по времени, либо по колличеству ограничиваться. Я сейчас из стриминга пуляю куски по 50 тысяч записей

а есть где-нибудь хорошие доклады про Tarantool?

Вас видео интересует или статьи?

@DennisAnikin, а где почитать и как попробовать репликацию из oracle в tarantool?

Я проходил это. Совет. Если Вы использеуте спарк-стриминг - делайте окна перед sinkFunction. Нужно либо по времени, либо по колличеству ограничиваться. Я сейчас из стриминга пуляю куски по 50 тысяч записей

Спасибо. Стриминг пока не используем. А сможете соориентировать, для СН в докер-контейнере сколько оптимально JDBC коннектов поднимать?

Здравствуйте! Такой вопрос: к примеру, движок AggregatingMergeTree агрегирует записи не сразу, а по достижению какого-то лимита не сагрегированных записей, как я понимаю (заполнения куска). Как указывается величина куска для агрегирования?

агрегация происходит при слиянии

Нет гарантии о каком то точном времени слияния. По этому данные при запросе из такого движка нужно доагрегировать

а когда происходит слияние?

Добрый день! А есть ли какие-то советы, как данные быстрее всего перелить из таблицы_1 в таблицу_2 (поменялись первичный ключ и ключ сэмплирования)? Есть примерно такой запрос: INSERT INTO table_v2 SELECT * from table_v1 where dt = '2017-02-15'; . Как его сделать побыстрее? Лучше делать через CLI или через HTTP-запрос? Какие переменные установить, чтобы ускорить процесс? Нужно перелить значительный объем данных за многие десятки дней.

Скорость по мере переливки, кстати, почему-то медленно линейно падает в течение всего процесса (page cache не виноват, скорость всё падает и падает и при достижении его размера) (боюсь, она вообще в ноль упадет в какой-то момент)

Результат тестирования Jasper Reports Server с ClickHouse: 1. строит неверные запросы при построении AdHoc View (похоже на баг самого сервера) 2. при любых джойнах использует алиасы для таблиц Непонятно, как заставить работать =(

А есть ли способ сделать Auto_Increment в Clickhouse?

только на промежуточном демоне

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

А всяческие варианты типа default count(*) это совсем извращения, да?)

ну это будет иметь соответствующий ужасающий penalty по скорости :)

Ага, понятно, спасибо :)

может ли кто-то подсказать по ошибке? [49] DB::Exception: Cannot drain connections: cancel first

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

Второй раз за день всплывает тема батчилок :) А кто что использует? У нас всё руками, но чуйка говорит, что это как-то странно.

А есть ли способ сделать Auto_Increment в Clickhouse?

Как вы хотели его применять?

Ну я подумываю использовать ReplacingMergeEngine, чтобы заменять некоторые записи. Для этого думал сделать Auto_Increment, а иногда пихать строки с новой версией и нужным id, чтобы строчку заменить