Stocker des données dans MySQL au format JSON

Je pensais que c'était une chose n00b à faire. Et donc, je ne l'ai jamais fait. Ensuite, j'ai vu que FriendFeed a fait cela et a en fait amélioré son échelle de base de données et réduit la latence. Je suis curieux de savoir si je devrais faire ça. Et, si oui, quelle est la bonne façon de le faire?

En gros, quel est le bon endroit pour apprendre à tout stocker dans MySQL comme une sorte de base de données CouchDB? Tout stocker au format JSON semble être plus facile et plus rapide (ne pas créer, moins de latence).

De plus, est-il facile de modifier, supprimer, etc., des éléments stockés au format JSON sur la base de données?

CouchDB et MySQL sont deux bêtes très différentes. JSON est le moyen natif de stocker des éléments dans CouchDB. Dans MySQL, le mieux que vous puissiez faire est de stocker les données JSON sous forme de texte dans un seul champ. Cela irait totalement à l'encontre de l'objectif de le stocker dans un SGBDR et compliquerait considérablement chaque transaction de base de données.

Ne fais pas ça.

Cela dit, FriendFeed semblait utiliser un schéma extrêmement personnalisé en plus de MySQL. Cela dépend vraiment de ce que vous voulez stocker exactement, il n'y a guère de réponse définitive sur la façon d'abuser d'un système de base de données, donc cela a du sens pour vous. Étant donné que l'article est très ancien et que leur principale raison contre Mongo et Couch était l'immaturité, je réévaluerais ces deux éléments si MySQL ne le coupe pas pour vous. Ils devraient avoir beaucoup grandi maintenant.

Tout le monde qui commente semble venir du mauvais angle, il est bon de stocker du code JSON via PHP dans une base de données relationnelle et il sera en fait plus rapide de charger et d'afficher des données complexes comme celle-ci, mais vous aurez des considérations de conception telles que recherche, indexation, etc.

La meilleure façon de faire est d'utiliser des données hybrides, par exemple si vous devez effectuer une recherche basée sur datetime MySQL (optimisé pour les performances) va être beaucoup plus rapide que PHP et pour quelque chose comme la recherche de la distance des lieux, MySQL devrait également être beaucoup plus rapide (remarquez que la recherche n'accède pas). Les données sur lesquelles vous n'avez pas besoin de rechercher peuvent ensuite être stockées au format JSON, BLOB ou tout autre format que vous jugez vraiment nécessaire.

Les données auxquelles vous devez accéder sont très facilement stockées au format JSON, par exemple un système de facturation de base par cas. Ils ne bénéficient pas du tout du SGBDR et pourraient être stockés dans JSON simplement par json_encoding ($ _ POST ['entires']) si vous avez la bonne structure de formulaire HTML.

Je suis heureux que vous soyez heureux d'utiliser MongoDB et j'espère que cela continuera à bien vous servir, mais ne pensez pas que MySQL sera toujours hors de votre radar, car votre application augmente en complexité, vous pourriez bien avoir besoin d'un SGBDR pour certaines fonctionnalités et fonctionnalités (même s'il s'agit simplement de retirer des données archivées ou des rapports commerciaux)

MySQL 5.7 prend désormais en charge un type de données JSON natif similaire à MongoDB et à d'autres magasins de données de documents sans schéma:

Prise en charge JSON

À partir de MySQL 5.7.8, MySQL prend en charge un type JSON natif. Les valeurs JSON ne sont pas stockées sous forme de chaînes, mais en utilisant un format binaire interne qui permet un accès en lecture rapide aux éléments du document. Les documents JSON stockés dans les colonnes JSON sont automatiquement validés chaque fois qu'ils sont insérés ou mis à jour, un document non valide produisant une erreur. Les documents JSON sont normalisés à la création et peuvent être comparés à l'aide de la plupart des opérateurs de comparaison tels que =, <, <=,>,> =, <>,! = Et <=>; pour plus d'informations sur les opérateurs pris en charge ainsi que sur la priorité et les autres règles suivies par MySQL lors de la comparaison des valeurs JSON, consultez Comparaison et classement des valeurs JSON.

MySQL 5.7.8 introduit également un certain nombre de fonctions pour travailler avec des valeurs JSON. Ces fonctions incluent celles répertoriées ici:

1. Fonctions qui créent des valeurs JSON: JSON_ARRAY (), JSON_MERGE () et JSON_OBJECT (). Reportez-vous à la Section 12.16.2, «Fonctions qui créent des valeurs JSON».
2. Fonctions qui recherchent les valeurs JSON: JSON_CONTAINS (), JSON_CONTAINS_PATH (), JSON_EXTRACT (), JSON_KEYS () et JSON_SEARCH (). See Section 12.16.3, «Fonctions qui recherchent des valeurs JSON».
3. Fonctions qui modifient les valeurs JSON: JSON_APPEND (), JSON_ARRAY_APPEND (), JSON_ARRAY_INSERT (), JSON_INSERT (), JSON_QUOTE (), JSON_REMOVE (), JSON_REPLACE (), JSON_SET () et JSON_UNQUOTE (). Reportez-vous à la Section 12.16.4, «Fonctions qui modifient les valeurs JSON».
4. Fonctions qui fournissent des informations sur les valeurs JSON: JSON_DEPTH (), JSON_LENGTH (), JSON_TYPE () et JSON_VALID (). See Section 12.16.5, «Fonctions qui renvoient des attributs de valeur JSON».

Dans MySQL 5.7.9 et versions ultérieures, vous pouvez utiliser colonne-> chemin comme raccourci pour JSON_EXTRACT (colonne, chemin). Cela fonctionne comme un alias pour une colonne partout où un identificateur de colonne peut apparaître dans une instruction SQL, y compris les clauses WHERE, ORDER BY et GROUP BY. Cela inclut SELECT, UPDATE, DELETE, CREATE TABLE et d'autres instructions SQL. Le côté gauche doit être un identificateur de colonne JSON (et non un alias). Le côté droit est une expression de chemin JSON entre guillemets qui est évaluée par rapport au document JSON renvoyé en tant que valeur de colonne.

Voir Section 12.16.3, «Fonctions qui recherchent des valeurs JSON», pour plus d'informations sur -> et JSON_EXTRACT (). Pour plus d'informations sur la prise en charge des chemins JSON dans MySQL 5.7, consultez Recherche et modification des valeurs JSON. Voir aussi Index secondaires et Colonnes générées virtuelles.

Plus d'informations:

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

les caractères json n'ont rien de spécial en ce qui concerne le stockage, des caractères tels que

{, }, [, ], ', a-z,0-9 .... sont vraiment rien de spécial et peut être stocké sous forme de texte.

le premier problème que tu vas avoir est celui-ci

{profile_id: 22, nom d'utilisateur: 'Robert', mot de passe: 'skhgeeht893htgn34ythg9er'}

qui stocké dans une base de données n'est pas si simple à mettre à jour à moins que vous n'ayez votre propre procédure et développé un jsondecode pour mysql

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

Donc, comme vous ne pouvez pas faire cela, vous devriez d'abord sélectionner le json, le décoder, le changer, le mettre à jour, donc en théorie, vous pourriez aussi bien passer plus de temps à construire une structure de base de données appropriée!

J'utilise json pour stocker des données, mais uniquement des métadonnées, des données qui ne sont pas mises à jour souvent, qui ne sont pas liées à l'utilisateur spécifique .. exemple si un utilisateur ajoute un message, et dans ce message, il ajoute des images mal analyser les images et créer des pouces et puis utilisez les URL du pouce au format json.

Pour illustrer à quel point il est difficile d'obtenir des données JSON à l'aide d'une requête, je vais partager la requête que j'ai faite pour gérer cela.

Il ne prend pas en compte les tableaux ou autres objets, juste les types de données de base. Vous devez remplacer les 4 instances de la colonne par le nom de la colonne stockant le JSON et les 4 instances de myfield par le champ JSON auquel vous souhaitez accéder.

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'

Cela dépend vraiment de votre cas d'utilisation. Si vous stockez des informations qui n'ont absolument aucune valeur dans les rapports et qui ne seront pas interrogées via des JOIN avec d'autres tables, il peut être judicieux pour vous de stocker vos données dans un champ de texte unique, codé en JSON.

Cela pourrait grandement simplifier votre modèle de données. Cependant, comme mentionné par RobertPitt, ne vous attendez pas à pouvoir combiner ces données avec d'autres données qui ont été normalisées.

C'est une vieille question, mais je peux toujours la voir en haut des résultats de recherche de Google, donc je suppose qu'il serait utile d'ajouter une nouvelle réponse 4 ans après que la question soit posée.

Tout d'abord, il existe une meilleure prise en charge du stockage de JSON dans le SGBDR. Vous pouvez envisager de passer à PostgreSQL (bien que MySQL prenne en charge JSON depuis la version 5.7.7). PostgreSQL utilise des commandes SQL très similaires à MySQL sauf qu'elles prennent en charge plus de fonctions. L'une des fonctions qu'ils ont ajoutées est qu'elles fournissent le type de données JSON et vous pouvez maintenant interroger le JSON stocké. ( Quelques références à ce sujet ) Si vous ne créez pas la requête directement dans votre programme, par exemple en utilisant PDO en php ou éloquent en Laravel, tout ce que vous avez à faire est simplement d'installer PostgreSQL sur votre serveur et de modifier les paramètres de connexion à la base de données. Vous n'avez même pas besoin de changer votre code.

La plupart du temps, comme le suggèrent les autres réponses, stocker des données au format JSON directement dans le SGBDR n'est pas une bonne idée. Il y a cependant quelques exceptions. Une situation à laquelle je peux penser est un champ avec un nombre variable d'entrées liées.

Par exemple, pour stocker la balise d'un article de blog, vous aurez normalement besoin d'un tableau pour l'article de blog, d'un tableau de balises et d'un tableau correspondant. Ainsi, lorsque l'utilisateur souhaite modifier un message et que vous devez afficher la balise associée à ce message, vous devrez interroger 3 tables. Cela endommagera beaucoup les performances si votre table / table de balises correspondante est longue.

En stockant les balises au format JSON dans la table des articles de blog, la même action ne nécessite qu'une seule recherche de table. L'utilisateur pourra alors voir l'article de blog à éditer plus rapidement, mais cela nuira aux performances si vous souhaitez faire un rapport sur l'article lié à une balise, ou peut-être effectuer une recherche par tag.

Vous pouvez également essayer de dé-normaliser la base de données. En dupliquant les données et en stockant les données dans les deux sens, vous pouvez bénéficier des deux méthodes. Vous aurez juste besoin d'un peu plus de temps pour stocker vos données et de plus d'espace de stockage (ce qui est bon marché par rapport au coût d'une plus grande puissance de calcul)

Je dirais que les deux seules raisons d'envisager cela sont:

• les performances ne sont tout simplement pas assez bonnes avec une approche normalisée
• vous ne pouvez pas facilement modéliser vos données particulièrement fluides / flexibles / changeantes

J'ai écrit un peu sur ma propre approche ici:

Quels problèmes d'évolutivité avez-vous rencontrés lors de l'utilisation d'un magasin de données NoSQL?

(voir la première réponse)

Même JSON n'était pas assez rapide, nous avons donc utilisé une approche de format de texte personnalisé. A travaillé / continue de bien fonctionner pour nous.

Y a-t-il une raison pour laquelle vous n'utilisez pas quelque chose comme MongoDB? (peut-être que MySQL est "requis"; juste curieux)

Il me semble que tout le monde qui répond à cette question manque le seul problème critique, à l'exception de @deceze - utiliser le bon outil pour le travail . Vous pouvez forcer une base de données relationnelle à stocker presque tous les types de données et vous pouvez forcer Mongo à gérer des données relationnelles, mais à quel prix? Vous finissez par introduire de la complexité à tous les niveaux de développement et de maintenance, de la conception du schéma au code d'application; sans parler du succès des performances.

En 2014, nous avons accès à de nombreux serveurs de bases de données qui gèrent exceptionnellement bien des types de données spécifiques.

• Mongo (stockage de documents)
• Redis (stockage de données clé-valeur)
• MySQL / Maria / PostgreSQL / Oracle / etc (données relationnelles)
• CouchDB (JSON)

Je suis sûr que j'en ai manqué d'autres, comme RabbirMQ et Cassandra. Mon point est d'utiliser le bon outil pour les données que vous devez stocker.

Si votre application nécessite le stockage et la récupération d'une variété de données vraiment, très rapidement (et qui ne le fait pas), n'hésitez pas à utiliser plusieurs sources de données pour une application. Les frameworks Web les plus populaires prennent en charge plusieurs sources de données (Rails, Django, Grails, Cake, Zend, etc.). Cette stratégie limite la complexité à un domaine spécifique de l'application, l'ORM ou l'interface de source de données de l'application.

Voici une fonction qui permettrait de sauvegarder / mettre à jour les clés d'un tableau JSON dans une colonne et une autre fonction qui récupère les valeurs JSON. Ces fonctions sont créées en supposant que le nom de la colonne de stockage du tableau JSON est json . Il utilise PDO .

Fonction de sauvegarde / mise à jour

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
 ));
}

où $ uid est l'identifiant de l'utilisateur, $ key - la clé JSON à mettre à jour et sa valeur est mentionnée comme $ val .

Fonction Get Value

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];
}

où $ key est une clé du tableau JSON dont nous avons besoin de la valeur.

La prise en charge précoce du stockage de JSON dans MySQL a été ajoutée à la version MySQL 5.7.7 JSON labs ( binaires Linux , source )! La version semble être issue d'une série de fonctions définies par l'utilisateur liées à JSON et rendues publiques en 2013 .

Ce support JSON natif naissant semble se diriger dans une direction très positive, y compris la validation JSON sur INSERT, un format de stockage binaire optimisé comprenant une table de recherche dans le préambule qui permet à la fonction JSN_EXTRACT d'effectuer des recherches binaires plutôt que d'analyser à chaque accès. Il existe également toute une série de nouvelles fonctions pour gérer et interroger des types de données JSON spécifiques:

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                                      |
+--------------------------------------------------+

IMHO, ce qui précède est un excellent cas d'utilisation pour cette nouvelle fonctionnalité; de nombreuses bases de données SQL ont déjà une table utilisateur et, plutôt que de faire des changements de schéma sans fin pour s'adapter à un ensemble évolutif de préférences utilisateur, avoir une seule colonne JSON à une seule JOINdistance est parfait. D'autant qu'il est peu probable qu'il ait jamais besoin d'être interrogé pour des éléments individuels.

Bien qu'il n'en soit encore qu'à ses débuts, l'équipe du serveur MySQL fait un excellent travail pour communiquer les changements sur le blog .

Je pense que le stockage de JSON dans une base de données mysql va en fait à l'encontre de l'objectif de l'utilisation du SGBDR tel qu'il est destiné à être utilisé. Je ne l'utiliserais dans aucune donnée qui serait manipulée à un moment donné ou rapportée, car elle ajoute non seulement de la complexité, mais pourrait également avoir un impact sur les performances en fonction de la façon dont elle est utilisée.

Cependant, j'étais curieux de savoir si quelqu'un d'autre pensait à une raison possible de faire cela. Je pensais faire une exception à des fins de journalisation. Dans mon cas, je souhaite enregistrer les demandes qui ont une quantité variable de paramètres et d'erreurs. Dans cette situation, je souhaite utiliser des tables pour le type de requêtes et les requêtes elles-mêmes avec une chaîne JSON de différentes valeurs obtenues.

Dans la situation ci-dessus, les demandes sont journalisées et jamais manipulées ou indexées dans le champ de chaîne JSON. CEPENDANT, dans un environnement plus complexe, j'essaierais probablement d'utiliser quelque chose qui a plus d'intention pour ce type de données et de le stocker avec ce système. Comme d'autres l'ont dit, cela dépend vraiment de ce que vous essayez d'accomplir, mais le respect des normes contribue toujours à la longévité et à la fiabilité!

JSON est également un type de données valide dans la base de données PostgreSQL. Cependant, la base de données MySQL n'a pas encore officiellement pris en charge JSON. Mais c'est de la cuisson: http://mysqlserverteam.com/json-labs-release-native-json-data-type-and-binary-format/

Je conviens également qu'il existe de nombreux cas valides où certaines données sont mieux sérialisées en une chaîne dans une base de données. La raison principale peut être lorsqu'elle n'est pas régulièrement interrogée et que son propre schéma peut changer - vous ne voulez pas changer le schéma de base de données correspondant à cela. La deuxième raison est que lorsque la chaîne sérialisée provient directement de sources externes, il se peut que vous ne souhaitiez pas toutes les analyser et les alimenter à tout prix jusqu'à ce que vous en utilisiez. J'attendrai donc que la nouvelle version de MySQL prenne en charge JSON, car il sera alors plus facile de basculer entre différentes bases de données.

J'utilise json pour enregistrer n'importe quoi pour un projet, j'utilise trois tables en fait! un pour les données en json, un pour l'index de chaque métadonnée de la structure json (chaque méta est encodée par un identifiant unique), et un pour l'utilisateur de session, c'est tout. Le benchmark ne peut pas être quantifié à cet état précoce du code, mais par exemple j'étais des vues utilisateur (jointure interne avec index) pour obtenir une catégorie (ou quoi que ce soit, en tant qu'utilisateur, ...), et c'était très lent (très très lent , la vue utilisée dans mysql n'est pas la bonne façon). Le module de recherche, dans cette structure, peut faire tout ce que je veux, mais je pense que mongodb sera plus efficace dans ce concept d'enregistrement de données json complet. Pour mon exemple, j'utilise des vues pour créer un arbre de catégorie, et du fil d'Ariane, mon dieu! tant de requêtes à faire! apache lui-même parti! et, en fait, pour ce petit site Web, j'utilise un php qui génère des arbres et du fil d'Ariane, l'extraction des données se fait par le module de recherche (qui n'utilise que l'index), la table de données n'est utilisée que pour la mise à jour. Si je veux, je peux détruire tous les index, et les régénérer avec chaque donnée, et faire le travail inverse pour, comme, détruire toutes les données (json) et les régénérer uniquement avec la table d'index. Mon projet est jeune, fonctionnant sous php et mysql, mais, parfois, j'utilise node js et mongodb sera plus efficace pour ce projet.

Utilisez json si vous pensez que vous pouvez le faire, juste pour le faire, parce que vous le pouvez! et oubliez-le si c'était une erreur; essayez de faire un bon ou un mauvais choix, mais essayez!

Faible

un utilisateur français

Je sais que c'est vraiment tard, mais j'ai eu une situation similaire où j'ai utilisé une approche hybride de maintien des normes SGBDR de normalisation des tables jusqu'à un certain point, puis de stockage des données dans JSON en tant que valeur de texte au-delà de ce point. Donc par exemple je stocke les données dans 4 tableaux suivant les règles de normalisation du SGBDR. Cependant, dans le 4ème tableau pour accueillir le schéma dynamique, je stocke les données au format JSON. Chaque fois que je veux récupérer des données, je récupère les données JSON, les analyse et les affiche en Java. Cela a fonctionné pour moi jusqu'à présent et pour garantir que je suis toujours en mesure d'indexer les champs que je transforme en données json dans la table de manière normalisée à l'aide d'un ETL. Cela garantit que pendant que l'utilisateur travaille sur l'application, il fait face à un décalage minimal et que les champs sont transformés en un format convivial SGBDR pour l'analyse des données, etc.

Vous pouvez utiliser l'essentiel: https://gist.github.com/AminaG/33d90cb99c26298c48f670b8ffac39c3

Après l'avoir installé sur le serveur (juste besoin du privilège root pas super), vous pouvez faire quelque chose comme ceci:

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

Il reviendra a 2 Vous pouvez renvoyer n'importe quoi à l'intérieur de JSON en utilisant ceci La bonne partie est qu'il prend en charge MySQL 5.1,5.2,5.6. Et vous n'avez pas besoin d'installer de binaire sur le serveur.

Basé sur un ancien projet common-schema, mais il fonctionne toujours aujourd'hui https://code.google.com/archive/p/common-schema/