En oversigt over JSON-kapaciteter i PostgreSQL

Hvad er JSON?

JSON står for "JavaScript Object Notation", som er en type dataformat, der populært bruges af webapplikationer. Det betyder, at dataene vil blive transmitteret mellem webapplikationer og servere i et sådant format. JSON blev introduceret som et alternativ til XML-formatet. I de "gode gamle dage" blev dataene brugt til at blive transmitteret i XML-format, som er en tung datatype sammenlignet med JSON. Nedenfor er et eksempel på JSON-formateret streng:

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

En JSON-streng kan indeholde et andet JSON-objekt i sig selv som vist nedenfor:

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

Moderne web- og mobilapplikationer genererer for det meste dataene i JSON-format, også kaldet "JSON Bytes", som opfanges af applikationsserverne og sendes over til databasen. JSON-bytes behandles efter tur, opdeles i separate kolonneværdier og indsættes i en RDBMS-tabel.
Eksempel:

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

Ovenstående JSON-data konverteres til en SQL som nedenfor..

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

Når det kommer til lagring og behandling af JSON-data, er der forskellige NoSQL-databaser, der understøtter det, og den mest populære er MongoDB. Når det kommer til RDBMS-databaser, blev JSON-strenge indtil for nylig behandlet som normal tekst, og der var ingen datatyper, som specifikt genkender, gemmer eller behandler JSON-formatstrenge. PostgreSQL, den mest populære open source RDBMS-database, er kommet med JSON-datatypen, som viste sig at være yderst gavnlig for ydeevne, funktionalitet og skalerbarhed, når det kommer til håndtering af JSON-data.

PostgreSQL + JSON

PostgreSQL-databasen er blevet mere og mere populær lige siden JSON-datatypen blev introduceret. Faktisk har PostgreSQL overgået MongoDB, når det kommer til at behandle en stor mængde JSON-data. Applikationerne kan gemme JSON-strenge i PostgreSQL-databasen i standard JSON-format. Udviklere skal bare fortælle applikationen at sende på tværs af JSON-strengene til databasen som en json-datatype og hente tilbage i JSON-formatet. Lagring af JSON-streng i JSON-data-type har flere fordele sammenlignet med lagring af samme i TEXT-data-type. JSON-datatypen kan kun acceptere gyldige JSON-formaterede strenge, hvis strengen ikke er i korrekt JSON-format, genereres en fejl. JSON data-type hjælper applikationen med at udføre effektive og indeksbaserede søgninger, som vi snart vil se i detaljer.

JSON-datatypen blev introduceret i PostgreSQL-9.2 post, hvor der blev foretaget betydelige forbedringer. Den største tilføjelse kom op i PostgreSQL-9.4 med tilføjelsen af ​​JSONB data-type. JSONB er en avanceret version af JSON-datatypen, som gemmer JSON-dataene i binært format. Dette er den store forbedring, som gjorde en stor forskel for den måde, JSON-data blev søgt og behandlet i PostgreSQL. Lad os se nærmere på fordelene ved JSON-datatyper.

JSON- og JSONB-datatyper

JSON data-type gemmer json-formaterede strenge som en tekst, der ikke er særlig kraftfuld og ikke understøtter mange JSON-relaterede funktioner, der bruges til søgninger. Den understøtter kun traditionel B-TREE-indeksering og understøtter ikke andre indekstyper, som er bydende nødvendige for hurtigere og effektive søgeoperationer på tværs af JSON-data.

JSONB, den avancerede version af JSON-datatypen, anbefales stærkt til lagring og behandling af JSON-dokumenter. Det understøtter en bred vifte af json-operatører og har adskillige fordele i forhold til JSON, såsom lagring af JSON-formaterede strenge i binært format og understøttelse af JSON-funktioner og indeksering for at udføre effektive søgninger.

Lad os se på forskellene.

Eksempel på #4 ovenfor

JSON

Nedenfor er en tabel med JSON-datatypen

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)

Understøtter ikke traditionelle JSON-operatører (som "@>" eller "#>"). Fuld tekstsøgning gennem JSON-data udføres ved hjælp af "@>" eller "#>" i en SQL, som ikke understøttes af JSON-datatypen

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

Nedenfor er en tabel med JSONB-datatypen

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)

Understøtter FULDTEKST-SØGNING gennem JSON-data ved hjælp af operatorer (som "@>")

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)

Sådan forespørges JSON-data

Lad os tage et kig på nogle PostgreSQL JSON-funktioner relateret til dataoperationer. Nedenfor kan du se, hvordan JSON-dataene ser ud i en tabel. Kolonnen "ordre_details" er af typen 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)

Vælg alle varekoderne inklusive deres forsendelsesdatoer

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)

Få item_code, mængde og pris på alle de ordrer, der er ankommet med fly

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)

JSON-operatorerne "->" og "->>" bruges til valg og sammenligninger i SQL-forespørgslen. Operatoren "->" returnerer JSON-objektfeltet som et felt i anførselstegn, og operatoren "->>" returnerer JSON-objektfeltet som TEXT. Ovenstående to SQL'er er eksempler på visning af JSON-feltværdier, som de er. Nedenfor er et eksempel på udtrækning af JSON-feltet i TEXT-formen.
Nedenfor er et eksempel på at hente JSON-feltet i form af 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)

Der er en anden operatør kaldet "#>", som bruges til at forespørge datadelen af ​​et JSON-element, som er en del af en JSON-streng. Lad os se på et eksempel.
Nedenfor er dataene i tabellen.

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

Jeg vil gerne se alle detaljerne med "State" "NSW" og "State" er JSON-objektnøglen, som er en del af nøglen "Location". Nedenfor er, hvordan du forespørger det samme.

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)

Aritmetiske operationer kan udføres på JSON-data. Typecasting er nødvendig, da datadelen af ​​JSON-kolonnen er TEXT.

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)

Ud over alt det ovenstående kan følgende operationer også udføres på JSON ved hjælp af SQL'er inklusive JOIN'er

1. Sortering af data ved hjælp af ORDER BY-klausul
2. Aggregation ved hjælp af aggregerede funktioner som SUM, AVG, MIN, MAX osv.
3. Gruppér dataene ved hjælp af GROUP BY-sætning

Hvad med ydeevne?

Dataene i JSON-kolonner vil være af tekst, og baseret på datastørrelsen kan der forventes ydeevneproblemer. Søgninger gennem JSON-data kan tage tid og regnekraft, hvilket resulterer i langsomme svar på applikationen/applikationerne. Det er bydende nødvendigt for DBA'er at sikre, at SQL'er, der rammer JSON-kolonnerne, reagerer hurtigt nok og giver god ydeevne. Da dataudtrækningen udføres via SQL, er den mulighed, som DBA'erne kigger efter, muligheden for indeksering, og ja, JSON-datatyper understøtter indekseringsmuligheder.

Lad os tage et kig på indekseringsmulighederne, som JSON giver os.

Indeksering af JSONB

JSONB-datatypen understøtter indeksering af FULD-TEKST-SØGNING. Dette er den vigtigste egenskab i JSONB, som DBA'er vil se frem til, når de bruger JSONB-datatyper. Et normalt indeks på en JSON-objektnøgle hjælper muligvis ikke, når du bruger JSON-specifikke operatorer i søgeforespørgslerne. Nedenfor er en TEKST-SØGNING-forespørgsel, der går til en FULD-TABEL-SCANNING

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 understøtter FULL-TEXT-SEARCH Indekstype kaldet GIN, som hjælper forespørgsler som ovenfor.
Lad mig nu oprette et GIN-indeks og se, om det hjælper

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

Hvis du kan se nedenfor, henter forespørgslen GIN-indekset

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)

Og et B-TREE indeks i stedet for GIN ville IKKE hjælpe

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

Du kan se nedenfor, forespørgslen foretrækker FULD-TABEL-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)

Hvad er GIN-indeks?

GIN står for Generalized Inverted Index. Kerneevnen i GIN Index er at fremskynde fuldtekstsøgninger. Når du udfører søgning baseret på specifikke nøgler eller elementer i en TEKST eller et dokument, er GIN Index vejen at gå. GIN Index gemmer "Nøgle" (eller et element eller en værdi) og "positionsliste"-parrene. Positionslisten er nøglens række-ID. Dette betyder, at hvis "Nøglen" forekommer flere steder i dokumentet, gemmer GIN-indekset kun nøglen én gang sammen med dens placering af forekomster, hvilket ikke kun holder GIN-indekset kompakt i størrelse og også hjælper med at fremskynde søgningerne på en fantastisk måde. vej. Dette er forbedringen i Postgres-9.4.

Udfordringer med GIN-indeks

Afhængigt af kompleksiteten af ​​dataene kan det være dyrt at vedligeholde GIN-indekser. Oprettelse af GIN-indekser kræver tid og ressourcer, da indekset skal søge gennem hele dokumentet for at finde nøglerne og deres række-id'er. Det kan være endnu mere udfordrende, hvis GIN-indekset er oppustet. Størrelsen af ​​GIN-indekset kan også være meget stor baseret på datastørrelsen og kompleksiteten.

Indeksering af JSON

JSON understøtter ikke tekstsøgning og indekser som 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

Normal indeksering som B-TREE understøttes af både JSON og JSONB

Ja, normale indekser som B-TREE Index understøttes af både JSON- og JSONB-datatyper og er ikke befordrende for tekstsøgningsoperationer. Hver JSON-objektnøgle kan indekseres individuelt, hvilket virkelig KUN vil hjælpe, når den samme objektnøgle bruges i WHERE-sætningen.
Lad mig oprette et B-TREE-indeks på JSONB og se, hvordan det virker

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

Vi har allerede lært ovenfor, at et B-TREE-indeks IKKE er nyttigt til at fremskynde SQL'er, der udfører FULD-TEKST-SØGNING på JSON-dataene ved hjælp af operatorer (som "@>") , og sådanne indekser vil KUN hjælpe med at fremskynde forespørgsler som f.eks. den nedenfor, som er typiske RDBMS-type SQL'er (som ikke er søgeforespørgsler). Hver af JSON-objektnøglerne kan indekseres individuelt, hvilket ville hjælpe forespørgsler med at fremskynde, når disse indekserede JSON-objektnøgler bruges WHERE-sætningen.
Eksemplet nedenfor forespørgsel bruger "l_shipmode" Object Key i WHERE-sætningen og siden det er indekseret, forespørgslen skal til en indeksscanning. Hvis du ønsker at søge ved hjælp af en anden objektnøgle, vil forespørgslen vælge at udføre en FULD TABLE-SCANNING.

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)

Det samme fungerer også med JSON-datatypen

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

Hvis du kan observere, bruger forespørgslen indekset

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)

Konklusion

Her er nogle ting, du skal huske, når du bruger PostgreSQL JSON-data...

• PostgreSQL er en af ​​de bedste muligheder for at gemme og behandle JSON-data
• Med alle de kraftfulde funktioner kan PostgreSQL være din dokumentdatabase
• Jeg har set arkitekturer, hvor to eller flere datalagre er valgt, med en blanding af PostgreSQL og NoSQL databaser som MongoDB eller Couchbase database. En REST API ville hjælpe applikationer med at skubbe dataene til forskellige datalagre. Med PostgreSQL, der understøtter JSON, kan denne kompleksitet i arkitektur undgås ved blot at vælge ét datalager.
• JSON-data i PostgreSQL kan forespørges og indekseres, hvilket giver en utrolig ydeevne og skalerbarhed
• JSONB Datatype er den mest foretrukne mulighed, da den er god til lagring og ydeevne. Understøtter fuldt ud FULLTEKST-SØGNING og indeksering. Giver god ydeevne
• Brug kun JSON-datatypen, hvis du vil gemme JSON-strenge som JSON, og du ikke udfører meget komplekse tekstsøgninger
• Den største fordel ved at have JSON i PostgreSQL er, at søgningen kan udføres ved hjælp af SQL'er
• JSON-søgeydelsen i PostgreSQL har været på niveau med de bedste NoSQL-databaser som MongoDB