На сколько популярно и корректно хранить данные в столбце в виде JSON строки?

Question

[MishaXXL]

Каким образом хранится в БД address, geoи company?
Это строки в JSON формате или отдельные таблицы?

{
    "id": 1,
    "name": "Leanne Graham",
    "username": "Bret",
    "email": "[e-mail]",
    "address": {
      "street": "Kulas Light",
      "suite": "Apt. 556",
      "city": "Gwenborough",
      "zipcode": "92998-3874",
      "geo": {
        "lat": "-37.3159",
        "lng": "81.1496"
      }
    },
    "phone": "1-770-736-8031 x56442",
    "website": "hildegard.org",
    "company": {
      "name": "Romaguera-Crona",
      "catchPhrase": "Multi-layered client-server neural-net",
      "bs": "harness real-time e-markets"
    }
},

Пример ответа из
https://jsonplaceholder.typicode.com/users

Answer 1

[mayton2019]

В конце 20-го века, когда Эдгар Кодд развивал свою реляционную теорию было очень
модно все данные нормализовывать для хранения их в БД. Это соотвествовало экономии
ресурсов (диски мерялись килобайтами и мегабайтами) и нормализация хорошо ложилась на
техно-стек. Все данные должны быть атомарны. И ты - плохой DBA и программист если
кладешь в ячейку что-то более комплексное чем просто атом.

В 2000х развитие веб и XML(XHTML/SGML, XSLT, XPath) дало толчок новым видам
хранения информации в виде markup languages. Появляются технологии семанического веба.
Мечтатели-теоретики создают RDF, OWL. Базы данных пытаются успеть втянуть в себя новые типы.
Oracle начинает поддерживать XML+Schema как тип данных в таблице. Браузер начинает
поддерживаеть трансформацию XML и обогащение его стилями. XML - моден. Его внедряют
везде где можно и где не нужно. Даже в конфигах Apache Http и в сборщике Maven.

Параллельно Дуглас Крокфорд работает над Java Scrip Obj Notation и создает лайтовый язык
для описания объектов и документов. Они - конкурируют с XML но JSON практически побеждает
в вебе, полностью захватывая веб протоколы (Ajax, WebSockets, e.t.c). И интеракцию с сервером.
JSON становится более популярный для REST. Многие БД тоже начинают поддерживать JSON.
Postgres даже делает бинарный JSON и добавляет спец-индексы для быстрого поиска атрибутов.
Узко-специализированные системы такие как Mongo изначально заточены на храннение JSON
информации.

BigData плавно проростает в 2007 (кажется) и где-то в 2014 (или позже) году фреймворк Spark начинает поддерживать DataFrames + Structured Types которые по сути являются зеркалом JSON. Фреймворк
позволяет грузить в бигдату JSON-lines датасеты, автоматически выводя схему.

Это - финал. Я считаю что после такой конвергенции в бигдату JSON получил путевку везде где только можно.
Сегодня вы можете без стыда использовать JSON везде в любых уровнях стека (даже в Redis) если
у вас хватает памяти и вы уже порешали вопросы бизнес-согласованности данных и умеете эти
данные инвалидировать и обновлять.

Если поискать анти-паттерны применения JSON в базах данных - то я-бы предложил такую метрику.
Если вы очень часто обновляете маленькое поле внутри большого JSON документа и это создает
сильные I/O нагрузки то скорее всего вам надо перепроектировать вашу БД как-то по другому
и вынести это поле во вне по отношению к документу

Comments

[My1Name]

Интересный, содержательный и познавательный ответ. Особенно понравилось начало:

Все данные должны быть атомарны. И ты - плохой DBA и программист если
кладешь в ячейку что-то более комплексное чем просто атом

и конец:

Если вы очень часто обновляете маленькое поле внутри большого JSON документа и это создает сильные I/O нагрузки то скорее всего вам надо перепроектировать вашу БД как-то по другому и вынести это поле во вне по отношению к документу

[ThunderCat]

Сегодня вы можете без стыда использовать JSON везде в любых уровнях стека (даже в Redis)

О как... Можно хранить строку в кей-валуе хранилище, ничоси...

Я считаю что после такой конвергенции в бигдату JSON получил путевку везде где только можно.

Да нифига. ЖСОН специфичный и многословный формат, по сути требующий парсинга на каждый чих, что во первых память, а во вторых - невозможность нормально связать объекты отношениями. Так что каждому инструменту свое применение.

PS: Akina в ответе весьма логично и доходчиво разложил что и как...

[mayton2019]

ThunderCat, этим летом мы загружали мета-данные о товарах очень крупной торговой сети.
И мы загружали их из BigData в Redis в формате JSON чтоб веб приложение бытро отрисовывало
описания товаров на сайте. Размер документов порядка 1 килобайта.

[ThunderCat]

mayton2019, И где тут про инновации и прочие плюшки? Метаданные связаны между собой примерно никак, кроме связи по ключу товара никаких других релаций с ними собсно не предусмотрено, именно по этому их можно хранить в кей-валуе хранилище (как раз сценарий сохранить - прочитать, по сути у вас тупо кэш). В сложных связках жсон все еще хреново себя ведет, даже в специально разработанных системах, уступая в производительности реляционкам, да и внутри движков с использованием жсон полей на самом деле более сложные индексы на основе жсона, а не тупой поиск по тексту, что создает кучу дополнительных нагрузок на ровном месте. С одной сторны - есть специфические задачи где жсон подходит и соответственно для него есть специфические инструменты, с другой - эти задачи достаточно узкие, чтобы рекомендовать жсон как революцию в хранении связанных данных и пихать его везде вместо классической реляционки. И уж тем более советовать его как замену реляционным данным, особенно новичкам не особо разбирающимся в теме.

[mayton2019]

ThunderCat, а это вообще нереляционные данные.

Мы отгружали денормализованную информацию для веба.

Answer 2

[Akina]

На сколько популярно и корректно хранить данные в столбце в виде JSON строки?

А это зависит от того, что с этими данными делать.

Если сохранить/вернуть - да, вполне.
Если найти по фрагменту - 50/50, и зависит в основном инструментов, имеющихся в конкретной СУБД.
Если выполнить более сложную обработку (сумма, в т.ч. с накоплением, среднее, медиана и пр.) - скорее нет.
Если использовать для связывания по фрагменту - почти наверняка нет.

Answer 3

[Василий Банников]

1. В реляционных базах - обычно это признак чего-то нехорошего, хотя сейчас во многих есть нативная поддержка JSON (в постгресе так она вообще очень хорошая)

Это строки в JSON формате или отдельные таблицы?

Можно и так и так, но
2. Если бы я хотел такую структуру получить в ответе, то geo я бы хранил просто в отдельных двух колонках в адресе. Сам адрес - в отдельной таблице. Компанию - тоже в отдельной таблице.
А для выдачи результата - джоинил.
А если это всё относится только к сущности пользователя (тоесть нету такого, что несколько пользователей относятся к одной организации, которую нужно дедуплицировать) - можно всё в одной таблице и хранить, но в разных колонках (и просто при выдаче результата приводить это к объектной модели)
Либо же иметь одну json-колонку, в которой иметь произвольное количество дополнительных/опциональных полей.

Answer 4

[Сергей Соловьев]

Если перейти по ссылке на сайте, то можно увидеть, что для хранения используется LowDB.
Ответ: хранится все в JSON файле в денормализованном виде