×Закрыть

Моделируем NoSQL — есть ли аналог XSD?

Общеисзвестно что в NoSQL в большинстве своем нет аналога иксемельного XSD, когда схему модели данных можно использовать для
— Создания и мейнтененса модели
— Валидации документов на правильную структуру
— Визуализации модели

В реляционках есть ERD + DDL которые совместно с субд выполняет все эти задачи, в хмл — хсд.

А что в НоСКЛ? Валидация только в коде, моделирование только в проприетарных тулзах?

Для JSON есть БЭТА проект джсон схемы (и это за десятилетия существования джсон и носкл), до сих пор не является индустриальным стандартом.

Есть у меня к этому интерес корыстный и потому вопрос к сообществу — какие ОБЩЕПРИНЯТЫЕ варианты создания\хранения\моделирования моделей данных для следующих носкл форматов вы знаете:
— JSON
— Graph
—Knowledge Graph
— ML data models (знаю что это не совсем то и тут часть моделей в реляционном нормализванном формате, но все же)

Создание модели данных в виде набора семплов сообщений\документов выглядит как шаг назад и имеет свои недостатки (как и плюсы).

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Я тут как раз смотрю курс на linkedIn learning:
www.linkedin.com/...​ql-for-sql-professionals

Так вот, там прямо говорят в самом начале, что NoSQL-базы принципиально schemaless. Т. е., можно определить схему on read, например, но для хранения не нужны никакие модели.

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

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

Если тебе нужна валидация — пользуй реляционную БД. Фишка NoSQL, в отсутствии каких-либо валидаций. В этом скорость + гибкость + простота использования.

В общем-то, неплохая штука для всяких хипстерских поделок — типа, быстрого прототипирования или форума с бложиком каких, где если ветка комментов отвалится, никто и не заметит. Но не более того.

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

да и в реляционных субд наличие XSD как то не в фокусе.

Ддл+субд обеспечивает полную валидацию и возможности к моделированию, если нужно (а в реляционках это в 85% необходимо)
Неважно как назвать схему модели данных, всем ясно что хсд нужно для хмл, не для реляционки

Хранить xml в виде varchar — скажем так, оригинально.

Это вы мне? Хз к чему этот комментарий к этой теме, но да пофиг, проходим мимо

это к каменту что «хсд нужно для хмл, не для реляционки»

И где ты узрел связь между моим

хсд нужно для хмл

И вашим, неизвестно откудо взятым

Хранить xml в виде varchar — скажем так, оригинально.

?
Осенний доу...

ну есои хранить данные рсубд как xml, то конечно же нужен xsd

И где я что либо подобное советовал?
У тебя бурная фантазия, укажи где ты это видишь и я постараюсь исправить это недоразумение

Я гдето писал что ты подобное советовал?

Тогда почему мы вообще это обсуждаем, если это не имеет отношения к моим комментам? Просто случайное утверждение?

у меня сложилось впечатление, что xsd как то взаимосязан rdbms — заголовок поста в общем то об этом.

А... нет, основная суть вопроса такая

У хмл есть хсд для моделирования данных
У sql рдбмс — ерд + ддл
У json — ? (Json schema только в бете сейчас, не в счет)
У graph dbs — ?

Я просто взял хмл для примера так как он очень близок к json по сути

нет там ничего из коробки и в общем то одна из (маркетинговых) идей NoSQL — это возможность единообразно хранить данные разного формата. Тоесть максимально кастомная валидация.
json schema лет 5(если не 10) в драфте, и де факто уже используется везде где оно надо.

одна из (маркетинговых) идей NoSQL

Которую советуют не применять на практике)

Ну, все ооочень сильно зависит от контекста :)

json schema лет 5(если не 10) в драфте, и де факто уже используется везде где оно надо.

а можно поподробнее плиз, тоесть это уже широковнедренный стандарт или нет?

А вам собственно зачем? Нишу ищете для заполнения своим продуктом — или для себя?

Если идею для стартапа — ну такое, похоже не сильно нужно. Особенно с отходом от больших монолитных СУБД с выделенными администраторами и предпочтением не интегрироваться через базы.

Если для себя — то да, в коде моделировать таки удобнее оказалось в большинстве случаев. Особенно если код — котлин :)

Что касаемо собственно «ОБЩЕПРИНЯТЫЕ варианты» — мне лично чаще всего встречаются свагеровские swagger.io/resources/open-api , avro, ну и protobuf до кучи. Сам не фанатею — простого перечисления полей с «optional/required» хватает.

NoSQL, кстати — это не обязательно schemaless. И наоборот — в тех же реляционных базах сейчас очень популярно сворачивать неосновные аттрибуты/сущности во всякие jsonb(postgres), xml (oracle, кажется даже с XSD!) и т.п.

отличный комментарий, спасибо

Небольшой вопрос уточнение — я слабо себе представляю удобность моделирования\валидации тяжелых моделей на, допустим, пару тысяч атрибутов и с вложенными подобьектами, те кто работал с FpML — меня поймут

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

сейчас отдельным комментом раскажу случай из жизни 5 летней давности, так сказать юз-кейс

Небольшой вопрос уточнение — я слабо себе представляю удобность моделирования\валидации тяжелых моделей на, допустим, пару тысяч атрибутов и с вложенными подобьектами, те кто работал с FpML — меня поймут

Не понятен посыл этого предложения. Не предствляешь вообще в принципе, в коде или без XSD связанного с DDL?

Вообще эти тяжелые объекты — типа «индустриальные стандарты» — совершенно не обязательно полностью всегда моделировать. Обычно удобнее их сохранить как они пришли — BLOBом или файлом где-то на S3, разбирать только значимые поля — пару десятков нужных, и передавать ссылку на исходник кому надо.

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

Я тоже про финансы. То что поля значимые — не значит, что все они всегда значимы. Ну то такое — может меня микросервисы покорежили.

Примеры — это не валидация. Это максимум — спецификация.

Что лучше для поддержки таких схем — вопрос кому. Кодерам (типа меня) статический код намного удобнее и явнее, чем монстро-схемы и разветвленые нормализированные ERD.

Некоторым кодерам даже все-равно как оно там в базе будет — для них ORM понаписаны, многие из которых даже DDL генерят.

Да, но ведь в случае разработки под индустриальный стандарт — задача спускается сверху вниз, а не наоборот. А значит у кодера без схемы стоит задача всю эту схему и валидацию кодить с нуля в сыром коде, да еще и задокументить попросят.
Такой себе фан

Че там документировать — стандарт же! На то он и стандарт.

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

Ты точно покорежен микросервисами)
В дата-хеви приложениях место и модель, в которых хранятся данные — биг дил, фразой что «ну вон оно в стандарте расписано» — никого не удовлетворит, прийдется описывать реализацию

Не очень понятно что ты называешь «дата-хеви приложениях». Я с такими вроде постоянно работаю — как по объемам, так и по сложности и важности данных. И с финансовыми тоже.

Что расписывать в реализации — как поля мапятся и проверяются?

Ну может в очень зарегулированных областях так надо делать — но там, скорее всего, сидят до сих пор на чистых RDBMS + XML/XSD. Если не EDI еще какой древний.

сидят до сих пор на чистых RDBMS + XML/XSD

Да, так и есть

5 лет назад я работал с FpML и появилась у меня идея — конвертнуть их монстр xsd в DDL модель и продавать тупо в инете, из инет магазина на скачку
сказано сделано, поднял интернет магаз, начал пилить модель. Монстр оказался слишком неубиваемым и поэтому я решил протестить идею на более простом формате — есть такой древний OASIS UBL xml формат, ни о чем.

Так вот, сайт на вордврессе с вукомерс, без раскрутки и сео, с парой пользователей в день всего с парой моделей древнего формата — вскоре принес первую покупку на 400 баксов, профессор из Канады выстрадал эту покупку — и именно выстрадал, так как даже вукомерс у меня на то время был направлен на песочницу пейпала (сик, дада знаю, полное профанство)

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

И вот вспомнил про тот случай и решил с новыми знаниями протестить идею опять. С тем форматом — проблем нет — есть xsd — делаешь ddl и вперед.

Но это ведь якобы прошлый век, вот и думаю про аналог в носкл, пару вариантов уже вырисовывается но коллективный разум всегда лучше, даже если это коллективный разум на спидах ДОУ =)

профессор из Канады

академический интерес специфичный и не очень показателен.

Не спорю, хотя если он есть — то надо его удовлетворить
Поэтому я про лендинг и возможности размышляю, а не про готовую бизнес модель

Особенно с отходом от больших монолитных СУБД

От перестановки слогаемых сумма не меняется. Валидация нужна и в мелких базах.

Валидация нужна и в мелких базах.

Валидация нужна. Но не обязательно в базах, особенно мелких.

От перестановки слогаемых сумма не меняется.

отход от больших монолитных СУБД — это не перестановка слагаемых, а изменения масштаба. Меняется.

Ничего не меняется. Тотже имейл, тотже телефон нужно валидировать. Связи между сущностями тоже нужно валидировать, держать данные в консистентном состоянии.
Можете не валидировать, но тогда база постепенно будет превращатся в свалку.
Будете валидировать кодом бизнесс логики, но основное правило валидации — чем ближе валидация к данным тем лучше. В идеале — сама бд заботится о консистентности.

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

Нету такого правила — это или ты его себе сам придумал, или неправильно понял где-то услышанное.

Единственное что действительно желательно давать базе по возможности рулить — это уникальность по ключу. Можно и без базы, но лучше с ней — а то начинаются всякие там локи, да еще и дистрибютед.

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

Имейлы и телефоны валидировать базой можно, но скорее плохой тон нынче. Лет двадцать назад, когда логика была в базах и процедурах — было логично. Сейчас — скорее нет.

Нету такого правила — это или ты его себе сам придумал, или неправильно понял где-то услышанное.

Есть такое правило. Его смысл, максимально защитить данные, чтобы какой либо кривой скрипт или кривой код не поломал данные в базе.

Единственное что действительно желательно давать базе по возможности рулить — это уникальность по ключу. Можно и без базы, но лучше с ней — а то начинаются всякие там локи, да еще и дистрибютед.

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

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

Можно много без чего обойтись, но это не отменяет того факта что нужно применять. Самый распространенный случай в тех же базах констреинт NOT NULL. Что произойдет если в вашем доменном агрегате Name будет например пустое, а Age отрицательное ?

Есть такое правило. Его смысл, максимально защитить данные, чтобы какой либо кривой скрипт или кривой код не поломал данные в базе.

Есть правило левые скрипты в базу не пускать.

Если коду доверия мало — лучше таки в базе валидировать. У меня обычно наоборот в командах.

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

И о чем это говорит? О том, что нету белого или черного, а есть градации серого.

Можно много без чего обойтись, но это не отменяет того факта что нужно применять. Самый распространенный случай в тех же базах констреинт NOT NULL. Что произойдет если в вашем доменном агрегате Name будет например пустое, а Age отрицательное ?

Если код это допустил — значит валидно. Если не валидно — надо чинить.

Про доменный агрегат не совсем понятно, но если это про данные свернутые в json, то это как бы не очень сложно надежно валидировать в современных языках. Скажем, в Котлине будет себе data class MyEntity(val name: String) — такой объект не может содержать null в name.

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

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

Расскажите, пожалуйста, как. Я знаю, что такое aggregate root, но слабо себе представляю, как обойтись без референтных связей.

Скорее всего имеется ввиду что в базе иметь foreign key не обязательно. Весь агрегат можно хранить как граф объектов в json или можно хранить в виде последовательности events. В обоих случаях не нужна субд и foreign keys

Скорее всего имеется ввиду что в базе иметь foreign key не обязательно.

да.

Весь агрегат можно хранить как граф объектов в json или можно хранить в виде последовательности events.

Первое — да, второе не уверен что вижу как помогает с уменьшением нужды в foreign key.

В обоих случаях не нужна субд и foreign keys

СУБД нужна в любом случае, кроме разве что хранения в (распределенной) файловой системе — не так ли? Если имеется в виду реляционная СУБД — то их не только для referential integrity используют.

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

В целом, Mykola Gurov уже дал исчерпывающий ответ.

Расскажите, пожалуйста, как. Я знаю, что такое aggregate root, но слабо себе представляю, как обойтись без референтных связей.

Рассказываю из собственного опыта. Как-то писали новый сервис. Для быстроты начальных итераций решили не только агрегаты по возможности в jsonb(postgres) держать, но и между связанными агрегатами без крайней надобности (типа связанного поиска по множественным сущностям) референтных связей не объявлять.

Оказалось, с определенной дисциплиной это вполне работает и даже во многих аспектах удобнее — нет мороки со связанными сущностями при dump/restore, и особенно — при чистке устаревших данных со значительным отличии по времени жизни разных сущностей. Так та система и осталась без связей, полет много лет нормальный. Во многих других системах, с которыми я сталкивался, такой подход чаще работает, чем нет.

Можно,конечно, и в ногу себе по неаккуратности прострелить — нужно быть готовым к «не найдено» по таким связям, например.

Отмазка: referential integrity — это мощный и полезный инструмент. Если не знаешь пользоваться им или нет в реляционной базе — скорее стоит пользоваться. Если девелоперы привыкли полагаться на «база умная — сама разберется» — точно нужно пользоваться.

У тебя в мозге вообще валидации нет, и абсолютно несовместимые вещи могут жить годами. Больше скажу, некоторые из этих «знаний» могут тебя убить, если применишь. Некоторые могли бы спасти жизнь — но не спасут, потому что нет валидации, ты в них не уверен. Ну и конечно же в этом всём абсолютно никакой логики.

Вся твоя память служит абсолютно противоположной цели: заставить действовать тебя БЫСТРО и не применяя логику. И поверь, когда она писалась, логика тоже не участвовала, лишь система вознаграждения и наказания.

Как же ты выжил, чёрт возьми? Как можешь работать? Как тебя допустили — писать умному компьютеру, как ему работать с данными, при том что ты сам ничего этого не умеешь и уметь не будешь?

Что «нормальные» формы ни разу не нормальны — надеюсь не нужно рассказывать? Потому что вся их нормальность определяется нормами. И с точки зрения человеческой логики, а также скорости доступа и надёжности — дублирование информации часто полезно, а компактное хранение рулит, и нередко сами данные занимают не больше, чем ссылка на другую таблицу.

А ещё целостность данных — это иллюзия. На самом деле это всего лишь ТЕСТ на этапе записи. После записи с данными может случиться что угодно (например сбой движка базы или файлового движка), и ты об этом возможно никогда не узнаешь, пока фейлы не станут массовыми. Так что тебе мешает провести эти ТЕСТЫ на уровне приложения, где ты гораздо лучше знаешь природу своих данных, без необходимости переводить логику на язык базы данных, а потом ещё и учиться переводить обратно ошибки — вместо того чтобы тупо доверить работать с базой фреймворку, а данные валидировать самому. Чаще всего валидация и так пишется.

Разруха — не в базах, разруха — в головах.

PS. Я тоже поначалу этому удивлялся, что выкинув Foreign Key из SQL-базы, вместе с поддерживающими их индексами — не получил ничего кроме солидного роста скорости на всех операциях записи. Бесплатно.

Ну все, Пение отписался — тема официально заапрувлена

От XML со всеми сопутствующими прибамбасами все уже давно избавились лет 10 назад, и перешли на JSON. Принципиального значения формат не имеет, но с json работать удобнее.

и что, какое это имеет отношение к моему вопросу?

Я, кста, не делал бы таких громких заявлений про избавились, энтерпрайз до сих пор юзает хмл во всю, ну и вот, не энтерпрайз гуглит хмл всего лишь на 25% меньше чем джсон

trends.google.com/...​ 5-y&q=/m/08745,/m/05cntt

Подписаться на комментарии