Des exemples d'utilisation de Postgres pour:

• un système de queue
• du pub/sub
• lock de ressources

Après les perfs ne sont pas les mêmes et Redis tiendra beaucoup plus la charge et avec une latence plus faible.

Une explication sur le fonctionnement du stockage de données avec Postgres

Une queue de message construite avec Postgres.

Projet prometteur mais assez récent donc à utiliser avec précaution.

Tout se fait en SQL:

-- creates the queue
SELECT pgmq.create('my_queue');

-- messages are sent as JSON
SELECT * from pgmq.send('my_queue', '{"foo": "bar1"}');

SELECT * FROM pgmq.read('my_queue', 30, 2);
-- or
SELECT pgmq.pop('my_queue');

Un système de queue qui utilise Postgres.

Ils expliquent comment ils ont construit cette gestion des queues et surtout le dépilage des tâches par des workers en présentant la structure des tables et les requêtes.

Ça à l'air chouette mais encore très peinture fraiche donc prudence :-)

Un retour de Figma sur une architecture de scaling de Postres

Un site très complet pour apprendre à mieux utiliser sa DB et comprendre les problèmes de performances pour les régler.

Un service d'hébergement Postgres moderne et à la demande

Un benchmark de requêtage sur des vecteurs d'embeddings dans Postgres avec l'addon pgvector et dans le pure player Pinecone.

Sur un setup équivalent en coût chez Supabase, Postgres est 10x plus rapide avec la même précision.

Donc si on héberge sa propre base Postgres c'est encore moins cher!

A noter que Postgres est beaucoup plus qu'une base vectorielle et qu'on va pouvoir filtrer les résultats avec des WHERE, faire des jointures, etc

Des présentation sur des concepts avancés de Postgres:

• Performance Tuning
• Explaining the Query Optimizer
• Joins and Indexes
• Database hardware
• Scaling opportunities
• Future of Sharding

(Merci Ocav pour le partage)

Un article sur l'insertion spéculative dans Postgres et les améliorations de performances qu'elle apporte.

L'insertion spéculative est faite avec la construction INSERT… ON CONFLICT.

Cette variante vérifie d'abord que l'insert peut être réalisé, ce qui évite la création de "dead tuples" qui sont des lignes n'ayant pu être insérées mais quand présentes jusqu'au prochain garbage collect (vacuum).

Sur une table ayant 1 millions de dead tuples, il y a une différence de perfs de presque 8000% au SELECT ! (0.7 ms vs 54 ms)

Les insert ayant échoués vont aussi incrémenter les ID de transaction et après 200 millions, cela va déclencher le garbage collector pour un nettoyage mais aussi ralentir toute la base de données.

Finalement, tous ces dead tuples consomment aussi de l'espace de stockage.

Bref, il est temps de passer à INSERT… ON CONFLICT DO NOTHING 😄

(Merci Gaël pour le partage)

Un serveur web qui permet d'accèder à une base PostgreSQL directement via une API REST!

Exemples:

• SELECT avec WHERE 👉 GET /people?age=gte.18&student=is.true
• un JOIN sur la table directors 👉 GET /films?select=title,director:directors(id,last_name)

Un framework pour créer des extensions PostgreSQL avec Rust.

Je ne savais pas mais à priori Rust est un langage de choix pour les extensions PostgreSQL maintenant.

C'est un très bon usecase car dans une base de données on a justement besoin de performances et de memory safety

Tous les conseils pour bien choisir sa clé primaire.

Dans la plupart des cas, un entier auto-incrémenté (serial) est suffisant, cependant il a quelques désavantages:

• prédictible: il est facile d'énumérer les ID et de deviner des choses comme le nombre d'utilisateurs sur un site (yoursite.com/users/41 renvoi le profil mais yoursite.com/users/42 renvoi une 404)
• ce n'est pas un standard SQL

Une autre possibilité est d'utiliser un UUID v4 car ceux ci sont totalement aléatoires. Par contre on a d'autres problèmes:

• pas possible de les trier
• beaucoup plus gros que notre entier auto-incrémenté
• leur indexage par la base de donnée est très difficile

C'est pour ça que d'autre types d'UUID sont apparus (voir UUID v7 et ULID), cette dernière génération inclue un timestamp afin de pouvoir les trier par exemple.

L'article termine sur un benchmark sur la vitesse de génération dans PostgreSQL mais aussi de la taille de la table et de son index.

Niveau vitesse, tous sont plus ou moins équivalents à part pour pushid et nanoid qui sont significativement plus lents.

Au niveau de la taille, sans surprise les dernières version d'UUID font augmenter l'espace utilisé.

Un ensemble de guides très complets publiés par Prisma.

Vous trouverez des guides sur:

• le data modeling
• bases de données relationnelles
• bases de données NoSQL document
• PostgreSQL
• MongoDB
• SQLite
• Microsoft SQL Server (nan je déconne y'a presque rien)

Le club Med a profité de la crise covid et de la fermeture de ses 60 villages pour construire une stratégie Data flambant neuve !

Les objectifs principaux étaient d'augmenter les ventes (~2-3% estimés) et d'analyser en détails l'impact des budgets publicité et marketing injectés dans le cycle de vente.

Niveua technique, le groupe voulait de l'analyse temps réel donc il a fallut ingérer les données depuis une douzaine de sources (CRM, ERP, site web , appels téléphoniques, etc) dans un datalake.

Concrètement un broker Kafka reçoit les messages qui proviennent majoritairement d'une base de données DB2 et tout est écrit sur un PostgreSQL ou BigQuery (donc tout chez Google Cloud Platform)

Des outils de Business Intelligence comme Qlikview ou Google Analytics permettent ensuite aux différents métiers d'exploiter la donnée.

Ce que je connaissais pas c'est Zeenea, un catalogue de données pour comprendre quels sont les flux, d'où viennent les données, à quelle moment sont-elles disponibles etc.

Au niveau des volumes, ils annoncent quand même 5 millions d'événements par jour !

Utiliser correctement une base de donnée relationnelle reste un exercice compliqué car il y a beaucoup de subtilité à comprendre.

Le plus important reste le concept d'index de lecture qui sont des structures permettant de retrouver plus rapidement de la donnée en échange d'un temps d'écriture plus long.

Le plan d'exécution des requêtes est aussi très important, l'auteur présente un exemple simple:

-- compute "now() - interval 3 days" then execute a table scan
publish_date < now() - interval '3 days'

-- for each line, compute "publish_date + interval 3 days and compare to now()"

publish_date + interval '3 days' < now()

Dans le deuxième cas, on va devoir récupérer chaque ligne et faire un calcul pour executer la requête. Il ne faut pas oublier que les bases de données relationnelles sont ensemblistes et donc faites pour fonctionner sur des ensembles de lignes plutôt que sur des lignes individuelles.

Un retour d'expérience sur l'utilisation de Timescale DB pour ingérer et traiter de grosses séries temporelles.

TimescaleDB est une extension de PostgreSQL donc on retrouve facilement ses repères.

Une de leur feature extra est la compression optimisée des séries temporelles pour gagner jusqu'à 90% d'espace (!)

Un ensemble d'outils pour PostgreSQL.