Armazenando dados no MySQL como JSON

Eu pensei que isso era uma coisa n00b a fazer. E, então, eu nunca fiz isso. Então vi que o FriendFeed fez isso e, na verdade, melhorou a escala do banco de dados e diminuiu a latência. Estou curioso para fazer isso. E, se sim, qual é o caminho certo para fazer isso?

Basicamente, qual é um bom lugar para aprender como armazenar tudo no MySQL como um banco de dados do tipo CouchDB? Armazenar tudo como JSON parece que seria mais fácil e rápido (sem construir, com menos latência).

Além disso, é fácil editar, excluir etc., os itens armazenados como JSON no banco de dados?

CouchDB e MySQL são dois animais muito diferentes. JSON é a maneira nativa de armazenar coisas no CouchDB. No MySQL, o melhor que você pode fazer é armazenar dados JSON como texto em um único campo. Isso anularia completamente o objetivo de armazená-lo em um RDBMS e complicaria bastante todas as transações do banco de dados.

Não.

Dito isto, o FriendFeed parecia usar um esquema extremamente personalizado sobre o MySQL. Realmente depende do que exatamente você deseja armazenar, quase não há uma resposta definitiva sobre como abusar de um sistema de banco de dados, por isso faz sentido para você. Dado que o artigo é muito antigo e a principal razão contra o Mongo e o Couch era a imaturidade, eu reavaliaria esses dois se o MySQL não resolver isso para você. Eles deveriam ter crescido muito agora.

Todos os comentários parecem estar chegando a esse ponto de vista errado; é bom armazenar código JSON via PHP em um banco de dados relacional e, de fato, será mais rápido carregar e exibir dados complexos como esse; no entanto, você terá considerações de design como pesquisa, indexação etc.

A melhor maneira de fazer isso é usar dados híbridos, por exemplo, se você precisar pesquisar com base em data e hora, o MySQL (desempenho ajustado) será muito mais rápido que o PHP e, para algo como pesquisar a distância dos locais, o MySQL também deverá ser bastante mais rápido (a busca por aviso não está sendo acessada). Os dados que você não precisa pesquisar podem ser armazenados em JSON, BLOB ou em qualquer outro formato que você considere realmente necessário.

Os dados que você precisa acessar são muito facilmente armazenados como JSON, por exemplo, um sistema básico de faturas por caso. Eles não se beneficiam muito do RDBMS e podem ser armazenados no JSON apenas por json_encoding ($ _ POST ['entires']) se você tiver a estrutura de formulário HTML correta.

Fico feliz que você esteja feliz em usar o MongoDB e espero que continue a atendê-lo bem, mas não pense que o MySQL sempre estará fora do seu radar, pois seu aplicativo aumenta a complexidade. Você pode acabar precisando de um RDBMS para algumas funcionalidades e recursos (mesmo que seja apenas para retirar dados arquivados ou relatórios comerciais)

O MySQL 5.7 agora suporta um tipo de dados JSON nativo semelhante ao MongoDB e outros armazenamentos de dados de documentos sem esquema:

Suporte JSON

A partir do MySQL 5.7.8, o MySQL suporta um tipo JSON nativo. Os valores JSON não são armazenados como sequências, em vez disso, usando um formato binário interno que permite acesso rápido de leitura aos elementos do documento. Os documentos JSON armazenados nas colunas JSON são validados automaticamente sempre que são inseridos ou atualizados, com um documento inválido produzindo um erro. Os documentos JSON são normalizados na criação e podem ser comparados usando a maioria dos operadores de comparação, como =, <, <=,>,> =, <>,! = E <=>; para obter informações sobre operadores suportados, bem como precedência e outras regras que o MySQL segue ao comparar valores JSON, consulte Comparação e Ordenação de Valores JSON.

O MySQL 5.7.8 também apresenta várias funções para trabalhar com valores JSON. Essas funções incluem as listadas aqui:

1. Funções que criam valores JSON: JSON_ARRAY (), JSON_MERGE () e JSON_OBJECT (). Consulte a Seção 12.16.2, “Funções que criam valores JSON”.
2. Funções que pesquisam valores JSON: JSON_CONTAINS (), JSON_CONTAINS_PATH (), JSON_EXTRACT (), JSON_KEYS () e JSON_SEARCH (). Consulte a Seção 12.16.3, “Funções que pesquisam valores JSON”.
3. Funções que modificam valores JSON: JSON_APPEND (), JSON_ARRAY_APPEND (), JSON_ARRAY_INSERT (), JSON_INSERT (), JSON_QUOTE (), JSON_REMOVE (), JSON_REPLACE (), JSON_SET () e JSON_UNQUOTE (). Consulte a Seção 12.16.4, “Funções que modificam valores JSON”.
4. Funções que fornecem informações sobre valores JSON: JSON_DEPTH (), JSON_LENGTH (), JSON_TYPE () e JSON_VALID (). Consulte a Seção 12.16.5, “Funções que retornam atributos de valor JSON”.

No MySQL 5.7.9 e posterior, você pode usar column-> path como abreviação de JSON_EXTRACT (coluna, caminho). Isso funciona como um alias para uma coluna sempre que um identificador de coluna pode ocorrer em uma instrução SQL, incluindo cláusulas WHERE, ORDER BY e GROUP BY. Isso inclui SELECT, UPDATE, DELETE, CREATE TABLE e outras instruções SQL. O lado esquerdo deve ser um identificador de coluna JSON (e não um alias). O lado direito é uma expressão de caminho JSON entre aspas que é avaliada em relação ao documento JSON retornado como o valor da coluna.

Consulte a Seção 12.16.3, “Funções que pesquisam valores JSON”, para obter mais informações sobre -> e JSON_EXTRACT (). Para obter informações sobre o suporte ao caminho JSON no MySQL 5.7, consulte Pesquisando e Modificando Valores JSON. Consulte também Índices secundários e colunas geradas virtuais.

Mais informações:

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

caracteres json não são nada de especial quando se trata de armazenamento, caracteres como

{, }, [, ], ', a-z, 0-9.... são realmente nada de especial e pode ser armazenado como texto.

o primeiro problema que você vai ter é esse

{profile_id: 22, nome de usuário: 'Robert', senha: 'skhgeeht893htgn34ythg9er'}

que armazenado em um banco de dados não é tão simples de atualizar, a menos que você tenha seu próprio procedimento e tenha desenvolvido um jsondecode para mysql

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

Então, como você não pode fazer isso, teria que primeiro selecionar o json, decodificá-lo, alterá-lo, atualizá-lo; portanto, em teoria, você também pode gastar mais tempo construindo uma estrutura de banco de dados adequada!

Eu uso o json para armazenar dados, mas apenas os metadados, dados que não são atualizados com frequência, não relacionados ao usuário específico. em seguida, use os URLs do polegar em um formato json.

Para ilustrar como é difícil obter dados JSON usando uma consulta, compartilharei a consulta que fiz para lidar com isso.

Ele não leva em consideração matrizes ou outros objetos, apenas tipos de dados básicos. Você deve alterar as 4 instâncias da coluna para o nome da coluna que armazena o JSON e as 4 instâncias de myfield para o campo JSON que deseja acessar.

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'

Realmente depende do seu caso de uso. Se você estiver armazenando informações que não têm absolutamente nenhum valor nos relatórios e não serão consultadas por meio de JOINs com outras tabelas, pode fazer sentido armazenar seus dados em um único campo de texto, codificado como JSON.

Isso poderia simplificar bastante o seu modelo de dados. No entanto, como mencionado por RobertPitt, não espere poder combinar esses dados com outros dados que foram normalizados.

Esta é uma pergunta antiga, mas ainda consigo ver isso no topo do resultado de pesquisa do Google, então acho que seria significativo adicionar uma nova resposta 4 anos após a pergunta.

Primeiro de tudo, há um suporte melhor ao armazenar JSON no RDBMS. Você pode considerar mudar para o PostgreSQL (embora o MySQL suporte JSON desde a versão 5.7.7). O PostgreSQL usa comandos SQL muito semelhantes ao MySQL, exceto que eles suportam mais funções. Uma das funções que eles adicionaram é que eles fornecem o tipo de dados JSON e agora você pode consultar o JSON armazenado. ( Alguma referência a isso ) Se você não está fazendo a consulta diretamente no seu programa, por exemplo, usando o PDO no php ou eloquent no Laravel, tudo que você precisa fazer é apenas instalar o PostgreSQL no servidor e alterar as configurações de conexão do banco de dados. Você nem precisa alterar seu código.

Na maioria das vezes, como as outras respostas sugeriam, armazenar dados como JSON diretamente no RDBMS não é uma boa ideia. Há alguma exceção, no entanto. Uma situação em que consigo pensar é em um campo com número variável de entrada vinculada.

Por exemplo, para armazenar tags de uma postagem de blog, normalmente você precisará de uma tabela para postagem de blog, uma tabela de tags e uma tabela correspondente. Portanto, quando o usuário deseja editar uma postagem e você precisa exibir qual tag está relacionada a essa postagem, será necessário consultar 3 tabelas. Isso prejudicará muito o desempenho se a tabela correspondente / tabela de tags for longa.

Armazenando as tags como JSON na tabela de postagem do blog, a mesma ação requer apenas uma pesquisa de tabela única. O usuário poderá ver a postagem do blog ser editada mais rapidamente, mas isso prejudicará o desempenho se você quiser fazer um relatório sobre qual postagem está vinculada a uma tag ou talvez pesquisar por tag.

Você também pode tentar desnormalizar o banco de dados. Duplicando os dados e armazenando-os de ambas as maneiras, você pode receber os benefícios de ambos os métodos. Você precisará de um pouco mais de tempo para armazenar seus dados e mais espaço de armazenamento (o que é barato comparado ao custo de mais poder de computação)

Eu diria que as duas únicas razões para considerar isso são:

• desempenho simplesmente não é bom o suficiente com uma abordagem normalizada
• você não pode modelar prontamente seus dados particularmente fluidos / flexíveis / variáveis

Eu escrevi um pouco sobre minha própria abordagem aqui:

Quais problemas de escalabilidade você encontrou ao usar um repositório de dados NoSQL?

(veja a resposta superior)

Mesmo o JSON não era rápido o suficiente, então usamos uma abordagem de formato de texto personalizado. Trabalhou / continua a funcionar bem para nós.

Existe uma razão para você não estar usando algo como o MongoDB? (pode ser que o MySQL seja "necessário"; apenas curioso)

Parece-me que todos os que estão respondendo a essa pergunta estão perdendo o problema crítico, exceto @deceze - use a ferramenta certa para o trabalho . Você pode forçar um banco de dados relacional a armazenar quase qualquer tipo de dados e o Mongo a lidar com dados relacionais, mas a que custo? Você acaba introduzindo complexidade em todos os níveis de desenvolvimento e manutenção, do design do esquema ao código do aplicativo; para não mencionar o desempenho atingido.

Em 2014, temos acesso a muitos servidores de banco de dados que lidam com tipos específicos de dados excepcionalmente bem.

• Mongo (armazenamento de documentos)
• Redis (armazenamento de dados com valor-chave)
• MySQL / Maria / PostgreSQL / Oracle / etc (dados relacionais)
• CouchDB (JSON)

Tenho certeza de que perdi alguns outros, como RabbirMQ e Cassandra. Meu ponto é, use a ferramenta certa para os dados que você precisa armazenar.

Se o seu aplicativo exigir o armazenamento e a recuperação de uma variedade de dados muito, muito rápido, (e quem não o faz) não evite usar várias fontes de dados para um aplicativo. As estruturas da web mais populares fornecem suporte para várias fontes de dados (Rails, Django, Grails, Cake, Zend, etc.). Essa estratégia limita a complexidade a uma área específica do aplicativo, o ORM ou a interface da fonte de dados do aplicativo.

Aqui está uma função que salvaria / atualizaria chaves de uma matriz JSON em uma coluna e outra função que recupera valores JSON. Essas funções são criadas assumindo que o nome da coluna de armazenamento da matriz JSON seja json . Está usando o DOP .

Função Salvar / Atualizar

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

onde $ uid é o ID do usuário, $ key - a chave JSON a ser atualizada e seu valor é mencionado como $ val .

Função 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];
}

onde $ key é uma chave da matriz JSON da qual precisamos do valor.

O suporte inicial para armazenar JSON no MySQL foi adicionado à versão do MySQL 5.7.7 JSON labs ( binários linux , fonte )! O lançamento parece ter crescido a partir de uma série de funções definidas pelo usuário relacionadas ao JSON tornadas públicas em 2013 .

Esse suporte nativo a JSON nativo parece estar caminhando em uma direção muito positiva, incluindo a validação JSON no INSERT, um formato de armazenamento binário otimizado, incluindo uma tabela de pesquisa no preâmbulo que permite que a função JSN_EXTRACT execute pesquisas binárias em vez de analisar em todos os acessos. Há também uma série de novas funções para manipular e consultar tipos de dados JSON específicos:

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, o acima é um ótimo caso de uso para essa nova funcionalidade; muitos bancos de dados SQL já possuem uma tabela de usuários e, em vez de fazer inúmeras alterações de esquema para acomodar um conjunto em evolução de preferências do usuário, JOINé perfeita ter uma única coluna JSON a uma única distância. Especialmente porque é improvável que ele precise ser consultado para itens individuais.

Embora ainda seja cedo, a equipe de servidor MySQL estão fazendo um grande trabalho de comunicação das mudanças no o blogue .

Acredito que armazenar JSON em um banco de dados mysql de fato anula o propósito de usar RDBMS como ele deve ser usado. Eu não o usaria em nenhum dado que fosse manipulado em algum momento ou relatado, pois ele não apenas adiciona complexidade, mas também pode facilmente afetar o desempenho, dependendo de como é usado.

No entanto, fiquei curioso para saber se alguém pensou em uma possível razão para fazer isso. Eu estava pensando em fazer uma exceção para fins de log. No meu caso, quero registrar solicitações que tenham uma quantidade variável de parâmetros e erros. Nessa situação, quero usar tabelas para o tipo de solicitações e as próprias solicitações com uma sequência JSON de diferentes valores que foram obtidos.

Na situação acima, as solicitações são registradas e nunca manipuladas ou indexadas no campo de sequência JSON. No entanto, em um ambiente mais complexo, eu provavelmente tentaria usar algo que tem mais intenção para esse tipo de dados e armazená-lo com esse sistema. Como outros já disseram, isso realmente depende do que você está tentando realizar, mas seguir os padrões sempre ajuda a longevidade e confiabilidade!

JSON também é um tipo de dados válido no banco de dados PostgreSQL. No entanto, o banco de dados MySQL ainda não suporta oficialmente o JSON. Mas está assando: http://mysqlserverteam.com/json-labs-release-native-json-data-type-and-binary-format/

Também concordo que existem muitos casos válidos de que alguns dados devem ser serializados para uma string em um banco de dados. O principal motivo pode ser quando não é consultado regularmente e quando o próprio esquema pode mudar - você não deseja alterar o esquema do banco de dados correspondente a isso. O segundo motivo é que, quando a seqüência de caracteres serializada é diretamente de fontes externas, você pode não querer analisar todas elas e alimentar o banco de dados a qualquer custo até usar alguma. Então, esperarei que a nova versão do MySQL suporte JSON, pois será mais fácil alternar entre diferentes bancos de dados.

Eu uso json para gravar qualquer coisa para um projeto, eu uso três tabelas de fato! um para os dados em json, um para o índice de cada metadado da estrutura json (cada meta é codificado por um ID exclusivo) e um para o usuário da sessão, isso é tudo. O benchmark não pode ser quantificado nesse estado inicial do código, mas, por exemplo, eu era visualizações de usuários (junção interna com índice) para obter uma categoria (ou qualquer coisa, como usuário, ...), e era muito lento (muito muito lento , a visualização usada no mysql não é o bom caminho). O módulo de pesquisa, nessa estrutura, pode fazer o que eu quiser, mas acho que o mongodb será mais eficiente nesse conceito de registro de dados json completo. Para meu exemplo, eu utilizo visualizações para criar uma árvore de categoria e trilha de navegação, meu deus! tantas consultas para fazer! o próprio apache se foi! e, de fato, para este pequeno site, eu uso um php que gera árvores e migalhas de pão, a extração dos dados é feita pelo módulo de pesquisa (que usa apenas o índice), a tabela de dados é usada apenas para atualização. Se eu quiser, posso destruir todos os índices e regenerá-los com cada dado, e fazer o trabalho inverso para, assim, destruir todos os dados (json) e regenerá-los apenas com a tabela de índices. Meu projeto é jovem, rodando sob php e mysql, mas, às vezes, uso o nó js e o mongodb será mais eficiente para este projeto.

Use json se você acha que pode fazer, apenas para fazê-lo, porque você pode! e esqueça, se foi um erro; tente fazer uma boa ou má escolha, mas tente!

Baixo

um usuário francês

Sei que isso é realmente muito tarde, mas tive uma situação semelhante em que usei uma abordagem híbrida de manter os padrões RDBMS de normalização de tabelas até certo ponto e depois armazenar dados em JSON como valor de texto além desse ponto. Por exemplo, eu armazeno dados em 4 tabelas, seguindo as regras de normalização do RDBMS. No entanto, na quarta tabela para acomodar o esquema dinâmico, eu armazeno dados no formato JSON. Toda vez que desejo recuperar dados, recupero os dados JSON, os analiso e os mostro em Java. Isso funcionou para mim até agora e para garantir que ainda seja capaz de indexar os campos que transformamos em dados json na tabela de uma maneira normalizada usando um ETL. Isso garante que, enquanto o usuário estiver trabalhando no aplicativo, ele enfrenta um atraso mínimo e os campos sejam transformados em um formato compatível com RDBMS para análise de dados etc.

Você pode usar esta essência: https://gist.github.com/AminaG/33d90cb99c26298c48f670b8ffac39c3

Depois de instalá-lo no servidor (você só precisa de privilégios de root e não super), você pode fazer algo assim:

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

Vai voltar a 2 . Você pode retornar qualquer coisa dentro do JSON usando isso. A parte boa é que ele suporta o MySQL 5.1,5.2,5.6. E você não precisa instalar nenhum binário no servidor.

Com base no projeto antigo common-schema, mas ainda está funcionando hoje https://code.google.com/archive/p/common-schema/