json和jsonb之间的区别的简单解释(原始图片来自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:文本存储«as is» Jsonb:没有空格 没有重复的键，最后一个键获胜 Jsonb:键排序

更多的演讲视频和幻灯片演示由jsonb开发人员。他们还引入了JsQuery，一个pg.extension，提供了强大的jsonb查询语言。

另一个重要的区别是，json类型没有相等操作符，但jsonb有。

这意味着在从表中选择json类型和/或其他字段时不能使用DISTINCT关键字(您可以使用DISTINCT ON代替，但由于这种情况，它并不总是可行的)。

首先，hstore是一个contrib模块，它只允许你存储key =>值对，其中键和值只能是文本(但是值也可以是sql null)。

json和jsonb都允许你存储一个有效的json值(在其规范中定义)。

F.ex。这些是有效的JSON表示:null, true， [1,false，"string"，{"foo":"bar"}]， {"foo":"bar"，"baz":[null]} - hstore只是JSON功能的一个小子集(但如果你只需要这个子集，也没关系)。

json和jsonb之间唯一的区别是它们的存储:

Json以纯文本格式存储，而 Jsonb以某种二进制表示形式存储

这有3个主要后果:

Jsonb通常比json占用更多的磁盘空间(有时不是) 与json相比，Jsonb需要更多的时间从其输入表示构建 Json操作要比jsonb花费更多的时间(并且每次在Json类型的值上执行一些操作时也需要进行解析)

当jsonb的稳定版本可用时，会有两个主要的用例，你可以很容易地在它们之间进行选择:

如果你只在应用程序中使用JSON表示，PostgreSQL只用于存储和检索这种表示，你应该使用JSON。 如果你在PostgreSQL中对JSON值做了很多操作，或者对一些JSON字段使用索引，你应该使用jsonb。

json和jsonb之间的区别的简单解释(原始图片来自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:文本存储«as is» Jsonb:没有空格 没有重复的键，最后一个键获胜 Jsonb:键排序

更多的演讲视频和幻灯片演示由jsonb开发人员。他们还引入了JsQuery，一个pg.extension，提供了强大的jsonb查询语言。

hstore is more of a "wide column" storage type, it is a flat (non-nested) dictionary of key-value pairs, always stored in a reasonably efficient binary format (a hash table, hence the name). json stores JSON documents as text, performing validation when the documents are stored, and parsing them on output if needed (i.e. accessing individual fields); it should support the entire JSON spec. Since the entire JSON text is stored, its formatting is preserved. jsonb takes shortcuts for performance reasons: JSON data is parsed on input and stored in binary format, key orderings in dictionaries are not maintained, and neither are duplicate keys. Accessing individual elements in the JSONB field is fast as it doesn't require parsing the JSON text all the time. On output, JSON data is reconstructed and initial formatting is lost.

在我看来，如果您处理的是机器可读的数据，那么一旦jsonb可用，就没有什么重要的理由不使用它。

我今天在PostgresOpen上，基准测试比MongoDB快多了。我相信它的选择速度快了500%。几乎所有东西都更快，与MongoDB相比至少快了200%。现在的一个例外是需要完全重写整个JSON列的更新——这一点MongoDB处理得更好。

JSONB上的gin索引听起来很棒。

PostgreSQL还将在内部持久化JSONB类型，并将其与数字、文本、布尔等类型进行匹配。

使用JSONB也可以实现连接。

为存储过程添加PLv8，这将是Node.js开发者的梦想成真。

由于它被存储为二进制，JSONB还将删除所有空白，改变属性的顺序，并使用属性的最后一次出现来删除重复的属性。

除了索引，当查询JSONB列和JSON列时，PostgreSQL不需要实际运行将每一行的文本转换为JSON的功能，这可能会节省大量的时间。