Что-то в доке не могу найти инфы по пользовательским функция и процедурам. Хочу корреляцию Пирсона вписать, не могу найти как

Что-то в доке не могу найти инфы по пользовательским функция и процедурам. Хочу корреляцию Пирсона вписать, не могу найти как

имхо никак с++

тут будут вопросы атомарности, достоверности данных ( что все записались ) можно просто отдельную таблицу -- типа фиксация пачки данных и делать из нее max()

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

replacing может не успеть хлопнуть записи

replacing может не успеть хлопнуть записи

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

По максимальному значению датывремя точнее

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

Да, я бы попробовал несколько вариантов 1) ReplaceMerge 2) Писать в отдельный MergeTree -- EventDate,UserId,EventDateTime, logId -- где logId какой-то int64 ключь uid -- хоть timestamp когда вы получили лог

Далее найти оптимальный

Да, я бы попробовал несколько вариантов 1) ReplaceMerge 2) Писать в отдельный MergeTree -- EventDate,UserId,EventDateTime, logId -- где logId какой-то int64 ключь uid -- хоть timestamp когда вы получили лог

2) а что потом с этим MerageTree делать??. Спасибо вам большое за наводку, попробу Replace с указанием версии в timestamp.

2) а что потом с этим MerageTree делать??. Спасибо вам большое за наводку, попробу Replace с указанием версии в timestamp.

Делать отдельный Select user_id ,max(logid) from group by user_id

Вот как видится схема:

Вот как видится схема:

пробовать) и смотреть где "грабли" будут)

Надо ))) спасибо и Всех с наступающим )))

Владимир, приходит от пользователя допустим 100 логов, мы их парсим и обрабатываем один за одним, а не паралелим. Простите за глупый вопрос а как пачку при помощи JS вставить в КХ?

В случае с js не получится сделать нормальный батчер (если только не nodejs), т.к. клиент вообще вещь непредсказуемая и напрямую с браузера это слать - плохо. Хорошо иметь прослойку, которая будет делать некие вычисления и затем уже пачками складывать логи в кх

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

В случае с js не получится сделать нормальный батчер (если только не nodejs), т.к. клиент вообще вещь непредсказуемая и напрямую с браузера это слать - плохо. Хорошо иметь прослойку, которая будет делать некие вычисления и затем уже пачками складывать логи в кх

Именно nodejs обрабатываем, оговорился ранее.

Именно nodejs обрабатываем, оговорился ранее.

Пффф...тогда не вижу проблемы написать прослойку, которая будет хранить прежнее состояние в redis (но fault tolerant) и дописывать в КХ уже новое состояние и тут же складывать его в redis.

Пффф...тогда не вижу проблемы написать прослойку, которая будет хранить прежнее состояние в redis (но fault tolerant) и дописывать в КХ уже новое состояние и тут же складывать его в redis.

А ReplacingMergeTree чем плох?

А ReplacingMergeTree чем плох?

Плох тем, что вам надо будет все запросы в эту таблицу делать с final. Мы тоже используем этот движок. Меня сейчас закидают, но это работает и работает сносно! :) У нас есть таблица в которой уже около 100 колонок и не больше 100 000 записей. В фоне мы агрегируем данные и кладем в таблицу типа Buffer, буффер при накоплении 500 строк или по прошествию 1 минуты скидывает данные в таблицу. Раз в 5 секунд вызывается OPTIMIZE TABLE ... PARTITION ... (партиция всего одна). Запросы все равно шлем с final (так, на всякий случай). Вобщем схема работает и решает даже на таких костылях поставленную задачу лучше чем MySQL и Postgres. Поверх CH у нас еще слой с бизнес логикой, которые может в один запрос отправить от 1 до n файлов, где n - кол-во фактов, которые вычисляются в подзапросах, которые джойнятся к таблице. Вобщем схема сложная, но запросы отрабатывают за 0.003, в редких случаях (когда транспонируем nested колонки в строки) время выполнения занимает 0.2, но это потому что читается порядка 50Gb для выполнения запроса и по этим 50Gb данных агрегация происходит.

Плох тем, что вам надо будет все запросы в эту таблицу делать с final. Мы тоже используем этот движок. Меня сейчас закидают, но это работает и работает сносно! :) У нас есть таблица в которой уже около 100 колонок и не больше 100 000 записей. В фоне мы агрегируем данные и кладем в таблицу типа Buffer, буффер при накоплении 500 строк или по прошествию 1 минуты скидывает данные в таблицу. Раз в 5 секунд вызывается OPTIMIZE TABLE ... PARTITION ... (партиция всего одна). Запросы все равно шлем с final (так, на всякий случай). Вобщем схема работает и решает даже на таких костылях поставленную задачу лучше чем MySQL и Postgres. Поверх CH у нас еще слой с бизнес логикой, которые может в один запрос отправить от 1 до n файлов, где n - кол-во фактов, которые вычисляются в подзапросах, которые джойнятся к таблице. Вобщем схема сложная, но запросы отрабатывают за 0.003, в редких случаях (когда транспонируем nested колонки в строки) время выполнения занимает 0.2, но это потому что читается порядка 50Gb для выполнения запроса и по этим 50Gb данных агрегация происходит.

У меня точно будет меньше 100 колонок (5 не больше) и так же до 100.000 записей. Вопрос только такой, зачем слать запрос с final? если без него он может выдать в результате более одной записи?

У меня точно будет меньше 100 колонок (5 не больше) и так же до 100.000 записей. Вопрос только такой, зачем слать запрос с final? если без него он может выдать в результате более одной записи?

Возьмите PostgreSQL ?

Возьмите PostgreSQL ?

Нам это не помогло :)

Но из коробки без тюнинга он работает в два раза шустрее MySQL :)

Нам это не помогло :)

На 5 колонок и 100к записей ?

Нет, у нас 100 колонок и ~70к строк

Но из этих 100 колонок у нас 70 колонок - массивы

Вот, а там у человека 5 колонок, PostgreSQL/MySQL вполне себе должны отлично работать на его задаче.

Вот, а там у человека 5 колонок, PostgreSQL/MySQL вполне себе должны отлично работать на его задаче.

Ну вообще да

Вот, а там у человека 5 колонок, PostgreSQL/MySQL вполне себе должны отлично работать на его задаче.

Задел на будущее ))) Кто знает как хотелки выростут.

Я думаю там и MySQL справится :) Если не ловить кейсы когда select col1, col2, col3 from (select ........) работает быстрее select col1, col2 from (select ........)

Плох тем, что вам надо будет все запросы в эту таблицу делать с final. Мы тоже используем этот движок. Меня сейчас закидают, но это работает и работает сносно! :) У нас есть таблица в которой уже около 100 колонок и не больше 100 000 записей. В фоне мы агрегируем данные и кладем в таблицу типа Buffer, буффер при накоплении 500 строк или по прошествию 1 минуты скидывает данные в таблицу. Раз в 5 секунд вызывается OPTIMIZE TABLE ... PARTITION ... (партиция всего одна). Запросы все равно шлем с final (так, на всякий случай). Вобщем схема работает и решает даже на таких костылях поставленную задачу лучше чем MySQL и Postgres. Поверх CH у нас еще слой с бизнес логикой, которые может в один запрос отправить от 1 до n файлов, где n - кол-во фактов, которые вычисляются в подзапросах, которые джойнятся к таблице. Вобщем схема сложная, но запросы отрабатывают за 0.003, в редких случаях (когда транспонируем nested колонки в строки) время выполнения занимает 0.2, но это потому что читается порядка 50Gb для выполнения запроса и по этим 50Gb данных агрегация происходит.

зачем слать запрос с final?

зачем слать запрос с final?

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

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

тоесть если в запрос добавить выборку по максимальному значению версии - это будет дольше?

тоесть если в запрос добавить выборку по максимальному значению версии - это будет дольше?

типа argMax?

да

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

Можно использовать что-то типа select ... from (select * from table order by version desc) limit 1 by userId. Но мы limit n by col - вообще сейчас стараемся не использовать, т.к. он багнутый ( Я давно писал репорты на эту тему, но пока ими не занимались.

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

Будем пробовать. и с лимитом и с arg. А в крадце - в чем баг?

Дополнительную базу - очень не хочется на этот сервер ставить

Я точне не могу сказать, но я два разных бага встретил. Первый баг - неверная работа оптимизатора, который выкидывает колонки из запроса, а второй какой то совсем простой, который со слов Алексея фиксится быстро.

Дополнительную базу - очень не хочется на этот сервер ставить

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

как я понимаю для сессионизации вам вообще нужна KV БД, а может даже просто структурами/библиотеками языка сможете обойтись

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

а по KV - я так понимаю это Key-Value базы данных?

да: мемкеш, редис, тарантул

Надо будет посмотреть, чтото легковесное и реплицируемое ), но для начала все же посмотрим на скорость ReplacingMergeTree с final)

да: мемкеш, редис, тарантул

мемкеш - это что за зыерь? Или вы имейте ввиду сохранение в оперативке?

http://memcached.org/

Надо будет посмотреть, чтото легковесное и реплицируемое ), но для начала все же посмотрим на скорость ReplacingMergeTree с final)

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

или это просто игры в больших ребят?

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

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

ну или идти с RDBMS классическим

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

ну тогда делайте это в структурах памяти вашего ЯП/платформы

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

не нужны все эти сериализации, сетевые издержки и т.д.

А реплицируемость?

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

и все компоненты имеют резервные узлы?

поддерживаютя A/A или автоматический A/S режим кластеризации?

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

но это все уже тут оффтоп

и вообще, вы уверены что умеете в репликацию?

если что, тарантул имеет асинхронную репликацию из коробки

и пробовали вообще оценить соотношение P(FAIL)*COST(FAIL) vs COST(REPLICA)

причем второй компонент — он вовсе не из стоимости N серверов и настройки на них БД состоит. вообще-то все приложение надо существенно переписывать и это а) непросто б) долго в) непривычно и короче — дорого.

потом еще это все поддерживать и эксплуатировать

но еще раз, тут это оффтоп

ну не совсем оффтоп

Всем привет! Столкнулись с проблемой, ReplacingMergeTree на 35 миллионов, вытаскиваем данные по условиям типа = in > < Запрос выполняется 70-80 секунд Какие есть варианты ускорения? Куда вообще смотреть?

Всем привет! Столкнулись с проблемой, ReplacingMergeTree на 35 миллионов, вытаскиваем данные по условиям типа = in > < Запрос выполняется 70-80 секунд Какие есть варианты ускорения? Куда вообще смотреть?

>< по дате?

да, по дате

Я вот для себя так и не понял. Индексы – они есть или нет?

индекс или есть один или ни одного.

https://pastebin.com/sDU02FGy - вот такая таблица

Запрос customer_id = type in created > utm_source != ''

да, по дате

Ключевое поле? с поддержкой сэмплирования на =

а у вас, видимо, toDate(created)=event_date ?

Ну он просто создается

надо переключиться на event_date

очевидно

ReplacingMergeTree(   event_date,   (customer_id, event_date),   8192

Так попробуй, посмотри на скорость

Колонок много выдергиваешь?

первую строку

это вообще проверка на существование записи

ReplacingMergeTree(   event_date,   (customer_id, event_date),   8192

Пробуй

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

Новую, создать из селекта можно

Задел на будущее ))) Кто знает как хотелки выростут.

Преждевременная оптимизация :)

Преждевременная оптимизация :)

Классическая ошибка многих

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

Классическая ошибка многих

Вопрос ресурсов, если все будет работать с ReplacingMergeTree по скорости на уровне sql решений, то собственно и огород из базданных городить не надо.

От вопрос ReplacingMergeTree поддерживает реплицирование?

Вопрос ресурсов, если все будет работать с ReplacingMergeTree по скорости на уровне sql решений, то собственно и огород из базданных городить не надо.

+1