Explication de JSONB introduit par PostgreSQL

Question

PostgreSQL vient d'introduire JSONB et c'est déjà une tendance sur hacker news . En quoi est-il différent de Hstore et JSON précédemment présents dans PostgreSQL ?

Quels sont ses avantages et ses limites et quand doit-on envisager de l'utiliser ?

Answer 1

D'abord, hstore est un module contributif, qui vous permet uniquement de stocker des paires clé => valeur, où les clés et les valeurs peuvent uniquement être text (toutefois, les valeurs peuvent être sql NULL aussi).

Les deux sites json & jsonb vous permet de stocker un fichier JSON valide valeur (défini dans son spec ).

Par exemple, ce sont des représentations JSON valides : null , true , [1,false,"string",{"foo":"bar"}] , {"foo":"bar","baz":[null]} - hstore n'est qu'un petit sous-ensemble par rapport à ce dont JSON est capable (mais si vous n'avez besoin que de ce sous-ensemble, c'est parfait).

La seule différence entre json & jsonb est leur stockage :

• json est stocké dans son format de texte brut, tandis que
• jsonb est stocké dans une représentation binaire

Il y a trois conséquences majeures à cela :

• jsonb prend généralement plus d'espace disque à stocker que json (parfois non)
• jsonb prend plus de temps à construire à partir de sa représentation d'entrée que json
• json les opérations se déroulent de manière significative plus de temps que jsonb (& l'analyse syntaxique doit également être effectuée à chaque fois que vous effectuez une opération sur un fichier de type json valeur typée)

Cuando jsonb sera disponible avec une version stable, il y aura deux cas d'utilisation majeurs, où vous pourrez facilement choisir entre les deux :

1. Si vous ne travaillez qu'avec la représentation JSON dans votre application, PostgreSQL n'est utilisé que pour stocker et récupérer cette représentation, vous devriez utiliser json .
2. Si vous effectuez beaucoup d'opérations sur la valeur JSON dans PostgreSQL, ou si vous utilisez l'indexation sur un champ JSON, vous devriez utiliser la méthode suivante jsonb .

Answer 2

Peeyush :

La réponse courte est :

• Si vous faites beaucoup de manipulations JSON à l'intérieur de PostgreSQL, comme le tri, le découpage, l'épissage, etc., vous devriez utiliser JSONB pour des raisons de vitesse.
• Si vous avez besoin de consultations indexées pour des recherches de clés arbitraires sur JSON, vous devez utiliser JSONB.
• Si vous ne faites ni l'un ni l'autre, vous devriez probablement utiliser JSON.
• Si vous devez préserver l'ordre des clés, les espaces blancs et les clés dupliquées, vous devez utiliser JSON.

Pour une réponse plus détaillée, vous devrez attendre que je rédige un article complet sur le "mode d'emploi" à l'approche de la sortie de la version 9.4.

Answer 3

• hstore est plutôt un type de stockage "à large colonne", c'est un dictionnaire plat (non imbriqué) de paires clé-valeur, toujours stocké dans un format binaire raisonnablement efficace (une table de hachage, d'où son nom).
• json stocke les documents JSON sous forme de texte, en effectuant la validation lorsque les documents sont stockés, et en les analysant à la sortie si nécessaire (c'est-à-dire en accédant à des champs individuels) ; il doit prendre en charge la totalité de la spécification JSON. Comme le texte JSON est stocké dans son intégralité, son formatage est préservé.
• jsonb prend des raccourcis pour des raisons de performance : Les données JSON sont analysées en entrée et stockées au format binaire, l'ordre des clés dans les dictionnaires n'est pas conservé, pas plus que les clés dupliquées. L'accès à des éléments individuels dans le champ JSONB est rapide car il ne nécessite pas d'analyser le texte JSON en permanence. À la sortie, les données JSON sont reconstruites et le formatage initial est perdu.

IMO, il n'y a pas de raison significative pour no en utilisant jsonb une fois qu'il est disponible, si vous travaillez avec des données lisibles par machine.

Answer 4

J'étais à la PostgresOpen aujourd'hui, et les benchmarks sont bien plus rapides que MongoDB . Je crois qu'il était environ 500% plus rapide pour les sélections. Presque tout était plus rapide, au moins de 200 % par rapport à MongoDB. La seule exception est une mise à jour qui nécessite la réécriture complète de la colonne JSON, ce que MongoDB gère mieux.

L'indexation gin sur JSONB semble étonnante.

De même, PostgreSQL conservera les types de JSONB en interne et les fera correspondre à des types tels que numérique, texte, booléen, etc.

Les jonctions seront également possibles en utilisant JSONB.

Ajoutez la PLv8 pour les procédures stockées et ce sera un rêve devenu réalité pour Node.js développeurs.

Étant donné qu'il est stocké sous forme binaire, JSONB supprime également tous les espaces blancs, modifie l'ordre des propriétés et supprime les propriétés en double en utilisant la dernière occurrence de la propriété.

Outre l'index, lors d'une requête sur une colonne JSONB par opposition à une colonne JSON, PostgreSQL n'a pas besoin d'exécuter la fonctionnalité de conversion du texte en JSON sur chaque ligne, ce qui représente un gain de temps considérable.

Answer 5

D'après ce que je sais,

• hstore tel qu'il existe actuellement (dans PostgreSQL 9.3) ne permet pas d'imbriquer d'autres objets et tableaux comme valeurs de ses paires clé/valeur. Cependant, un futur patch hstore permettra l'imbrication. Ce correctif ne sera pas inclus dans la version 9.4 et ne le sera peut-être pas de sitôt.

• json tel qu'il existe actuellement fait permet l'imbrication, mais il est basé sur le texte et ne permet pas l'indexation, il est donc "lent".

• jsonb qui sera publié avec la 9.4 aura les capacités d'imbrication actuelles de json, ainsi que l'indexation GIN/GIST de hstore, il sera donc rapide.

Les personnes travaillant sur PostgreSQL 9.4 semblent dire que le nouveau type jsonb, rapide, séduira les personnes qui auraient choisi d'utiliser un fichier NoSQL magasin de données comme MongoDB mais elle peut désormais combiner une base de données relationnelle et des données non structurées interrogeables sous un même toit.

Pourquoi HStore2/jsonb est le patch le plus important de la 9.4

Les benchmarks de PostgreSQL 9.4 jsonb semblent être à égalité ou dans certains cas plus rapides que MongoDB.

http://texture.io/alphabetum/postgresql-incl-hstore-vs-mongodb