{"id":7351,"date":"2019-08-06T06:57:07","date_gmt":"2019-08-06T13:57:07","guid":{"rendered":"https:\/\/www.couchbase.com\/blog\/?p=7351"},"modified":"2023-07-26T12:09:43","modified_gmt":"2023-07-26T19:09:43","slug":"postgres-jsonb-and-nosql","status":"publish","type":"post","link":"https:\/\/www.couchbase.com\/blog\/pt\/postgres-jsonb-and-nosql\/","title":{"rendered":"Compara\u00e7\u00e3o do Postgres JSONB com o NoSQL"},"content":{"rendered":"

A realidade \u00e9 que os bancos de dados est\u00e3o convergindo e, nos \u00faltimos anos, est\u00e1 se tornando cada vez mais dif\u00edcil apontar quais s\u00e3o os melhores cen\u00e1rios para cada armazenamento de dados sem uma compreens\u00e3o profunda de como as coisas funcionam nos bastidores.\u00a0<\/span><\/p>\n

O Postgres tem sido meu RDBMS favorito h\u00e1 anos, e estou entusiasmado com a crescente popularidade de seu suporte a JSONB. Na minha opini\u00e3o, isso ajudar\u00e1 os desenvolvedores a se familiarizarem mais com todas as vantagens de armazenar dados como JSON em vez de tabelas antigas.<\/span><\/p>\n

No entanto, j\u00e1 vi muitas pessoas apresentarem inadvertidamente o Postgres 11 como \"O novo NoSQL\" ou que n\u00e3o precisam de nenhum Banco de dados NoSQL<\/a> pois j\u00e1 est\u00e3o usando o Postgres. Neste artigo, gostaria de abordar as principais diferen\u00e7as e os casos de uso.<\/span><\/p>\n

Se voc\u00ea n\u00e3o tiver tempo para ler o artigo inteiro, resumirei as descobertas mais importantes na conclus\u00e3o.<\/span><\/p>\n

 <\/p>\n

Modelagem de dados: RDBMS e bancos de dados de documentos<\/b><\/h2>\n

Todos n\u00f3s conhecemos o custo de uma opera\u00e7\u00e3o JOIN em um RDBMS em escala: Se voc\u00ea tiver 1 milh\u00e3o de usu\u00e1rios com 10 prefer\u00eancias cada, ent\u00e3o, para trazer esse usu\u00e1rio de volta \u00e0 mem\u00f3ria, supondo que voc\u00ea esteja usando uma estrutura ORM (<\/span>Mapeamento objeto-relacional<\/span>), voc\u00ea precisar\u00e1 fazer uma jun\u00e7\u00e3o com uma tabela de USER_PREFERENCES com 10 milh\u00f5es de linhas.\u00a0<\/span><\/p>\n

Em um cen\u00e1rio do mundo real, os usu\u00e1rios geralmente tamb\u00e9m est\u00e3o associados a muitas outras entidades, o que tornar\u00e1 esse cen\u00e1rio ainda pior e for\u00e7ar\u00e1 os desenvolvedores a decidir quais relacionamentos devem ser pregui\u00e7osos ou ansiosos. Atualmente, todos os RDBMS j\u00e1 t\u00eam muitas otimiza\u00e7\u00f5es para o cen\u00e1rio acima, mas modelar os dados da forma como temos feito nos \u00faltimos 30 anos definitivamente n\u00e3o \u00e9 o ideal.\u00a0<\/span><\/p>\n

Um dos motivos pelos quais o RDBMS se tornou t\u00e3o bom em lidar com transa\u00e7\u00f5es \u00e9 exatamente a limita\u00e7\u00e3o de seu modelo de dados: Faz sentido armazenar um pedido se n\u00e3o houver itens nele? Ainda assim, sou obrigado a criar uma transa\u00e7\u00e3o para salvar essa \"unidade \u00fanica\" espalhada entre pelo menos duas tabelas: <\/span>ORDEM<\/b> e <\/span>ORDER_ITEM<\/b>.<\/span><\/p>\n

Vejamos um cen\u00e1rio ainda mais comum: como um usu\u00e1rio pode ser armazenado em um banco de dados de documentos em compara\u00e7\u00e3o com um RDBMS:<\/span><\/p>\n

\"\"<\/p>\n

Em um banco de dados de documentos, as entidades com relacionamentos fortes geralmente s\u00e3o armazenadas em uma \u00fanica estrutura. Nessa abordagem, quase n\u00e3o h\u00e1 custo adicional para carregar itens como prefer\u00eancias e permiss\u00f5es, enquanto em um modelo relacional isso exigiria pelo menos duas uni\u00f5es.<\/span><\/p>\n

\u00a0Agora, vamos expandir esse exemplo para um caso de uso simples de com\u00e9rcio eletr\u00f4nico:<\/span><\/p>\n

\"\"<\/p>\n

 <\/p>\n

No exemplo acima, um banco de dados de documentos n\u00e3o precisaria de nenhum JOIN para listar usu\u00e1rios e produtos. No entanto, para os pedidos, ele pode precisar de um ou dois, o que \u00e9 totalmente aceit\u00e1vel. O mesmo modelo em um RDBMS exigiria pelo menos cerca de 12 tabelas:<\/span><\/p>\n

\"\"<\/p>\n

Usando nosso exemplo acima, voc\u00ea pode notar que os JOINs s\u00e3o essenciais para um RDBMS, enquanto no banco de dados de documentos eles s\u00e3o usados com menos frequ\u00eancia. O mesmo se aplica a transa\u00e7\u00f5es ou opera\u00e7\u00f5es em cascata, pois a maioria das entidades relacionadas \u00e9 armazenada em um \u00fanico documento.<\/span><\/p>\n

Alguns dos bancos de dados NoSQL mais famosos do mercado ainda n\u00e3o oferecem suporte adequado a JOINs. Felizmente, esse n\u00e3o \u00e9 o caso aqui. O Couchbase suporta at\u00e9 mesmo <\/span>ANSI JOINs<\/span><\/a>:\u00a0<\/span><\/p>\n

SELECT DISTINCT route.destinationairportFROM `travel-sample` airport JOIN `travel-sample` route\u00a0 \r\n     ON airport.faa = route.sourceairport\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\r\n       AND route.type = \"route\"\r\nWHERE airport.type = \"airport\"\u00a0\u00a0\r\n     AND airport.city = \"San Francisco\"\u00a0\u00a0\r\n     AND airport.country = \"United States\";<\/pre>\n
Sei que voc\u00ea j\u00e1 deve ter visto essa explica\u00e7\u00e3o sobre a modelagem de dados para RDBMS e a modelagem de dados para NoSQL, mas preciso enfatizar isso, pois cada banco de dados \u00e9 otimizado para um modelo de dados espec\u00edfico, e isso ter\u00e1 um papel importante durante os testes de desempenho.\u00a0<\/span><\/p>\n
 <\/p>\n
O mito do silo<\/b><\/h2>\n
Como o usu\u00e1rio e o nome do produto raramente ser\u00e3o alterados, voc\u00ea poderia simplesmente armazen\u00e1-los na entidade Orders para evitar alguns JOINS. Bancos de dados NoSQL<\/a>mas isso n\u00e3o \u00e9 rigorosamente aplicado:<\/span><\/p>\n
\"\"<\/p>\n
O armazenamento em cache de dados em outras entidades pode melhorar significativamente o desempenho da consulta em escala, mas h\u00e1 algumas compensa\u00e7\u00f5es: Se voc\u00ea tiver que armazenar em cache esses dados em v\u00e1rias partes do sistema, sempre que esses dados forem alterados, ser\u00e1 necess\u00e1rio executar algumas atualiza\u00e7\u00f5es para \"manter os dados sincronizados\".\u00a0<\/span><\/p>\n
J\u00e1 vi muitos desenvolvedores experientes usarem isso como uma desvantagem dos bancos de dados de documentos, e sempre tenho que lembr\u00e1-los de que voc\u00ea poderia ter exatamente o mesmo problema em um RDBMS.\u00a0<\/span><\/p>\n
 <\/p>\n
Tipo de coluna JSONB do Postgres<\/b><\/h2>\n
No Postgres, JSONB \u00e9 um tipo especial de coluna que pode armazenar JSON em um formato otimizado para leituras:<\/span><\/p>\n
CREATE TABLE my_table (\u00a0\u00a0id integer NOT NULL,\u00a0\u00a0data jsonb);<\/pre>\n
Conforme declarado neste <\/span>v\u00eddeo<\/span><\/a>Embora haja algumas penalidades de desempenho ao armazenar dados em uma coluna JSONB, o banco de dados precisa analisar o JSON para armazen\u00e1-lo em um formato otimizado para leituras, o que parece ser uma compensa\u00e7\u00e3o justa.<\/span><\/p>\n
OBSERVA\u00c7\u00c3O:<\/b> Vamos ignorar a coluna JSON do Postgres por enquanto, pois at\u00e9 mesmo o documento do Postgres afirma que voc\u00ea deve, em geral, escolher JSONB em vez do tipo de coluna JSON.<\/span><\/p>\n
Em teoria, voc\u00ea pode at\u00e9 emular um banco de dados de documentos no Postgres usando uma coluna JSONB para todas as entidades aninhadas:<\/span><\/p>\n
CREATE TABLE users (\u00a0\u00a0\r\n     id integer NOT NULL,\u00a0\u00a0\r\n     name varchar,\u00a0\u00a0username varchar,\u00a0\u00a0\r\n     address jsonb,\u00a0\u00a0\r\n     preferences jsonb,\u00a0\u00a0\r\n     permissions jsonb\r\n);<\/pre>\n
 <\/p>\n
Manipula\u00e7\u00e3o de dados<\/span><\/h2>\n
 <\/p>\n
\u00c9 aqui que as coisas come\u00e7am a ficar realmente interessantes: Em primeiro lugar, o Postgres n\u00e3o est\u00e1 seguindo exatamente o padr\u00e3o <\/span>Padr\u00f5es SQL:2016<\/span><\/a> (<\/span>ISO\/IEC 9075:2016<\/b><\/a>). Isso n\u00e3o \u00e9 necessariamente uma coisa ruim, pois as consultas nessa especifica\u00e7\u00e3o podem facilmente ficar muito grandes, mas ainda assim \u00e9 algo a se ter em mente.<\/span><\/p>\n
Eu sempre gosto de destacar os padr\u00f5es porque os bancos de dados NoSQL j\u00e1 passaram por esse caminho antes, e hoje temos dezenas de linguagens diferentes e um investimento significativo em refatora\u00e7\u00e3o se voc\u00ea quiser migrar de um NoSQL para outro.\u00a0<\/span><\/p>\n
Espero que sim, <\/span>SQL++<\/span><\/a> veio em seu socorro, o pai do pr\u00f3prio SQL, Don Chamberlin, <\/span>escreveu um livro sobre isso<\/span><\/a> no ano passado. Nesta sess\u00e3o, compararei as fun\u00e7\u00f5es e os operadores JSON do Postgress com uma implementa\u00e7\u00e3o do SQL++ chamada N1QL, que \u00e9 a linguagem de consulta que usamos no Couchbase.<\/span><\/p>\n
Inser\u00e7\u00f5es<\/span><\/h3>\n
As inser\u00e7\u00f5es s\u00e3o o que voc\u00ea espera, a principal diferen\u00e7a entre a sintaxe do Postgres e a do N1QL \u00e9 que, no primeiro, apenas algumas colunas de uma linha conter\u00e3o strings codificadas em JSON, enquanto no segundo, todo o documento \u00e9 um JSON:<\/span><\/p>\n
Postgres:<\/span><\/h4>\n
INSERT INTO users VALUES (1, 'First User', 'user1',\u00a0\u00a0 \r\n'{\"streetName\": \"Wayside Lane\", \"houseNumber\": 3104, \"zipcode\": \"94538\", \"city\": \"Fremont\", \"state\": \"CA\", \"country\": \"US\", \"entrances\": [{\"name\" : \"main\"}] }',\u00a0\u00a0\r\n'[{\"name\": \"lang\", \"value\": \"en\"},{\"name\": \"notification\", \"value\":\"emailOnly\"},\u00a0{{\"name\":\"timezone\",\"value\": \"GMT+2\"}]',\u00a0\r\n'{\"groups\":[\"MARKETING\"], \"roles\": [\"ADMIN\", \"PREMIUM_USER\"]}');<\/pre>\n
 <\/p>\n
Couchbase:<\/span><\/h4>\n
INSERT INTO `test` ( KEY, VALUE ) VALUES ( \"1\", {\r\n  \"type\": \"users\",\r\n  \"name\": \"First User\",\r\n  \"username\": \"user1\",\r\n  \"address\": {\r\n    \"streetName\": \"Wayside Lane\", \r\n      \"houseNumber\": 3104, \r\n        \"zipcode\": 94538, \r\n        \"city\": \"Fremont\", \r\n        \"state\": \"CA\", \r\n        \"country\": \"US\", \r\n        \"entrances\": [{\"name\" : \"main\"}] },\r\n  \"preferences\": [\r\n    {\"name\": \"lang\", \"value\": \"en\"},\r\n    {\"name\": \"notification\", \"value\":\"emailOnly\"},\r\n    {\"name\":\"timezone\",\"value\": \"GMT+2\"}],\r\n  \"permissions\": {\r\n    \"groups\":[\"MARKETING\"], \r\n    \"roles\": [\"ADMIN\", \"PREMIUM_USER\"]}\r\n});\r\n<\/pre>\n
 <\/p>\n
Atualiza\u00e7\u00f5es<\/span><\/h3>\n
Vamos come\u00e7ar com uma atualiza\u00e7\u00e3o muito simples<\/span><\/p>\n
Postgres:<\/span><\/h4>\n
update users set address = jsonb_set(address, '{state}', '\"California\"') WHERE address->'state' = '\"CA\"';<\/pre>\n
Na sintaxe do Postgres, as cadeias de caracteres devem ser especificadas entre aspas duplas e simples ('\"CA\"'), enquanto os literais devem estar entre aspas simples (\"false\" ou \"123\").\u00a0<\/span><\/p>\n
Couchbase:<\/span><\/h4>\n
update `test` set address.state = 'California' where address.state = 'CA' and type = 'users'<\/pre>\n
No Couchbase, n\u00e3o h\u00e1 um conceito semelhante a uma tabela, portanto, diferenciamos os documentos de acordo com um \"<\/span>tipo<\/b>\", que, nesse caso, deve ser igual a \"<\/span>usu\u00e1rios<\/b>\". Todo o restante da consulta \u00e9 semelhante ao SQL padr\u00e3o ou, se voc\u00ea veio do mundo Java, \u00e9 quase a mesma sintaxe do JPA JPQL.<\/span><\/p>\n
Vamos tentar um exemplo mais complexo em que adicionamos uma nova entrada \u00e0 casa, atualizamos o c\u00f3digo postal e removemos a fun\u00e7\u00e3o ADMIN do usu\u00e1rio de destino:<\/span><\/p>\n
Postgres:<\/span><\/h4>\n
UPDATE users\r\n   SET address = jsonb_set( jsonb_set(\r\n\t\t\t\t\taddress::jsonb,\r\n\t\t\t\t\tarray['entrances'],\r\n\t\t\t\t\t(address->'entrances')::jsonb || '{\"name\": \"backyard\"}'::jsonb), \r\n\t\t\t\t '{zipcode}', '94537'),\r\n\t\tpermissions = jsonb_set(permissions, '{roles}', (permissions->'roles') - 'ADMIN')<\/pre>\n
As consultas do Postgres podem facilmente se tornar muito complexas se voc\u00ea precisar manipular o JSON. Em alguns casos, voc\u00ea pode at\u00e9 mesmo <\/span>precisam criar fun\u00e7\u00f5es<\/span><\/a> apenas para executar algumas atualiza\u00e7\u00f5es b\u00e1sicas. Para mim, isso \u00e9 um sinal de que ainda precisamos de alguns aprimoramentos na linguagem de consulta.\u00a0<\/span><\/p>\n
Couchbase:<\/span><\/h4>\n
update `test` set address.zipcode = 94537, \r\n                  address.entrances = ARRAY_APPEND(address.entrances,  {\"name\": \"backyard\"}),\r\n                  permissions.roles = ARRAY_REMOVE(permissions.roles, \"ADMIN\") \r\n<\/pre>\n
Mesmo que n\u00e3o esteja familiarizado com o N1QL, voc\u00ea pode entender claramente o que est\u00e1 acontecendo na consulta acima, pois o N1QL tem <\/span>dezenas de fun\u00e7\u00f5es apenas para lidar com matrizes<\/span><\/a>.<\/span><\/p>\n
 <\/p>\n
SELECTs<\/span><\/h3>\n
Como a sele\u00e7\u00e3o de dados \u00e9 um t\u00f3pico extenso, vamos dividi-lo em sess\u00f5es menores:<\/span><\/p>\n
<\/h4>\n
Consulta de dados simples<\/span><\/h4>\n
Postgres:<\/span><\/h4>\n
select address->'city' from users where address @> '{\"zipcode\": \"94537\"}'\r\nselect * from users where address @> '{\"entrances\":[{\"name\": \"backyard\"}]}'\r\n<\/pre>\n
O m\u00e1gico <\/span>@><\/strong> permite que voc\u00ea combine facilmente um par chave-valor ou um objeto dentro do seu JSON. De fato, ele facilita a correspond\u00eancia de coisas no JSON, embora haja algumas coisas que voc\u00ea deve ter em mente:<\/span><\/p>\n