Explication de JSONB introduite par PostgreSQL
PostgreSQL vient d'introduire JSONB et il a déjà tendance à suivre les nouvelles du pirate informatique . Ce serait formidable si quelqu'un pouvait expliquer en quoi c'est différent de Hstore et de JSON précédemment présents dans PostgreSQL. Quels sont ses avantages et ses limites et quand devrait-on envisager de l'utiliser?
Tout d'abord, hstore est un module contrib, qui vous permet uniquement de stocker des paires clé => valeur, clés et valeurs ne pouvant être que texts (toutefois, les valeurs peuvent également être sql NULLs).
json & jsonb vous permettent tous les deux de stocker une valeur JSON valide (définie dans sa spec ).
F.ex. Ce sont des représentations JSON valides: null, true, [1,false,"string",{"foo":"bar"}], {"foo":"bar","baz":[null]} - hstore est juste un petit sous-ensemble par rapport à ce que JSON est capable (mais si vous avez seulement besoin de ce sous-ensemble, c'est très bien).
La seule différence entre json et jsonb est leur stockage:
jsonest stocké dans son format de texte brut, tandis quejsonbest stocké dans une représentation binaire
Il en résulte 3 conséquences majeures:
jsonbnécessite généralement plus d'espace disque à stocker quejson(parfois non)jsonbprend plus de temps à construire à partir de sa représentation en entrée quejson- Les opérations
jsonprennent considérablement plus de temps quejsonb(et l’analyse doit également être effectuée chaque fois que vous effectuez une opération à une valeur typéejson)
Lorsque jsonb sera disponible avec une version stable, il y aura deux cas d'utilisation principaux, lorsque vous pourrez facilement choisir entre eux:
- Si vous travaillez uniquement avec la représentation JSON dans votre application, PostgreSQL ™ est uniquement utilisé pour stocker et récupérer cette représentation, vous devez utiliser
json. - Si vous effectuez de nombreuses opérations sur la valeur JSON dans PostgreSQL, ou utilisez l'indexation sur certains champs JSON, vous devez utiliser
jsonb.
Peeyush:
La réponse courte est:
- Si vous faites beaucoup de manipulations JSON à l'intérieur PostgreSQL, comme le tri, le découpage en tranches, le raccordement, etc., vous devez utiliser JSONB pour des raisons de rapidité.
- Si vous avez besoin de recherches indexées pour des recherches de clés arbitraires sur JSON, vous devez utiliser JSONB.
- Si vous ne faites rien de ce qui précède, vous devriez probablement utiliser JSON.
- Si vous devez conserver l'ordre des clés, les espaces et les clés en double, vous devez utiliser JSON.
Pour une réponse plus longue, vous devrez attendre que je fasse un article "HowTo" complet plus proche de la version 9.4.
Une explication simple de la différence entre json et jsonb ( image originale de PostgresProfessional ):
SELECT '{"c":0, "a":2,"a":1}'::json, '{"c":0, "a":2,"a":1}'::jsonb;
json | jsonb
------------------------+---------------------
{"c":0, "a":2,"a":1} | {"a": 1, "c": 0}
(1 row)
- json: stockage textuel "tel quel"
- jsonb: pas d'espaces blancs
- jsonb: pas de clés en double, dernière victoire
- jsonb: les clés sont triées
Plus dans discours vidéo et présentation de diaporama par les développeurs de jsonb. En outre, ils ont introduit JsQuery , pg.extension fournit un puissant langage de requête jsonb
hstoreest davantage un type de stockage "colonne large", c'est un dictionnaire simple (non imbriqué) de paires clé-valeur, toujours stocké dans un format binaire raisonnablement efficace (une table de hachage, d'où son nom).jsonstocke les documents JSON sous forme de texte, en effectuant une validation lorsque les documents sont stockés et en les analysant en sortie si nécessaire (c'est-à-dire en accédant à des champs individuels); il devrait supporter l'intégralité de la spécification JSON. Comme tout le texte JSON est stocké, sa mise en forme est préservée.jsonbprend des raccourcis pour des raisons de performances: les données JSON sont analysées lors de la saisie et stockées au format binaire, les commandes de clé dans les dictionnaires ne sont pas conservées, ni 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 à tout moment. En sortie, les données JSON sont reconstruites et le formatage initial est perdu.
OMI, il n'y a pas de raison importante pour que pas utilise jsonb une fois qu'il est disponible, si vous utilisez des données lisibles par machine.
J’étais au pgopen aujourd’hui, les benchmarks sont bien plus rapides que mongodb, je crois que c’était environ 500% plus rapide pour les sélections. À peu près tout était plus rapide, à 200% au moins, par rapport à Mongodb, qu’une exception à la règle est une mise à jour qui nécessite une réécriture complète de la colonne json complète, quelque chose que mongodb gère mieux.
L’indexation du gin sur jsonb semble incroyable.
De plus, postgres conservera les types de jsonb en interne et les fera correspondre à des types tels que numérique, texte, booléen, etc.
Les jointures seront aussi possibles avec jsonb
Ajouter PLv8 pour les procédures stockées et ce sera essentiellement un rêve devenu réalité pour les développeurs de node.js.
Étant stocké en tant que fichier binaire, jsonb supprimera également tous les espaces, modifiera l'ordre des propriétés et supprimera les propriétés en double en utilisant la dernière occurrence de la propriété.
Outre l'index lors de l'interrogation d'une colonne jsonb par rapport à une colonne json, postgres n'a pas à exécuter la fonctionnalité permettant de convertir le texte en json sur chaque ligne, ce qui permettra probablement de gagner un temps considérable.
JSONB est une "meilleure" version de JSON.
Regardons un exemple:
SELECT '{"c":0, "a":2,"a":1}'::json, '{"c":0, "a":2,"a":1}'::jsonb;
json | jsonb
------------------------+---------------------
{"c":0, "a":2,"a":1} | {"a": 1, "c": 0}
(1 row)
- JSON stocke des espaces, c’est pourquoi nous pouvons voir des espaces lorsque la clé "a" est stockée, contrairement à JSONB.
- JSON stocke toutes les valeurs de clé. C'est la raison pour laquelle vous pouvez voir plusieurs valeurs (2 et 1) par rapport à la clé "a", alors que JSONB ne "stocke" que la dernière valeur.
- JSON conserve l'ordre dans lequel les éléments sont insérés, tandis que JSONB conserve l'ordre "trié".
- Les objets JSONB sont stockés sous forme de fichier binaire décompressé, par opposition aux "données brutes" dans JSON, où aucune analyse des données n'est requise lors de l'extraction.
- JSONB prend également en charge l'indexation, ce qui peut constituer un avantage significatif.
En règle générale, il convient de préférer JSONB, sauf en cas de besoins spécifiques, tels que des hypothèses héritées sur la commande des clés d'objet.
Autant que je sache,
hstore tel qu'il existe actuellement (dans Postgresql 9.3) ne permet pas d'imbriquer d'autres objets et tableaux en tant que valeurs de ses paires clé/valeur. Cependant, un futur patch hstore permettra l'imbrication. ce correctif ne sera pas dans la version 9.4 et pourrait ne pas être inclus de si tôt.
json tel qu'il existe actuellement permet de permettre une imbrication, mais il est basé sur du texte et ne permet pas d'indexation; il est donc "lent"
jsonb qui sera publié avec la version 9.4 aura les capacités actuelles d’imbrication de json, ainsi que l’indexation GIN/Gist de hstore, il sera donc rapide
Les personnes travaillant sur postgresql 9.4 semblent affirmer que le nouveau type jsonb rapide plaira aux personnes qui auraient choisi d'utiliser un magasin de données noSQL comme MongoDB, mais peuvent désormais combiner une base de données relationnelle avec des données non structurées pouvant faire l'objet de requêtes
http://www.databasesoup.com/2014/02/why-hstore2jsonb-is-most-important.html
Les repères de postgresql 9.4 jsonb semblent être sur un pied d'égalité ou, dans certains cas, plus rapides que MongoDB
http://texture.io/alphabetum/postgresql-incl-hstore-vs-mongodb
Une autre différence importante, qui n’a été mentionnée dans aucune des réponses ci-dessus, est qu’il n’existe pas d’opérateur d’égalité pour le type json, mais il en existe un pour le type jsonb.
Cela signifie que vous ne pouvez pas utiliser le mot clé DISTINCT lorsque vous sélectionnez ce type json- et/ou d'autres champs d'une table (vous pouvez utiliser DISTINCT ON à la place, mais ce n'est pas toujours possible. cas comme ceci ).