Almacenamiento de datos en MySQL como JSON

Pensé que esto era algo increíble. Y, entonces, nunca lo he hecho. Luego vi que FriendFeed hizo esto y en realidad mejoró su escala de base de datos y disminuyó la latencia. Tengo curiosidad por saber si debería hacer esto. Y, si es así, ¿cuál es la forma correcta de hacerlo?

Básicamente, ¿cuál es un buen lugar para aprender a almacenar todo en MySQL como una especie de base de datos CouchDB? Almacenar todo como JSON parece que sería más fácil y rápido (no construir, menos latencia).

Además, ¿es fácil editar, eliminar, etc., cosas almacenadas como JSON en la base de datos?

CouchDB y MySQL son dos bestias muy diferentes. JSON es la forma nativa de almacenar cosas en CouchDB. En MySQL, lo mejor que puede hacer es almacenar datos JSON como texto en un solo campo. Esto frustraría por completo el propósito de almacenarlo en un RDBMS y complicaría mucho cada transacción de la base de datos.

No lo hagas.

Dicho esto, FriendFeed parecía usar un esquema extremadamente personalizado sobre MySQL. Realmente depende de lo que desee almacenar exactamente, apenas hay una respuesta definitiva sobre cómo abusar de un sistema de base de datos, por lo que tiene sentido para usted. Dado que el artículo es muy antiguo y su principal razón en contra de Mongo y Couch fue la inmadurez, reevaluaría estos dos si MySQL no es adecuado para usted. Deberían haber crecido mucho ahora.

Todos los que comentan parecen estar llegando a esto desde el ángulo incorrecto, está bien almacenar código JSON a través de PHP en una base de datos relacional y, de hecho, será más rápido cargar y mostrar datos complejos como este, sin embargo, tendrá consideraciones de diseño como búsqueda, indexación, etc.

La mejor manera de hacer esto es usar datos híbridos, por ejemplo, si necesita buscar en base a la fecha y hora, MySQL (rendimiento ajustado) será mucho más rápido que PHP y para algo como la distancia de búsqueda de lugares, MySQL también debería ser mucho más rápido (observe que la búsqueda no accede). Los datos en los que no necesita buscar se pueden almacenar en JSON, BLOB o en cualquier otro formato que realmente considere necesario.

Los datos a los que necesita acceder se almacenan muy fácilmente como JSON, por ejemplo, un sistema básico de facturación por caso. No se benefician mucho de RDBMS, y podrían almacenarse en JSON solo con json_encoding ($ _ POST ['entires']) si tiene la estructura de formulario HTML correcta.

Me alegro de que esté contento con MongoDB y espero que siga sirviéndole bien, pero no crea que MySQL siempre va a estar fuera de su radar, ya que su aplicación aumenta en complejidad, es posible que termine necesitando un RDBMS para algunas funciones y características (incluso si es solo para retirar datos archivados o informes comerciales)

MySQL 5.7 Now admite un tipo de datos JSON nativo similar a MongoDB y otros almacenes de datos de documentos sin esquema:

Soporte JSON

A partir de MySQL 5.7.8, MySQL admite un tipo JSON nativo. Los valores JSON no se almacenan como cadenas, sino que utilizan un formato binario interno que permite un acceso de lectura rápida a los elementos del documento. Los documentos JSON almacenados en columnas JSON se validan automáticamente cada vez que se insertan o actualizan, y un documento no válido produce un error. Los documentos JSON se normalizan en el momento de la creación y se pueden comparar utilizando la mayoría de los operadores de comparación como =, <, <=,>,> =, <>,! = Y <=>; para obtener información sobre los operadores admitidos, así como la precedencia y otras reglas que MySQL sigue al comparar valores JSON, consulte Comparación y ordenación de valores JSON.

MySQL 5.7.8 también introduce una serie de funciones para trabajar con valores JSON. Estas funciones incluyen las enumeradas aquí:

1. Funciones que crean valores JSON: JSON_ARRAY (), JSON_MERGE () y JSON_OBJECT (). Consulte la Sección 12.16.2, “Funciones que crean valores JSON”.
2. Funciones que buscan valores JSON: JSON_CONTAINS (), JSON_CONTAINS_PATH (), JSON_EXTRACT (), JSON_KEYS () y JSON_SEARCH (). Consulte la Sección 12.16.3, “Funciones que buscan valores JSON”.
3. Funciones que modifican los valores de JSON: JSON_APPEND (), JSON_ARRAY_APPEND (), JSON_ARRAY_INSERT (), JSON_INSERT (), JSON_QUOTE (), JSON_REMOVE (), JSON_REPLACE (), JSON_SET () y JSON_UNQUOTE (). Consulte la Sección 12.16.4, “Funciones que modifican los valores JSON”.
4. Funciones que proporcionan información sobre valores JSON: JSON_DEPTH (), JSON_LENGTH (), JSON_TYPE () y JSON_VALID (). Consulte la Sección 12.16.5, “Funciones que devuelven atributos de valor JSON”.

En MySQL 5.7.9 y versiones posteriores, puede usar column-> path como abreviatura de JSON_EXTRACT (columna, ruta). Esto funciona como un alias para una columna siempre que pueda aparecer un identificador de columna en una declaración SQL, incluidas las cláusulas WHERE, ORDER BY y GROUP BY. Esto incluye SELECT, UPDATE, DELETE, CREATE TABLE y otras sentencias SQL. El lado izquierdo debe ser un identificador de columna JSON (y no un alias). El lado derecho es una expresión de ruta JSON entre comillas que se evalúa contra el documento JSON devuelto como valor de columna.

Consulte la Sección 12.16.3, “Funciones que buscan valores JSON”, para obtener más información sobre -> y JSON_EXTRACT (). Para obtener información sobre la compatibilidad con rutas JSON en MySQL 5.7, consulte Búsqueda y modificación de valores JSON. Consulte también Índices secundarios y columnas generadas virtuales.

Más información:

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

Los caracteres json no son nada especial cuando se trata de almacenamiento, caracteres como

{, }, [, ], ', a-z, 0-9.... son realmente nada especial y puede ser almacenado como texto.

el primer problema que vas a tener es este

{profile_id: 22, nombre de usuario: 'Robert', contraseña: 'skhgeeht893htgn34ythg9er'}

que almacenado en una base de datos no es tan fácil de actualizar a menos que tenga su propio procedimiento y desarrolle un jsondecode para mysql

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

Entonces, como no puede hacer eso, primero tendrá que SELECCIONAR el json, decodificarlo, cambiarlo, actualizarlo, por lo que, en teoría, ¡también podría pasar más tiempo construyendo una estructura de base de datos adecuada!

Utilizo json para almacenar datos, pero solo metadatos, datos que no se actualizan con frecuencia, no relacionados con el usuario específico ... ejemplo, si un usuario agrega una publicación, y en esa publicación agrega imágenes, analizaré las imágenes y crearé pulgares y luego use las URL miniatura en formato json.

Para ilustrar lo difícil que es obtener datos JSON mediante una consulta, compartiré la consulta que hice para manejar esto.

No tiene en cuenta matrices u otros objetos, solo tipos de datos básicos. Debe cambiar las 4 instancias de column por el nombre de la columna que almacena el JSON y cambiar las 4 instancias de myfield por el campo JSON al que desea acceder.

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 de su caso de uso. Si está almacenando información que no tiene absolutamente ningún valor en los informes y no se consultará a través de JOIN con otras tablas, puede tener sentido que almacene sus datos en un solo campo de texto, codificado como JSON.

Esto podría simplificar enormemente su modelo de datos. Sin embargo, como lo menciona RobertPitt, no espere poder combinar estos datos con otros datos que se han normalizado.

Esta es una pregunta antigua, pero todavía puedo verla en la parte superior del resultado de búsqueda de Google, por lo que supongo que sería significativo agregar una nueva respuesta 4 años después de que se formuló la pregunta.

En primer lugar, existe un mejor soporte para almacenar JSON en RDBMS. Puede considerar cambiar a PostgreSQL (aunque MySQL es compatible con JSON desde v5.7.7). PostgreSQL usa comandos SQL muy similares a MySQL, excepto que admiten más funciones. Una de las funciones que agregaron es que proporcionan el tipo de datos JSON y ahora puede consultar el JSON almacenado. ( Alguna referencia sobre esto ) Si no está realizando la consulta directamente en su programa, por ejemplo, usando PDO en php o elocuente en Laravel, todo lo que necesita hacer es instalar PostgreSQL en su servidor y cambiar la configuración de conexión de la base de datos. Ni siquiera necesita cambiar su código.

La mayoría de las veces, como sugirieron las otras respuestas, almacenar datos como JSON directamente en RDBMS no es una buena idea. Sin embargo, hay algunas excepciones. Una situación en la que puedo pensar es un campo con un número variable de entrada vinculada.

Por ejemplo, para almacenar la etiqueta de una publicación de blog, normalmente necesitará tener una tabla para la publicación de blog, una tabla de etiquetas y una tabla coincidente. Por lo tanto, cuando el usuario quiera editar una publicación y usted necesite mostrar qué etiqueta está relacionada con esa publicación, deberá consultar 3 tablas. Esto dañará mucho el rendimiento si su tabla coincidente / tabla de etiquetas es larga.

Al almacenar las etiquetas como JSON en la tabla de publicaciones del blog, la misma acción solo requiere una búsqueda de una sola tabla. El usuario podrá ver la publicación del blog para editarla más rápido, pero esto dañará el rendimiento si desea hacer un informe sobre qué publicación está vinculada a una etiqueta, o tal vez buscar por etiqueta.

También puede intentar desnormalizar la base de datos. Al duplicar los datos y almacenar los datos de ambas formas, puede beneficiarse de ambos métodos. Solo necesitará un poco más de tiempo para almacenar sus datos y más espacio de almacenamiento (que es barato en comparación con el costo de más potencia de cálculo)

Yo diría que las únicas dos razones para considerar esto son:

• el rendimiento no es lo suficientemente bueno con un enfoque normalizado
• no puede modelar fácilmente sus datos particularmente fluidos / flexibles / cambiantes

Escribí un poco sobre mi propio enfoque aquí:

¿Qué problemas de escalabilidad ha encontrado al utilizar un almacén de datos NoSQL?

(ver la respuesta principal)

Incluso JSON no era lo suficientemente rápido, por lo que utilizamos un enfoque de formato de texto personalizado. Funcionó / ​​sigue funcionando bien para nosotros.

¿Hay alguna razón por la que no estás usando algo como MongoDB? (podría ser que MySQL sea "obligatorio"; solo es curioso)

Me parece que todos los que responden a esta pregunta se están perdiendo el único problema crítico, excepto @deceze: use la herramienta adecuada para el trabajo . Puede obligar a una base de datos relacional a almacenar casi cualquier tipo de datos y puede obligar a Mongo a manejar datos relacionales, pero ¿a qué costo? Termina introduciendo complejidad en todos los niveles de desarrollo y mantenimiento, desde el diseño del esquema hasta el código de la aplicación; sin mencionar el éxito en el rendimiento.

En 2014 tenemos acceso a muchos servidores de bases de datos que manejan tipos específicos de datos excepcionalmente bien.

• Mongo (almacenamiento de documentos)
• Redis (almacenamiento de datos de valor-clave)
• MySQL / Maria / PostgreSQL / Oracle / etc (datos relacionales)
• CouchDB (JSON)

Estoy seguro de que extrañé a algunos otros, como RabbirMQ y Cassandra. Mi punto es que use la herramienta adecuada para los datos que necesita almacenar.

Si su aplicación requiere el almacenamiento y la recuperación de una variedad de datos muy, muy rápido (y quién no), no dude en utilizar múltiples fuentes de datos para una aplicación. Los frameworks web más populares brindan soporte para múltiples fuentes de datos (Rails, Django, Grails, Cake, Zend, etc.). Esta estrategia limita la complejidad a un área específica de la aplicación, el ORM o la interfaz de origen de datos de la aplicación.

Aquí hay una función que guardaría / actualizaría las claves de una matriz JSON en una columna y otra función que recupera valores JSON. Estas funciones se crean asumiendo que el nombre de la columna para almacenar la matriz JSON es json . Está utilizando PDO .

Función guardar / actualizar

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

donde $ uid es la identificación del usuario, $ key : la clave JSON para actualizar y su valor se menciona como $ val .

Función Obtener valor

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

donde $ key es una clave de la matriz JSON de la que necesitamos el valor.

¡Se ha agregado soporte temprano para almacenar JSON en MySQL a la versión de laboratorios JSON de MySQL 5.7.7 ( binarios de Linux , código fuente )! El lanzamiento parece haber surgido de una serie de funciones definidas por el usuario relacionadas con JSON que se hicieron públicas en 2013 .

Este soporte JSON nativo naciente parece ir en una dirección muy positiva, incluida la validación JSON en INSERT, un formato de almacenamiento binario optimizado que incluye una tabla de búsqueda en el preámbulo que permite que la función JSN_EXTRACT realice búsquedas binarias en lugar de analizar cada acceso. También hay una gran cantidad de funciones nuevas para manejar y consultar tipos de datos 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                                      |
+--------------------------------------------------+

En mi humilde opinión, lo anterior es un gran caso de uso para esta nueva funcionalidad; muchas bases de datos SQL ya tienen una tabla de usuarios y, en lugar de realizar cambios de esquema interminables para adaptarse a un conjunto cambiante de preferencias de usuario, tener una sola columna JSON a una JOINdistancia es perfecto. Especialmente porque es poco probable que alguna vez necesite ser consultado para artículos individuales.

Si bien todavía es temprano, el equipo del servidor MySQL está haciendo un gran trabajo comunicando los cambios en el blog .

Creo que almacenar JSON en una base de datos mysql, de hecho, anula el propósito de usar RDBMS como está destinado a ser usado. No lo usaría en ningún dato que se manipule en algún momento o sobre el que se informe, ya que no solo agrega complejidad, sino que también podría afectar fácilmente al rendimiento dependiendo de cómo se use.

Sin embargo, tenía curiosidad por saber si alguien más pensaba en una posible razón para hacer esto. Estaba pensando en hacer una excepción con fines de registro. En mi caso, quiero registrar solicitudes que tengan una cantidad variable de parámetros y errores. En esta situación, quiero usar tablas para el tipo de solicitudes y las solicitudes en sí mismas con una cadena JSON de diferentes valores que se obtuvieron.

En la situación anterior, las solicitudes se registran y nunca se manipulan o indexan dentro del campo de cadena JSON. SIN EMBARGO, en un entorno más complejo, probablemente trataría de usar algo que tenga más intención para este tipo de datos y almacenarlo con ese sistema. Como han dicho otros, realmente depende de lo que esté tratando de lograr, pero seguir los estándares siempre ayuda a la longevidad y la confiabilidad.

JSON también es un tipo de datos válido en la base de datos PostgreSQL. Sin embargo, la base de datos MySQL aún no es compatible oficialmente con JSON. Pero está horneando: http://mysqlserverteam.com/json-labs-release-native-json-data-type-and-binary-format/

También estoy de acuerdo en que hay muchos casos válidos en los que es mejor serializar algunos datos en una cadena en una base de datos. La razón principal podría ser cuando no se consulta con regularidad y cuando su propio esquema puede cambiar; no desea cambiar el esquema de la base de datos correspondiente. La segunda razón es que cuando la cadena serializada proviene directamente de fuentes externas, es posible que no desee analizarlas todas y alimentar la base de datos a cualquier costo hasta que use alguna. Así que estaré esperando la nueva versión de MySQL para admitir JSON, ya que será más fácil cambiar entre diferentes bases de datos.

Uso json para grabar cualquier cosa para un proyecto, ¡de hecho uso tres tablas! uno para los datos en json, uno para el índice de cada metadato de la estructura json (cada meta está codificado por una identificación única) y uno para el usuario de la sesión, eso es todo. El punto de referencia no se puede cuantificar en este estado inicial del código, pero por ejemplo, fui vistas de usuario (combinación interna con índice) para obtener una categoría (o cualquier cosa, como usuario, ...), y fue muy lento (muy, muy lento , la vista usada en mysql no es la buena manera). El módulo de búsqueda, en esta estructura, puede hacer lo que quiera, pero creo que mongodb será más eficiente en este concepto de registro de datos json completo. Por mi ejemplo, utilizo vistas para crear un árbol de categorías y una ruta de navegación, ¡Dios mío! tantas consultas por hacer! apache mismo se ha ido! y, de hecho, para este pequeño sitio web, utilizo un php que genera árbol y ruta de navegación, la extracción de los datos la realiza el módulo de búsqueda (que usa solo índice), la tabla de datos se usa solo para actualización. Si quiero, puedo destruir todos los índices y regenerarlos con cada dato, y hacer el trabajo inverso para, como, destruir todos los datos (json) y regenerarlos solo con la tabla de índices. Mi proyecto es joven, se ejecuta en php y mysql, pero, en algún momento, creo que usar node js y mongodb será más eficiente para este proyecto.

Use json si cree que puede hacerlo, solo por hacerlo, ¡porque puede! y olvídalo si fue un error; intente hacer una buena o mala elección, ¡pero intente!

Bajo

un usuario francés

Sé que es muy tarde, pero tuve una situación similar en la que usé un enfoque híbrido para mantener los estándares RDBMS de normalizar tablas hasta cierto punto y luego almacenar datos en JSON como valor de texto más allá de ese punto. Entonces, por ejemplo, almaceno datos en 4 tablas siguiendo las reglas de normalización de RDBMS. Sin embargo, en la cuarta tabla para acomodar el esquema dinámico, almaceno datos en formato JSON. Cada vez que quiero recuperar datos, recupero los datos JSON, los analizo y los muestro en Java. Esto me ha funcionado hasta ahora y para asegurarme de que todavía puedo indexar los campos que transformo en datos json en la tabla de manera normalizada usando un ETL. Esto asegura que mientras el usuario está trabajando en la aplicación se enfrenta a un retraso mínimo y los campos se transforman a un formato compatible con RDBMS para el análisis de datos, etc.

Puede utilizar esta esencia: https://gist.github.com/AminaG/33d90cb99c26298c48f670b8ffac39c3

Después de instalarlo en el servidor (solo necesita privilegios de root, no super), puede hacer algo como esto:

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

Volverá a 2 . Puede devolver cualquier cosa dentro de JSON usando esto. La parte buena es que es compatible con MySQL 5.1,5.2,5.6. Y no es necesario instalar ningún binario en el servidor.

Basado en un proyecto antiguo common-schema, pero todavía funciona hoy https://code.google.com/archive/p/common-schema/