Explicación de JSONB introducida por PostgreSQL

PostgreSQL acaba de presentar JSONB y ya está en tendencia en las noticias de los hackers . Sería genial si alguien pudiera explicar cómo es diferente de Hstore y JSON previamente presentes en PostgreSQL. ¿Cuáles son sus ventajas y limitaciones y cuándo debería alguien considerar usarlo?

Primero, hstore es un módulo contrib, que solo le permite almacenar pares clave => valor, donde las claves y los valores solo pueden ser text s (sin embargo, los valores también pueden ser sql NULL ).

Tanto json jsonb permiten almacenar un valor JSON válido (definido en su especificación ).

F.ex. estas son representaciones JSON válidas: null , true , [1,false,"string",{"foo":"bar"}] , {"foo":"bar","baz":[null]}hstore is solo un pequeño subconjunto en comparación con lo que JSON es capaz (pero si solo necesitas este subconjunto, está bien).

La única diferencia entre json y jsonb es su almacenamiento:

  • json se almacena en su formato de texto plano, mientras
  • jsonb se almacena en alguna representación binaria

Hay 3 consecuencias principales de esto:

  • jsonb generalmente toma más espacio en disco para almacenar que json (a veces no)
  • jsonb toma más tiempo para construir a partir de su representación de entrada que json
  • json operaciones json toman mucho más tiempo que jsonb (y el análisis también debe hacerse cada vez que se realiza una operación a un valor tipeado json )

Cuando jsonb estará disponible con una versión estable, habrá dos casos de uso principales, cuando pueda seleccionar fácilmente entre ellos:

  1. Si solo trabaja con la representación JSON en su aplicación, PostgreSQL solo se usa para almacenar y recuperar esta representación, debe usar json .
  2. Si realiza muchas operaciones en el valor JSON en PostgreSQL, o utiliza la indexación en algún campo JSON, debe usar jsonb .

Peeyush:

La respuesta corta es:

  • Si está haciendo mucha manipulación JSON dentro de PostgreSQL, como ordenar, cortar, empalmar, etc., debe usar JSONB por razones de velocidad.
  • Si necesita búsquedas indexadas para búsquedas de claves arbitrarias en JSON, entonces debe usar JSONB.
  • Si no está haciendo ninguna de las anteriores, probablemente debería usar JSON.
  • Si necesita conservar el orden de las teclas, el espacio en blanco y las claves duplicadas, debe usar JSON.

Para obtener una respuesta más larga, deberá esperar a que realice una descripción completa del “cómo” más cercana a la versión 9.4.

Una explicación simple de la diferencia entre json y jsonb ( imagen original de PostgresProfessional ):

 SELECT '{"c":0, "a":2,"a":1}'::json, '{"c":0, "a":2,"a":1}'::jsonb; json | jsonb ------------------------+--------------------- {"c":0, "a":2,"a":1} | {"a": 1, "c": 0} (1 row) 
  • json: almacenamiento de texto «como es»
  • jsonb: sin espacios en blanco
  • jsonb: sin claves duplicadas, la última clave gana
  • jsonb: las claves están ordenadas

Más en video de discurso y presentación de presentación de diapositivas por los desarrolladores de jsonb. También introdujeron JsQuery , pg.extension proporciona un poderoso lenguaje de consulta jsonb

  • hstore es más un tipo de almacenamiento de “columna ancha”, es un diccionario plano (no nested) de pares clave-valor, siempre almacenado en un formato binario razonablemente eficiente (una tabla hash, de ahí el nombre).
  • json almacena los documentos JSON como texto, realizando la validación cuando se almacenan los documentos y analizándolos en la salida si es necesario (es decir, accediendo a campos individuales); debería soportar toda la especificación JSON. Como se almacena todo el texto JSON, se conserva su formato.
  • jsonb toma accesos directos por motivos de rendimiento: los datos JSON se analizan en la entrada y se almacenan en formato binario, no se mantienen las ordenaciones de las teclas en los diccionarios y tampoco se duplican las claves. El acceso a elementos individuales en el campo JSONB es rápido ya que no requiere analizar el texto JSON todo el tiempo. En la salida, los datos JSON se reconstruyen y se pierde el formato inicial.

OMI, no hay una razón importante para no usar jsonb una vez que esté disponible, si está trabajando con datos legibles por máquina.

Estuve en pgopen hoy los puntos de referencia son mucho más rápidos que mongodb, creo que fue aproximadamente 500% más rápido para los seleccionados. Casi todo fue más rápido al menos en un 200% cuando se contrasta con mongodb, que una excepción en este momento es una actualización que requiere reescribir completamente toda la columna json algo que mongodb maneja mejor.

La indización de la ginebra en jsonb suena increíble.

También postgres persistirá en los tipos de jsonb internamente y básicamente combinará esto con tipos tales como numérico, texto, booleano, etc.

Las uniones también serán posibles usando jsonb

Agregue PLv8 para los procedimientos almacenados y esto será básicamente un sueño hecho realidad para los desarrolladores de node.js.

Siendo que está almacenado como jsonb binario también quitará todos los espacios en blanco, cambiará el orden de las propiedades y eliminará las propiedades duplicadas utilizando la última ocurrencia de la propiedad.

Además del índice al consultar contra una columna jsonb en contraste con una columna json, postgres no tiene que ejecutar realmente la funcionalidad para convertir el texto a json en cada fila, lo que probablemente ahorrará una gran cantidad de tiempo solo.

Por lo que yo puedo decir,

  • hstore tal como existe actualmente (en Postgresql 9.3) no permite anidar otros objetos y matrices como los valores de sus pares clave / valor. sin embargo, un futuro parche de hstore permitirá el anidamiento. este parche no estará en la versión 9.4 y no se incluirá en el corto plazo.

  • json tal como existe actualmente permite el anidamiento, pero está basado en texto, y no permite la indexación, por lo tanto es “lento”

  • jsonb que se lanzará con 9.4 tendrá las capacidades de anidación actuales de json, así como la indexación GIN / GIST de hstore, por lo que será rápido

Las personas que trabajan en postgresql 9.4 parecen estar diciendo que el nuevo y rápido tipo jsonb atraerá a las personas que hubieran elegido usar un almacén de datos noSQL como MongoDB, pero ahora pueden combinar una base de datos relacional con datos no estructurados disponibles bajo un mismo techo

http://www.databasesoup.com/2014/02/why-hstore2jsonb-is-most-important.html

Los puntos de referencia de postgresql 9.4 jsonb parecen estar a la par o en algunos casos más rápidos que MongoDB

http://texture.io/alphabetum/postgresql-incl-hstore-vs-mongodb

jsonb es la versión “mejor” de JSON. Veamos con ayuda de un ejemplo.

Comparación por Prosfessional Postgres

  1. JSON permite espacios en blanco, es por eso que podemos ver espacios cuando se almacena la clave “a”, mientras que JSONB no.
  2. JSON almacena todos los valores de la clave. Esta es la razón por la que puede ver valores múltiples (2 y 1) contra la tecla “a”, mientras que JSONB solo “almacena” el último valor.
  3. JSON mantiene el orden en que los elementos están insertados, mientras que JSONB mantiene el orden “ordenado”.
  4. Los objetos JSONB se almacenan como binarios descomprimidos en lugar de “datos sin procesar” en JSON, donde no se requiere el repaso de los datos durante la recuperación.
  5. jsonb también es compatible con la indexación, lo que puede ser una ventaja significativa.

En general, uno debería preferir JSONB, a menos que haya necesidades bastante especializadas, como suposiciones heredadas sobre el orden de las claves de objetos.

Otra diferencia importante, que no se mencionó en ninguna de las respuestas anteriores, es que no existe un operador de igualdad para el tipo json , pero hay uno para jsonb .

Esto significa que no puede usar la palabra clave DISTINCT al seleccionar este json -type y / u otros campos de una tabla (puede usar DISTINCT ON lugar, pero no siempre es posible debido a casos como este ).