PostgreSQL是不是你的下一个JSON数据库？

概述介绍《PostgreSQL是不是你的下一个JSON数据库？》开发教程，希望对您有用。

《Postgresql是不是你的下一个JsON数据库？》要点：
本文介绍了Postgresql是不是你的下一个JsON数据库？，希望对您有用。如果有疑问，可以联系我们。

根据BetterIDge定律(任何头条的设问句可以用一个词来回答：不是),除非你的JsON数据很少修改,并且查询很多.

最新版的Postgresql添加更多对JsON的支持,我们曾经问过Postgresql是否可以替换MongoDB作为JsON数据库,答案显而易见,但我们更希望的是,啊哈,这个问题由读者来问了.

“Postgresql不是已经有一些Json的支持了吗?”

是的,在Postgresql 9.4之前的版本也有JsON 数据类型了,你可以这样：

CREATE table justJson ( ID INTEGER,doc JsON)>INSERT INTO justJson VALUES ( 1,'{    "name":"fred","address":{        "line1":"52 The Elms","line2":"Elmstreet","postcode":"ES1 1ES"        }    }');

保存了JsON的原始文本到数据库,包含空白行和键顺序及重新的键,我们来查看下保存的数据：

>SELECT * FROM justJson; ID |               doc----+---------------------------------  1 | {                              +    |     "name":"fred",+    |     "address":{                +    |         "line1":"52 The Elms",+    |         "line2":"Elmstreet",+    |         "postcode":"ES1 1ES"   +    |         }                      +    |     }(1 row)

跟保存之前的文本一模一样,但我们仍可以解析出具体的数据出来,Postgresql提供了一套JsON的 *** 作办法进行查找,例如,我们只要查出address信息,如果做?

select doc->>'address' FROM justJson;              ?column?--------------------------------- {                              +         "line1":"52 The Elms",+         "line2":"Elmstreet",+         "postcode":"ES1 1ES"   +         }(1 row)

doc字段的 ->> *** 作符是查询JsON对象的某个字段并返回文本,用数字也可以当作数组的索引,但仍返回文本.跟 ->> 类似的还有 -> *** 作符,返回不转文本的内容,可以用它来导航搜索JsON对象,如：

select doc->'address'->>'postcode' FROM justJson;   ?column?---------- ES1 1ES(1 row)

还有个更简短的写法来指定搜索路径,用 #>> *** 作符,如梦：

select doc#>>'{address,postcode}' FROM justJson;   ?column?---------- ES1 1ES(1 row)

通过保存完整的JsON数据类型可使其跟源数据完全一样并且不会丢失内容,但为坚持完全一致也带来了成本,性能的缺失,而且不能索引...所有,尽管可以很方便的维持一致性和坚持JsON文档,但仍有很大的提升空间,所以引入了JsONB.

"JsONB有什么不同?"

JsONB可以将整个JsON文档转有层级的KEY/VALUE数据对,所有的空白字符删除了,重复键只保留最后一次,键也没有排序,而是用HASH来保留了,上面的例子中用JsONB的版本的话,看来起类似这样：

>CREATE table justJsonb ( ID INTEGER,doc JsONB)>INSERT INTO justJsonb VALUES ( 1,"postcode":"ES1 1ES"        }    }');>SELECT * FROM justJsonb; ID |                                                doc----+----------------------------------------------------------------------------------------------------  1 | {"name": "fred","address": {"line1": "52 The Elms","line2": "Elmstreet","postcode": "ES1 1ES"}}(1 row)

可以看到,所有非文本内容都消失了,替换成JsON文档需要的最少格式,这种压缩方式表示当数据插入时会自动格式化,这样可以减少之后拜访数据分析处理的工作量.

"Postgresql的这种数据有点像HSTORE"

看到键值对,JsONB还真有点像Postgresql的HSTORE扩展,它也可以保留键值对,但它是一个扩展,而,JsONB(以及JsON)是在Postgresql内核的,HSTORE只有一级层级,但Postgresql可以有嵌套的元素,并且,HSTORE只能存字符串,而JsONB还可以存JsON的所数字类型.

“那JsONB到底带给我啥好处呢?”

索引,到处用上索引,你不能在Postgresql对JsON类型创建真正的索引,你可以创建表达式索引(Expression indexes),但只限于你想索引的内容,例如：

create index justJson_postcode on justJson ((doc->'address'->>'postcode'));  

只有邮编(postcode)索引了,其它都没有索引.

而JsONB,支持GIN索引,一种通用返转索引(Generalized Inverted Index),Postgresql提供了另外一套索引 *** 作符来支持,包括 @> 包括JsON,<@ 最包括,? 测试字符串是否存在,?| 任意字符串是否存在,?& 所有存大的字符串.

有两类索引可用,默认叫 Json_ops,它支持所有 *** 作符(译者：指普通Json *** 作符)和一个只支持&> *** 作符的Jsonb_path_ops索引(译者：指索引 *** 作符),默认索引给JsON中的每个键值都创建了索引,其实 Jsonb_path_ops只创建了一个比默认复杂的更高压缩的hash表索引,但默认索引担任更多 *** 作能力同时增加了空间本钱.给表添加一些数据,我们再来看看某个邮编,如果我们创建了一个默认的GIN JsON索引然后查询：

explain select * from justJsonb where doc @> '{ "address": { "postcode":"HA36CC" } }';                             query PLAN----------------------------------------------------------------- Seq Scan on justJsonb  (cost=0.00..3171.14 rows=100 {"address": {"postcode": "HA36CC"}}'::Jsonb)(2 rows)

可以看出来是顺序扫瞄表,如果我们加个默认的JsON GIN索引后再看看有什么不同?

> create index justJsonb_gin on justJsonb using gin (doc);> explain select * from justJsonb where doc @> '{ "address": { "postcode":"HA36CC" } }';                                  query PLAN------------------------------------------------------------------------------- Bitmap Heap Scan on justJsonb  (cost=40.78..367.62 rows=100 {"address": {"postcode": "HA36CC"}}'::Jsonb)   ->  Bitmap Index Scan on justJsonb_gin  (cost=0.00..40.75 rows=100 {"address": {"postcode": "HA36CC"}}'::Jsonb)(4 rows)

搜索性能提升很大,但暗藏了空间的耗费,例中是41%的数据大小,让我们删除索引重复执行Jsonb_path_ops GIN索引.

> create index justJsonb_gin on justJsonb using gin (doc Jsonb_path_ops);> explain select * from justJsonb where doc @> '{ "address": { "postcode":"HA36CC" } }';                                  query PLAN------------------------------------------------------------------------------- Bitmap Heap Scan on justJsonb  (cost=16.78..343.62 rows=100 {"address": {"postcode": "HA36CC"}}'::Jsonb)   ->  Bitmap Index Scan on justJsonb_gin  (cost=0.00..16.75 rows=100 {"address": {"postcode": "HA36CC"}}'::Jsonb)(4 rows)

总成本低了点,索引体积小了很多,这是典型的创建索引速度和空间平衡的办法,但比顺序扫瞄性能高很多.

“我应该用它作为我的JsON数据库吗?”

如果你经常更新你的JsON文档,回答是否定的,Postgresql最擅长的是存储和攻取JsON文档及他们的字段,但尽管如此你可以取出单个字段,你也不能更新单个字段；实际上你可以,将整个JsON解析出来,添加新的字段再写回,让JsON分析器处理重复,但你很明显不想依赖这个.

如果你的主要数据用关系数据库用得很好,JsON数据只是一群补充(静态数据),那么用Postgresql就可以了,而且用JsONB表现和索引能力将更高效.另外,如果你的数据模型是可变内容的集合,那么你可能会寻找一样主流工业级的Json文档数据库如MongoDB或RethinkDB.

内存溢出PHP培训学院每天发布《Postgresql是不是你的下一个JsON数据库？》等实战技能，PHP、MysqL、liNUX、APP、Js,CSS全面培养人才。

总结

以上是内存溢出为你收集整理的PostgreSQL是不是你的下一个JSON数据库？全部内容，希望文章能够帮你解决PostgreSQL是不是你的下一个JSON数据库？所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。