параметры ?
{"cpuAbi":"arm64-v8a", "openGlVersion":"3.2", "screenResolution":"480"}
Насколько помнится, в старых версиях КХ манипуляций с JSON кроме extract-функций нет
Относительно новый кликхаус у меня. И проблем обновится нету.
Насколько вижу по изменениям на githhub, такого рода функциональность не завезена вроде. Если не попробовать JSON_QUERY, но не вижу примеров удаления элемента с этим синтаксисом... Или можно попробовать создать таблицу с парсингом вашего JSON, куда переливать данные без ваших полей.🤔 https://github.com/ClickHouse/ClickHouse/pull/24148
если json именно такой простой, то я бы удалил регекспом. Или (что лучше) перевел бы его целиком в Map/массивы и работал бы с ним дальше уже в таком виде.
Он не всегда одинаковый :(
А валидации JSON не было со стороны клиента предусмотрено? (хотя о чем это я) Через ifNull можно попробовать, или при парсинге JSON через MV/ручками сделать Nullable data type с default полями. Можно ручками скрипт сделать, который удалять будет поля из JSON перед пушем в базу. Вариантов исполнения много.
нужен JSON_MODIFY, как в ms sql. создал фичереквест. поставьте лайк если не жалко https://github.com/ClickHouse/ClickHouse/issues/30408
Меня смущает отсутствие именно кейсов разрешения проблем, я вижу, что в случае введения этого CH могут начать использовать как документоориентированное хранилище, но это мое имхо.
вы походу пропустили последнее видео от алексея (ссылка в закрепе если что). уже сейчас многие используют кликхаус вместо эластика для хранения логов и прочих структурированных данных, а в первом квартале 2022 добавят новый тип поля JSON, чтобы это стало ещё проще и эффективнее. так что количество кейсов буде только расти.
Я не пропускал, я просто пытаюсь понять какие могут быть use case и рационализировано ли внедрение этой фичи :)
нет конечно таких кейсов нет ни одного, а Map, Nested И Json были добавлены в кликхаус просто так. в остальных sql базах функции для работы с json тоже добавили просто так. более того даже в js он не был нужен. сарказм off. серьёзно, для меня использование json настолько очевидно, что я даже не понимаю, как кому-то в голову могло прийти, что он не особо нужен и не знать при этом ни одного кейса. в этом чатике уже кучу раз поднимались такие кейсы, я не вижу смысла переписывать это заново, а так же не особо хочу описывать свои кейсы. если вам это не надо, то просто не используйте это. видимо у вас просто никогда не было таких кейсов.
Хранить сырые данные в json и разбирать на плоский таблицы
Простите, конечно, за оффтоп, но ваше выражение сейчас показалось мне слишком грубым.
Ну скорее всего страдать будут тогда. Хотя впрочем возможно UPDATE одного ключа в JSON у кх будет работать быстрее чем в допустим postgresql или где еще есть JSON(B) тип данных, тк в кх будет колоночное хранение
Возможно, не стану отрицать, просто в моих кейсах немногочисленных решали разворачивание JSON скриптами на Python для КХ. Просто проверить надо будет, наверное, что да как. :)
У некоторых к сожалению в JSONах, может быть черти что в колонках, и заранее развернуть все не получится (или будет очень сложно)
приношу извинения за тон.
Да, сталкивались с подобным. У мня как провайдер информации один из страдает непредсказуемым поведением в JSON, если вспомнить кейс нестандартных JSON, поэтому руками пилили. 😅
Многие с придыханием ждут, что бы руками можно было не пилить. Плюс забавная штука будет, что кх будет максимально компактно пытаться упаковывать JSON колонки в партах, те если допустим там только 0 и 1 будет, то кх использует UInt8
не обязательно использовать апдейты, можно было бы использовать MV + ReplacingMT и добавление/обновление одного поля в json с помощью JSON_MODIFY, но сейчас пока нет такой функции, а делать такое на регулярке - это себе в ногу стрелять.
Если входные данные строго структурированы - смысла нет. А если постоянно подключаются новые системы-источники и есть вероятность, что входящие данные не распарсятся корректно, то где-то нужно хранить исходные данные. В файлах, отдельной базе или самом кликзаузе
Обсуждают сегодня