sql >> Base de Datos >  >> RDS >> PostgreSQL

Una descripción general de las capacidades de JSON dentro de PostgreSQL

¿Qué es JSON?

JSON significa "Notación de objetos de JavaScript", que es un tipo de formato de datos utilizado popularmente por las aplicaciones web. Esto significa que los datos se transmitirían entre aplicaciones web y servidores en dicho formato. JSON se introdujo como una alternativa al formato XML. En los "buenos viejos tiempos", los datos solían transmitirse en formato XML, que es un tipo de datos pesado en comparación con JSON. A continuación se muestra un ejemplo de cadena con formato JSON:

{ "ID":"001","name": "Ven", "Country": "Australia",  "city": "Sydney", "Job Title":"Database Consultant"}

Una cadena JSON puede contener otro objeto JSON dentro de sí mismo, como se muestra a continuación:

{ "ID":"001", "name": "Ven", "Job Title":"Database Consultant", "Location":{"Suburb":"Dee Why","city": "Sydney","State":"NSW","Country": "Australia"}}

Las aplicaciones web y móviles de hoy en día generan principalmente los datos en formato JSON, también denominados "Bytes JSON", que son recogidos por los servidores de aplicaciones y enviados a la base de datos. Los bytes JSON se procesan a su vez, se dividen en valores de columna independientes y se insertan en una tabla RDBMS.
Ejemplo:

{ "ID":"001","name": "Ven", "Country": "Australia",  "city": "Sydney", "Job Title":"Database Consultant"}

Los datos JSON anteriores se convierten a un SQL como el siguiente.

Insert into test (id, name, country,city,job_title) values  (001,'Ven','Australia','Sydney','Database Consultant');

Cuando se trata de almacenar y procesar los datos JSON, existen varias bases de datos NoSQL que lo admiten y la más popular es MongoDB. Cuando se trata de bases de datos RDBMS, hasta hace poco tiempo, las cadenas JSON se trataban como texto normal y no había tipos de datos que reconocieran, almacenaran o procesaran específicamente cadenas en formato JSON. PostgreSQL, la base de datos RDBMS de código abierto más popular, ha creado el tipo de datos JSON que resultó ser muy beneficioso para el rendimiento, la funcionalidad y la escalabilidad cuando se trata de manejar datos JSON.

PostgreSQL + JSON

La base de datos PostgreSQL se ha vuelto cada vez más popular desde que se introdujo el tipo de datos JSON. De hecho, PostgreSQL ha superado a MongoDB cuando se trata de procesar una gran cantidad de datos JSON. Las aplicaciones pueden almacenar cadenas JSON en la base de datos PostgreSQL en el formato JSON estándar. Los desarrolladores solo necesitan decirle a la aplicación que envíe las cadenas JSON a la base de datos como un tipo de datos json y las recupere en formato JSON. El almacenamiento de una cadena JSON en el tipo de datos JSON tiene varias ventajas en comparación con el almacenamiento de la misma en el tipo de datos TEXT. El tipo de datos JSON solo puede aceptar cadenas con formato JSON válido, si la cadena no tiene el formato JSON correcto, se genera un error. El tipo de datos JSON ayuda a la aplicación a realizar búsquedas eficientes y basadas en índices que veremos en detalle en breve.

El tipo de datos JSON se introdujo en la publicación PostgreSQL-9.2 y se realizaron mejoras significativas. La principal adición surgió en PostgreSQL-9.4 con la adición del tipo de datos JSONB. JSONB es una versión avanzada del tipo de datos JSON que almacena los datos JSON en formato binario. Esta es la mejora principal que marcó una gran diferencia en la forma en que se buscaron y procesaron los datos JSON en PostgreSQL. Echemos un vistazo detallado a las ventajas de los tipos de datos JSON.

Tipos de datos JSON y JSONB

El tipo de datos JSON almacena cadenas con formato json como un texto que no es muy poderoso y no admite muchas funciones relacionadas con JSON que se usan para búsquedas. Solo admite la indexación B-TREE tradicional y no admite otros tipos de índices que son imprescindibles para operaciones de búsqueda más rápidas y eficientes en datos JSON.

JSONB, la versión avanzada del tipo de datos JSON, es muy recomendable para almacenar y procesar documentos JSON. Admite una amplia gama de operadores json y tiene numerosas ventajas sobre JSON, como el almacenamiento de cadenas con formato JSON en formato binario y la compatibilidad con funciones e indexación JSON para realizar búsquedas eficientes.

Veamos las diferencias.

JSON JSONB
1 Muy parecido a un tipo de datos de TEXTO que almacena solo documentos JSON válidos. Almacena los documentos JSON en formato binario.
2 Almacena los documentos JSON tal cual, incluidos los espacios en blanco. Recorta los espacios en blanco y almacena en un formato propicio para búsquedas más rápidas y eficientes
3 No es compatible con la indexación de BÚSQUEDA DE TEXTO COMPLETO Admite indexación de BÚSQUEDA DE TEXTO COMPLETO
4 No es compatible con una amplia gama de funciones y operadores JSON Admite todas las funciones y operadores JSON

Ejemplo para el n.° 4 mencionado anteriormente

JSON

A continuación se muestra una tabla con tipo de datos JSON

dbt3=# \d product
                   Table "dbt3.product"
     Column     |  Type  | Collation | Nullable | Default
----------------+--------+-----------+----------+---------
 item_code      | bigint |           | not null |
 productdetails | json   |           |          |
Indexes:
    "product_pkey" PRIMARY KEY, btree (item_code)

No es compatible con los operadores JSON tradicionales (como "@>" o "#>"). La búsqueda de texto completo a través de datos JSON se realiza utilizando "@>" o "#>" en un SQL que no es compatible con el tipo de datos JSON

dbt3=# select * from product where productdetails @> '{"l_shipmode":"AIR"}' and productdetails @> '{"l_quantity":"27"}';
ERROR:  operator does not exist: json @> unknown
LINE 1: select * from product where productdetails @> '{"l_shipmode"...
                                                   ^
HINT:  No operator matches the given name and argument types. You might need to add explicit type casts.
dbt3=#

JSONB

A continuación se muestra una tabla con tipo de datos JSONB

dbt3=# \d products
                  Table "dbt3.products"
    Column     |  Type  | Collation | Nullable | Default
---------------+--------+-----------+----------+---------
 item_code     | bigint |           | not null |
 order_details | jsonb  |           |          |
Indexes:
    "products_pkey" PRIMARY KEY, btree (item_code)

Admite BÚSQUEDA DE TEXTO COMPLETO a través de datos JSON mediante operadores (como “@>”)

dbt3=# select * from products where order_details @> '{"l_shipmode" : "AIR"}' limit 2;
 item_code |                                                                                        order_details
-----------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
         4 | {"l_partkey": 21315, "l_orderkey": 1, "l_quantity": 28, "l_shipdate": "1996-04-21", "l_shipmode": "AIR", "l_commitdate": "1996-03-30", "l_shipinstruct": "NONE", "l_extendedprice": 34616.7}
         8 | {"l_partkey": 42970, "l_orderkey": 3, "l_quantity": 45, "l_shipdate": "1994-02-02", "l_shipmode": "AIR", "l_commitdate": "1994-01-04", "l_shipinstruct": "NONE", "l_extendedprice": 86083.6}
(2 rows)
Descargue el documento técnico hoy Administración y automatización de PostgreSQL con ClusterControlObtenga información sobre lo que necesita saber para implementar, monitorear, administrar y escalar PostgreSQLDescargar el documento técnico

Cómo consultar datos JSON

Echemos un vistazo a algunas capacidades JSON de PostgreSQL relacionadas con las operaciones de datos. A continuación se muestra cómo se ven los datos JSON en una tabla. La columna "detalles_del_pedido" es de tipo JSONB

dbt3=# select * from product_details ;
 item_code |                                                                                                 order_details
-----------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
         1 | {"l_partkey": 1551894, "l_orderkey": 1, "l_quantity": 17, "l_shipdate": "1996-03-13", "l_shipmode": "TRUCK", "l_commitdate": "1996-02-12", "l_shipinstruct": "DELIVER IN PERSON", "l_extendedprice": 33078.9}
         2 | {"l_partkey": 673091, "l_orderkey": 1, "l_quantity": 36, "l_shipdate": "1996-04-12", "l_shipmode": "MAIL", "l_commitdate": "1996-02-28", "l_shipinstruct": "TAKE BACK RETURN", "l_extendedprice": 38306.2}
         3 | {"l_partkey": 636998, "l_orderkey": 1, "l_quantity": 8, "l_shipdate": "1996-01-29", "l_shipmode": "REG AIR", "l_commitdate": "1996-03-05", "l_shipinstruct": "TAKE BACK RETURN", "l_extendedprice": 15479.7}
         4 | {"l_partkey": 21315, "l_orderkey": 1, "l_quantity": 28, "l_shipdate": "1996-04-21", "l_shipmode": "AIR", "l_commitdate": "1996-03-30", "l_shipinstruct": "NONE", "l_extendedprice": 34616.7}
         5 | {"l_partkey": 240267, "l_orderkey": 1, "l_quantity": 24, "l_shipdate": "1996-03-30", "l_shipmode": "FOB", "l_commitdate": "1996-03-14", "l_shipinstruct": "NONE", "l_extendedprice": 28974}
         6 | {"l_partkey": 156345, "l_orderkey": 1, "l_quantity": 32, "l_shipdate": "1996-01-30", "l_shipmode": "MAIL", "l_commitdate": "1996-02-07", "l_shipinstruct": "DELIVER IN PERSON", "l_extendedprice": 44842.9}
         7 | {"l_partkey": 1061698, "l_orderkey": 2, "l_quantity": 38, "l_shipdate": "1997-01-28", "l_shipmode": "RAIL", "l_commitdate": "1997-01-14", "l_shipinstruct": "TAKE BACK RETURN", "l_extendedprice": 63066.3}
         8 | {"l_partkey": 42970, "l_orderkey": 3, "l_quantity": 45, "l_shipdate": "1994-02-02", "l_shipmode": "AIR", "l_commitdate": "1994-01-04", "l_shipinstruct": "NONE", "l_extendedprice": 86083.6}
         9 | {"l_partkey": 190355, "l_orderkey": 3, "l_quantity": 49, "l_shipdate": "1993-11-09", "l_shipmode": "RAIL", "l_commitdate": "1993-12-20", "l_shipinstruct": "TAKE BACK RETURN", "l_extendedprice": 70822.1}
        10 | {"l_partkey": 1284483, "l_orderkey": 3, "l_quantity": 27, "l_shipdate": "1994-01-16", "l_shipmode": "SHIP", "l_commitdate": "1993-11-22", "l_shipinstruct": "DELIVER IN PERSON", "l_extendedprice": 39620.3}
(10 rows)

Seleccione todos los códigos de artículos, incluidas sus fechas de envío

dbt3=# select item_code, order_details->'l_shipdate' as shipment_date from product_details ;

 item_code | shipment_date
-----------+---------------
         1 | "1996-03-13"
         2 | "1996-04-12"
         3 | "1996-01-29"
         4 | "1996-04-21"
         5 | "1996-03-30"
         6 | "1996-01-30"
         7 | "1997-01-28"
         8 | "1994-02-02"
         9 | "1993-11-09"
        10 | "1994-01-16"
(10 rows)

Obtenga el código_artículo, la cantidad y el precio de todos los pedidos que llegaron por vía aérea

dbt3=# select item_code, order_details->'l_quantity' as quantity, order_details->'l_extendedprice' as price, order_details->'l_shipmode' as price from product_details where order_details->>'l_shipmode'='AIR';

 item_code | quantity |  price  | price
-----------+----------+---------+-------
         4 | 28       | 34616.7 | "AIR"
         8 | 45       | 86083.6 | "AIR"
(2 rows)

Los operadores JSON "->" y "->>" se utilizan para selecciones y comparaciones en la consulta SQL. El operador "->" devuelve el campo Objeto JSON como un campo entre comillas y el operador "->>" devuelve el campo Objeto JSON como TEXTO. Los dos SQL anteriores son ejemplos de visualización de valores de campo JSON tal cual. A continuación se muestra el ejemplo de cómo extraer el campo JSON en forma de TEXTO.
A continuación se muestra un ejemplo de cómo obtener el campo JSON en forma de TEXTO

dbt3=# select item_code, order_details->>'l_shipdate' as shipment_date from product_details ;
 item_code | shipment_date
-----------+---------------
         1 | 1996-03-13
         2 | 1996-04-12
         3 | 1996-01-29
         4 | 1996-04-21
         5 | 1996-03-30
         6 | 1996-01-30
         7 | 1997-01-28
         8 | 1994-02-02
         9 | 1993-11-09
        10 | 1994-01-16
(10 rows)

Hay otro operador llamado "#>" que se usa para consultar la parte de datos de un elemento JSON que, a su vez, es parte de una cadena JSON. Veamos un ejemplo.
A continuación se muestran los datos de la tabla.

dbt3=# select * from test_json ;
  id   |                                                                                                details
-------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 10000 | {"Job": "Database Consultant", "name": "Venkata", "Location": {"city": "Sydney", "State": "NSW", "Suburb": "Dee Why", "Country": "Australia"}}
 20000 | {"Job": "Database Consultant", "name": "Smith", "Location": {"city": "Sydney", "State": "NSW", "Suburb": "Manly", "Country": "Australia"}}
 30000 | {"Job": "Developer", "name": "John", "Location": {"city": "Sydney", "State": "NSW", "Suburb": "Brookvale", "Country": "Australia"}}
 50000 | {"cars": {"Ford": [{"doors": 4, "model": "Taurus"}, {"doors": 4, "model": "Escort"}], "Nissan": [{"doors": 4, "model": "Sentra"}, {"doors": 4, "model": "Maxima"}, {"doors": 2, "model": "Skyline"}]}}
 40000 | {"Job": "Architect", "name": "James", "Location": {"city": "Melbourne", "State": "NSW", "Suburb": "Trugnania", "Country": "Australia"}}

Quiero ver todos los detalles con "Estado" "NSW" y "Estado" es la clave de objeto JSON que forma parte de la clave "Ubicación". A continuación se muestra cómo consultar lo mismo.

dbt3=# select * from test_json where details #> '{Location,State}'='"NSW"';
  id   |                                                                    details
-------+------------------------------------------------------------------------------------------------------------------------------------------------
 10000 | {"Job": "Database Consultant", "name": "Venkata", "Location": {"city": "Sydney", "State": "NSW", "Suburb": "Dee Why", "Country": "Australia"}}
 20000 | {"Job": "Database Consultant", "name": "Smith", "Location": {"city": "Sydney", "State": "NSW", "Suburb": "Manly", "Country": "Australia"}}
 30000 | {"Job": "Developer", "name": "John", "Location": {"city": "Sydney", "State": "NSW", "Suburb": "Brookvale", "Country": "Australia"}}
 30000 | {"Job": "Architect", "name": "James", "Location": {"city": "Melbourne", "State": "NSW", "Suburb": "Trugnania", "Country": "Australia"}}
(4 rows)

Las operaciones aritméticas se pueden realizar en datos JSON. Se necesita conversión de tipos ya que la parte de datos de la columna JSON es TEXTO.

dbt3=# select item_code, order_details->'l_quantity' as quantity, order_details->'l_extendedprice' as price, order_details->'l_shipmode' as price from product_details where (order_details->'l_quantity')::int > 10;
 item_code | quantity |  price  |  price
-----------+----------+---------+---------
         1 | 17       | 33078.9 | "TRUCK"
         2 | 36       | 38306.2 | "MAIL"
         4 | 28       | 34616.7 | "AIR"
         5 | 24       | 28974   | "FOB"
         6 | 32       | 44842.9 | "MAIL"
         7 | 38       | 63066.3 | "RAIL"
         8 | 45       | 86083.6 | "AIR"
         9 | 49       | 70822.1 | "RAIL"
        10 | 27       | 39620.3 | "SHIP"
(9 rows)

Además de todo lo anterior, las siguientes operaciones también se pueden realizar en JSON utilizando SQL, incluidas las JOIN

  1. Ordenar los datos usando la cláusula ORDER BY
  2. Agregación mediante funciones agregadas como SUM, AVG, MIN, MAX, etc.
  3. Agrupa los datos usando la cláusula GROUP BY

¿Qué tal el rendimiento?

Los datos en las columnas JSON serán de naturaleza de texto y, según el tamaño de los datos, se pueden esperar problemas de rendimiento. Las búsquedas a través de datos JSON pueden consumir tiempo y potencia informática, lo que da como resultado respuestas lentas a las aplicaciones. Es imperativo que los DBA se aseguren de que los SQL que ingresan a las columnas JSON respondan lo suficientemente rápido y rindan un buen rendimiento. Dado que la extracción de datos se realiza a través de SQL, la opción que buscarían los DBA es la posibilidad de indexación y sí, los tipos de datos JSON admiten opciones de indexación.

Echemos un vistazo a las opciones de indexación que nos brinda JSON.

Indización de JSONB

El tipo de datos JSONB admite la indexación de BÚSQUEDA DE TEXTO COMPLETO. Esta es la capacidad más importante de JSONB que los DBA esperarán cuando utilicen tipos de datos JSONB. Es posible que un índice normal en una clave de objeto JSON no ayude cuando se usan operadores específicos de JSON en las consultas de búsqueda. 

dbt3=# explain select * from products where order_details @> '{"l_shipmode" : "AIR"}';
                             QUERY PLAN
--------------------------------------------------------------------
 Seq Scan on products  (cost=0.00..4205822.65 rows=59986 width=252)
   Filter: (order_details @> '{"l_shipmode": "AIR"}'::jsonb)
(2 rows)

JSONB es compatible con el tipo de índice BÚSQUEDA DE TEXTO COMPLETO llamado GIN, que ayuda a consultas como las anteriores.
Ahora, déjame crear un índice GIN y ver si eso ayuda

dbt3=# create index od_gin_idx on products using gin(order_details jsonb_path_ops);
CREATE INDEX

Si puede observar a continuación, la consulta recoge el índice GIN

dbt3=# explain select * from products where order_details @> '{"l_shipmode" : "AIR"}';
                                  QUERY PLAN
-------------------------------------------------------------------------------
 Bitmap Heap Scan on products  (cost=576.89..215803.18 rows=59986 width=252)
   Recheck Cond: (order_details @> '{"l_shipmode": "AIR"}'::jsonb)
   ->  Bitmap Index Scan on od_gin_idx  (cost=0.00..561.90 rows=59986 width=0)
         Index Cond: (order_details @> '{"l_shipmode": "AIR"}'::jsonb)

Y un índice B-TREE en lugar de GIN NO ayudaría

dbt3=# create index idx on products((order_details->>'l_shipmode'));
CREATE INDEX

dbt3=# \d products
                  Table "dbt3.products"
    Column     |  Type  | Collation | Nullable | Default
---------------+--------+-----------+----------+---------
 item_code     | bigint |           | not null |
 order_details | jsonb  |           |          |
Indexes:
    "products_pkey" PRIMARY KEY, btree (item_code)
    "idx" btree ((order_details ->> 'l_shipmode'::text))

Puede ver a continuación, la consulta prefiere FULL-TABLE-SCAN

dbt3=# explain select * from products where order_details @> '{"l_shipmode" : "AIR"}';
                             QUERY PLAN
--------------------------------------------------------------------
 Seq Scan on products  (cost=0.00..4205822.65 rows=59986 width=252)
   Filter: (order_details @> '{"l_shipmode": "AIR"}'::jsonb)

¿Qué es el índice GIN?

GIN significa Índice Invertido Generalizado. La capacidad central de GIN Index es acelerar las búsquedas de texto completo. Al realizar una búsqueda basada en claves o elementos específicos en un TEXTO o un documento, el índice GIN es el camino a seguir. El índice GIN almacena los pares "Clave" (o un elemento o un valor) y la "lista de posiciones". La lista de posiciones es el ID de fila de la clave. Esto significa que, si la "Clave" aparece en varios lugares del documento, el Índice GIN almacena la Clave solo una vez junto con su posición de ocurrencias, lo que no solo mantiene el Índice GIN compacto en tamaño y también ayuda a acelerar las búsquedas en gran medida. camino. Esta es la mejora en Postgres-9.4.

Desafíos con el índice GIN

Según la complejidad de los datos, el mantenimiento de los índices GIN puede resultar costoso. La creación de índices GIN consume tiempo y recursos, ya que el índice tiene que buscar en todo el documento para encontrar las claves y sus ID de fila. Puede ser aún más desafiante si el índice GIN está inflado. Además, el tamaño del índice GIN puede ser muy grande según el tamaño y la complejidad de los datos.

Indización de JSON

JSON no admite búsquedas de texto e índices como GIN

dbt3=# create index pd_gin_idx on product using gin(productdetails jsonb_path_ops);
ERROR:  operator class "jsonb_path_ops" does not accept data type json

La indexación normal como B-TREE es compatible tanto con JSON como con JSONB

Sí, los índices normales como B-TREE Index son compatibles con los tipos de datos JSON y JSONB y no son adecuados para las operaciones de búsqueda de texto. Cada clave de objeto JSON se puede indexar individualmente, lo que realmente ayudaría SOLO cuando se usa la misma clave de objeto en la cláusula WHERE.
Permítanme crear un índice B-TREE en JSONB y ver cómo funciona

dbt3=# create index idx on products((order_details->>'l_shipmode'));
CREATE INDEX

dbt3=# \d products
                  Table "dbt3.products"
    Column     |  Type  | Collation | Nullable | Default
---------------+--------+-----------+----------+---------
 item_code     | bigint |           | not null |
 order_details | jsonb  |           |          |
Indexes:
    "products_pkey" PRIMARY KEY, btree (item_code)
    "idx" btree ((order_details ->> 'l_shipmode'::text))

Ya hemos aprendido anteriormente que un índice B-TREE NO es útil para acelerar los SQL haciendo BÚSQUEDA DE TEXTO COMPLETO en los datos JSON usando operadores (como "@>"), y dichos índices SOLO ayudarían a acelerar las consultas como el siguiente, que son SQL de tipo RDBMS típicos (que no son consultas de búsqueda). Cada una de las claves de objeto JSON se puede indexar individualmente, lo que ayudaría a acelerar las consultas cuando esas claves de objeto JSON indexadas se usan en la cláusula WHERE.
El ejemplo a continuación utiliza la clave de objeto "l_shipmode" en la cláusula WHERE y desde está indexado, la consulta va a realizar un análisis de índice. Si desea buscar usando una clave de objeto diferente, entonces, la consulta elegiría hacer un ESCANEO DE TABLA COMPLETA.

dbt3=# explain select * from products where order_details->>'l_shipmode'='AIR';
                                   QUERY PLAN
---------------------------------------------------------------------------------
 Index Scan using idx on products  (cost=0.56..1158369.34 rows=299930 width=252)
   Index Cond: ((order_details ->> 'l_shipmode'::text) = 'AIR'::text)

Lo mismo funciona con el tipo de datos JSON también

dbt3=# create index idx on products((order_details->>'l_shipmode'));
CREATE INDEX

dbt3=# \d products
                  Table "dbt3.products"
    Column     |  Type  | Collation | Nullable | Default
---------------+--------+-----------+----------+---------
 item_code     | bigint |           | not null |
 order_details | json  |           |          |
Indexes:
    "products_pkey" PRIMARY KEY, btree (item_code)
    "idx" btree ((order_details ->> 'l_shipmode'::text))

Si puede observar, la consulta está utilizando el Índice

dbt3=# explain select * from products where order_details->>'l_shipmode'='AIR';
                                   QUERY PLAN
---------------------------------------------------------------------------------
 Index Scan using idx on products  (cost=0.56..1158369.34 rows=299930 width=252)
   Index Cond: ((order_details ->> 'l_shipmode'::text) = 'AIR'::text)

Conclusión

Estas son algunas cosas que debe recordar al utilizar datos JSON de PostgreSQL...

  • PostgreSQL es una de las mejores opciones para almacenar y procesar datos JSON
  • Con todas las potentes funciones, PostgreSQL puede ser su base de datos de documentos
  • He visto arquitecturas en las que se eligen dos o más almacenes de datos, con una combinación de bases de datos PostgreSQL y NoSQL como MongoDB o la base de datos Couchbase. Una API REST ayudaría a las aplicaciones a enviar los datos a diferentes almacenes de datos. Con PostgreSQL compatible con JSON, esta complejidad en la arquitectura se puede evitar simplemente eligiendo un almacén de datos.
  • Los datos JSON en PostgreSQL se pueden consultar e indexar, lo que brinda un rendimiento y escalabilidad increíbles
  • El tipo de datos JSONB es la opción más preferida, ya que es bueno para el almacenamiento y el rendimiento. Totalmente compatible con BÚSQUEDA DE TEXTO COMPLETO e indexación. Ofrece un buen rendimiento
  • Use el tipo de datos JSON solo si desea almacenar cadenas JSON como JSON y no está realizando búsquedas de texto muy complejas
  • La mayor ventaja de tener JSON en PostgreSQL es que la búsqueda se puede realizar usando SQLs
  • El rendimiento de búsqueda JSON en PostgreSQL ha estado a la par con las mejores bases de datos NoSQL como MongoDB