JSONB com indexação vs. hstore

Estou tentando decidir sobre o design do banco de dados, com o mínimo possível de suposições (sobre como o aplicativo da Web realmente evolui) neste estágio.

Como primeiro passo, entendendo que JOINS são caros, estou considerando um pequeno número de tabelas monolíticas em oposição a um grande número de tabelas menores normalizadas. Como segundo ponto, estou confuso entre o uso de hstore e tabelas regulares e JSONB (com indexação GiST).

AFAIK (sinta-se à vontade para corrigir):

1. Geralmente, no Postgres, o hstore é conhecido por ter um desempenho melhor que outros tipos de dados. Esta apresentação do FOSDEM PGDAY tem algumas estatísticas interessantes (na segunda metade dos slides). https://wiki.postgresql.org/images/b/b4/Pg-as-nosql-pgday-fosdem-2013.pdf

2. Uma vantagem do hstore é a indexação rápida (GiN ou GiST). No entanto, com a indexação JSONB, GiN e GiST também pode ser aplicada aos dados JSON.

3. Este blog de um profissional do 2º Quadrante diz "Nesse momento, provavelmente vale a pena substituir o uso do hstore pelo jsonb em todos os novos aplicativos" (role até o final): http://blog.2ndquadrant.com/postgresql-anti-patterns-unnecessary -jsonhstore-dynamic-columns /

Então, eu gostaria de decidir o seguinte:

1. Para a parte principal (estruturada) dos dados: ela deve estar em algumas tabelas relacionais (relativamente grandes com muitas colunas) ou deve haver um número de armazenamentos de valores-chave usando hstore?
2. Para os dados ad hoc (contribuído / não estruturado pelo usuário), ele deve estar em JSON ou armazenamentos de valor de chave ad hoc no hstore (com as chaves armazenadas em uma das principais tabelas relacionais)?

Os bancos de dados relacionais são projetados em torno de junções e otimizados para fazê-los bem.

A menos que você tenha um bom motivo para não usar um design normalizado, use um design normalizado.

jsonbe coisas hstoreboas para quando você não pode usar um modelo de dados normalizado, como quando o modelo de dados muda rapidamente e é definido pelo usuário.

Se você pode modelá-lo relacionalmente, modele-o relacionalmente. Se não puder, considere json, etc. Se você estiver escolhendo entre json / jsonb / hstore, geralmente escolha jsonb, a menos que tenha um motivo para não fazê-lo.

Foi o que eu disse no meu blog , que aborda apenas esse tópico. Por favor, leia o post completo . O parágrafo que você citou indica que, se você estiver escolhendo uma estrutura dinâmica, deverá escolher jsonb em vez de hstore, mas o restante da postagem do blog é sobre o motivo pelo qual você geralmente prefere modelar de forma relacional, se puder.

Tão. Modele a parte estruturada principal de forma relacional. Se as tabelas forem realmente amplas e com muitas colunas, isso pode ser um sinal de que é necessária uma normalização adicional. Não tenha medo de junções. Aprenda a amar as junções. A junção de muitas tabelas pequenas geralmente será mais rápida do que a consulta e a manutenção de grandes tabelas desnormalizadas. Desnormalize apenas se for necessário para casos específicos e, de preferência, através de visualizações materializadas ... mas não faça isso até que você saiba que precisa e tenha um problema concreto real para resolver.

Para dados contribuídos pelo usuário de forma livre e não estruturada, use jsonb. Ele deve ter um desempenho tão bom quanto o hstore, mas é mais flexível e fácil de trabalhar.

Uma coisa relevante a entender: os índices GiST e GIN, como os usados ​​no jsonb, geralmente são muito menos eficientes do que um índice simples da árvore b. Eles são mais flexíveis, mas um índice de árvore b em uma coluna normal quase sempre será muito, muito mais rápido.