Een overzicht van JSON-mogelijkheden binnen PostgreSQL

Wat is JSON?

JSON staat voor "JavaScript Object Notation", een type gegevensformaat dat in de volksmond wordt gebruikt door webtoepassingen. Dit betekent dat de gegevens in een dergelijk formaat tussen webapplicaties en servers worden verzonden. JSON is geïntroduceerd als alternatief voor het XML-formaat. In de "goede oude tijd" werden de gegevens die werden gebruikt om te worden verzonden in XML-indeling, wat een zwaar gegevenstype is in vergelijking met JSON. Hieronder ziet u een voorbeeld van een JSON-geformatteerde tekenreeks:

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

Een JSON-tekenreeks kan een ander JSON-object in zichzelf bevatten, zoals hieronder getoond:

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

Moderne web- en mobiele applicaties genereren de gegevens meestal in JSON-indeling, ook wel "JSON-bytes" genoemd, die worden opgehaald door de applicatieservers en naar de database worden verzonden. De JSON-bytes worden op hun beurt verwerkt, opgesplitst in afzonderlijke kolomwaarden en ingevoegd in een RDBMS-tabel.
Voorbeeld:

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

Bovenstaande JSON-gegevens worden geconverteerd naar een SQL zoals hieronder..

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

Als het gaat om het opslaan en verwerken van de JSON-gegevens, zijn er verschillende NoSQL-databases die dit ondersteunen en de meest populaire is MongoDB. Als het gaat om RDBMS-databases, werden JSON-tekenreeksen tot voor kort behandeld als normale tekst en waren er geen gegevenstypen die specifiek JSON-tekenreeksen herkennen, opslaan of verwerken. PostgreSQL, de meest populaire open-source RDBMS-database, heeft het JSON-gegevenstype ontwikkeld dat zeer gunstig bleek te zijn voor prestaties, functionaliteit en schaalbaarheid als het gaat om het verwerken van JSON-gegevens.

PostgreSQL + JSON

PostgreSQL-database is steeds populairder geworden sinds het JSON-gegevenstype werd geïntroduceerd. PostgreSQL presteerde zelfs beter dan MongoDB als het gaat om het verwerken van een grote hoeveelheid JSON-gegevens. De applicaties kunnen JSON-strings opslaan in de PostgreSQL-database in het standaard JSON-formaat. Ontwikkelaars hoeven de applicatie alleen maar te vertellen om de JSON-strings naar de database te verzenden als een json-gegevenstype en terug te halen in het JSON-formaat. Het opslaan van een JSON-tekenreeks in het JSON-gegevenstype heeft verschillende voordelen in vergelijking met het opslaan ervan in het gegevenstype TEXT. JSON-gegevenstype kan alleen geldige JSON-geformatteerde tekenreeksen accepteren. Als de tekenreeks niet de juiste JSON-indeling heeft, wordt een fout gegenereerd. JSON-gegevenstype helpt de applicatie om efficiënte en op index gebaseerde zoekopdrachten uit te voeren, wat we binnenkort in detail zullen zien.

Het JSON-gegevenstype is geïntroduceerd in PostgreSQL-9.2, waarin aanzienlijke verbeteringen zijn aangebracht. De belangrijkste toevoeging kwam naar voren in PostgreSQL-9.4 met de toevoeging van JSONB-gegevenstype. JSONB is een geavanceerde versie van het JSON-gegevenstype waarin de JSON-gegevens in binair formaat worden opgeslagen. Dit is de belangrijkste verbetering die een groot verschil maakte voor de manier waarop JSON-gegevens werden doorzocht en verwerkt in PostgreSQL. Laten we de voordelen van JSON-gegevenstypen eens nader bekijken.

JSON- en JSONB-gegevenstypen

JSON-gegevenstype slaat json-geformatteerde tekenreeksen op als een tekst die niet erg krachtig is en niet veel JSON-gerelateerde functies ondersteunt die voor zoekopdrachten worden gebruikt. Het ondersteunt alleen traditionele B-TREE-indexering en ondersteunt geen andere indextypen die noodzakelijk zijn voor snellere en efficiënte zoekbewerkingen in JSON-gegevens.

JSONB, de geavanceerde versie van het JSON-gegevenstype, wordt ten zeerste aanbevolen voor het opslaan en verwerken van JSON-documenten. Het ondersteunt een breed scala aan json-operators en heeft tal van voordelen ten opzichte van JSON, zoals het opslaan van JSON-geformatteerde strings in binair formaat, en het ondersteunen van JSON-functies en indexering, om efficiënte zoekopdrachten uit te voeren.

Laten we eens kijken naar de verschillen.

	JSON	JSONB
1	Net zoals een TEXT-gegevenstype dat alleen een geldig JSON-document opslaat.	Slaat de JSON-documenten op in binair formaat.
2	Slaat de JSON-documenten op zoals ze zijn, inclusief spaties.	Verwijdert witte ruimtes en slaat op in een formaat dat bevorderlijk is voor snellere en efficiënte zoekopdrachten
3	Ondersteunt geen FULL-TEXT-SEARCH Indexing	Ondersteunt FULL-TEXT-SEARCH Indexing
4	Ondersteunt geen breed scala aan JSON-functies en operators	Ondersteunt alle JSON-functies en operators

Voorbeeld voor #4 hierboven vermeld

JSON

Hieronder staat een tabel met JSON-gegevenstype

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)

Ondersteunt geen traditionele JSON-operators (zoals "@>" of "#>"). Zoeken in volledige tekst door JSON-gegevens wordt gedaan met "@>" of "#>" in een SQL die niet wordt ondersteund door JSON-gegevenstype

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

Hieronder staat een tabel met JSONB-gegevenstype

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)

Ondersteunt VOLLEDIGE TEKST ZOEKEN via JSON-gegevens met behulp van operators (zoals "@>")

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)

Download de whitepaper vandaag PostgreSQL-beheer en -automatisering met ClusterControlLees wat u moet weten om PostgreSQL te implementeren, bewaken, beheren en schalenDownload de whitepaper

JSON-gegevens opvragen

Laten we eens kijken naar enkele PostgreSQL JSON-mogelijkheden met betrekking tot gegevensbewerkingen Hieronder ziet u hoe de JSON-gegevens eruitzien in een tabel. Kolom "order_details" is van het type 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)

Selecteer alle artikelcodes inclusief hun verzenddatums

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)

Ontvang de item_code, hoeveelheid en prijs van alle bestellingen die per vliegtuig zijn aangekomen

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)

De JSON-operators "->" en "->>" worden gebruikt voor selecties en vergelijkingen in de SQL-query. De operator "->" retourneert het JSON-objectveld als een veld tussen aanhalingstekens en de operator "->>" retourneert het JSON-objectveld als TEKST. De bovenstaande twee SQL's zijn voorbeelden van het weergeven van JSON-veldwaarden zoals ze zijn. Hieronder ziet u een voorbeeld van het ophalen van het JSON-veld in het TEKST-formulier.
Hieronder ziet u een voorbeeld van het ophalen van het JSON-veld in de vorm van TEXT

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)

Er is een andere operator genaamd "#>" die wordt gebruikt om het gegevensgedeelte van een JSON-element op te vragen dat op zijn beurt weer onderdeel is van een JSON-tekenreeks. Laten we een voorbeeld bekijken.
Hieronder staan de gegevens in de tabel.

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"}}

Ik wil alle details zien met "State" "NSW" en "State" is de JSON-objectsleutel die deel uitmaakt van de sleutel "Locatie". Hieronder leest u hoe u hetzelfde kunt opvragen.

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)

Rekenkundige bewerkingen kunnen worden uitgevoerd op JSON-gegevens. Typecasting is nodig omdat het gegevensgedeelte van de JSON-kolom TEXT is.

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)

Afgezien van al het bovenstaande, kunnen de volgende bewerkingen ook worden uitgevoerd op JSON met behulp van SQL's, waaronder JOIN's

De gegevens sorteren met behulp van de ORDER BY-clausule
Aggregatie met behulp van aggregatiefuncties zoals SUM, AVG, MIN, MAX enz.
Groepeer de gegevens met behulp van de GROUP BY-clausule

Hoe zit het met de prestaties?

De gegevens in JSON-kolommen zullen van tekst zijn en op basis van de gegevensgrootte kunnen prestatieproblemen worden verwacht. Zoekopdrachten door JSON-gegevens kunnen tijd en rekenkracht vergen, wat resulteert in trage reacties op de applicatie(s). Het is absoluut noodzakelijk voor DBA's om ervoor te zorgen dat SQL's die de JSON-kolommen raken, snel genoeg reageren en goede prestaties leveren. Aangezien de gegevensextractie via SQL wordt gedaan, is de optie waarnaar de DBA's zoeken de mogelijkheid van indexering en ja, JSON-gegevenstypen ondersteunen indexeringsopties.

Laten we eens kijken naar de indexeringsopties die JSON ons biedt.

JSONB indexeren

JSONB-gegevenstype ondersteunt FULL-TEXT-SEARCH Indexing. Dit is de belangrijkste mogelijkheid van JSONB waar DBA's naar uitkijken bij het gebruik van JSONB-gegevenstypen. Een normale index op een JSON-objectsleutel helpt mogelijk niet bij het gebruik van JSON-specifieke operators in de zoekopdrachten. Hieronder staat een TEXT SEARCH-query die geldt voor een 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)
(2 rows)

JSONB ondersteunt FULL-TEXT-SEARCH Index-type genaamd GIN, dat helpt bij zoekopdrachten zoals hierboven.
Laat me nu een GIN-index maken en kijken of dat helpt

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

Als je hieronder kunt zien, haalt de zoekopdracht de GIN-index op

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)

En een B-TREE-index in plaats van GIN zou NIET helpen

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

U kunt hieronder zien, de zoekopdracht geeft de voorkeur aan 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)

Wat is de GIN-index?

GIN staat voor Generalized Inverted Index. De kerncapaciteit van GIN Index is het versnellen van zoekopdrachten in volledige tekst. Bij het zoeken op basis van specifieke sleutels of elementen in een TEKST of een document, is GIN Index de juiste keuze. GIN Index slaat "Sleutel" (of een element of een waarde) en de "positielijst" paren op. De positielijst is de rowID van de sleutel. Dit betekent dat als de "sleutel" op meerdere plaatsen in het document voorkomt, GIN Index de sleutel slechts één keer opslaat, samen met de positie van de gebeurtenissen, wat niet alleen de GIN-index compact houdt en ook helpt bij het versnellen van de zoekopdrachten op een geweldige manier. manier. Dit is de verbetering in Postgres-9.4.

Uitdagingen met GIN Index

Afhankelijk van de complexiteit van de gegevens kan het onderhouden van GIN-indexen duur zijn. Het maken van GIN-indexen kost tijd en middelen, aangezien de index het hele document moet doorzoeken om de sleutels en hun rij-ID's te vinden. Het kan nog uitdagender zijn als de GIN-index opgeblazen is. Ook kan de grootte van de GIN-index erg groot zijn op basis van de gegevensomvang en complexiteit.

JSON indexeren

JSON ondersteunt geen tekst zoeken en indexen zoals 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

Normale indexering zoals B-TREE wordt ondersteund door zowel JSON als JSONB

Ja, normale indexen zoals B-TREE Index worden ondersteund door zowel JSON- als JSONB-gegevenstypen en zijn niet bevorderlijk voor tekstzoekbewerkingen. Elke JSON-objectsleutel kan afzonderlijk worden geïndexeerd, wat ALLEEN zou helpen als dezelfde objectsleutel wordt gebruikt in de WHERE-component.
Laat me een B-TREE-index maken op JSONB en kijken hoe het werkt

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

We hebben hierboven al geleerd dat een B-TREE-index NIET nuttig is voor het versnellen van SQL's die FULL-TEXT-SEARCHING doen op de JSON-gegevens met behulp van operators (zoals "@>") , en dergelijke indexen zouden ALLEEN helpen om de query's zoals de onderstaande, dit zijn typische RDBMS-type SQL's (die geen zoekopdrachten zijn). Elk van de JSON-objectsleutels kan afzonderlijk worden geïndexeerd, wat zou helpen bij het versnellen van zoekopdrachten wanneer die geïndexeerde JSON-objectsleutels worden gebruikt in de WHERE-component.
Het onderstaande voorbeeld gebruikt de objectsleutel "l_shipmode" in de WHERE-component en sindsdien het is geïndexeerd, de query gaat voor een indexscan. Als u met een andere objectsleutel wilt zoeken, kiest de query ervoor om een VOLLEDIGE TABEL-SCAN uit te voeren.

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)

Hetzelfde werkt ook met het JSON-gegevenstype

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

Als u kunt zien, gebruikt de zoekopdracht de Index

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)

Conclusie

Hier zijn enkele dingen om te onthouden bij het gebruik van PostgreSQL JSON-gegevens...

PostgreSQL is een van de beste opties om JSON-gegevens op te slaan en te verwerken
Met alle krachtige functies kan PostgreSQL uw documentdatabase zijn
Ik heb architecturen gezien waar twee of meer datastores worden gekozen, met een mix van PostgreSQL- en NoSQL-databases zoals MongoDB of Couchbase-database. Een REST API zou applicaties helpen om de gegevens naar verschillende datastores te pushen. Met PostgreSQL-ondersteuning voor JSON kan deze complexiteit in de architectuur worden vermeden door slechts één gegevensopslag te kiezen.
JSON-gegevens in PostgreSQL kunnen worden opgevraagd en geïndexeerd, wat ongelooflijke prestaties en schaalbaarheid oplevert
JSONB-gegevenstype heeft de meeste voorkeur, omdat het goed is voor opslag en prestaties. Ondersteunt volledig VOLLEDIGE TEKST ZOEKEN en indexeren. Geeft goede prestaties
Gebruik het JSON-gegevenstype alleen als u JSON-tekenreeksen als JSON wilt opslaan en u niet veel complexe tekstzoekopdrachten uitvoert
Het grootste voordeel van JSON in PostgreSQL is dat de zoekopdracht kan worden uitgevoerd met behulp van SQL's
De JSON-zoekprestaties in PostgreSQL zijn vergelijkbaar met de beste NoSQL-databases zoals MongoDB