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.
Un retour de Figma sur une architecture de scaling de Postres
Un article que j'ai écrit pour parler de la hype autour des bases de données vectorielles et de pourquoi il vaut mieux utiliser une base de données classique avec fonctionnalité de recherche vectorielle comme Elasticsearch ou Postgres.
Une solution alternative à Redis avec une compatibilité API.
Ils promettent de meilleurs performances et moins de consommation de ressources.
Une base de données orientée Document comme Mongo DB mais construite avec Postgres.
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 article qui compare différentes bases de données vectorielles pour stocker les embeddings des LLMs et faire de la recherche sémantique.
A noter que si vous avez déjà Postgres ou Elasticsearch, les deux proposent un mode vectoriel.
Les bases de données dédiées aux vecteurs comme Qdrant ou Pinecone ne sont vraiment intéressantes que pour des gros volumes (> 100 000 vecteurs)
Un article qui parle des uuidv7 qui comportent une composante temporelle pour être triable par défaut tout étant utilisables dans des systèmes distribués car uniques.
Les performances sont bien supérieures et ça vient du fait qu'ils possèdent une partie aléatoire moins importante (en plus du fait qu'ils soient triable)
Le comité ISO a terminé de travailler sur la norme SQL 2023.
Au programme quelques améliorations du langage (qui étaient déjà supportées dans de nombreuses DB comme Postgres par exemple) mais surtout l'introduction du support du JSON et des graphes.
Par exemple les chemins seront simplement accessible avec des "."
// {"foo": {"bar": [100, 200, 300]}, ...}
SELECT t.j.foo.bar[2], ... FROM table ...Un nouveau type de base de données qui émerge avec l'IA: la base de données vectorielle
En IA, on représente les données du monde réel sous la forme de vecteurs à N dimensions. Concrètement ce sont des tableaux de nombres à virgules.
Ce genre de base de donnée permet ensuite de rechercher plus efficacement des vecteurs qui sont proches par exemple.
Un exemple de recherche de contexte similaire lors d'une question posée à GPT3 https://docs.pinecone.io/docs/gen-qa-openai
Un retour d'expérience sur l'utilisation de Cassandra à un très haut niveau chez Discord.
Des problèmes de maintenance majoritairement liés à la manière dont ils utilisaient Cassandra car des ralentissements en lecture sur un noeud impactaient tout le cluster car la lecture/écriture se fait en quorum.
La "compaction" (réindexation) des tables par Cassandra et le GC de la JVM causaient aussi des problèmes de latence.
Ils ont décidé de migrer toutes leurs DB vers ScyllaDB qui est compatible Cassandra mais en C++ donc plus rapide et pas de GC!
Il n'ont pas réglé leur problème qu'avec une nouvelle base de données mais aussi avec des middleware de cache écrit en Rust pour la performance C++ et la sureté mémoire.
La migration fut aussi très compliqué et les premières prévisions étaient extrèmement longues (3 mois) mais la encore un rewrite du connecteur en Rust sauve la mise (9 jours!)
Conclusions:
- plus de stabilité
- 177 noeuds Cassandra à 72 ScyllaDB
- latence p99 40-125ms avec Cassandra et 15ms avec ScyllaDB
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)
Une base de donnée type Graph basée sur du JSON.
Ils affichent des performances équivalentes voir meilleurs que MongoDB et Postgres sur des opérations tels que:
- single write
- single read
Sinon côté features d'une DB graph, à priori ils font beaucoup mieux que Neo4J, le principal concurrent.
Leur langage de recherche ressemble à du pseudo-code:
FOR doc IN users
FILTER doc._key == "phil"
RETURN doc
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)
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/41renvoi le profil maisyoursite.com/users/42renvoi 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)
Un REX sur les limites de MongoDB.
Concrètement dans le cas de Malt, MongoDB leur a permis d'itérer rapidement au début mais par la suite son utilisation a ralenti les développements et le fonctionnement de l'application.
A noter que l'article porte beaucoup sur les anciennes versions de MongoDB, sans les transactions ou le mot clé $lookup.
Dans les problèmes rencontrés:
- le langage de requête en JSON qui n'est pas aussi clair que du SQL
- la modélisation nosql qui implique beaucoup de dénormalisation et de duplication
- la cohérence des données et les jointures qui doivent se faire dans le code
Bref, comme d'habitude il faut utiliser la bonne base de donnée pour le bon problème et lorsqu'il s'agit de la modélisation d'un système relationnel (90% des applications) alors une base de données relationnel est de mise.
Un article qui explique pas à pas le fonctionnement d'une base de données relationnelle.
Il utilise l'algèbre relationnel pour décrire chaque opération.
Dans une DB relationnelle, chaque ligne peut-être considérée comme un vecteur à N dimensions (les dimensions sont les colonnes).
"Adrien", 29, "Minsk" est un vecteur à 3 dimension (nom, age, ville) qui représente une personne.
A partir du la on peut dérouler toutes les opérations comme la projection (SELECT), la selection (WHERE), le produit vectoriel (JOIN)
Une base de données pee-to-peer, c-a-d qui permet de communiquer avec d'autres clients pour se synchroniser sur l'état commun partagé.
ça m'a l'air plutôt compliqué à gérer, surtout avec des clients malicieux mais par contre le côté offline first est toujours bon à prendre :-)
(Merci Pierre pour le partage)