PostgreSQL
 sql >> Base de données >  >> RDS >> PostgreSQL

Un aperçu des capacités JSON dans PostgreSQL

Qu'est-ce que JSON ?

JSON signifie "JavaScript Object Notation" qui est un type de format de données couramment utilisé par les applications Web. Cela signifie que les données seraient transmises entre les applications Web et les serveurs dans un tel format. JSON a été introduit comme alternative au format XML. Au "bon vieux temps", les données étaient transmises au format XML, qui est un type de données lourd par rapport à JSON. Voici un exemple de chaîne au format JSON :

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

Une chaîne JSON peut contenir un autre objet JSON en lui-même, comme illustré ci-dessous :

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

Les applications Web et mobiles modernes génèrent principalement des données au format JSON, également appelées «octets JSON», qui sont récupérées par les serveurs d'applications et envoyées à la base de données. Les octets JSON sont à leur tour traités, décomposés en valeurs de colonne distinctes et insérés dans une table RDBMS.
Exemple :

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

Les données JSON ci-dessus sont converties en SQL comme ci-dessous.

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

En ce qui concerne le stockage et le traitement des données JSON, diverses bases de données NoSQL le prennent en charge et la plus populaire est MongoDB. En ce qui concerne les bases de données RDBMS, jusqu'à récemment, les chaînes JSON étaient traitées comme du texte normal et aucun type de données ne reconnaissait, stockait ou traitait spécifiquement les chaînes au format JSON. PostgreSQL, la base de données RDBMS open source la plus populaire, a mis au point le type de données JSON qui s'est avéré très bénéfique pour les performances, les fonctionnalités et l'évolutivité lorsqu'il s'agit de gérer les données JSON.

PostgreSQL + JSON

La base de données PostgreSQL est devenue de plus en plus populaire depuis l'introduction du type de données JSON. En fait, PostgreSQL surpasse MongoDB lorsqu'il s'agit de traiter une grande quantité de données JSON. Les applications peuvent stocker des chaînes JSON dans la base de données PostgreSQL au format JSON standard. Les développeurs doivent simplement dire à l'application d'envoyer les chaînes JSON à la base de données en tant que type de données json et de les récupérer au format JSON. Le stockage de la chaîne JSON dans le type de données JSON présente plusieurs avantages par rapport au stockage de la même chose dans le type de données TEXT. Le type de données JSON ne peut accepter que des chaînes au format JSON valides. Si la chaîne n'est pas au format JSON correct, une erreur est générée. Le type de données JSON aide l'application à effectuer des recherches efficaces et basées sur l'index, ce que nous verrons en détail sous peu.

Le type de données JSON a été introduit dans le post PostgreSQL-9.2 qui, des améliorations significatives ont été apportées. L'ajout majeur est venu dans PostgreSQL-9.4 avec l'ajout du type de données JSONB. JSONB est une version avancée du type de données JSON qui stocke les données JSON au format binaire. Il s'agit de l'amélioration majeure qui a fait une grande différence dans la façon dont les données JSON ont été recherchées et traitées dans PostgreSQL. Voyons en détail les avantages des types de données JSON.

Types de données JSON et JSONB

Le type de données JSON stocke les chaînes au format json sous forme de texte qui n'est pas très puissant et ne prend pas en charge de nombreuses fonctions liées à JSON utilisées pour les recherches. Il ne prend en charge que l'indexation B-TREE traditionnelle et ne prend pas en charge les autres types d'index qui sont impératifs pour des opérations de recherche plus rapides et efficaces dans les données JSON.

JSONB, la version avancée du type de données JSON, est fortement recommandé pour le stockage et le traitement des documents JSON. Il prend en charge un large éventail d'opérateurs JSON et présente de nombreux avantages par rapport à JSON, comme le stockage de chaînes au format JSON au format binaire et la prise en charge des fonctions JSON et de l'indexation, pour effectuer des recherches efficaces.

Voyons les différences.

  JSON JSONB
1 Un peu comme un type de données TEXT qui stocke uniquement un document JSON valide. Stocke les documents JSON au format binaire.
2 Stocke les documents JSON tels quels, y compris les espaces blancs. Élimine les espaces blancs et stocke dans un format propice à des recherches plus rapides et efficaces
3 Ne prend pas en charge l'indexation FULL-TEXT-SEARCH Prend en charge l'indexation FULL-TEXT-SEARCH
4 Ne prend pas en charge une large gamme de fonctions et d'opérateurs JSON Prend en charge toutes les fonctions et opérateurs JSON

Exemple pour #4 listé ci-dessus

JSON

Ci-dessous un tableau avec le type de données 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)

Ne prend pas en charge les opérateurs JSON traditionnels (comme "@>" ou "#>"). La recherche en texte intégral dans les données JSON est effectuée à l'aide de "@>" ou "#>" dans un SQL qui n'est pas pris en charge par le type de données 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

Ci-dessous un tableau avec le type de données 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)

Prend en charge la recherche de texte intégral via des données JSON à l'aide d'opérateurs (comme "@>")

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)
Téléchargez le livre blanc aujourd'hui PostgreSQL Management &Automation with ClusterControlDécouvrez ce que vous devez savoir pour déployer, surveiller, gérer et faire évoluer PostgreSQLTélécharger le livre blanc

Comment interroger les données JSON

Jetons un coup d'œil à certaines fonctionnalités PostgreSQL JSON liées aux opérations de données. Voici à quoi ressemblent les données JSON dans une table. La colonne "order_details" est de 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)

Sélectionnez tous les codes d'articles, y compris leurs dates d'expédition

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)

Obtenez l'item_code, la quantité et le prix de toutes les commandes arrivées par avion

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)

Les opérateurs JSON "->" et "->>" sont utilisés pour les sélections et les comparaisons dans la requête SQL. L'opérateur "->" renvoie le champ d'objet JSON sous forme de champ entre guillemets et l'opérateur "->>" renvoie le champ d'objet JSON sous forme de TEXTE. Les deux SQL ci-dessus sont des exemples d'affichage des valeurs de champ JSON telles quelles. Ci-dessous, l'exemple d'extraction du champ JSON sous la forme TEXT.
Ci-dessous, un exemple de récupération du champ JSON sous la forme 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)

Il existe un autre opérateur appelé "#>" qui est utilisé pour interroger la partie données d'un élément JSON qui fait à son tour partie d'une chaîne JSON. Prenons un exemple.
Vous trouverez ci-dessous les données du tableau.

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

Je veux voir tous les détails avec "State" "NSW" et "State" est la clé d'objet JSON qui fait partie de la clé "Location". Vous trouverez ci-dessous comment interroger la même chose.

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)

Des opérations arithmétiques peuvent être effectuées sur des données JSON. La conversion de type est nécessaire car la partie données de la colonne JSON est 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)

Outre tout ce qui précède, les opérations suivantes peuvent également être effectuées sur JSON à l'aide de SQL, y compris les JOIN

  1. Tri des données à l'aide de la clause ORDER BY
  2. Agrégation à l'aide de fonctions d'agrégation telles que SUM, AVG, MIN, MAX, etc.
  3. Regrouper les données à l'aide de la clause GROUP BY

Qu'en est-il des performances ?

Les données dans les colonnes JSON seront de nature textuelle et, en fonction de la taille des données, des problèmes de performances peuvent être attendus. Les recherches dans les données JSON peuvent prendre du temps et de la puissance de calcul, ce qui entraîne des réponses lentes aux applications. Il est impératif que les administrateurs de base de données s'assurent que les requêtes SQL qui accèdent aux colonnes JSON répondent suffisamment rapidement et offrent de bonnes performances. Étant donné que l'extraction des données se fait via SQL, l'option recherchée par les DBA est la possibilité d'indexation et oui, les types de données JSON prennent en charge les options d'indexation.

Jetons un coup d'œil aux options d'indexation que JSON nous apporte.

Indexation JSONB

Le type de données JSONB prend en charge l'indexation FULL-TEXT-SEARCH. Il s'agit de la capacité la plus importante de JSONB que les administrateurs de bases de données attendront avec impatience lorsqu'ils utiliseront les types de données JSONB. Un index normal sur une clé d'objet JSON peut ne pas aider lors de l'utilisation d'opérateurs spécifiques à JSON dans les requêtes de recherche. Ci-dessous, une requête TEXT SEARCH qui va pour un 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 prend en charge le type d'index FULL-TEXT-SEARCH appelé GIN qui aide les requêtes comme ci-dessus.
Maintenant, laissez-moi créer un index GIN et voir si cela aide

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

Si vous pouvez observer ci-dessous, la requête récupère l'index 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)

Et un index B-TREE au lieu de GIN n'aiderait PAS

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

Vous pouvez voir ci-dessous, la requête préfère 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'est-ce que l'indice GIN ?

GIN signifie Index inversé généralisé. La capacité principale de GIN Index est d'accélérer les recherches en texte intégral. Lorsque vous effectuez une recherche basée sur des clés ou des éléments spécifiques dans un TEXTE ou un document, l'index GIN est la solution. L'index GIN stocke la "clé" (ou un élément ou une valeur) et les paires "liste de positions". La liste des positions est le rowID de la clé. Cela signifie que si la "clé" apparaît à plusieurs endroits dans le document, l'index GIN ne stocke la clé qu'une seule fois avec sa position d'occurrences, ce qui non seulement maintient la taille compacte de l'index GIN et aide également à accélérer les recherches dans un grand chemin. Il s'agit de l'amélioration de Postgres-9.4.

Défis avec l'indice GIN

Selon la complexité des données, la maintenance des index GIN peut être coûteuse. La création d'index GIN consomme du temps et des ressources car l'index doit parcourir l'ensemble du document pour trouver les clés et leurs ID de ligne. Cela peut être encore plus difficile si l'indice GIN est gonflé. De plus, la taille de l'index GIN peut être très importante en fonction de la taille et de la complexité des données.

Indexation JSON

JSON ne prend pas en charge la recherche de texte et les index comme 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

L'indexation normale telle que B-TREE est prise en charge à la fois par JSON et JSONB

Oui, les index normaux tels que l'index B-TREE sont pris en charge par les types de données JSON et JSONB et ne sont pas propices aux opérations de recherche de texte. Chaque clé d'objet JSON peut être indexée individuellement, ce qui serait vraiment utile UNIQUEMENT lorsque la même clé d'objet est utilisée dans la clause WHERE.
Laissez-moi créer un index B-TREE sur JSONB et voir comment cela fonctionne

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

Nous avons déjà appris ci-dessus qu'un index B-TREE n'est PAS utile pour accélérer les requêtes SQL effectuant une RECHERCHE DE TEXTE COMPLET sur les données JSON à l'aide d'opérateurs (comme "@>"), et de tels index aideraient UNIQUEMENT à accélérer les requêtes comme celui ci-dessous, qui sont des SQL typiques de type RDBMS (qui ne sont pas des requêtes de recherche). Chacune des clés d'objet JSON peut être indexée individuellement, ce qui accélérerait les requêtes lorsque ces clés d'objet JSON indexées sont utilisées dans la clause WHERE.
L'exemple de requête ci-dessous utilise la clé d'objet "l_shipmode" dans la clause WHERE et depuis il est indexé la requête va pour une analyse d'index. Si vous souhaitez effectuer une recherche à l'aide d'une clé d'objet différente, la requête choisira alors d'effectuer un FULL-TABLE-SCAN.

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)

La même chose fonctionne également avec le type de données 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))

Si vous pouvez observer, la requête utilise l'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)

Conclusion

Voici quelques éléments à retenir lors de l'utilisation des données PostgreSQL JSON...

  • PostgreSQL est l'une des meilleures options pour stocker et traiter les données JSON
  • Avec toutes ses fonctionnalités puissantes, PostgreSQL peut être votre base de données de documents
  • J'ai vu des architectures où deux magasins de données ou plus sont choisis, avec un mélange de bases de données PostgreSQL et NoSQL comme MongoDB ou la base de données Couchbase. Une API REST aiderait les applications à pousser les données vers différents magasins de données. Avec PostgreSQL prenant en charge JSON, cette complexité de l'architecture peut être évitée en choisissant simplement un magasin de données.
  • Les données JSON dans PostgreSQL peuvent être interrogées et indexées, ce qui offre des performances et une évolutivité incroyables
  • Le type de données JSONB est l'option préférée car il est bon en termes de stockage et de performances. Prend entièrement en charge la recherche et l'indexation en texte intégral. Offre de bonnes performances
  • N'utilisez le type de données JSON que si vous souhaitez stocker des chaînes JSON au format JSON et que vous n'effectuez pas de recherches textuelles très complexes
  • Le plus grand avantage d'avoir JSON dans PostgreSQL est que la recherche peut être effectuée à l'aide de SQL
  • Les performances de recherche JSON dans PostgreSQL sont comparables à celles des meilleures bases de données NoSQL telles que MongoDB