Archiviazione dei dati in MySQL come JSON

Pensavo fosse una cosa n00b da fare. E quindi non l'ho mai fatto. Poi ho visto che FriendFeed ha fatto questo e ha effettivamente migliorato la scalabilità del loro DB e ridotto la latenza. Sono curioso di farlo. E, in tal caso, qual è il modo giusto per farlo?

Fondamentalmente, qual è un buon posto per imparare a memorizzare tutto in MySQL come una sorta di DB CouchDB? Memorizzare tutto come JSON sembra che sarebbe più facile e veloce (non costruire, meno latenza).

Inoltre, è facile modificare, eliminare, ecc., Le cose archiviate come JSON sul DB?

CouchDB e MySQL sono due bestie molto diverse. JSON è il modo nativo per archiviare elementi in CouchDB. In MySQL, il meglio che potresti fare è memorizzare i dati JSON come testo in un singolo campo. Ciò vanificherebbe completamente lo scopo di memorizzarlo in un RDBMS e complicherebbe notevolmente ogni transazione del database.

Non farlo.

Detto questo, FriendFeed sembrava utilizzare uno schema estremamente personalizzato sopra MySQL. Dipende davvero da cosa esattamente si desidera memorizzare, non c'è quasi una risposta definitiva su come abusare di un sistema di database, quindi ha senso per te. Dato che l'articolo è molto vecchio e la ragione principale contro Mongo e Couch era l'immaturità, rivaluterei questi due se MySQL non lo taglia per te. Dovrebbero essere cresciuti molto ormai.

Tutti i commenti sembrano arrivare da una prospettiva sbagliata, va bene memorizzare il codice JSON tramite PHP in un DB relazionale e in effetti sarà più veloce caricare e visualizzare dati complessi come questo, tuttavia avrai considerazioni di progettazione come ricerca, indicizzazione, ecc.

Il modo migliore per farlo è usare dati ibridi, ad esempio se hai bisogno di cercare in base a data e ora MySQL (ottimizzato per le prestazioni) sarà molto più veloce di PHP e per qualcosa come la ricerca a distanza di luoghi MySQL dovrebbe essere anche molto più veloce (notare che la ricerca non accede). I dati su cui non è necessario eseguire la ricerca possono quindi essere archiviati in JSON, BLOB o in qualsiasi altro formato che ritieni necessario.

I dati a cui devi accedere vengono archiviati molto facilmente come JSON, ad esempio un sistema di fatturazione di base per caso. Non traggono alcun vantaggio da RDBMS e potrebbero essere archiviati in JSON solo da json_encoding ($ _ POST ['entires']) se si dispone della corretta struttura del modulo HTML.

Sono contento che tu sia felice di usare MongoDB e spero che continui a servirti bene, ma non pensare che MySQL sarà sempre fuori dal tuo radar, poiché la tua app aumenta di complessità potresti finire per aver bisogno di un RDBMS per alcune funzionalità e caratteristiche (anche se si tratta solo di ritirare i dati archiviati o il reporting aziendale)

MySQL 5.7 ora supporta un tipo di dati JSON nativo simile a MongoDB e altri archivi dati di documenti senza schema:

Supporto JSON

A partire da MySQL 5.7.8, MySQL supporta un tipo JSON nativo. I valori JSON non vengono archiviati come stringhe, ma utilizzano un formato binario interno che consente l'accesso rapido in lettura agli elementi del documento. I documenti JSON archiviati nelle colonne JSON vengono convalidati automaticamente ogni volta che vengono inseriti o aggiornati, con un documento non valido che genera un errore. I documenti JSON vengono normalizzati al momento della creazione e possono essere confrontati utilizzando la maggior parte degli operatori di confronto come =, <, <=,>,> =, <>,! = E <=>; per informazioni sugli operatori supportati, sulla precedenza e su altre regole che MySQL segue durante il confronto dei valori JSON, vedere Confronto e ordinamento dei valori JSON.

MySQL 5.7.8 introduce anche una serie di funzioni per lavorare con i valori JSON. Queste funzioni includono quelle elencate qui:

1. Funzioni che creano valori JSON: JSON_ARRAY (), JSON_MERGE () e JSON_OBJECT (). Vedere la Sezione 12.16.2, "Funzioni che creano valori JSON".
2. Funzioni che cercano valori JSON: JSON_CONTAINS (), JSON_CONTAINS_PATH (), JSON_EXTRACT (), JSON_KEYS () e JSON_SEARCH (). Vedere la Sezione 12.16.3, "Funzioni che ricercano valori JSON".
3. Funzioni che modificano i valori JSON: JSON_APPEND (), JSON_ARRAY_APPEND (), JSON_ARRAY_INSERT (), JSON_INSERT (), JSON_QUOTE (), JSON_REMOVE (), JSON_REPLACE (), JSON_SET () e JSON_UNQUOTE (). Vedere la Sezione 12.16.4, "Funzioni che modificano i valori JSON".
4. Funzioni che forniscono informazioni sui valori JSON: JSON_DEPTH (), JSON_LENGTH (), JSON_TYPE () e JSON_VALID (). Vedere la Sezione 12.16.5, "Funzioni che restituiscono attributi di valore JSON".

In MySQL 5.7.9 e versioni successive, puoi utilizzare colonna-> percorso come abbreviazione per JSON_EXTRACT (colonna, percorso). Funziona come un alias per una colonna ogni volta che un identificatore di colonna può essere presente in un'istruzione SQL, incluse le clausole WHERE, ORDER BY e GROUP BY. Ciò include SELECT, UPDATE, DELETE, CREATE TABLE e altre istruzioni SQL. Il lato sinistro deve essere un identificatore di colonna JSON (e non un alias). Il lato destro è un'espressione di percorso JSON tra virgolette che viene valutata rispetto al documento JSON restituito come valore di colonna.

Vedere Sezione 12.16.3, "Funzioni che ricercano valori JSON", per ulteriori informazioni su -> e JSON_EXTRACT (). Per informazioni sul supporto del percorso JSON in MySQL 5.7, consulta Ricerca e modifica dei valori JSON. Vedere anche Indici secondari e colonne generate virtuali.

Ulteriori informazioni:

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

i caratteri json non sono niente di speciale quando si tratta di archiviazione, caratteri come

{, }, [, ], ', a-z, 0-9.... sono davvero niente di speciale e possono essere memorizzati come testo.

il primo problema che avrai è questo

{profile_id: 22, nome utente: "Robert", password: "skhgeeht893htgn34ythg9er"}

quello memorizzato in un database non è così semplice da aggiornare a meno che tu non abbia la tua procedura e sviluppato un jsondecode per mysql

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

Quindi, poiché non puoi farlo, dovresti prima SELEZIONARE il json, decodificarlo, modificarlo, aggiornarlo, quindi in teoria potresti anche dedicare più tempo alla costruzione di una struttura di database adeguata!

Uso json per archiviare i dati ma solo i metadati, dati che non vengono aggiornati spesso, non relativi all'utente specifico .. esempio se un utente aggiunge un post, e in quel post aggiunge immagini mal analizza le immagini e crea thumb e quindi utilizzare gli URL del pollice in formato json.

Per illustrare quanto sia difficile ottenere dati JSON utilizzando una query, condividerò la query che ho effettuato per gestirlo.

Non prende in considerazione array o altri oggetti, ma solo tipi di dati di base. È necessario modificare le 4 istanze di colonna nel nome della colonna che memorizza il JSON e modificare le 4 istanze di myfield nel campo JSON a cui si desidera accedere.

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'

Dipende davvero dal tuo caso d'uso. Se stai archiviando informazioni che non hanno assolutamente alcun valore nei rapporti e non verranno interrogate tramite JOIN con altre tabelle, potrebbe avere senso memorizzare i tuoi dati in un unico campo di testo, codificato come JSON.

Questo potrebbe semplificare notevolmente il tuo modello di dati. Tuttavia, come menzionato da RobertPitt, non aspettarti di poter combinare questi dati con altri dati che sono stati normalizzati.

Questa è una vecchia domanda, ma riesco ancora a vederla nella parte superiore del risultato di ricerca di Google, quindi immagino che sarebbe significativo aggiungere una nuova risposta 4 anni dopo la domanda.

Prima di tutto, c'è un supporto migliore per l'archiviazione di JSON in RDBMS. Potresti considerare di passare a PostgreSQL (sebbene MySQL abbia supportato JSON dalla v5.7.7). PostgreSQL utilizza comandi SQL molto simili a MySQL tranne che supportano più funzioni. Una delle funzioni che hanno aggiunto è che forniscono il tipo di dati JSON e ora puoi eseguire query sul JSON archiviato. ( Qualche riferimento su questo ) Se non stai facendo la query direttamente nel tuo programma, ad esempio, usando PDO in php o eloquent in Laravel, tutto ciò che devi fare è solo installare PostgreSQL sul tuo server e modificare le impostazioni di connessione del database. Non hai nemmeno bisogno di cambiare il tuo codice.

La maggior parte delle volte, come suggerito dalle altre risposte, archiviare i dati come JSON direttamente in RDBMS non è una buona idea. Ci sono però alcune eccezioni. Una situazione a cui posso pensare è un campo con un numero variabile di voci collegate.

Ad esempio, per memorizzare il tag di un post di blog, normalmente sarà necessario disporre di una tabella per il post del blog, una tabella di tag e una tabella di corrispondenza. Quindi, quando l'utente vuole modificare un post e devi visualizzare quale tag è correlato a quel post, dovrai interrogare 3 tabelle. Ciò danneggerà notevolmente le prestazioni se la tabella di corrispondenza / tabella dei tag è lunga.

Memorizzando i tag come JSON nella tabella dei post del blog, la stessa azione richiede solo una singola ricerca nella tabella. L'utente sarà quindi in grado di vedere il post del blog da modificare più rapidamente, ma ciò danneggerà le prestazioni se si desidera fare un rapporto su quale post è collegato a un tag, o magari cercare per tag.

Puoi anche provare a denormalizzare il database. Duplicando i dati e archiviando i dati in entrambi i modi, è possibile beneficiare di entrambi i metodi. Avrai solo bisogno di un po 'più di tempo per archiviare i tuoi dati e più spazio di archiviazione (che è economico rispetto al costo di una maggiore potenza di calcolo)

Direi che gli unici due motivi per considerare questo sono:

• le prestazioni non sono abbastanza buone con un approccio normalizzato
• non è possibile modellare prontamente i dati particolarmente fluidi / flessibili / mutevoli

Ho scritto un po 'del mio approccio qui:

Quali problemi di scalabilità hai riscontrato utilizzando un archivio dati NoSQL?

(vedi la risposta in alto)

Anche JSON non era abbastanza veloce, quindi abbiamo utilizzato un approccio in formato testo personalizzato. Ha funzionato / continua a funzionare bene per noi.

C'è una ragione per cui non stai usando qualcosa come MongoDB? (potrebbe essere che MySQL sia "richiesto"; solo curioso)

Mi sembra che tutti coloro che rispondono a questa domanda manchino dell'unica questione critica, tranne @deceze: usa lo strumento giusto per il lavoro . Puoi forzare un database relazionale per archiviare quasi tutti i tipi di dati e puoi forzare Mongo a gestire i dati relazionali, ma a quale costo? Si finisce per introdurre complessità a tutti i livelli di sviluppo e manutenzione, dalla progettazione dello schema al codice dell'applicazione; per non parlare del successo delle prestazioni.

Nel 2014 abbiamo accesso a molti server di database che gestiscono eccezionalmente bene tipi specifici di dati.

• Mongo (archiviazione documenti)
• Redis (archiviazione dati valore-chiave)
• MySQL / Maria / PostgreSQL / Oracle / etc (dati relazionali)
• CouchDB (JSON)

Sono sicuro che mi sono persi altri, come RabbirMQ e Cassandra. Il punto è che usa lo strumento giusto per i dati che devi memorizzare.

Se la tua applicazione richiede l'archiviazione e il recupero di una varietà di dati molto, molto velocemente (e chi non lo fa) non esitare a utilizzare più origini dati per un'applicazione. I framework web più diffusi forniscono supporto per più origini dati (Rails, Django, Grails, Cake, Zend, ecc.). Questa strategia limita la complessità a un'area specifica dell'applicazione, l'ORM o l'interfaccia dell'origine dati dell'applicazione.

Ecco una funzione che salva / aggiorna le chiavi di un array JSON in una colonna e un'altra funzione che recupera i valori JSON. Queste funzioni vengono create presupponendo che il nome della colonna di archiviazione dell'array JSON sia json . Sta usando DOP .

Funzione Salva / Aggiorna

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

dove $ uid è l'id dell'utente, $ key - la chiave JSON da aggiornare e il suo valore è menzionato come $ val .

Funzione Ottieni valore

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

dove $ key è una chiave dell'array JSON da cui abbiamo bisogno del valore.

Il supporto iniziale per l'archiviazione di JSON in MySQL è stato aggiunto alla versione di MySQL 5.7.7 JSON labs ( binari di Linux , sorgente )! La versione sembra essere cresciuta da una serie di funzioni definite dall'utente relative a JSON rese pubbliche nel 2013 .

Questo nascente supporto JSON nativo sembra andare in una direzione molto positiva, inclusa la convalida JSON su INSERT, un formato di archiviazione binario ottimizzato che include una tabella di ricerca nel preambolo che consente alla funzione JSN_EXTRACT di eseguire ricerche binarie anziché analizzare a ogni accesso. C'è anche tutta una serie di nuove funzioni per la gestione e l'interrogazione di specifici tipi di dati 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                                      |
+--------------------------------------------------+

IMHO, quanto sopra è un ottimo caso d'uso per questa nuova funzionalità; molti database SQL hanno già una tabella utente e, invece di apportare infinite modifiche allo schema per adattarsi a un insieme in evoluzione di preferenze utente, avere una singola colonna JSON a JOINdistanza è perfetto. Tanto più che è improbabile che debba essere interrogato per singoli elementi.

Mentre è ancora presto, il team di MySQL server stanno facendo un grande lavoro di comunicare i cambiamenti sul blog .

Credo che l'archiviazione di JSON in un database mysql in effetti vanifichi lo scopo dell'utilizzo di RDBMS poiché è previsto che venga utilizzato. Non lo userei in nessun dato che potrebbe essere manipolato a un certo punto o riportato, poiché non solo aggiunge complessità ma potrebbe anche influire facilmente sulle prestazioni a seconda di come viene utilizzato.

Tuttavia, ero curioso se qualcun altro pensasse a una possibile ragione per farlo effettivamente. Stavo pensando di fare un'eccezione per scopi di registrazione. Nel mio caso, voglio registrare le richieste che hanno una quantità variabile di parametri ed errori. In questa situazione, desidero utilizzare le tabelle per il tipo di richieste e le richieste stesse con una stringa JSON di valori diversi ottenuti.

Nella situazione precedente, le richieste vengono registrate e non vengono mai manipolate o indicizzate all'interno del campo della stringa JSON. TUTTAVIA, in un ambiente più complesso, probabilmente proverei a usare qualcosa che ha più un'intenzione per questo tipo di dati e lo memorizzerei con quel sistema. Come altri hanno già detto, dipende davvero da quello che stai cercando di ottenere, ma seguire gli standard aiuta sempre la longevità e l'affidabilità!

JSON è un tipo di dati valido anche nel database PostgreSQL. Tuttavia, il database MySQL non ha ancora ufficialmente supportato JSON. Ma sta cuocendo: http://mysqlserverteam.com/json-labs-release-native-json-data-type-and-binary-format/

Sono anche d'accordo che ci sono molti casi validi in cui è meglio serializzare alcuni dati in una stringa in un database. Il motivo principale potrebbe essere quando non viene regolarmente interrogato e quando il proprio schema potrebbe cambiare: non si desidera modificare lo schema del database corrispondente a quello. Il secondo motivo è che quando la stringa serializzata proviene direttamente da origini esterne, potresti non voler analizzarle tutte e inserirle nel database ad ogni costo finché non ne usi una qualsiasi. Quindi aspetterò la nuova versione di MySQL per supportare JSON poiché sarà più facile passare da un database all'altro.

Uso json per registrare qualsiasi cosa per un progetto, in effetti uso tre tabelle! uno per i dati in json, uno per l'indice di ogni metadata della struttura json (ogni meta è codificato da un ID univoco) e uno per l'utente della sessione, tutto qui. Il benchmark non può essere quantificato in questo stato iniziale del codice, ma ad esempio sono stato le visualizzazioni dell'utente (inner join con indice) per ottenere una categoria (o qualsiasi altra cosa, come utente, ...), ed era molto lento (molto molto lento , la vista usata in mysql non è il modo giusto). Il modulo di ricerca, in questa struttura, può fare tutto ciò che voglio, ma penso che mongodb sarà più efficiente in questo concetto di record di dati json completo. Per il mio esempio, ho visualizzazioni utente per creare un albero di categoria e breadcrumb, mio ​​dio! tante query da fare! apache stesso andato! e, infatti, per questo piccolo sito, utilizzo un php che genera albero e breadcrumb, l'estrazione dei dati viene effettuata dal modulo di ricerca (che utilizza solo indice), la tabella dati viene utilizzata solo per l'aggiornamento. Se voglio, posso distruggere tutti gli indici e rigenerarli con ogni dato, e fare il lavoro inverso per distruggere tutti i dati (json) e rigenerarli solo con la tabella degli indici. Il mio progetto è giovane, funziona con php e mysql, ma a volte penso che l'utilizzo di node js e mongodb sarà più efficiente per questo progetto.

Usa json se pensi di poterlo fare, solo per farlo, perché puoi! e dimenticalo se è stato un errore; prova a fare una scelta buona o cattiva, ma prova!

Basso

un utente francese

So che è davvero tardi, ma ho avuto una situazione simile in cui ho utilizzato un approccio ibrido per mantenere gli standard RDBMS di normalizzare le tabelle fino a un certo punto e quindi archiviare i dati in JSON come valore di testo oltre quel punto. Quindi, ad esempio, memorizzo i dati in 4 tabelle seguendo le regole di normalizzazione RDBMS. Tuttavia nella 4a tabella per accogliere lo schema dinamico memorizzo i dati in formato JSON. Ogni volta che voglio recuperare i dati, recupero i dati JSON, li analizzo e li visualizzo in Java. Questo ha funzionato per me finora e per assicurarmi di essere ancora in grado di indicizzare i campi che trasformo in dati json nella tabella in modo normalizzato utilizzando un ETL. Ciò garantisce che mentre l'utente sta lavorando sull'applicazione, deve affrontare un ritardo minimo e i campi vengono trasformati in un formato compatibile con RDBMS per l'analisi dei dati, ecc.

Puoi usare questa sintesi: https://gist.github.com/AminaG/33d90cb99c26298c48f670b8ffac39c3

Dopo averlo installato sul server (serve solo il privilegio di root, non super), puoi fare qualcosa del genere:

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

Tornerà a 2 . Puoi restituire qualsiasi cosa all'interno di JSON usando questo La parte buona è che supporta MySQL 5.1,5.2,5.6. E non è necessario installare alcun binario sul server.

Basato su un vecchio progetto common-schema, ma funziona ancora oggi https://code.google.com/archive/p/common-schema/