2015-11-11 15 views
53

In MySQL 5.7 un nuovo tipo di dati per memorizzare JSON data in MySQL tabelle è stato aggiunto . Sarà ovviamente un grande cambiamento in MySQL. Sono elencati alcuni beneficiSupporto JSON nativo in MySQL 5.7: quali sono i pro e i contro del tipo di dati JSON in MYSQL?

documento di convalida - Solo i documenti JSON validi possono essere memorizzati in una colonna JSON, in modo da ottenere la convalida automatica dei dati.

Accesso efficiente - Ancora più importante, quando si archivia un documento JSON in una colonna JSON, non viene memorizzato come valore di testo normale. Invece, viene memorizzato in formato binario ottimizzato che consente l'accesso rapido ad oggetto membri ed elementi dell'array.

Prestazioni - Migliora le prestazioni della query creando indici su valori all'interno delle colonne JSON. Questo può essere ottenuto con "indici funzionali" su colonne virtuali.

Convenienza - La sintassi in linea aggiuntivo per le colonne JSON rende molto naturale per integrare le query del documento all'interno del vostro SQL. Ad esempio, (features.feature è una colonna JSON): SELECT feature->"$.properties.STREET" AS property_street FROM features WHERE id = 121254;

WOW! includono alcune grandi caratteristiche. Ora è più facile manipolare i dati. Ora è possibile memorizzare dati più complessi nella colonna. Quindi MySQL ora è condito con NoSQL.

Ora posso immaginare una query per i dati JSON qualcosa come

SELECT * FROM t1 
WHERE JSON_EXTRACT(data,"$.series") IN 
( 
SELECT JSON_EXTRACT(data,"$.inverted") 
FROM t1 | {"series": 3, "inverted": 8} 
WHERE JSON_EXTRACT(data,"$.inverted")<4); 

Quindi non penso mai di una struttura dello schema complessa e chiavi esterne in MySQL. Memorizzo relazioni complesse usando solo poche tabelle. È buono? Rompe la normalizzazione. Se ciò è possibile, suppongo che si comporterà come NoSQL in una colonna MySQL. Voglio davvero saperne di più su questa funzione. Pro e contro del tipo di dati JSON MySQL.

+0

oh si prega di non dire quello che penso che stai dicendo. [Qui, leggi questo] (http://stackoverflow.com/a/32620163).La tua è un'altra variante su una cattiva idea. – Drew

+0

@Drew Hai dato una grande risposta. Ma non è una mia domanda. Voglio solo sapere che se scriviamo una query per dati json, potremmo saltare le regole sql. perché non abbiamo bisogno di molte tabelle – Imran

+0

hai detto 'Ora è possibile memorizzare dati più complessi nella colonna'. Fai attenzione – Drew

risposta

35

Il seguente da MySQL 5.7 brings sexy back with JSON suona bene a me:

Utilizzando il tipo di dati JSON in MySQL viene fornito con due vantaggi rispetto memorizzazione stringhe JSON in un campo di testo:

convalida dei dati. I documenti JSON verranno automaticamente convalidati e i documenti non validi produrranno un errore. Migliorato il formato di memoria interna . I dati JSON vengono convertiti in un formato che consente di leggere rapidamente l'accesso ai dati in un formato strutturato. Il server è in grado di oggetti secondari di ricerca o valori nidificati di chiave o un indice, consentendo aggiunto flessibilità e prestazioni.

...

sapori specializzati di NoSQL negozi (Documento DB, negozi di valori-chiave e grafico DB) sono probabilmente migliori opzioni per i loro casi d'uso specifici, ma l'aggiunta di questo tipo di dati potrebbe consentire di ridurre la complessità della vostra tecnologia stack. Il prezzo si collega ai database MySQL (o compatibili). Ma non è un problema per molti utenti.

Nota la lingua su convalida del documento in quanto è un fattore importante. Immagino che sia necessario eseguire una serie di test per confrontare i due approcci. Quei due esseri:

  1. MySQL con tipi di dati JSON
  2. MySQL, senza

La rete ha ma slideshares poco profonde fin d'ora sul tema della mysql/JSON/prestazioni da quello che sto vedendo.

Forse il tuo post può essere un hub per questo. O forse la performance è un ripensamento dopo l'altro, non è sicuro, e sei semplicemente eccitato di non creare un mucchio di tavoli.

+5

Uno con; Il tipo di dati JSON non è supportato dalle tabelle della memoria Mysql, come i tipi di dati, TEXT e BLOB. Ciò significa che se è richiesta una tabella temporanea, verrà creata una tabella basata su disco non in memoria. Alcuni casi in cui viene utilizzata una tabella temporanea qui delineata: https://dev.mysql.com/doc/refman/5.7/en/internal-temporary-tables.html –

6

ho avuto in questo problema di recente, e io riassumere le seguenti esperienze:

1, non c'è un modo per risolvere tutti i problemi. 2, dovresti usare correttamente il JSON.

Un caso:

Ho una tabella di nome: CustomField, e deve due colonne: name, fields. name è una stringa localizzata, è contenuto dovrebbe piace:

{ 
    "en":"this is English name", 
    "zh":"this is Chinese name" 
    ...(other languages) 
} 

E fields dovrebbe essere simile a questo:

[ 
    { 
    "filed1":"value", 
    "filed2":"value" 
    ... 
    }, 
    { 
    "filed1":"value", 
    "filed2":"value" 
    ... 
    } 
    ... 
] 

Come si può vedere, sia la name e fields possono essere salvati come JSON, e funziona!

Tuttavia, se utilizzo lo name per cercare questa tabella molto frequentemente, cosa devo fare? Utilizzare lo JSON_CONTAINS, JSON_EXTRACT ...? Ovviamente, non è una buona idea salvarlo come JSON più, dovremmo salvarlo su una tabella indipendente: CustomFieldName.

Dal caso di cui sopra, credo che si dovrebbe tenere a mente queste idee:

  1. Perché MYSQL supporto JSON?
  2. Perché si desidera utilizzare JSON? La tua logica aziendale ha solo bisogno di questo? O c'è qualcos'altro?
  3. mai essere pigro

Grazie

+1

Potresti essere interessato all'utilizzo di una colonna VIRTUAL. https://www.percona.com/blog/2016/03/07/json-document-fast-lookup-with-mysql-5-7/ – Bell

Problemi correlati