Clever Geek Handbook

¿Se necesita Redis o es suficiente PostgreSQL?

imagen



Existe una arquitectura probada que he visto muchas veces para respaldar sus servicios y aplicaciones web:



  • PostgreSQL para almacenamiento de datos
  • Redis para coordinar las colas de trabajos en segundo plano (y algunas operaciones atómicas limitadas)


Redis es fantástico, pero ¿y si te dijera que sus casos de uso más comunes para esta pila en realidad se pueden lograr usando solo PostgreSQL?



Escenario 1: cola de trabajos



Quizás el uso más común de Redis que he visto es coordinar el envío de trabajos desde su servicio web al grupo de trabajadores en segundo plano. La idea es que desee registrar el deseo de hacer algún tipo de trabajo en segundo plano (tal vez con alguna entrada) y asegurarse de que solo uno de sus muchos trabajadores en segundo plano lo ejecute. Redis ayuda con esto porque proporciona un rico conjunto de operaciones atómicas para sus estructuras de datos.



Pero desde el lanzamiento de la versión 9.5, PostgreSQL tiene una función SKIP

LOCKED para la instrucción SELECT… FOR… ( documentación aquí ). Cuando se especifica esta opción, PostgreSQL simplemente ignorará cualquier fila que requiera una espera de liberación de bloqueo.



Veamos este ejemplo desde la perspectiva de un trabajador en segundo plano: 



BEGIN;

WITH job AS (
  SELECT
    id
  FROM
    jobs
  WHERE
    status = 'pending'
  LIMIT 1
  FOR UPDATE SKIP LOCKED
)
UPDATE
  jobs
SET
  status = 'running'
WHERE
  jobs.id = job.id
RETURNING
  jobs.*;

COMMIT;


Cuando se especifica FOR UPDATE SKIP LOCKED, el bloqueo de nivel de fila se establece implícitamente en cualquier fila devuelta por SELECT. Además, dado que especificó SKIP LOCKED, esta declaración no se bloqueará para otra transacción. Si hay otro trabajo listo para ser procesado, será devuelto. No hay preocupación de que varios procesos de trabajo que ejecutan este comando reciban la misma fila debido al bloqueo a nivel de fila.



La mayor advertencia para este método es que si tiene una gran cantidad de trabajadores que intentan ejecutar esta cola, y una gran cantidad de trabajos los está proporcionando, es posible que pasen algún tiempo saltando entre trabajos y tratando de adquirir un candado. En la práctica, la mayoría de las aplicaciones en las que he trabajado tienen menos de una docena de trabajadores en segundo plano y es poco probable que los costos sean significativos.



Escenario 2: Bloques de aplicaciones



Imaginemos que tiene una rutina de sincronización con un servicio de terceros y solo necesita una instancia, que funcione para cualquier usuario en todos los procesos del servidor. Otra aplicación común de Redis que he visto es el bloqueo distribuido.



PostgreSQL también puede lograr esto usando bloqueos de recomendación (bloqueos de aviso). Los bloqueos de aviso le permiten usar el mismo mecanismo de bloqueo que PostgreSQL usa internamente, para sus propios propósitos definidos por la aplicación.



Escenario 3: Pub / Sub



Dejé el ejemplo más genial para el final: enviar eventos a sus clientes activos. Por ejemplo, suponga que necesita notificar a un usuario que tiene un nuevo mensaje disponible para leer. O quizás desee transferir datos al cliente cuando estén disponibles. Normalmente, los websockets son la capa de transporte para estos eventos, mientras que Redis sirve como motor de Pub / Sub.



Sin embargo, a partir de la versión 9, PostgreSQL también proporciona esta funcionalidad con los operadores LISTEN y NOTIFY... Cualquier cliente de PostgreSQL puede suscribirse (ESCUCHAR) a un canal de mensajes específico, que es solo una cadena arbitraria. Cuando cualquier otro cliente envía un mensaje NOTIFICAR a través de este canal, todos los demás clientes suscritos serán notificados. Opcionalmente, puede adjuntar un pequeño mensaje.



Si está utilizando Rails y ActionCable, el uso de PostgreSQL incluso es compatible desde el primer momento.



Aprovechando al máximo PostgreSQL



Redis ocupa fundamentalmente un nicho diferente al de PostgreSQL y sobresale en lo que PostgreSQL no busca. Los ejemplos incluyen el almacenamiento en caché de datos con TTL y el almacenamiento y procesamiento de datos efímeros.



Sin embargo, PostgreSQL tiene mucho más poder de lo que podría esperar cuando lo aborda en términos de otra base de datos SQL o alguna entidad misteriosa que vive detrás de su ORM.



Existe una buena posibilidad de que las cosas para las que está utilizando Redis también resulten buenas para PostgreSQL. Podría valer la pena deshacerse de Redis y ahorrar en costos operativos y complejidad de desarrollo confiando en múltiples servicios de datos.


More articles:


All Articles