Explication de JSONB introduite par PostgreSQL

First, hstore est un module contrib, qui ne vous permet de stocker que les couples key => value, où les clés et les valeurs ne peuvent être que text s (cependant les valeurs peuvent aussi être sql NULL s).

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

f. ex. ce sont des représentations valides de JSON: 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 n'avez besoin que de ce sous-ensemble, c'est très bien).

la seule différence entre json et jsonb est leur stockage:

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

il y a 3 conséquences majeures de cela:

• jsonb prend généralement plus d'espace disque à stocker que json (parfois pas)
• jsonb prend plus de temps à construire à partir de sa représentation d'entrée que json
• json les opérations prennent considérablement plus de temps que jsonb (&parsing doit également être fait chaque fois que vous faites une opération à un json valeur typée)

quand jsonb sera disponible avec une version stable, il y aura deux cas d'utilisation majeure, quand vous pouvez choisir facilement entre eux:

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

Peeyush:

la réponse courte est:

• Si vous faites beaucoup de JSON manipulation à l'intérieur PostgreSQL, telles que le tri, de découpage, de collage, etc., vous devriez utiliser JSONB pour des raisons de vitesse.
• si vous avez besoin de recherche indexée pour des recherches de clés arbitraires sur JSON, vous devez utiliser JSONB.
• si vous ne faites aucun des deux ci-dessus, vous devriez probablement utiliser JSON.
• si vous avez besoin de préserver l'ordre des clés, les espaces et les clés dupliquées, vous devez utiliser JSON.

pour une réponse plus longue, vous aurez besoin d'attendre que je fasse un" HowTo " writeup complet plus proche de la version 9.4.

une explication simple de la différence entre json et jsonb ( image originale par Postgressif ):

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: des textes de stockage "comme est"
• jsonb: pas d'espaces
• jsonb: pas de doubles de clés, clé dernière victoire
• jsonb: les clés sont triées

plus dans speech video et présentation du diaporama par les développeurs jsonb. Ils ont également introduit JsQuery , pg.l'extension fournit un langage de requête JSONB puissant

• hstore est plus d'un type de stockage "large colonne", c'est un dictionnaire plat (non imbriqué) des paires de valeurs de clé, toujours stocké dans un format binaire raisonnablement efficace (une table de hachage, d'où le nom).
• json stocke les documents JSON sous forme de texte, en effectuant la validation lorsque les documents sont stockés, et en les analysant sur la sortie si nécessaire (c.-à-d. en accédant à des champs individuels); il devrait prendre en charge l'ensemble de la spécification JSON. Puisque le texte entier de JSON est stocké, 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 dans un format binaire, les commandes de clés dans les dictionnaires ne sont pas maintenues, ni les clés dupliquées. L'accès aux éléments individuels dans le champ JSONB est rapide car il n'est pas nécessaire d'analyser le texte JSON tout le temps. En sortie, les données JSON sont reconstruites et le formatage initial est perdu.

IMO, il y a aucune raison significative pour pas en utilisant jsonb une fois disponible, si vous travaillez avec des données lisibles par machine.

j'étais à la pgopen aujourd'hui les benchmarks sont beaucoup plus rapides que mongodb, je crois qu'il était d'environ 500% plus rapide pour les sélects. À peu près tout était plus rapide au moins d'au moins 200% comparé à mongodb, qu'une exception est une mise à jour qui nécessite de réécrire complètement la colonne entière de JSON quelque chose que mongodb gère mieux.

le gin indexé sur jsonb sonne incroyable.

aussi postgres persistera types de jsonb à l'intérieur et essentiellement correspondre à cela avec des types tels que numérique, texte, booléen, etc.

Rejoint le sera également possible à l'aide de jsonb

ajouter PLv8 pour les procédures stockées et ce sera essentiellement un rêve devenu réalité pour le noeud.les développeurs de js.

étant il est stocké comme JSONB binaire va également dépouiller tous les espaces, changer l'ordre des propriétés et supprimer les propriétés dupliquées en utilisant la dernière occurance de la propriété.

outre l'index lors de la recherche contre une colonne jsonb contrastée à une colonne JSON postgres ne doit pas réellement exécuter la fonctionnalité de convertir le texte en json sur chaque ligne qui permettra probablement de gagner une grande quantité de temps seul.

autant que je sache,

• hstore telle qu'elle existe actuellement (dans Postgresql 9.3) ne permet pas de nidification d'autres objets et les tableaux que les valeurs de ses paires clé/valeur. cependant, un futur îlot hstore permettra la nidification. ce patch ne sera pas dans la version 9.4 et peuvent ne pas être inclus tout moment bientôt.

• json telle qu'elle existe actuellement ne permettre la nidification, mais est basé sur le texte, et ne permet pas l'indexation, donc il est "lent "

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

les gens qui travaillent sur postgresql 9.4 semblent dire que le nouveau type JSONB rapide fera appel à des gens qui auraient choisi d'utiliser un magasin de données noSQL comme MongoDB, mais peuvent maintenant, combinez une base de données relationnelle avec des données non structurées interrogeables sous un même toit

http://www.databasesoup.com/2014/02/why-hstore2jsonb-is-most-important.html

"151900920 des" points de référence de postgresql 9.4 jsonb semblent être au même niveau ou dans certains cas plus rapide que MongoDB

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

jsonb est la version "meilleure" de JSON. Permet de vérifier à l'aide d'un exemple.

1. JSON permet les espaces blancs, c'est pourquoi nous pouvons voir les espaces lorsque la touche " a " est stockée, tandis que JSONB ne le fait pas.
2. JSON stocke toutes les valeurs de key. C'est la raison pour laquelle vous pouvez voir des valeurs multiples (2 et 1) contre la touche "a" , alors que JSONB ne "stocke" que la valeur la plus récente.
3. JSON maintient l'ordre dans lequel les éléments sont insérés, tandis que JSONB maintient l'ordre "trié".
Les objets
4. JSONB sont stockés en tant que binaires décompressés par opposition aux "données brutes" dans JSON , où aucune réparation des données n'est nécessaire pendant la récupération.
5. jsonb supporte également l'indexation, qui peut être un avantage significatif.

en général, on devrait préférer JSONB, à moins qu'il n'y ait tout à fait besoins spécialisés, comme les hypothèses héritées sur la commande des clés d'objet.

une autre différence importante, qui n'a pas été mentionnée dans la réponse ci-dessus, est qu'il n'y a pas d'opérateur d'égalité pour le type json , mais il y en a un pour le type jsonb .

cela signifie que vous ne pouvez pas utiliser DISTINCT mot-clé lors de la sélection de ce json - type et/ou d'autres champs d'une table (vous pouvez utiliser DISTINCT ON à la place, mais ce n'est pas toujours possible en raison de cas comme ce ).