PostgreSQL
 sql >> Baza danych >  >> RDS >> PostgreSQL

Przegląd możliwości JSON w PostgreSQL

Co to jest JSON?

JSON to skrót od „JavaScript Object Notation”, który jest rodzajem formatu danych powszechnie używanym przez aplikacje internetowe. Oznacza to, że dane byłyby przesyłane między aplikacjami internetowymi a serwerami w takim formacie. JSON został wprowadzony jako alternatywa dla formatu XML. W „starych dobrych czasach” dane używane do przesyłania w formacie XML, który jest typem danych o dużej wadze w porównaniu do JSON. Poniżej znajduje się przykład ciągu w formacie JSON:

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

Ciąg JSON może zawierać w sobie inny obiekt JSON, jak pokazano poniżej:

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

Współczesne aplikacje internetowe i mobilne w większości generują dane w formacie JSON, określanym również jako „bajty JSON”, które są zbierane przez serwery aplikacji i przesyłane do bazy danych. Bajty JSON są kolejno przetwarzane, dzielone na oddzielne wartości kolumn i wstawiane do tabeli RDBMS.
Przykład:

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

Powyższe dane JSON są konwertowane na SQL, jak poniżej.

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

Jeśli chodzi o przechowywanie i przetwarzanie danych JSON, wspierają go różne bazy danych NoSQL, a najpopularniejszą z nich jest MongoDB. Jeśli chodzi o bazy danych RDBMS, do niedawna ciągi JSON były traktowane jako normalny tekst i nie było typów danych, które konkretnie rozpoznają, przechowują lub przetwarzają ciągi formatu JSON. PostgreSQL, najpopularniejsza baza danych RDBMS typu open source, opracowała typ danych JSON, który okazał się bardzo korzystny pod względem wydajności, funkcjonalności i skalowalności, jeśli chodzi o obsługę danych JSON.

PostgreSQL + JSON

Baza danych PostgreSQL stała się coraz bardziej popularna od czasu wprowadzenia typu danych JSON. W rzeczywistości PostgreSQL przewyższa MongoDB, jeśli chodzi o przetwarzanie dużej ilości danych JSON. Aplikacje mogą przechowywać łańcuchy JSON w bazie danych PostgreSQL w standardowym formacie JSON. Deweloperzy muszą tylko powiedzieć aplikacji, aby wysyłała ciągi JSON do bazy danych jako typ danych json i pobierała je z powrotem w formacie JSON. Przechowywanie ciągu JSON w typie danych JSON ma kilka zalet w porównaniu do przechowywania tego samego w typie danych TEXT. Typ danych JSON może akceptować tylko prawidłowe ciągi w formacie JSON, jeśli ciąg nie ma prawidłowego formatu JSON, generowany jest błąd. Typ danych JSON pomaga aplikacji przeprowadzać wydajne i oparte na indeksie wyszukiwania, które wkrótce zobaczymy szczegółowo.

Typ danych JSON został wprowadzony w poście PostgreSQL-9.2, w którym dokonano znaczących ulepszeń. Główny dodatek pojawił się w PostgreSQL-9.4 z dodaniem typu danych JSONB. JSONB to zaawansowana wersja typu danych JSON, która przechowuje dane JSON w formacie binarnym. Jest to główne ulepszenie, które znacznie zmieniło sposób wyszukiwania i przetwarzania danych JSON w PostgreSQL. Przyjrzyjmy się szczegółowo zaletom typów danych JSON.

Typy danych JSON i JSONB

Typ danych JSON przechowuje ciągi sformatowane w formacie json jako tekst, który nie jest zbyt wydajny i nie obsługuje wielu funkcji związanych z JSON używanych do wyszukiwania. Obsługuje tylko tradycyjne indeksowanie B-TREE i nie obsługuje innych typów indeksów, które są niezbędne do szybszych i wydajnych operacji wyszukiwania w danych JSON.

JSONB, zaawansowana wersja typu danych JSON, jest wysoce zalecana do przechowywania i przetwarzania dokumentów JSON. Obsługuje szeroką gamę operatorów json i ma wiele zalet w porównaniu z JSON, takich jak przechowywanie ciągów w formacie JSON w formacie binarnym oraz obsługa funkcji i indeksowania JSON w celu wykonywania wydajnych wyszukiwań.

Przyjrzyjmy się różnicom.

  JSON JSONB
1 Prawie jak typ danych TEKST, który przechowuje tylko ważny dokument JSON. Przechowuje dokumenty JSON w formacie binarnym.
2 Przechowuje dokumenty JSON bez zmian, w tym spacje. Przycina białe przestrzenie i przechowuje w formacie sprzyjającym szybszym i wydajnym wyszukiwaniom
3 Nie obsługuje indeksowania WYSZUKIWANIA PEŁNEGO TEKSTU Obsługuje indeksowanie WYSZUKIWANIA PEŁNEGO TEKSTU
4 Nie obsługuje szerokiego zakresu funkcji i operatorów JSON Obsługuje wszystkie funkcje i operatory JSON

Przykład dla #4 wymienionego powyżej

JSON

Poniżej znajduje się tabela z typem danych 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)

Nie obsługuje tradycyjnych operatorów JSON (takich jak „@>” lub „#>”). Wyszukiwanie pełnotekstowe w danych JSON odbywa się za pomocą „@>” lub „#>” w SQL, który nie jest obsługiwany przez typ danych 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

Poniżej znajduje się tabela z typem danych 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)

Obsługuje WYSZUKIWANIE PEŁNEGO TEKSTU za pomocą danych JSON przy użyciu operatorów (takich jak „@>”)

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)
Pobierz oficjalny dokument już dziś Zarządzanie i automatyzacja PostgreSQL za pomocą ClusterControlDowiedz się, co musisz wiedzieć, aby wdrażać, monitorować, zarządzać i skalować PostgreSQLPobierz oficjalny dokument

Jak wysyłać zapytania do danych JSON

Rzućmy okiem na niektóre możliwości PostgreSQL JSON związane z operacjami na danych. Poniżej przedstawiamy, jak dane JSON wyglądają w tabeli. Kolumna „order_details” jest typu 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)

Wybierz wszystkie kody produktów, w tym daty ich wysyłki

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)

Uzyskaj kod_produktu, ilość i cenę wszystkich zamówień dostarczonych drogą lotniczą

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)

Operatory JSON „->” i „->>” są używane do selekcji i porównań w zapytaniu SQL. Operator „->” zwraca pole obiektu JSON jako pole w cudzysłowie, a operator „->>” zwraca pole obiektu JSON jako TEKST. Powyższe dwa kody SQL są przykładami wyświetlania wartości pól JSON bez zmian. Poniżej przykład pobrania pola JSON w postaci TEKST.
Poniżej przykład pobrania pola JSON w postaci TEKST

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)

Istnieje inny operator o nazwie „#>”, który służy do zapytania o część danych elementu JSON, która z kolei jest częścią ciągu JSON. Spójrzmy na przykład.
Poniżej znajdują się dane w tabeli.

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

Chcę zobaczyć wszystkie szczegóły z „State” „NSW” i „State” to klucz obiektu JSON, który jest częścią klucza „Location”. Poniżej znajduje się sposób zapytania o to samo.

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)

Na danych JSON można wykonywać operacje arytmetyczne. Rzutowanie typów jest potrzebne, ponieważ częścią danych kolumny JSON jest TEKST.

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)

Oprócz wszystkich powyższych, następujące operacje można również wykonać na JSON za pomocą SQLs, w tym JOIN

  1. Sortowanie danych za pomocą klauzuli ORDER BY
  2. Agregacja przy użyciu funkcji agregujących, takich jak SUM, AVG, MIN, MAX itp.
  3. Pogrupuj dane za pomocą klauzuli GROUP BY

A co z wydajnością?

Dane w kolumnach JSON będą miały charakter tekstowy i na podstawie rozmiaru danych można się spodziewać problemów z wydajnością. Wyszukiwanie danych JSON może zająć dużo czasu i mocy obliczeniowej, powodując powolne odpowiedzi aplikacji. Administratorzy baz danych muszą upewnić się, że kody SQL trafiające do kolumn JSON odpowiadają wystarczająco szybko i zapewniają dobrą wydajność. Ponieważ wyodrębnianie danych odbywa się za pomocą SQL, opcją, której szukaliby administratorzy baz danych, jest możliwość indeksowania i tak, typy danych JSON obsługują opcje indeksowania.

Przyjrzyjmy się opcjom indeksowania, które oferuje JSON.

Indeksowanie JSONB

Typ danych JSONB obsługuje indeksowanie FULL-TEXT-SEARCH. Jest to najważniejsza funkcja JSONB, na którą administratorzy baz danych będą oczekiwać podczas korzystania z typów danych JSONB. Normalny indeks w kluczu obiektu JSON może nie pomóc w przypadku używania operatorów specyficznych dla JSON w zapytaniach wyszukiwania. Poniżej znajduje się zapytanie TEXT SEARCH, które prowadzi do 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 obsługuje indeks FULL-TEXT-SEARCH o nazwie GIN, który pomaga w zapytaniach takich jak powyżej.
Teraz pozwól mi utworzyć indeks GIN i zobaczę, czy to pomoże

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

Jeśli możesz zaobserwować poniżej, zapytanie pobiera indeks 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)

A indeks B-TREE zamiast GIN NIE pomoże

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

Jak widać poniżej, zapytanie preferuje SKANOWANIE PEŁNEJ TABELI

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)

Co to jest indeks WZ?

GIN to skrót od Generalized Inverted Index. Główną funkcją Indeksu GIN jest przyspieszenie wyszukiwania pełnotekstowego. Podczas wyszukiwania w oparciu o określone klucze lub elementy w TEKŚCIE lub dokumencie, indeks WZ jest drogą do zrobienia. Indeks GIN przechowuje pary „Klucz” (lub element lub wartość) oraz „Lista pozycji”. Lista pozycji to rowID klucza. Oznacza to, że jeśli „Klucz” występuje w wielu miejscach w dokumencie, indeks GIN przechowuje klucz tylko raz wraz z jego pozycją wystąpień, co nie tylko utrzymuje kompaktowy rozmiar indeksu WZ, ale także pomaga przyspieszyć wyszukiwanie w wielkim sposób. To jest ulepszenie w Postgres-9.4.

Wyzwania związane z indeksem WZ

W zależności od złożoności danych utrzymanie indeksów WZ może być kosztowne. Tworzenie indeksów WZ pochłania czas i zasoby, ponieważ indeks musi przeszukiwać cały dokument, aby znaleźć klucze i ich identyfikatory wierszy. Może być jeszcze trudniejsze, jeśli indeks GIN jest rozdęty. Ponadto rozmiar indeksu GIN może być bardzo duży w zależności od rozmiaru i złożoności danych.

Indeksowanie JSON

JSON nie obsługuje wyszukiwania tekstu i indeksów, takich jak 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

Normalne indeksowanie, takie jak B-TREE, jest obsługiwane zarówno przez JSON, jak i JSONB

Tak, normalne indeksy, takie jak B-TREE Index, są obsługiwane przez typy danych JSON i JSONB i nie sprzyjają operacjom wyszukiwania tekstowego. Każdy klucz obiektu JSON może być indeksowany indywidualnie, co naprawdę pomogłoby TYLKO wtedy, gdy ten sam klucz obiektu jest używany w klauzuli WHERE.
Pozwólcie, że utworzę indeks B-TREE w JSONB i zobaczę, jak to dział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))

Dowiedzieliśmy się już powyżej, że indeks B-DRZEWA NIE jest przydatny do przyspieszania zapytań SQL wykonujących WYSZUKIWANIE PEŁNEGO TEKSTU na danych JSON za pomocą operatorów (takich jak „@>”), a takie indeksy pomogłyby TYLKO przyspieszyć zapytania takie jak te poniżej, które są typowymi SQL typu RDBMS (które nie są zapytaniami wyszukiwania). Każdy klucz JSON Object może być indeksowany indywidualnie, co pomogłoby przyspieszyć zapytania, gdy te indeksowane klucze obiektów JSON są używane w klauzuli WHERE.
W poniższym przykładzie zapytanie używa klucza obiektu „l_shipmode” w klauzuli WHERE i ponieważ jest indeksowane zapytanie jest skanowane indeksem. Jeśli chcesz wyszukiwać przy użyciu innego klucza obiektu, zapytanie wybierze wykonanie PEŁNEGO SKANOWANIA TABELI.

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)

To samo działa również z typem danych JSON

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

Jeśli widzisz, zapytanie korzysta z indeksu

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)

Wniosek

Oto kilka rzeczy, o których należy pamiętać podczas korzystania z danych PostgreSQL JSON...

  • PostgreSQL to jedna z najlepszych opcji przechowywania i przetwarzania danych JSON
  • Dzięki wszystkim potężnym funkcjom PostgreSQL może być Twoją bazą danych dokumentów
  • Widziałem architektury, w których wybrano dwa lub więcej magazynów danych, z mieszanką baz danych PostgreSQL i NoSQL, takich jak baza danych MongoDB lub Couchbase. Interfejs API REST pomógłby aplikacjom w przesyłaniu danych do różnych magazynów danych. Z PostgreSQL obsługującym JSON można uniknąć tej złożoności w architekturze, wybierając tylko jeden magazyn danych.
  • Dane JSON w PostgreSQL można odpytywać i indeksować, co zapewnia niesamowitą wydajność i skalowalność
  • Typ danych JSONB jest najbardziej preferowaną opcją, ponieważ jest dobry pod względem przechowywania i wydajności. W pełni obsługuje WYSZUKIWANIE PEŁNEGO TEKSTU i indeksowanie. Zapewnia dobrą wydajność
  • Używaj typu danych JSON tylko wtedy, gdy chcesz przechowywać ciągi JSON jako JSON i nie wykonujesz zbyt skomplikowanych wyszukiwań tekstowych
  • Największą zaletą posiadania JSON w PostgreSQL jest to, że wyszukiwanie można przeprowadzić za pomocą SQL
  • Wydajność wyszukiwania JSON w PostgreSQL była na równi z najlepszymi bazami danych NoSQL, takimi jak MongoDB

  1. Database
    2.   
  2. Mysql
    3.   
  3. Oracle
    4.   
  4. Sqlserver
    5.   
  5. PostgreSQL
    6.   
  6. Access
    7.   
  7. SQLite
    8.   
  8. MariaDB

  1. Wyjaśnienie JSONB wprowadzone przez PostgreSQL

  2. Zresetuj wartość sekwencji jako 1

  3. Jak zaktualizować wiele kolumn w PostgreSQL

  4. Połącz się ze zdalną bazą danych PostgreSql za pomocą Powershell

  5. Prawidłowe wstawienie nazwy tabeli