Коллеги, а я вот что-то подзапутался. Есть ли сейчас какая-то БД,

в которую можно запушить в таблицу/коллекцию JSON, а потом иметь к нему SQL доступ? Это нужно как стейджинг для сбора данных до того, как корежить основную Clickhouse таблицу, соответственно данных там будет мало, до миллиона строк.


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

джисон ту мап и не надо оэрэмить на ровном месте

поясни пожалуйста, что именно гуглить?

пойсон или ждейсон

Так Бартунов вроде рассказывал, что они много хорошего для работы с jsonb сделали, в том числе для запросов по самому джсону. Или предполагается ещё бо́льшая вложенность?

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

мы льем 100 тыс записей в секунду в кликхаус. Иногда эту таблицу надо менять, добавлять новые поля. Хочется сделать так, чтобы можно было протестить, что вообще будет заливаться без миграций БД. Можно или сделать какой-то принимающий сервер, который будет, увидев новое поле, автоматически мигрировать стейджинговый кликхаус (ну рано или поздно он провернет это на проде), или писать стейджинговые данные не в кликхаус, а в другую БД, которая по своему SQL не катастрофически отличается от кликхауса. Условно считаем, что у постгреса и мускля достаточно одинаковый SQL для простых задач. Записать поток тестовых данных в постгрес можно, но тогда надо будет весь читающий код переделать на ORM, который будет с кликом по одному работать, а с постгресом через раскрытие json поля.

Если устроит ограниченный SQL, который имеет Elastic Search, то можно его попробовать.

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

пойду посмотрю, спасибо

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

да, есть старая схема, а тут приехали новые данные от флюссоника, который ещё в ветке запущен

InfluxDB?

я посмотрю, спасибо

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

потому что тогда надо будет кроме редактирования флюссоника ещё и миграции в кликхаусе гонять. А если получится лить в коллекцию жсонов, то проверить, что уходит, _возможно_ получится и без этого

а, типа бесхемное тебе надо. понял. тогда еластик, посмотри couch еще, он кстати эрланговый

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

А нельзя сделать View в PostgreSQL, которая раскрывает JSON поле в ту же структуру, которая в Clickhouse?

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

С подтверждением от человеческого существа ака оператора — вполне, совсем автоматически чревато.

такое еще https://github.com/tarantool/avro-schema

я как раз хочу без схемы залить

ну тут про другое - тут как раз сравнение мутация схем

ага. Это сложная и важная тема, да

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

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

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