Хранение данных в MySQL как JSON

Я подумал, что это непростая задача. Итак, я никогда этого не делал. Затем я увидел, что FriendFeed сделал это и фактически улучшил масштабирование своей БД и уменьшил задержку. Мне любопытно, стоит ли мне это сделать. И если да, то как правильно это сделать?

В принципе, где можно научиться хранить все в MySQL как БД типа CouchDB? Кажется, что хранить все в формате JSON будет проще и быстрее (не для сборки, с меньшей задержкой).

Кроме того, легко ли редактировать, удалять и т. Д. Вещи, хранящиеся как JSON в БД?

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

Не.

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

Кажется, что все, кто комментирует, приходят к этому с неправильной точки зрения, можно хранить код JSON через PHP в реляционной БД, и на самом деле будет быстрее загружать и отображать такие сложные данные, однако у вас будут соображения дизайна, такие как поиск, индексация и т. д.

Лучший способ сделать это - использовать гибридные данные, например, если вам нужно выполнить поиск на основе datetime, MySQL (с настроенной производительностью) будет намного быстрее, чем PHP, и для чего-то вроде расстояния поиска мест MySQL также должно быть много быстрее (обратите внимание, что поиск не дает доступа). Данные, которые вам не нужно искать, могут быть сохранены в JSON, BLOB или любом другом формате, который вы действительно сочтете необходимым.

Данные, к которым вам нужен доступ, очень легко сохранить в виде JSON, например, в базовой системе счетов-фактур для каждого случая. Они не сильно выигрывают от РСУБД и могут быть сохранены в JSON только с помощью json_encoding ($ _ POST ['entires']), если у вас есть правильная структура HTML-формы.

Я рад, что вам нравится использовать MongoDB, и надеюсь, что он по-прежнему будет вам хорошо служить, но не думайте, что MySQL всегда будет вне поля вашего зрения, поскольку ваше приложение становится все сложнее, и вам вполне может потребоваться СУБД для некоторые функции и возможности (даже если это просто для удаления архивных данных или бизнес-отчетности)

MySQL 5.7 теперь поддерживает собственный тип данных JSON, аналогичный MongoDB и другим хранилищам данных документов без схемы:

Поддержка JSON

Начиная с MySQL 5.7.8, MySQL поддерживает собственный тип JSON. Значения JSON не хранятся в виде строк, вместо этого используется внутренний двоичный формат, который обеспечивает быстрый доступ для чтения к элементам документа. Документы JSON, хранящиеся в столбцах JSON, автоматически проверяются всякий раз, когда они вставляются или обновляются, а недопустимый документ вызывает ошибку. Документы JSON нормализуются при создании и могут сравниваться с помощью большинства операторов сравнения, таких как =, <, <=,>,> =, <>,! = И <=>; для получения информации о поддерживаемых операторах, а также о приоритете и других правилах, которым MySQL следует при сравнении значений JSON, см. Сравнение и упорядочение значений JSON.

MySQL 5.7.8 также вводит ряд функций для работы со значениями JSON. Эти функции включают перечисленные здесь:

1. Функции, которые создают значения JSON: JSON_ARRAY (), JSON_MERGE () и JSON_OBJECT (). См. Раздел 12.16.2, «Функции, которые создают значения JSON».
2. Функции, выполняющие поиск значений JSON: JSON_CONTAINS (), JSON_CONTAINS_PATH (), JSON_EXTRACT (), JSON_KEYS () и JSON_SEARCH (). См. Раздел 12.16.3, «Функции, выполняющие поиск значений JSON».
3. Функции, изменяющие значения JSON: JSON_APPEND (), JSON_ARRAY_APPEND (), JSON_ARRAY_INSERT (), JSON_INSERT (), JSON_QUOTE (), JSON_REMOVE (), JSON_REPLACE (), JSON_SET () и JSON )_UNQUOTE (). См. Раздел 12.16.4, «Функции, изменяющие значения JSON».
4. Функции, предоставляющие информацию о значениях JSON: JSON_DEPTH (), JSON_LENGTH (), JSON_TYPE () и JSON_VALID (). См. Раздел 12.16.5, «Функции, возвращающие атрибуты значений JSON».

В MySQL 5.7.9 и новее вы можете использовать столбец-> путь как сокращение для JSON_EXTRACT (столбец, путь). Это работает как псевдоним для столбца везде, где идентификатор столбца может встречаться в операторе SQL, включая предложения WHERE, ORDER BY и GROUP BY. Сюда входят SELECT, UPDATE, DELETE, CREATE TABLE и другие операторы SQL. В левой части должен быть идентификатор столбца JSON (а не псевдоним). Правая сторона - это указанное в кавычках выражение пути JSON, которое оценивается по документу JSON, возвращаемому в качестве значения столбца.

См. Раздел 12.16.3, «Функции, выполняющие поиск значений JSON», для получения дополнительной информации о -> и JSON_EXTRACT (). Для получения информации о поддержке пути JSON в MySQL 5.7 см. Поиск и изменение значений JSON. См. Также Вторичные индексы и Виртуальные генерируемые столбцы.

Больше информации:

https://dev.mysql.com/doc/refman/5.7/en/json.html

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

{, }, [, ], ', a-z, 0-9.... нет ничего особенного , и могут быть сохранены в виде текста.

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

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

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

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

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

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

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

Он не принимает во внимание массивы или другие объекты, а только основные типы данных. Вы должны изменить 4 экземпляра столбца на имя столбца, в котором хранится JSON, и изменить 4 экземпляра myfield на поле JSON, к которому вы хотите получить доступ.

SELECT
    SUBSTRING(
        REPLACE(REPLACE(REPLACE(column, '{', ''), '}', ','), '"', ''),
        LOCATE(
            CONCAT('myfield', ':'),
            REPLACE(REPLACE(REPLACE(column, '{', ''), '}', ','), '"', '')
        ) + CHAR_LENGTH(CONCAT('myfield', ':')),
        LOCATE(
            ',',
            SUBSTRING(
                REPLACE(REPLACE(REPLACE(column, '{', ''), '}', ','), '"', ''),
                LOCATE(
                    CONCAT('myfield', ':'),
                    REPLACE(REPLACE(REPLACE(column, '{', ''), '}', ','), '"', '')
                ) + CHAR_LENGTH(CONCAT('myfield', ':'))
            )
        ) - 1
    )
    AS myfield
FROM mytable WHERE id = '3435'

Это действительно зависит от вашего варианта использования. Если вы храните информацию, которая не имеет абсолютно никакого значения в отчетах и ​​не будет запрашиваться через JOINs с другими таблицами, может иметь смысл хранить ваши данные в одном текстовом поле, закодированном как JSON.

Это может значительно упростить вашу модель данных. Однако, как упоминал Роберт Питт, не ожидайте, что сможете объединить эти данные с другими нормализованными данными.

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

Прежде всего, улучшена поддержка хранения JSON в СУБД. Вы можете подумать о переходе на PostgreSQL (хотя MySQL поддерживает JSON с версии v5.7.7). PostgreSQL использует очень похожие команды SQL, как и MySQL, за исключением того, что они поддерживают больше функций. Одна из добавленных функций заключается в том, что они предоставляют тип данных JSON, и теперь вы можете запрашивать сохраненный JSON. ( Некоторая ссылка на это ) Если вы не составляете запрос непосредственно в своей программе, например, используя PDO в php или красноречиво в Laravel, все, что вам нужно сделать, это просто установить PostgreSQL на свой сервер и изменить настройки подключения к базе данных. Вам даже не нужно менять свой код.

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

Например, для хранения тега сообщения в блоге обычно требуется таблица для сообщения в блоге, таблица тегов и таблица соответствия. Итак, когда пользователь хочет отредактировать сообщение, и вам нужно отобразить, какой тег связан с этим сообщением, вам нужно будет запросить 3 таблицы. Это сильно повредит производительности, если ваша таблица соответствия / таблица тегов будет длинной.

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

Вы также можете попробовать денормализовать базу данных. Дублируя данные и сохраняя данные обоими способами, вы можете получить преимущества обоих методов. Вам просто потребуется немного больше времени для хранения ваших данных и больше места для хранения (что дешево по сравнению с затратами на большую вычислительную мощность)

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

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

Я немного написал о своем подходе здесь:

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

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

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

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

Мне кажется, что каждый, кто отвечает на этот вопрос, как бы упускает из виду одну критическую проблему, кроме @deceze - используйте правильный инструмент для работы . Вы можете заставить реляционную базу данных хранить почти любой тип данных, и вы можете заставить Mongo обрабатывать реляционные данные, но какой ценой? В итоге вы усложняете все уровни разработки и сопровождения, от дизайна схемы до кода приложения; не говоря уже о производительности.

В 2014 году у нас есть доступ ко многим серверам баз данных, которые исключительно хорошо обрабатывают определенные типы данных.

• Mongo (хранилище документов)
• Redis (хранилище данных ключ-значение)
• MySQL / Maria / PostgreSQL / Oracle / и т. Д. (Реляционные данные)
• CouchDB (JSON)

Я уверен, что скучал по некоторым другим, таким как RabbirMQ и Cassandra. Я хочу сказать, что используйте правильный инструмент для данных, которые вам нужно хранить.

Если вашему приложению требуется действительно очень быстрое хранение и извлечение различных данных (а кто этого не делает), не уклоняйтесь от использования нескольких источников данных для приложения. Большинство популярных веб-фреймворков обеспечивают поддержку нескольких источников данных (Rails, Django, Grails, Cake, Zend и т. Д.). Эта стратегия ограничивает сложность одной конкретной областью приложения, ORM или интерфейсом источника данных приложения.

Вот функция, которая будет сохранять / обновлять ключи массива JSON в столбце, и другая функция, которая извлекает значения JSON. Эти функции создаются при условии, что имя столбца для хранения массива JSON - json . Он использует PDO .

Функция сохранения / обновления

function save($uid, $key, $val){
 global $dbh; // The PDO object
 $sql = $dbh->prepare("SELECT `json` FROM users WHERE `id`=?");
 $sql->execute(array($uid));
 $data      = $sql->fetch();
 $arr       = json_decode($data['json'],true);
 $arr[$key] = $val; // Update the value
 $sql=$dbh->prepare("UPDATE `users` SET `json`=? WHERE `id`=?");
 $sql->execute(array(
   json_encode($arr), 
   $uid
 ));
}

где $ uid - это идентификатор пользователя, $ key - ключ JSON для обновления, а его значение упоминается как $ val .

Функция получения значения

function get($uid, $key){
 global $dbh;
 $sql = $dbh->prepare("SELECT `json` FROM `users` WHERE `id`=?");
 $sql->execute(array($uid));
 $data = $sql->fetch();
 $arr  = json_decode($data['json'], true);
 return $arr[$key];
}

где $ key - это ключ массива JSON, из которого нам нужно значение.

Ранняя поддержка для хранения JSON в MySQL была добавлена ​​в выпуск MySQL 5.7.7 JSON labs ( двоичные файлы Linux , исходный код )! Релиз, похоже, вырос из серии пользовательских функций, связанных с JSON, опубликованных еще в 2013 году. .

Эта зарождающаяся нативная поддержка JSON, кажется, движется в очень позитивном направлении, включая проверку JSON на INSERT, оптимизированном двоичном формате хранения, включая таблицу поиска в преамбуле, которая позволяет функции JSN_EXTRACT выполнять двоичный поиск, а не анализировать при каждом доступе. Существует также целый ряд новых функций для обработки и запроса определенных типов данных JSON:

CREATE TABLE users (id INT, preferences JSON);

INSERT INTO users VALUES (1, JSN_OBJECT('showSideBar', true, 'fontSize', 12));

SELECT JSN_EXTRACT(preferences, '$.showSideBar') from users;

+--------------------------------------------------+
| id   | JSN_EXTRACT(preferences, '$.showSideBar') |
+--------------------------------------------------+
| 1    | true                                      |
+--------------------------------------------------+

ИМХО, приведенное выше - отличный вариант использования этой новой функциональности; во многих базах данных SQL уже есть пользовательская таблица, и вместо того, чтобы вносить бесконечные изменения схемы в соответствии с развивающимся набором пользовательских предпочтений, лучше всего иметь один столбец JSON, который находится отдельно JOIN. Тем более, что вряд ли когда-нибудь понадобится запрашивать отдельные элементы.

Хотя это еще рано, команда MySQL сервер делает большую работу по информированию о изменениях на в блоге .

Я считаю, что хранение JSON в базе данных mysql на самом деле противоречит цели использования СУБД в том виде, в котором она предназначена. Я бы не стал использовать его в каких-либо данных, которые в какой-то момент будут обрабатываться или сообщаться, поскольку это не только добавляет сложности, но и может легко повлиять на производительность в зависимости от того, как они используются.

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

В приведенной выше ситуации запросы регистрируются и никогда не обрабатываются и не индексируются в строковом поле JSON. ОДНАКО, в более сложной среде я, вероятно, попытался бы использовать что-то, что больше предназначено для этого типа данных, и сохранить его в этой системе. Как уже говорили другие, это действительно зависит от того, чего вы пытаетесь достичь, но следование стандартам всегда способствует долговечности и надежности!

JSON также является допустимым типом данных в базе данных PostgreSQL. Однако база данных MySQL еще официально не поддерживает JSON. Но это запекание: http://mysqlserverteam.com/json-labs-release-native-json-data-type-and-binary-format/

Я также согласен с тем, что существует множество допустимых случаев, когда некоторые данные лучше сериализовать в строку в базе данных. Основная причина может заключаться в том, что он не запрашивается регулярно и когда его собственная схема может измениться - вы не хотите изменять соответствующую схему базы данных. Вторая причина заключается в том, что когда сериализованная строка поступает непосредственно из внешних источников, вы можете не захотеть анализировать их все и передавать в базу данных любой ценой, пока вы не используете их. Так что я буду ждать, пока новая версия MySQL будет поддерживать JSON, так как тогда будет проще переключаться между разными базами данных.

Я использую json для записи чего угодно для проекта, фактически использую три таблицы! один для данных в json, один для индекса всех метаданных структуры json (каждая мета кодируется уникальным идентификатором) и один для пользователя сеанса, вот и все. Тест не может быть определен количественно на этом раннем этапе кода, но, например, я использовал просмотры пользователей (внутреннее соединение с индексом), чтобы получить категорию (или что-то еще, как пользователь, ...), и это было очень медленно (очень-очень медленно , использование представления в mysql - не лучший способ). Модуль поиска в этой структуре может делать все, что я хочу, но я думаю, что mongodb будет более эффективным в этой концепции полной записи данных json. В моем примере я использую представления для создания дерева категорий и хлебных крошек, боже мой! так много запросов! сам apache ушел! и, собственно говоря, для этого небольшого веб-сайта я использую PHP, который генерирует дерево и хлебные крошки, извлечение данных выполняется модулем поиска (который использует только индекс), таблица данных используется только для обновления. Если я хочу, я могу уничтожить все индексы и регенерировать их с каждыми данными, а также выполнить обратную работу, например, уничтожить все данные (json) и восстановить их только с помощью таблицы индексов. Мой проект молодой, работает под php и mysql, но иногда я думаю, что использование node js и mongodb будет более эффективным для этого проекта.

Используйте json, если считаете, что можете, просто для этого, потому что вы можете! и забудьте об этом, если это была ошибка; попробуйте сделать хороший или плохой выбор, но попробуйте!

Низкий

французский пользователь

Я знаю, что это действительно поздно, но у меня была аналогичная ситуация, когда я использовал гибридный подход к поддержанию стандартов РСУБД для нормализации таблиц до определенного момента и последующего сохранения данных в JSON в виде текстового значения после этого момента. Так, например, я храню данные в 4 таблицах, следуя правилам нормализации СУБД. Однако в 4-й таблице для размещения динамической схемы я храню данные в формате JSON. Каждый раз, когда я хочу получить данные, я извлекаю данные JSON, анализирую их и отображаю на Java. До сих пор это сработало для меня, и я по-прежнему могу индексировать поля, которые я преобразовываю в данные json в таблице, нормализованным образом с использованием ETL. Это гарантирует, что пока пользователь работает с приложением, он сталкивается с минимальной задержкой, а поля преобразовываются в удобный формат РСУБД для анализа данных и т. Д.

Вы можете использовать эту суть: https://gist.github.com/AminaG/33d90cb99c26298c48f670b8ffac39c3

После установки на сервер (просто нужны привилегии root, а не супер), вы можете сделать что-то вроде этого:

select extract_json_value('{"a":["a","2"]}','(/a)')

Он вернется. a 2 Вы можете вернуть что угодно внутри JSON, используя это. Хорошая часть состоит в том, что он поддерживает MySQL 5.1,5.2,5.6. И вам не нужно устанавливать на сервер какой-либо двоичный файл.

На основе старого проекта common-schema, но он все еще работает сегодня https://code.google.com/archive/p/common-schema/