DD
ну тогда назвали бы KafkaRows - вопросов нет
Зачем такая привязка, он делает буквально то что обещает.
JSON в каждой строчке
Size: a a a
2020 August 22
DD
окей. а почему JSONEachRow не возвращает тогда "meta", "data", "rows" etc ?
DT
Ну потому, что они не ложатся на формат, тот же TSV тоже не умеет эти поля емнип
S
Dmitriy D
не, это усложнение для клиента, ему теперь надо парсить это поле, а если он хочет импортнуть куда-то, теперь ему надо это поле вырезать и тд, АПИ становится более говнистым. если вы понимаете о чем я.
КЛИЕНТ ВСЕ РАВНО ПАРСИТ JSON ;)
что за ерунду вы говорите? ;)
сделайте что нибудь типа вот такого
и все будет нормально
let result = async fetch();
return result.data;
что за ерунду вы говорите? ;)
сделайте что нибудь типа вот такого
и все будет нормально
let result = async fetch();
return result.data;
DD
это для богатых, а у нас хай лоад. result.data - непозволительная роскошь
DT
Dmitriy D
это для богатых, а у нас хай лоад. result.data - непозволительная роскошь
Что тогда делает JSON тут в первую очередь тогда, он же неимоверно жирен.
DD
ну АПИ весь мир потребляет через джейсон, так что тут выбора нету. мы по сути отдаем байты из одного сокета в другой. так что тут проблемы нету. проблема в том что мы не можем откусить эти левые поля, без оверхеда значительного.
S
Dmitriy D
это для богатых, а у нас хай лоад. result.data - непозволительная роскошь
простите, про хайлоад и JSON в 2020 вы очень смешно сейчас сказали
если у вас "хайлоад"
делайте FORMAT Protobuf
и живите с ним
если у вас "хайлоад"
делайте FORMAT Protobuf
и живите с ним
S
Dmitriy D
ну АПИ весь мир потребляет через джейсон, так что тут выбора нету. мы по сути отдаем байты из одного сокета в другой. так что тут проблемы нету. проблема в том что мы не можем откусить эти левые поля, без оверхеда значительного.
DD
спасибо за ценные советы
DT
тут про оверхед на перекладывания структур в памяти, а не передачи по сети(хотя меня сеть бы больше смущала)
S
Dmitriy D
ну АПИ весь мир потребляет через джейсон, так что тут выбора нету. мы по сути отдаем байты из одного сокета в другой. так что тут проблемы нету. проблема в том что мы не можем откусить эти левые поля, без оверхеда значительного.
вы про streaming json parsing слышали? ;)
вообще то можете
вообще то можете
S
тут про оверхед на перекладывания структур в памяти, а не передачи по сети(хотя меня сеть бы больше смущала)
Дмитрий. покажите публичную доку по вашему API
и примеры SDK?
и примеры SDK?
DT
Дмитрий. покажите публичную доку по вашему API
и примеры SDK?
и примеры SDK?
Та это же не моя API :) Мы так то разные Дмитрии:)
S
ой извините =)
S
Dmitriy D
ну АПИ весь мир потребляет через джейсон, так что тут выбора нету. мы по сути отдаем байты из одного сокета в другой. так что тут проблемы нету. проблема в том что мы не можем откусить эти левые поля, без оверхеда значительного.
покажите документацию на API и примеры SDK?
DD
я хотел обратить внимание разрабов на проблемы с форматом джейсон, еще раз. так как тикеты я заводил 1.5 года назад. думал что за 1.5 года были какие-то фиксы. сейчас в кликхаусе нету нормальной возможности работы с джейсоном. в то время как все современные СУБД эту возможность давно уже имееют. вот и все. а как зафиксать на своей стороне мы найдем способ
DT
Dmitriy D
я хотел обратить внимание разрабов на проблемы с форматом джейсон, еще раз. так как тикеты я заводил 1.5 года назад. думал что за 1.5 года были какие-то фиксы. сейчас в кликхаусе нету нормальной возможности работы с джейсоном. в то время как все современные СУБД эту возможность давно уже имееют. вот и все. а как зафиксать на своей стороне мы найдем способ
Ну, это не совсем проблемы, а так сказать as intended, те предлагать можно новый формат, но его поддержку будут реализовать только когда будут достаточное кол-во желающих его
DD
ну я бы не сказал что это не проблемы. вот я например увидел, что уже есть функции по работе с дежйсоном. но их нельзя заюзать для того же FORMAT JSON. тоже intended?