{"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\/es\/postgres-jsonb-and-nosql\/","title":{"rendered":"Comparaci\u00f3n de Postgres JSONB con NoSQL"},"content":{"rendered":"

La realidad es que las bases de datos est\u00e1n convergiendo y, en los \u00faltimos a\u00f1os, se est\u00e1 haciendo a\u00fan m\u00e1s dif\u00edcil se\u00f1alar cu\u00e1les son los mejores escenarios para cada almac\u00e9n de datos sin un conocimiento profundo de c\u00f3mo funcionan las cosas bajo el cap\u00f3.\u00a0<\/span><\/p>\n

Postgres ha sido mi RDBMS favorito durante a\u00f1os, y estoy encantado con la creciente popularidad de su soporte JSONB. En mi opini\u00f3n personal, ayudar\u00e1 a que los desarrolladores est\u00e9n m\u00e1s familiarizados con todas las ventajas de almacenar datos como JSON en lugar de como simples tablas.<\/span><\/p>\n

Sin embargo, he visto a mucha gente presentando inadvertidamente Postgres 11 como \"El Nuevo NoSQL\" o que no necesitan ning\u00fan Base de datos NoSQL<\/a> puesto que ya utilizan Postgres. En este art\u00edculo, me gustar\u00eda abordar las principales diferencias y casos de uso.<\/span><\/p>\n

Si no tiene tiempo de leer todo el art\u00edculo, resumir\u00e9 los resultados m\u00e1s importantes en la conclusi\u00f3n.<\/span><\/p>\n

 <\/p>\n

Modelizaci\u00f3n de datos: RDBMS y bases de datos de documentos<\/b><\/h2>\n

Todos estamos familiarizados con el coste de una operaci\u00f3n JOIN en un RDBMS a escala: Si tienes 1 Mill\u00f3n de usuarios con 10 preferencias cada uno, entonces para traer a este usuario a la memoria, suponiendo que est\u00e1s usando un framework ORM (<\/span>Mapeo Objeto-Relacional<\/span>) tendr\u00e1 que hacer un join con una tabla de USER_PREFERENCES con 10 millones de filas.\u00a0<\/span><\/p>\n

En el mundo real, los usuarios tambi\u00e9n suelen estar asociados a muchas otras entidades, lo que empeorar\u00e1 a\u00fan m\u00e1s la situaci\u00f3n y obligar\u00e1 a los desarrolladores a decidir qu\u00e9 relaciones deben ser perezosas o ansiosas. Hoy en d\u00eda, todos los RDBMS disponen de muchas optimizaciones para el escenario anterior, pero modelar los datos de la forma en que lo hemos venido haciendo durante los \u00faltimos 30 a\u00f1os es definitivamente sub\u00f3ptima.\u00a0<\/span><\/p>\n

Una de las razones por las que RDBMS se hizo tan bueno en el manejo de transacciones es exactamente por la limitaci\u00f3n de su modelo de datos: \u00bfTiene sentido almacenar un pedido si no hay art\u00edculos en \u00e9l? A\u00fan as\u00ed, me veo obligado a crear una transacci\u00f3n para guardar esta \"unidad \u00fanica\" repartida entre al menos dos tablas: <\/span>PEDIR<\/b> y <\/span>\u00cdTEM_ORDEN<\/b>.<\/span><\/p>\n

Veamos un escenario a\u00fan m\u00e1s com\u00fan: c\u00f3mo se puede almacenar un usuario en una base de datos de documentos frente a un RDBMS:<\/span><\/p>\n

\"\"<\/p>\n

En una base de datos de documentos, las entidades con fuertes relaciones suelen almacenarse en una \u00fanica estructura. En este enfoque, casi no hay coste adicional para cargar cosas como preferencias y permisos, mientras que en un modelo relacional requerir\u00eda al menos 2 uniones.<\/span><\/p>\n

\u00a0Ahora, ampliemos este ejemplo a un caso sencillo de comercio electr\u00f3nico:<\/span><\/p>\n

\"\"<\/p>\n

 <\/p>\n

En el ejemplo anterior, una base de datos de documentos no necesitar\u00eda ning\u00fan JOIN para listar usuarios y productos. Para los pedidos, sin embargo, podr\u00eda necesitar una o dos, lo que es totalmente aceptable. El mismo modelo en un RDBMS requerir\u00eda al menos ~12 tablas:<\/span><\/p>\n

\"\"<\/p>\n

Utilizando nuestro ejemplo anterior, puede observar que los JOIN son esenciales para un RDBMS, mientras que en una base de datos de documentos se utilizan con menos frecuencia. Lo mismo ocurre con las transacciones o las operaciones en cascada, ya que la mayor\u00eda de las entidades relacionadas se almacenan en un \u00fanico documento.<\/span><\/p>\n

Algunas de las bases de datos NoSQL m\u00e1s famosas todav\u00eda no soportan JOINs correctamente. Afortunadamente, este no es el caso aqu\u00ed. Couchbase incluso soporta <\/span>UNIONES ANSI<\/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
S\u00e9 que es posible que haya visto esta explicaci\u00f3n sobre el modelado de datos para RDBMS vs modelado de datos para NoSQL antes, pero tengo que hacer hincapi\u00e9 en que a medida que cada base de datos est\u00e1 optimizado para un modelo de datos espec\u00edfico, y que jugar\u00e1 un papel importante durante las pruebas de rendimiento.\u00a0<\/span><\/p>\n
 <\/p>\n
El mito del silo<\/b><\/h2>\n
Como el usuario y el nombre del producto raramente cambiar\u00e1n, podr\u00eda simplemente almacenarlos ambos en la entidad Pedidos para evitar unos cuantos JOINS, esta es una estrategia com\u00fan en Bases de datos NoSQL<\/a>pero no se aplica estrictamente:<\/span><\/p>\n
\"\"<\/p>\n
El almacenamiento en cach\u00e9 de datos en otras entidades puede mejorar significativamente el rendimiento de tus consultas a escala, pero hay algunas contrapartidas: Si tienes que almacenar en cach\u00e9 estos datos en m\u00faltiples partes de tu sistema, cada vez que estos datos cambien tendr\u00e1s que ejecutar unas cuantas actualizaciones para \"mantener los datos sincronizados\".\u00a0<\/span><\/p>\n
He visto a muchos desarrolladores experimentados utilizar esto como un inconveniente de las bases de datos de documentos, y siempre tengo que recordarles que se podr\u00eda tener exactamente el mismo problema en un RDBMS.\u00a0<\/span><\/p>\n
 <\/p>\n
Postgres JSONB Tipo de columna<\/b><\/h2>\n
En Postgres, JSONB es un tipo especial de columna que puede almacenar JSON en un formato optimizado para lecturas:<\/span><\/p>\n
CREATE TABLE my_table (\u00a0\u00a0id integer NOT NULL,\u00a0\u00a0data jsonb);<\/pre>\n
Como se indica en este <\/span>v\u00eddeo<\/span><\/a>Si bien es cierto que el almacenamiento de datos en una columna JSONB tiene algunas penalizaciones de rendimiento, la base de datos tiene que analizar el JSON para almacenarlo en un formato optimizado para la lectura, lo que parece una compensaci\u00f3n justa.<\/span><\/p>\n
NOTA:<\/b> Ignoremos la columna JSON de Postgres por ahora, ya que incluso la documentaci\u00f3n de Postgres indica que, en general, deber\u00edas elegir JSONB en lugar del tipo de columna JSON.<\/span><\/p>\n
En teor\u00eda, incluso se puede emular una base de datos de documentos en Postgres utilizando una columna JSONB para todas las entidades anidadas:<\/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
Manipulaci\u00f3n de datos<\/span><\/h2>\n
 <\/p>\n
Aqu\u00ed es donde las cosas empiezan a ponerse realmente interesantes: En primer lugar, Postgres no sigue exactamente la <\/span>Normas SQL:2016<\/span><\/a> (<\/span>ISO\/IEC 9075:2016<\/b><\/a>). Esto no es necesariamente algo malo, ya que las consultas en esta especificaci\u00f3n pueden ser f\u00e1cilmente bastante grandes, pero sigue siendo algo a tener en cuenta.<\/span><\/p>\n
Siempre me gusta destacar los est\u00e1ndares porque las bases de datos NoSQL ya han recorrido este camino antes, y hoy en d\u00eda tenemos docenas de lenguajes diferentes y una importante inversi\u00f3n en refactorizaci\u00f3n si quieres migrar de una NoSQL a otra.\u00a0<\/span><\/p>\n
Ojal\u00e1, <\/span>SQL<\/span><\/a> vino al rescate, el padre del propio SQL, Don Chamberlin, <\/span>escribi\u00f3 un libro sobre ello<\/span><\/a> el a\u00f1o pasado. En esta sesi\u00f3n, comparar\u00e9 las funciones y operadores JSON de Postgress con una implementaci\u00f3n de SQL++ llamada N1QL, que es el lenguaje de consulta que utilizamos en Couchbase.<\/span><\/p>\n
Insertos<\/span><\/h3>\n
Las inserciones son lo que cabr\u00eda esperar, la principal diferencia entre la sintaxis de Postgres y N1QL es que en la primera, s\u00f3lo unas pocas columnas de una fila contendr\u00e1n una cadena codificada en JSON, mientras que en la segunda, todo el documento es un 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
Actualizaciones<\/span><\/h3>\n
Empecemos con una actualizaci\u00f3n muy sencilla<\/span><\/p>\n
Postgres:<\/span><\/h4>\n
update users set address = jsonb_set(address, '{state}', '\"California\"') WHERE address->'state' = '\"CA\"';<\/pre>\n
En la sintaxis de Postgres, las cadenas deben especificarse entre comillas dobles y simples ('\"CA\"'), mientras que los literales deben ir entre comillas simples ('false' o '123').\u00a0<\/span><\/p>\n
Couchbase:<\/span><\/h4>\n
update `test` set address.state = 'California' where address.state = 'CA' and type = 'users'<\/pre>\n
En Couchbase no existe un concepto similar al de tabla, por lo que diferenciamos los documentos seg\u00fan un \"<\/span>tipo<\/b>\", que en este caso debe ser igual a \"<\/span>usuarios<\/b>\". El resto de la consulta es similar al SQL est\u00e1ndar, o si vienes del mundo Java, es casi la misma sintaxis que JPA JPQL.<\/span><\/p>\n
Intentemos un ejemplo m\u00e1s complejo en el que a\u00f1adimos una nueva entrada a la casa, actualizamos el c\u00f3digo postal y eliminamos el rol ADMIN del usuario 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
Las consultas Postgres pueden volverse f\u00e1cilmente demasiado complejas si necesitas manipular el JSON. En algunos casos, incluso <\/span>tienen que crear funciones<\/span><\/a> s\u00f3lo para ejecutar algunas actualizaciones b\u00e1sicas. Para m\u00ed, esto es se\u00f1al de que a\u00fan necesitamos algunas mejoras en el lenguaje 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
Incluso si usted no est\u00e1 familiarizado con N1QL puede entender claramente lo que est\u00e1 pasando en la consulta anterior, N1QL tiene <\/span>docenas de funciones s\u00f3lo para tratar matrices<\/span><\/a>.<\/span><\/p>\n
 <\/p>\n
SELECCIONE<\/span><\/h3>\n
Como la selecci\u00f3n de datos es un tema extenso, vamos a dividirlo en sesiones m\u00e1s peque\u00f1as:<\/span><\/p>\n
<\/h4>\n
Consulta de datos sencillos<\/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
La magia <\/span>@><\/strong> te permite emparejar f\u00e1cilmente un par clave-valor o un objeto dentro de tu JSON. De hecho, hace que sea m\u00e1s f\u00e1cil hacer coincidir cosas en JSON, aunque hay algunas cosas que debes tener en cuenta:<\/span><\/p>\n