Kafka est rapide — mais j’utiliserai Postgres
(topicpartition.io)Argument central
L’industrie tech se divise en deux camps :
- Camp 1 : adopter sans discernement des stacks techniques modernes et complexes en courant après les mots à la mode
- Camp 2 : n’utiliser que ce qui est nécessaire, avec une approche sensée et pragmatique
L’auteur soutient que, dans la plupart des cas, on peut utiliser Postgres à la place de Kafka comme système de pub/sub et de file d’attente.
Résultats des benchmarks
Performances en pub/sub
- Nœud unique 4 vCPU : 5 036 messages écrits par seconde, 25 183 lus par seconde (fan-out x5)
- Réplication sur 3 nœuds 4 vCPU : débit similaire maintenu, avec une légère hausse de la latence
- Nœud unique 96 vCPU : 243 000 messages par seconde, vitesse de lecture de 1.16 GiB/s
Performances en file d’attente (Queue)
- Nœud unique 4 vCPU : 2 885 messages par seconde
- Nœud unique 96 vCPU : 20 144 messages par seconde
Points clés
- Progrès du matériel : avec le matériel moderne (CPU 192 cœurs, 4 To de RAM), un nœud unique est devenu extrêmement puissant
- Renaissance de Postgres : le mouvement « utilisons Postgres pour tout » prend de l’ampleur
- Pragmatisme : même une énorme startup comme OpenAI utilise encore une instance Postgres unique
- Coût organisationnel : introduire une nouvelle technologie entraîne des coûts d’apprentissage, d’exploitation, de monitoring, etc.
Conclusion
« Utilisons simplement Postgres jusqu’à ce qu’il casse »
La plupart des entreprises n’ont besoin que d’un débit de quelques Mo par seconde, ce que Postgres peut largement absorber. Le message est qu’il faut n’introduire des systèmes distribués complexes que lorsqu’ils deviennent réellement nécessaires.
8 commentaires
Kafka est lent...
Je ne sais pas si Bubble est adapté à toutes les situations, mais j’ai souvent vu des cas où l’on utilisait Kafka alors qu’il n’était pas nécessaire, ce qui entraînait une charge de travail supplémentaire.
Encore un éloge de PostgreSQL...
L’important, c’est d’utiliser ce dont on a besoin
et d’avoir une architecture qui permette de changer de manière flexible.
En voyant ça, je repense à la recommandation PostgreSQL la plus extrême.
Oh, comment avez-vous modifié le titre comme vous le vouliez ?
Le titre ?
Je n’ai pourtant pas particulièrement cherché à en faire des tonnes.
https://news.hada.io/guidelines
> Prise en charge de Markdown
> Elle est disponible à la fois dans le corps du texte et dans les commentaires.
> Elle suit par défaut la spécification CommonMark.
> Les images ne sont pas prises en charge.
En plus, dans le cas d’une URL GeekNews, il semble qu’une icône s’affiche devant le titre du lien.
Je vais juste continuer à utiliser SQLite jusqu’à ce qu’il casse.