当前位置:  开发笔记 > 前端 > 正文

PostgreSQL引入的JSONB解释

如何解决《PostgreSQL引入的JSONB解释》经验,为你挑选了7个好方法。

PostgreSQL刚刚推出了JSONB,它已经在黑客新闻上发展趋势.如果有人能够解释它与之前在PostgreSQL中出现的Hstore和JSON有何不同,那就太好了.它的优点和局限是什么?何时有人考虑使用它?



1> pozs..:

首先,hstore是一个contrib模块,它只允许你存储key => value对,其中键和值只能是texts(但值也可以是sql NULL).

这两个jsonjsonb允许你存储一个有效的JSON (在其定义的规范).

F.ex. 这些都是有效的JSON表示:null,true,[1,false,"string",{"foo":"bar"}],{"foo":"bar","baz":[null]}- hstore相比有什么JSON能够(但如果你只需要这个子集,它的罚款)只是一个小的子集.

json&之间的唯一区别jsonb是他们的存储:

json 以纯文本格式存储,而

jsonb 存储在一些二进制表示中

这有三个主要后果:

jsonb通常需要更多的磁盘空间来存储json(有时不会)

jsonb 从输入表示开始构建需要更多时间 json

json操作采取显著超过时间jsonb(解析也需要在每一个你做一些工作时间进行json类型化值)

何时jsonb可以使用稳定版本,将有两个主要用例,当您可以轻松地在它们之间进行选择时:

    如果您只在应用程序中使用JSON表示,PostgreSQL仅用于存储和检索此表示,您应该使用json.

    如果您对PostgreSQL中的JSON值执行了大量操作,或者在某些JSON字段上使用索引,则应该使用jsonb.


因为,出于遗留原因:在JSON中,如果对象的(键,表,映射,哈希,无论在宿主语言中称为什么)键值对的排序不同,则在语义上没有任何区别。如果您依赖于此,则实际上是在使用与JSON不同的东西。-对于`text`与`json`:后者带有JSON验证,因此在无效JSON时,它只会在插入时失败,而不是在您的应用程序每次读取它时都会失败(因为它得到了无效的表示)。同样,您可以在数据库中将后者安全地转换为`jsonb`。
这是一篇很棒的帖子,解释了JSONB的实现细节(http://pgeoghegan.blogspot.com/2014/03/what-i-think-of-jsonb.html)

2> FuzzyChef..:

Peeyush:

简短的回答是:

如果你 PostgreSQL 中进行了很多JSON操作,比如排序,切片,拼接等,你应该出于速度原因使用JSONB.

如果您需要在JSON上进行任意键搜索的索引查找,那么您应该使用JSONB.

如果您不同时使用上述两种方法,则应该使用JSON.

如果需要保留键排序,空格和重复键,则应使用JSON.

对于更长的答案,你需要等待我在接近9.4版本的时候做一个完整的"HowTo"写.



3> ChelowekKot..:

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:文本存储«按原样»

jsonb:没有空格

jsonb:没有重复的键,最后一键获胜

jsonb:键已排序

更多关于jsonb开发人员的演讲视频和幻灯片演示.他们还介绍了JsQuery,pg.extension提供了强大的jsonb查询语言



4> Ivan Voras..:

hstore 它更像是一个"宽列"存储类型,它是键值对的平面(非嵌套)字典,总是以合理有效的二进制格式(哈希表,因此名称)存储.

json将JSON文档存储为文本,在存储文档时执行验证,并在需要时在输出上解析它们(即访问单个字段); 它应该支持整个JSON规范.由于存储了整个JSON文本,因此会保留其格式.

jsonb出于性能原因采用快捷方式:JSON数据在输入时解析并以二进制格式存储,字典中的键排序不会保留,也不是重复键.访问JSONB字段中的各个元素非常快,因为它不需要始终解析JSON文本.在输出时,重建JSON数据并丢失初始格式.

IMO,不存在用于显著理由使用jsonb一旦有货,如果你与机器可读数据的工作.



5> 小智..:

jsonb是JSON的"更好"版本.让我们借助一个例子来检查.

专业Postgres的比较

    JSON存储空白区域,这就是为什么我们可以在存储键"a"时看到空格,而JSONB则不会.

    JSON存储key的所有值.这就是您可以看到针对键"a"的多个值(2和1)的原因,而JSONB仅"存储"最后一个值.

    JSON维护元素的命名顺序,而JSONB维护"排序"顺序.

    JSONB对象存储为解压缩二进制文件,而不是JSON中的"原始数据",在检索期间不需要重新分析数据.

    JSONB还支持索引,这可能是一个显着的优势.

通常,人们应该更喜欢JSONB,除非有非常特殊的需求,例如关于对象键排序的遗留假设.



6> John..:

我今天在pgopen基准测试比mongodb更快,我认为选择速度快了约500%.与mongodb相比,几乎所有东西都至少快了200%,而现在的一个例外是需要完全重写mongodb处理的整个json列的更新.

关于jsonb的杜松子酒索引听起来很神奇.

postgres还会在内部持久保存jsonb类型,并且基本上与数字,文本,布尔等类型匹配.

使用jsonb也可以加入

为存储过程添加PLv8,这对于node.js开发人员来说基本上是梦想成真.

将它存储为二进制jsonb也将删除所有空格,更改属性的顺序并使用属性的最后一次出现删除重复属性.

除了查询与json列对比的jsonb列时的索引postgres不必实际运行将文本转换为每行上的json的功能,这可能会节省大量时间.



7> 小智..:

据我所知,

当前存在的hstore(在Postgresql 9.3中)不允许将其他对象和数组嵌套为其键/值对的值.但是,未来的hstore补丁将允许嵌套.此补丁不会在9.4版本中,也可能不会很快包含在内.

JSON,因为它目前存在确实允许嵌套,但基于文本的,并且不允许索引,因此它是"慢"

将与9.4一起发布的jsonb将具有json的当前嵌套功能,以及hstore的GIN/GIST索引,因此它将很快

在postgresql 9.4上工作的人似乎在说新的快速jsonb类型会吸引那些选择使用像MongoDB这样的noSQL数据存储的人,但现在可以将关系数据库与可查询的非结构化数据结合在一起

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

postgresql 9.4 jsonb的基准测试似乎与MongoDB相当或在某些情况下比MongoDB更快

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

推荐阅读
臭小子
这个屌丝很懒,什么也没留下!
DevBox开发工具箱 | 专业的在线开发工具网站    京公网安备 11010802040832号  |  京ICP备19059560号-6
Copyright © 1998 - 2020 DevBox.CN. All Rights Reserved devBox.cn 开发工具箱 版权所有