postgresql row_to_json的妙用

posted onJanuary 30,2013and written byJack ChristenseninDevelopment

A new feature in Postgresql 9.2 is JSON support. It includes a JSON data type and two JSON functions. These allow us to return JSON directly from the database server. This article covers how it is done and includes a benchmark comparing it with Traditional Rails JSON generation techniques.

How To

The simplest way to return JSON is withrow_to_json()function. It accepts a row value and returns a JSON value.

select row_to_json(words) from ;

This will return a single column per row in the words table.

{"id":6013,"text":"advancement""pronunciation" However,sometimes we only want to include some columns in the JSON instead of the entire row. In theory we Could use the row constructor method.
 
 
(rowidtext)) ;
 
 
 While this does return only the id and text columns,unfortunately it loses the field names and replaces them with f1,f2,f3,etc.
 
 
"f1""f2"}
 
 
 To work around this we must either create a row type and cast the row to that type or use a subquery. A subquery will typically be easier.
 
 
t)
from (
  text words
) t
 
 
 This results in the JSON output for which we would hope:
 
 
}
 
 
 The other commonly used technique isarray_aggandarray_to_json.array_aggis a aggregate function likesumorcount. It aggregates its argument into a Postgresql array.array_to_jsontakes a Postgresql array and flattens it into a single JSON value.
 
 
array_to_jsonarray_agg)))
    (
      words
    t
 
 
 This will result in a JSON array of objects:
 
 
[{6001"abaissed"},{6002"abbatial"6003"abelia" In exchange for a substantial jump in complexity,we can also use subqueries to return an entire object graph:
 
 
pronunciationd)))
      (
        part_of_speechbody
        deFinitions
        where word_id=.id
        order by position asc
      d
    as deFinitions
  words
  text = 'autumn'
 
 
 This Could return a result like the following:
 
 
{
  : "autumn""deFinitions": [
    {
        "part_of_speech""noun""body""skilder wearifully uninfolded..."
    "verb""intrafissural fernbird kittly..."
    "adverb""infrugal lansquenet impolarizable..."
    }
  ]
}
 
 
 ObvIoUsly,the sql to generate this JSON response is far more verbose than generating it in Ruby. Let’s see what we get in exchange.
 
 
 Benchmarks
 
 
 I created a sample benchmark application to test multiple JSON generation approaches. The sample domain is a dictionary. The source is athttps://github.com/JackC/json_api_bench.
 
 
 The first test is of an extremely light weight auto-complete search. The result set is simply an array of strings. I tested three approaches: loading the entire ActiveRecord domain model,using pluck,and using Postgresql (view source).
 
 
+-----------------------------+----------+
| Name                        | Reqs/Sec |
+-----------------------------+----------+
| Quick Search Domain         | 467.84   |
| Quick Search Pluck          | 496.89   |
| Quick Search Postgresql     | 540.54   |
+-----------------------------+----------+
 
 
 Pluck should probably be the preferred approach in this case. While Postgresql is about 8% faster,the code is less clear.
 
 
 The next test is of a slightly richer word search. It returns an array of objects that each include text,pronunciation,part of speech,and deFinition (view source).
 
 
+-----------------------------+----------+
| Name                        | Reqs/Sec |
+-----------------------------+----------+
| Rich Search Domain          | 322.58   |
| Rich Search Select All      | 418.85   |
| Rich Search Postgresql      | 500.00   |
+-----------------------------+----------+
 
 
 In this case,select_all should still usually be preferred over Postgresql. The loss of clarity is not worth the 19% performance increase.
 
 
 Now we get to a test of an entire object graph for a word. This returns an object with text,an array of deFinitions,an array of quotes,an array of synonyms,and an array of antonyms (view source)
 
 
+-----------------------------+----------+
| Name                        | Reqs/Sec |
+-----------------------------+----------+
| DeFinition Domain           | 130.72   |
| DeFinition Postgresql       | 457.14   |
+-----------------------------+----------+
 
 
 Now things start to get more favorable for Postgresql. In exchange for a substantial block of sql we get a 3.51x throughput increase.
 
 
 Finally,we run a test of returning multiple deFinitions per call. This is a more synthetic benchmark to exercise heavy weight API responses (view source).
 
 
+-----------------------------+----------+
| Name                        | Reqs/Sec |
+-----------------------------+----------+
| Many DeFinitions Domain     | 25.82    |
| Many DeFinitions Postgresql | 330.58   |
+-----------------------------+----------+
 
 
 For a large JSON object graph Postgresql JSON generation can offer well over 12x the throughput.
 
 
 Conclusions
 
 
 Postgresql is always faster than Traditional Rails JSON generation,but the code is always more verbose. For simple responses that do not involve nested objects,the performance gain is insufficient to warrant the loss in code clarity. As the object graph increases in size and complexity,the performance gains become more and more attractive.