Просто неудобно такие стряпать - да

Мы просто написали билдер запросов с fluent подобным интерфейсом

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

Мы просто написали билдер запросов с fluent подобным интерфейсом

Не выкладывали в опенсорс случаем? Сами аналогичное планируем и местами уже сделали

Не выкладывали в опенсорс случаем? Сами аналогичное планируем и местами уже сделали

Выложили, но он для php

Выложили, но он для php

В можно ссылочку у нас тоже php

https://github.com/the-tinderbox/ClickhouseBuilder

https://github.com/the-tinderbox/ClickhouseBuilder

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

Да, без морды )

Эх, жаль :)

Ну, морду всегда напилить можно :)

Ну, морду всегда напилить можно :)

Это я уже делаю, в процессе пытаюсь придумать универсальную структуру данных если все получится - тоже выложу

Это я уже делаю, в процессе пытаюсь придумать универсальную структуру данных если все получится - тоже выложу

Это json называется. Я для похожих случаев делал так: с помошью if-ов и группировки формировал json-строку с различными колонками и значениями в объект или массив объектов. И уже на клиенте парсил значение колонки как json-объект

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

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

да, было бы интересно! PS а прямо в запросе нельзя ли создать nested структуру? что бы у меня атрибуты были в виде массива key/value ?

да, было бы интересно! PS а прямо в запросе нельзя ли создать nested структуру? что бы у меня атрибуты были в виде массива key/value ?

Сложно сказать, мне проще пока формировать json-строку, у меня nodejs?

А зачем если можно подключить таблицу по MYSQL/odbc?

https://clickhouse.yandex/docs/ru/dicts/external_dicts_dict_sources.html Так? Но же и есть подключить как словарь.

https://clickhouse.yandex/docs/ru/dicts/external_dicts_dict_sources.html Так? Но же и есть подключить как словарь.

* Добавлены табличные функции mysql и odbc и соответствующие движки таблиц MySQL, ODBC для обращения к удалённым базам данных. Функциональность в состоянии "бета". из changelog

а ктото пробовал заливать данные через внешние словари, или это извращение?

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

сейчас мне приходится формировать файл tsv через copy и посылать post запросом

Чем не решение

copy требует суперюзера

вот кусок кода с примером как ходить в mysql https://github.com/yandex/ClickHouse/blob/798299ba8934aeee8e1106e457062fc13df41b40/dbms/src/TableFunctions/TableFunctionMySQL.h

этого в 0.1.36 еще нету?

а стоп 0.1.36 это от jdbc драйвера версия

блин

у меня 1.1.54342 стоит

copy требует суперюзера

А это сильно проблема?

админы могут отжать такие права

госконтора все дела

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

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

как обходной метод - поставьте пакет с виртуализацией

и внутри виртуалки уже крутите что хотите

есть еще дба)

вот они просто пойдут и суперюзера отберут

Если есть ДБА то я бы тоже разработчиков в базу не пускал) На самом деле это просто задача по которой именно с ними вы и должны проконсультироваться как её лучше сделать, а не городить костыли

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

которые вообще хз кто и где

Ну, сделайте хранимку и дайте прав только на нее и наплевать кто её запускает

я просто думал, что как раз copy и отправка через post это костыль

Исходите их того, что у КХ 2-а стандартных интерфейса ввода/вывода: http, нативный протокол поверх tcp + есть Kafka Engine для возможности напрямую читать с Kafka

я планирую сделать 2-3 таблицы replacedmergetable + штук 10 join + гдето 20-30 внешних словарей

Штук 10 join для КХ звучит как угроза)

не, они будут по 1 использоватся

Привет всем. Как лучше всего поделить транзакционную модель и субъектную? Вот у меня есть куча транзакций, подгружаемых раз в 15 минут в кликхаус, есть отдельная БД, в которую из этих транзакций складывается инфа о субъектах (кто, кому). Естественно, подразумеваются запросы в духе "все люди, заплатившие за период с X по Y больше N денег компании с айдишником A". В кликхаусе данные ненормализованы, естественно. В субъектной базе до 4 НФ. Теперь мне нужно научиться быстро делать смежные выборки по двум БД. Первая мысль была класть транзакции в нормализованную БД тоже, в урезанном виде, но чего-то постгрес жрёт под это действо как не в себя. Может, кто сталкивался с чем-нибудь подобным, и нашёл более адекватное решение?

есть сущность, и есть у нее свойства

стандатрый путь CH это Dictionaries и Arrays

Это платёжный шлюз. Я могу запихать услуги и провайдеров в dictionaries, но вот клиентов - точно нет. Кроме того, их нужно матчить по-хитрому. Допустим, у человека в одном сервисе есть email, в другом есть телефон, в третьем - телефон и email. В четвёртом - ИИН. В пятом - ИИН и email. В шестом - домашний адрес, в седьмом - домашний адрес и ИИН. Я должен знать, что это один человек (или близкая группа людей). Удобней всего, насколько я понимаю, такой матчинг в нормализованном data warehouse проводить. Но сами транзакции удобней хранить в clickhouse. Отсюда и вопрос.

Клиентов до матчинга между разными по сигнатуре услугами 8 миллионов примерно. После матчинга остаётся где-то 5. Кроме того, их каждые 15 минут становится больше. Поэтому, думаю, словарь тут не подходит. Если я ошибаюсь - поправьте, пожалуйста.

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

йоу

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

а так как с вложенными структурами плохо работает

то только join

в постгресе связь 1 ко многим с кучей таблиц

и в каждой таблице 1-10 свойств

в постгресе связь 1 ко многим с кучей таблиц

Звёздочка? Угу, сейчас так и делаю. Видимо, это единственный вариант. Оуке, спасибо. Тогда просто подумаю, можно ли записывать не все транзакции, или по-максимуму выкинуть лишнюю инфу из них.

у меня стоит шедулер который раз в секунду собирает все что пришло и отправляет в кликхаус

постгрес приводит все к нужному мне виду

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

В общем, теперь я вижу это так: 1) получаем сырые данные в CH 2) нормализуем, переливаем в PG 3) джойним, разворачиваем в аналитические таблицы, переливаем в другую БД в CH Третий шаг не обязателен, нужен только в том случае, если сам postgres тупит в аналитике. Пожалуй, его можно сдвинуть в сторону data mart по стандартной схеме. Я правильно всё понимаю?

а почему сырые именно в клихаус?

почему сырые в постргес не записать?

Ну, я просто следовал стандартной схеме, где operational data storage собирает данные со всех master data storage, и хранит их в ненормализованном виде. Поскольку CH лучше подходит для хранения ненормализованных данных, то его и взял. Плюс через полгода примерно мы займёмся сбором не только фактологической информации, но и поведенческой. По сути, логов. В этот момент времени, как я опасаюсь, информации станет слишком много для постгрешки.

монго?

Ну это уже зоопарк какой-то будет.

у нас сейчас постгрес mssql и кликхаус)

скоро еще будет или монго или кассандра

а куда без зоопарка?

для каждой задачи свое средство

универсальность враг производительности

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

в монго можно писать вообще все что есть

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

Вот хорошее видео про зоопарк в почте России, и про КХ в нём https://www.youtube.com/watch?v=6JwMho6UfK4

СloutchDB докучи, у вас много разных БД в прод.

А, по поводу шидулера, кстати. Есть ли какие-нибудь более-менее готовые штуки для этого типа задач? ETL по расписанию, то бишь. Если будет мониторинг какой-нибудь из коробки - вообще будет отлично. Пока что Celery использую. И понял, что, возможно, пишу велосипед.

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

а в постгресе или кликхаусе нужно заранее поля создать

написать обработку

Sounds legit

у меня spring запускает

мне кажется для сбора поведенческой информации монго почти идеален

А, по поводу шидулера, кстати. Есть ли какие-нибудь более-менее готовые штуки для этого типа задач? ETL по расписанию, то бишь. Если будет мониторинг какой-нибудь из коробки - вообще будет отлично. Пока что Celery использую. И понял, что, возможно, пишу велосипед.

luigi, apache airflow на python

Шпашиба

Engine = MergeTree(timestamp (id), 8192) PARTITION BY toYYYYMM(timestamp) ORDER BY timestamp DESC ?

Добрый день, попробовал похожий вариант: Engine = MergeTree PARTITION BY toYYYYMM(event_date) ORDER BY (event_date, project_id, tpl_id) DESC но сервер ругается на DESC, выходит не получится хранить данные в обратном порядке для быстрой выдачи.

Нет. Лучше поставить новый компилятор. Если есть принципиальные соображения, по которым надо использовать старый (например, у вас форк компилятора под особое железо), то надо вручную адаптировать код.

Спасибо, собрал через 7.2 из devtoolset, заодно свое творчество уже под с11 перевел :)

Приветствую! Подскажите, пожалуйста, самостоятельно найти ответа не получилось. Можно ли каким-то способом использовать 2 разных limit-by ? например SELECT day, client, domain, count(*) as count FROM table ARRAY JOIN domain GROUP BY toDate(date) AS day, client, domain ORDER BY day ASC, client ASC, count DESC LIMIT 2 BY day, client LIMIT 10 BY dayт.е. получить в итоге по 10 записей на day, а внутри по 2 записи на day, client. т.е. по 5 уникальным client на день

у меня не получилось

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

а как использовать set таблицы?

where not tlds in (select domain from whitelisted) - не работает, говорит, что нет read для set не поддерживается

а просто not tlds in whitelisted вообще не о том

where not tlds in whitelisted