алхимию пользуем в связке с кх, особо не жалуемся

+1

О. А сколько колонок в таблицах?

не помню, штук 50 что ли. а какое это имеет значение?

в разрезе данного вопроса :)

Интересует размер моделей в смысле "это наш класс клика, у него три сотни полей".

Ну т.е. я раньше прикидывал кейсы использования КХ и у меня получалось, что либо ORM не нужен, либо КХ используется как простобаза. Видимо, что-то пропустил.

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

у неё есть core часть и orm часть, которая обертка над первой

Да, но объём кода и работы не тот же, что без Алхимии?

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

не пробовал без неё)

ну в целом разница будет не велика

select([func.toMonday(table.x.time), func.count(), func.groupUniq(table.c.user_id)]).where(table.c.time >= X).group_by(func.toMonday(table.x.time))

вот пример запроса

думаю, можно представить, сколько он будет занимать на raw sql

Такой же, что и в raw, собсно.

в целом да

только табличку описать надо будет :)

но структурированней получается эт точно

А нафига тогда? :) Привычка?

крайне полезно при генерации запросов

на ходу

ну и да, привычка

Понятно. Спасибо. :)

оверхеда почти нет, так что почему бы и нет

А как работает alter колонок? UInt64-> Int64, UInt32 -> UInt64, Float32 -> Int32, при мердже меняет или на лету (во время select)? create table x (a Float32) engine=MergeTree partition by tuple() order by tuple(); insert into x values (-1000), (4.3), (3.14), (3000), (-100400.4); alter table x modify column a Int32;

А как работает alter колонок? UInt64-> Int64, UInt32 -> UInt64, Float32 -> Int32, при мердже меняет или на лету (во время select)? create table x (a Float32) engine=MergeTree partition by tuple() order by tuple(); insert into x values (-1000), (4.3), (3.14), (3000), (-100400.4); alter table x modify column a Int32;

Преобразует сразу - во время ALTER.

т.е. на колонке размером 1 TБ, придется ждать?

Да.

Да.

ОК, Спасибо.

А кстати insert в этот момент, пока alter идет, в каком типе делать?

А никто не проверял, реальный perforamce String vs Fixed String. Есть строка, размер которой от 1 до 1024, что реально быстрее? Вроде как fixed string должен быть, а как на самом деле?

А никто не проверял, реальный perforamce String vs Fixed String. Есть строка, размер которой от 1 до 1024, что реально быстрее? Вроде как fixed string должен быть, а как на самом деле?

FixedString имеет смысл использовать, когда размер действительно фиксированный. То есть, не от 1 до 1024, а всегда 32, например. В остальных случаях лучше предпочитать String.

FixedString имеет смысл использовать, когда размер действительно фиксированный. То есть, не от 1 до 1024, а всегда 32, например. В остальных случаях лучше предпочитать String.

Спасибо

Denis (0) увеличил репутацию Alexey Milovidov (3)

/stat@combot

combot.org/c/-1001080295593

О, кстати, Алексей, хотел спросить, насколько плохая идея вместо fat width таблицы использовать много, объединенных по индексу FixedString(32)?

О, кстати, Алексей, хотел спросить, насколько плохая идея вместо fat width таблицы использовать много, объединенных по индексу FixedString(32)?

А какой в этом смысл (какое преимущество)?

То есть, сам по себе memcmp для 32х байт - это довольно быстро, но там растет число джоинов

А какой в этом смысл (какое преимущество)?

Да никакого - расширял схему, добавляя таблицы и не ломая совместимость

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

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

Много JOIN-ов плохо работает - как по удобству (сейчас более одного JOIN-а в запросе писать трудно), так и по скорости (для JOIN правая часть сохраняется в хэш-таблицу и по ней делаются lookup-ы).

То есть, лучше сделать колбасу без возможности миграции?

Если только она не слишком широкая. Слишком - это многие тысячи столбцов - тогда вставки будут медленными. Впрочем, если всегда вставляется всё сразу, то толстая таблица всё-равно лучше.

Хотя я сам склоняюсь к такому варианту - я слишком думал о flexibility, забывая, что ch - это не мускуль с row oriented идеологией

У меня толстые массивы

Колонок там будет точно меньше тысячи

Ок. В зависимости от толщины массивов может быть разумно уменьшить index_granularity а также размер пачки при вставке.

Ок. В зависимости от толщины массивов может быть разумно уменьшить index_granularity а также размер пачки при вставке.

Я думаю, у меня в почтах именно размеры вставки не такие впечатляющие, как в кликах пользователей. Там будут жырные инсерты по тысяче записей - каждая на 2 килобайта текста, скажем, раз в 10 секунд

А вот медленный селект - это проблема, да

Я думаю, у меня в почтах именно размеры вставки не такие впечатляющие, как в кликах пользователей. Там будут жырные инсерты по тысяче записей - каждая на 2 килобайта текста, скажем, раз в 10 секунд

Это Ок.

господа а как долго может продлится стадия Starting up tables. ?

чот уже 20 минут в логе это последняя запись

данных не скзать что много. чуть больше 1t. но по ресурсам не видно что бы что то потреблялось. просто висим и всё

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

Также он выводит, какие именно таблицы он загружает.

сам себе отвечу. 30 минут.

Также он выводит, какие именно таблицы он загружает.

увы нет

увы нет

Наверное вы переключили логгирование в information. 2018.08.06 22:45:31.162028 [ 2 ] <Debug> default.hits_1000m (Data): Loading data parts

да конечно в information

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

на трассе слишком много информации. я бы и инфо наверное бы хотел избавить от <Information> HTTPHandler: Done processing query

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

нее. монги там давно нету. чистый http

Наверное для соединения с этим словарём такой таймаут.

хм. проверю. спасибо

/stat@combot

combot.org/c/-1001080295593

подскажите, как посмотреть подробности, в чем именно ошибка текст ошибки такой [ClickHouse SQL] Code: 36, e.displayText() = DB::Exception: Sampling expression must be present in the primary key, e.what() = DB::Exception

это был запрос на создание таблицы

У нас Kafka, но кворум победить не смогли. Задолбало ловить рандомно конфликты нод ZooKeeper, волево вырубили кворум.

А вы писали на какой-то одной реплике, или пытались на многих (в то смысле, что это проблема именно Кафка<->кворум, или параллельность<->кворум)? Я так понимаю, если запустить четко один поток записи на одной реплике, через MV например, и кворум, то должно быть ок, кворум не любит только параллельную запись.

У нас Kafka, но кворум победить не смогли. Задолбало ловить рандомно конфликты нод ZooKeeper, волево вырубили кворум.

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

А вы писали на какой-то одной реплике, или пытались на многих (в то смысле, что это проблема именно Кафка<->кворум, или параллельность<->кворум)? Я так понимаю, если запустить четко один поток записи на одной реплике, через MV например, и кворум, то должно быть ок, кворум не любит только параллельную запись.

Это точно не проблема Кафки, т.к. конфликт кворума возникал в основном без неё, когда мы интенсивно скриптом мигрировали данные из Эластика в КХ.

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

Смирились. :) На носу придумывание и раскатка мастер-базы — поднимем какой-нибудь MySQL / PostgreSQL, раз в час будем сверять с КХ количество строк в таблицах, если что, дольём.

коллеги, добрый день! по чатику найти не смог, поэтому напишу повторно, звиняйте, если что. баг: 1. таблица id, str, int 2. строка значений: 1, 'some text \\', 0 3. при выгрузке в csv получаем строку 1,"some text \",0 4. при этом получается экранированная слэшом кавычка, что не даёт правильно распарсить csv штатными средствами

А хотелось бы чтобы там осталось \\?

ну, конечно

версия 1.1.54390

т.е. даже не так: там должно быть \\\\, чтобы обратно эта строка в кавычках разбиралась как \\

Подскажите, наиболее быстрый способ загрузки данных в КХ. Данных очень много. И еще вопрос целесообразно ли использовать kafka?

Подскажите, наиболее быстрый способ загрузки данных в КХ. Данных очень много. И еще вопрос целесообразно ли использовать kafka?

csv, можно в несколько потоков загружать

Подскажите, наиболее быстрый способ загрузки данных в КХ. Данных очень много. И еще вопрос целесообразно ли использовать kafka?

csv Например, сейчас у меня из мускуля 1 час экспортится 50гигов csv. В КХ импортится все это минут за 6-7

Порядка 300-400 гб в час в csv файлах

Порядка 300-400 гб в час в csv файлах

распараллель

Подскажите, наиболее быстрый способ загрузки данных в КХ. Данных очень много. И еще вопрос целесообразно ли использовать kafka?

Лей напрямую в stdin

Подскажите, наиболее быстрый способ загрузки данных в КХ. Данных очень много. И еще вопрос целесообразно ли использовать kafka?

Кафка хороша как накопитель. Грубо говоря, КХ любит одну пачку INSERT на тысячу строк, а не тысячу INSERT по строке. Соответственно, ставится Кафка, в которую в топики со всех концов льются понемногу данные, а с другого конца раз в секунду, например, что-то выгребает и стопками впихует в КХ.

https://stackoverflow.com/questions/47708424/importing-from-mysql-dump-to-clickhouse

Писал еще давненько. Лучше способа не нашел

Писал еще давненько. Лучше способа не нашел

А есть библиотека, которая обращается к client и напрямую льет данные в stdin?

А есть библиотека, которая обращается к client и напрямую льет данные в stdin?

А чем cat не устроил?

А чем cat не устроил?

У меня не один файл, а несколько тысяч и новые выпадают раз в 5-10 секунд. Просто плохо представляю как это сделать через cat. Могли бы вы поподробнее объяснить.

cat * |

лучше уж тогда tail -f *|