Storing Data in MySQL as JSON

I thought this was a n00b thing to do. And, so, I've never done it. Then I saw that FriendFeed did this and actually made their DB scale better and decreased latency. I'm curious if I should do this. And, if so, what's the right way to do it?

Basically, what's a good place to learn how to store everything in MySQL as a CouchDB sort of DB? Storing everything as JSON seems like it'd be easier and quicker (not to build, less latency).

Also, is it easy to edit, delete, etc., things stored as JSON on the DB?

113
задан Flimzy 17 May 2018 в 11:20
поделиться

3 ответа

CouchDB и MySQL — два очень разных зверя. JSON — это собственный способ хранения данных в CouchDB. В MySQL лучшее, что вы можете сделать, это хранить данные JSON в виде текста в одном поле. Это полностью лишило бы смысла хранить его в СУБД и значительно усложнило бы каждую транзакцию базы данных.

Не надо.

Сказав это, FriendFeed, похоже, использовал чрезвычайно пользовательскую схему поверх MySQL. Это действительно зависит от того, что именно вы хотите хранить, едва ли существует однозначный ответ о том, как злоупотреблять системой баз данных, поэтому для вас это имеет смысл. Учитывая, что статья очень старая, а их основной причиной против Mongo и Couch была незрелость, я бы переоценил эти два, если MySQL не подойдет вам. Они уже должны были сильно вырасти.

56
ответ дан 24 November 2019 в 02:39
поделиться

символы json не представляют собой ничего особенного, когда дело доходит до хранения, такие символы, как

{,},[,],',az,0-9.... на самом деле ничего особенного и может храниться как текст.

первая проблема, с которой вы столкнетесь, это

{ id_профиля: 22, имя пользователя: «Роберт», пароль: 'skhgeeht893htgn34ythg9er' }

который хранится в базе данных, не так просто обновить, если у вас нет собственной процедуры и вы не разработали jsondecode для mysql

UPDATE users SET JSON(user_data,'username') = 'New User';

Так как вы не можете этого сделать, вам придется сначала ВЫБРАТЬ json, декодировать его, изменить его , обновите его, так что теоретически вы могли бы потратить больше времени на построение подходящей структуры базы данных!

Я использую json для хранения данных, но только метаданных, данных, которые не обновляются часто, не связаны с конкретным пользователем. Например, если пользователь добавляет сообщение, и в этом сообщении он добавляет изображения, плохо анализирует изображения и создайте превью, а затем используйте URL-адреса в формате json.

24
ответ дан 24 November 2019 в 02:39
поделиться

Я бы сказал, что есть только две причины, чтобы это учитывать:

  • производительность просто недостаточно хороша при нормализованном подходе
  • вы не можете легко смоделировать свои особенно гибкие/изменяющиеся данные

Я написал Немного о моем собственном подходе:

С какими проблемами масштабируемости вы столкнулись при использовании хранилища данных NoSQL?

(см. верхний ответ)

Даже JSON был недостаточно быстрым, поэтому мы использовали подход с пользовательским текстовым форматом. Работал/продолжает работать хорошо для нас.

Есть ли причина, по которой вы не используете что-то вроде MongoDB? (может быть MySQL "требуется", просто любопытно)

8
ответ дан 24 November 2019 в 02:39
поделиться
Другие вопросы по тегам:

Похожие вопросы: