介绍PostgreSQL中的jsonb数据类型

所属分类: 数据库 / 数据库其它 阅读数: 135
收藏 0 赞 0 分享

PostgreSQL 9.4 正在加载一项新功能叫jsonb,是一种新型资料,可以储存支援GIN索引的JSON 资料。换言之,此功能,在即将来临的更新中最重要的是,如果连这都不重要的话,那就把Postgres 置于文件为本数据库系统的推荐位置吧。

自从9.2开始,一个整合JSON 资料类型已经存在,带有一整套功能(例如资料产生和资料解构功能),还有9.3新增的操作者。当使用JSON 资料类型,资料的被存储成一完全一样的副本,功能还在此之上运作,还另外需要后台运作的重新分析。

这心得JSONB 资料类型以已降解的2元格式存储,所以,插入此资料会比JSON高效,因为后台不再需要重新分析,因此让它更快速运行,而且还兼顾GIN 索引。就是因为最后这个原因,我们实际上建议读者使用jsonb来代替json制作程式(当然你还可以因应需要而使用json)。请记住jsonb使用相同的操作者和功能,读者们可以看我之前的帖子去令你得到些什么启发(或者干脆看Postgres的文件)。
 

现在让我们看一下JSONB是如何工作的,同时和JSON比较一下。采用的测试数据是860万的geobase类型数据,大概1.1G大小,包括了城市名,国家代码(可以在这参见完整列表)等很多字段。首先通过底层复制(raw copy)来把这些数据存储到数据库的一个新表里面,之后把这张表通过一组填充因子是100的表转换成JSON/JSONB,之后来看它们各占多少空间。
 

=# COPY geodata FROM '$HOME/Downloads/allCountries.txt';
COPY 8647839
=# CREATE TABLE geodata_jsonb (data jsonb) with (fillfactor=100);
CREATE TABLE
=# CREATE TABLE geodata_json (data json) with (fillfactor=100);
CREATE TABLE
=# \timing
Timing is on.
=# INSERT INTO geodata_json SELECT row_to_json(geodata) FROM geodata;
INSERT 0 8647839
Time: 287158.457 ms
=# INSERT INTO geodata_jsonb SELECT row_to_json(geodata)::jsonb FROM geodata;
INSERT 0 8647839
Time: 425825.967 ms

生成JSONB数据花费稍微长一点时间,大小有没有区别呢?
 

=# SELECT pg_size_pretty(pg_relation_size('geodata_json'::regclass)) AS json,
     pg_size_pretty(pg_relation_size('geodata_jsonb'::regclass)) AS jsonb;
 json  | jsonb 
---------+---------
 3274 MB | 3816 MB
(1 row)

在JSON数据上面做索引从9.3版本开始,比如用操作符(注意 因为它返回文本,所以'->>'被采用;并且根据查询不同,索引采用不同的关键字)
 

=# CREATE INDEX geodata_index ON
  geodata_json ((data->>'country_code'), (data->>'asciiname'));
CREATE INDEX
=# SELECT pg_size_pretty(pg_relation_size('geodata_index'::regclass))
  AS json_index;
 json_index 
------------
 310 MB
(1 row)
=# SELECT (data->>'population')::int as population,
     data->'latitude' as latitude,
     data->'longitude' as longitude
  FROM geodata_json WHERE data->>'country_code' = 'JP' AND
    data->>'asciiname' = 'Tokyo' AND
    (data->>'population')::int != 0;
 population | latitude | longitude 
------------+----------+-----------
  8336599 | 35.6895 | 139.69171
(1 row)
=# -- Explain of previous query
                            QUERY PLAN                            
-------------------------------------------------------------------------------------------------------------------------
 Bitmap Heap Scan on geodata_json (cost=6.78..865.24 rows=215 width=32)
  Recheck Cond: (((data ->> 'country_code'::text) = 'JP'::text) AND ((data ->> 'asciiname'::text) = 'Tokyo'::text))
  Filter: (((data ->> 'population'::text))::integer <> 0)
  -> Bitmap Index Scan on geodata_index (cost=0.00..6.72 rows=216 width=0)
     Index Cond: (((data ->> 'country_code'::text) = 'JP'::text) AND ((data ->> 'asciiname'::text) = 'Tokyo'::text))
 Planning time: 0.172 ms
(6 rows)

在这个例子里,计划(planner)可以使用bitmap索引扫描,同时使用了之前产生的索引。


现在,JSONB的一个新特点就是检查包含带有操作符@>的数据容量,这种数据是可以用GIN来索引的,这种操作符数据也包括了?,?|和?&(为了检查给定的关键字是否存在)。 GIN索引对两类操作符起作用:

    缺省操作符类,之前列出的四个;

    jsonb_hash_ops,仅支持@>,但是当搜索数据时性能表现不错,而且所占磁盘空间较小;

下面是它如何工作:
 

=# CREATE INDEX geodata_gin ON geodata_jsonb
   USING GIN (data jsonb_hash_ops);
CREATE INDEX
=# SELECT (data->>'population')::int as population,
   data->'latitude' as latitude,
   data->'longitude' as longitude
  FROM geodata_jsonb WHERE data @> '{"country_code": "JP", "asciiname": "Tokyo"}' AND
    (data->>'population')::int != 0;
 population | latitude | longitude 
------------+----------+-----------
  8336599 | 35.6895 | 139.69171
(1 row)
 =# SELECT pg_size_pretty(pg_relation_size('geodata_gin'::regclass)) AS jsonb_gin;
 jsonb_gin
-----------
 1519 MB
(1 row)
=# -- EXPLAIN of previous query
                   QUERY PLAN                   
-------------------------------------------------------------------------------------
 Bitmap Heap Scan on geodata_jsonb (cost=131.01..31317.76 rows=8605 width=418)
  Recheck Cond: (data @> '{"asciiname": "Tokyo", "country_code": "JP"}'::jsonb)
  Filter: (((data ->> 'population'::text))::integer <> 0)
  -> Bitmap Index Scan on geodata_gin (cost=0.00..128.86 rows=8648 width=0)
     Index Cond: (data @> '{"asciiname": "Tokyo", "country_code": "JP"}'::jsonb)
 Planning time: 0.134 ms

根据应用的需求,你或许想采用空间消耗低的索引,比如BTree建立在JSON数据上的索引类型;GIN索引有着更多的优点,因为它覆盖了所有的JSON字段,并且检查容量;

更多精彩内容其他人还在看

sql 左连接和右连接的使用技巧(left join and right join)

今天做项目,发现左右连接是不一样的。主要是说明了区别,是不是必须用左连接或右连接,大家可以根据需要选择。
收藏 0 赞 0 分享

mysql "group by"与"order by"的研究--分类中最新的内容

这两天让一个数据查询难了。主要是对group by 理解的不够深入。才出现这样的情况
收藏 0 赞 0 分享

MSSQL转MySQL数据库的实际操作记录

今天把一个MSSQL的数据库转成MySQL,在没有转换工具的情况下,对于字段不多的数据表我用了如下手功转换的方法,还算方便。MSSQL使用企业管理器操作,MySQL用phpmyadmin操作。
收藏 0 赞 0 分享

程序员应该知道的数据库设计的两个误区

在几乎所有的企业级应用程序中,包括各种MIS、ERP、CRM等等,都会使用数据库,这样的好处是显而易见的,很容易地实现了数据层和业务逻辑层的分离,而且对于性能的优化也在一定程度上提供了便利。
收藏 0 赞 0 分享

大数据量,海量数据处理方法总结

大数据量的问题是很多面试笔试中经常出现的问题,比如baidu google 腾讯这样的一些涉及到海量数据的公司经常会问到。
收藏 0 赞 0 分享

MDAC2.8 安装问题与解决方法

根据Windows XP的版本不同,有的版本需要安装MDAC2.8,一般Windows XP SP2或以上版本就不需要安装。不需要安装时系统会提示“MDAC 2.8 RTM 与此版本 Windows 不兼容。现在它的所有功能都成为 Windows 的一部分”。
收藏 0 赞 0 分享

SQLServer 2005 和Oracle 语法的一点差异小结

Microsoft SQL Server 和Oracle 语法的一点差异小结,需要的朋友可以参考下。
收藏 0 赞 0 分享

数据库设计规范化的五个要求 推荐收藏

通常情况下,可以从两个方面来判断数据库是否设计的比较规范。一是看看是否拥有大量的窄表,二是宽表的数量是否足够的少。
收藏 0 赞 0 分享

数据库为何要建立索引的原因说明

数据库索引是为了增加查询速度而对表字段附加的一种标识。见过很多人机械的理解索引的概念,认为增加索引只有好处没有坏处。
收藏 0 赞 0 分享

数据库测试 实用技巧及测试方法

软件应用程序已经离不开数据库。无论是在Web、桌面应用、客户端服务器、企业和个人业务,都需要数据库在后端操作。
收藏 0 赞 0 分享
查看更多