Explanação do JSONB introduzida pelo PostgreSQL

O PostgreSQL acaba de lançar o JSONB e já é uma tendência em notícias sobre hackers . Seria ótimo se alguém pudesse explicar como é diferente do Hstore e do JSON anteriormente presentes no PostgreSQL. Quais são suas vantagens e limitações e quando alguém deve considerar usá-lo?

    Primeiro, o hstore é um módulo contrib, que permite armazenar apenas pares key => value, onde chaves e valores podem ser apenas text s (no entanto, valores podem ser sql NULL s também).

    Ambos json & jsonb permitem que você armazene um valor JSON válido (definido em sua especificação ).

    F.ex. estas são representações JSON válidas: null , true , [1,false,"string",{"foo":"bar"}] , {"foo":"bar","baz":[null]}hstore é apenas um pequeno subconjunto comparado ao que o JSON é capaz (mas se você precisar apenas deste subconjunto, tudo bem).

    A única diferença entre json e jsonb é o armazenamento:

    • json é armazenado em seu formato de texto simples, enquanto
    • jsonb é armazenado em alguma representação binária

    Existem 3 conseqüências principais disso:

    • jsonb geralmente leva mais espaço em disco para armazenar do que json (às vezes não)
    • jsonb leva mais tempo para construir a partir de sua representação de input do que json
    • json operações do json demoram significativamente mais tempo que o jsonb (e a análise também precisa ser feita toda vez que você fizer alguma operação com um valor typescript por json )

    Quando o jsonb estiver disponível com uma versão estável, haverá dois principais casos de uso, quando você poderá selecionar facilmente entre eles:

    1. Se você trabalha somente com a representação JSON em sua aplicação, o PostgreSQL é usado apenas para armazenar e recuperar esta representação, você deve usar o json .
    2. Se você faz muitas operações no valor JSON no PostgreSQL, ou usa indexação em algum campo JSON, você deve usar o jsonb .

    Peeyush:

    A resposta curta é:

    • Se você está fazendo muita manipulação JSON dentro do PostgreSQL, como ordenação, fatiamento, emenda, etc., você deve usar o JSONB por razões de velocidade.
    • Se você precisar de pesquisas indexadas para pesquisas de chave arbitrárias em JSON, então você deve usar JSONB.
    • Se você não está fazendo nenhum dos itens acima, provavelmente deve usar o JSON.
    • Se você precisa preservar a ordem das chaves, o espaço em branco e as chaves duplicadas, use o JSON.

    Para uma resposta mais longa, você precisará aguardar que eu faça um writeup “HowTo” completo mais próximo da versão 9.4.

    Uma explicação simples da diferença entre json e jsonb ( imagem original de 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: armazenamento textual «como é»
    • jsonb: sem espaços em branco
    • jsonb: sem chaves duplicadas, última vitória chave
    • jsonb: chaves são classificadas

    Mais em vídeo de fala e apresentação de slides por desenvolvedores jsonb. Também eles introduziram JsQuery , pg.extension fornece poderosa linguagem de consulta jsonb

    • hstore é mais um tipo de armazenamento de “coluna larga”, é um dictionary plano (não nested) de pares de valores-chave, sempre armazenado em um formato binário razoavelmente eficiente (uma tabela de hash, daí o nome).
    • json armazena documentos JSON como texto, realizando a validação quando os documentos são armazenados e analisando-os na saída, se necessário (ou seja, acessando campos individuais); ele deve suportar toda a especificação JSON. Como todo o texto JSON é armazenado, sua formatação é preservada.
    • jsonb toma atalhos por motivos de desempenho: os dados JSON são analisados ​​na input e armazenados em formato binário, as ordenações de chaves nos dictionarys não são mantidas e nenhuma delas é duplicada. Acessar elementos individuais no campo JSONB é rápido, pois não exige a análise do texto JSON o tempo todo. Na saída, os dados JSON são reconstruídos e a formatação inicial é perdida.

    IMO, não há razão significativa para não usar o jsonb quando ele estiver disponível, se você estiver trabalhando com dados legíveis por máquina.

    Eu estava no pgopen hoje benchmarks são muito mais rápidos que o mongodb, acredito que foi cerca de 500% mais rápido para selects. Quase tudo foi mais rápido, pelo menos, em 200%, quando contrastado com mongodb, do que uma exceção agora é uma atualização que requer rewrite completamente a coluna json inteira algo que mongodb lida melhor.

    O gin indexado no jsonb parece incrível.

    Também o postgres irá persistir tipos de jsonb internamente e basicamente combinará isso com tipos como numérico, texto, booleano etc.

    Juntas também serão possíveis usando o jsonb

    Adicione PLv8 para stored procedures e isso basicamente será um sonho para desenvolvedores node.js.

    Por ser armazenado como binário, o jsonb também tira todo o espaço em branco, altera a ordem das propriedades e remove propriedades duplicadas usando a última ocorrência da propriedade.

    Além do índice ao consultar uma coluna jsonb em contraste com uma coluna json, o postgres não precisa executar a funcionalidade para converter o texto para json em cada linha, o que provavelmente salvará uma grande quantidade de tempo sozinha.

    Tanto quanto eu posso dizer,

    • hstore como existe atualmente (no Postgresql 9.3) não permite aninhar outros objects e matrizes como os valores de seus pares de chave / valor. no entanto, um futuro patch hstore permitirá o aninhamento. este patch não estará na versão 9.4 e poderá não ser incluído em breve.

    • json como existe atualmente permite o aninhamento, mas é baseado em texto, e não permite a indexação, portanto, é “lento”

    • O jsonb que será lançado com o 9.4 terá os resources de nesting atuais do json, assim como a indexação GIN / GIST do hstore, então será rápido

    As pessoas que trabalham no postgresql 9.4 parecem estar dizendo que o novo tipo jsonb rápido atrairá as pessoas que escolheram usar um armazenamento de dados noSQL como o MongoDB, mas agora podem combinar um database relacional com dados não estruturados de consulta sob o mesmo teto

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

    Os benchmarks do postgresql 9.4 jsonb parecem estar no mesmo nível ou em alguns casos mais rápidos que o MongoDB

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

    jsonb é a versão “melhor” do JSON. Vamos verificar com ajuda de um exemplo.

    Comparação por Postgres Prosfessional

    1. O JSON permite espaços em branco, e é por isso que podemos ver espaços quando a chave “a” é armazenada, enquanto o JSONB não.
    2. JSON armazena todos os valores de chave. Esta é a razão pela qual você pode ver vários valores (2 e 1) contra a chave “a”, enquanto o JSONB apenas “armazena” o último valor.
    3. O JSON mantém a ordem em que os elementos são inseridos, enquanto o JSONB mantém a ordem “classificada”.
    4. Objetos JSONB são armazenados como binários descomprimidos, em oposição a “dados brutos” em JSON, onde nenhuma repetição de dados é necessária durante a recuperação.
    5. O jsonb também suporta indexação, o que pode ser uma vantagem significativa.

    Em geral, deve-se preferir o JSONB, a menos que haja necessidades bastante especializadas, como suposições herdadas sobre a ordenação de chaves de object.

    Outra diferença importante, que não foi mencionada em nenhuma das respostas acima, é que não existe um operador de igualdade para o tipo json , mas existe um para o jsonb .

    Isso significa que você não pode usar a palavra-chave DISTINCT ao selecionar esse tipo de json e / ou outros campos de uma tabela (você pode usar DISTINCT ON , mas nem sempre é possível devido a casos como este ).