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, '{
    "name":"fred",
    "address":{
        "line1":"52 The Elms",
        "line2":"Elmstreet",
        "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。

参考

PostgreSQL vs MongoDB http://my.oschina.net/Suregogo/blog/358277

Query JSON in PostgreSQL http://schinckel.net/2014/05/25/querying-json-in-postgres/

原文： https://www.compose.io/articles/is-postgresql-your-next-json-database/

<译：朱淦 350050183@qq.com 2015.8.9>