Comment savoir si mes écritures en continu bloquent ma base de données?

[Lily72]

Salut à tous, je me pose une question depuis que j’ai commencé à travailler sur un petit projet perso. J’ai une appli qui enregistre des données de capteurs en temps réel, et je stocke tout dans une base de données relationnelle classique. Mais en regardant les logs, je me demande si je ne suis pas en train de créer un goulot d’étranglement sans m’en rendre compte, surtout avec ces écritures en continu. Est-ce que certains d’entre vous ont déjà été dans ce cas et ont ressenti ce doute sur le dimensionnement ?

[Paul15]

Pour moi le premier réflexe est de regarder le débit d écriture et la latence moyenne par écriture puis de le comparer au plafond théorique de ta base et du système autour. Un goulot peut venir du journal WAL de la concurrence sur les index du réseau ou du nombre de connexions. Le dimensionnement se joue sur le débit maximal que ta DB peut encaisser sans bloquer les Worker. Mesure ce que tu peux mesurer IOPS latences 95e et 99e temps passé en verrou et temps d attente sur les files de commit. Si les chiffres restent bons mais que les logs montrent des pics regarde le batching et le commit groupé il faut aussi vérifier s il y a des verrous sur des lignes fréquemment mises à jour et le coût des index.

[CharlesM]

Je dirais que croire tout de suite a un goulot sur le dimensionnement sans mesures c est rapide Tu as mesuré les latences hors pics et l IOPS réel

[Kenneth39]

Ca peut etre stressant de voir les logs et de se dire qu on a mal dimensionne mais parfois c est normal Avec des capteurs qui ecrivent en continu le systeme peut monter dans des etats bizarres puis se stabiliser Le dimensionnement batching la durabilite et les choix d architecture peuvent influencer l impression que tout est bloque Le plus utile c est de traquer les pics et de les relier a des evenements concrets batching ecriture en batch index qui saute rotation des logs

[WilliamG]

C est ecrit vite c est pas un gros mot c est juste le debit qui compte et ce que la DB peut supporter sans te faire attendre les utilisateurs

[MarkZM]

En reformulant ce que tu demandes ce nest pas tant une question de est ce que c est un goulot mais de comment on declare le debit soutenu les latences de commit et l impact du dimensionnement sur l experience utilisateur La reponse depend du debit de latence de batching et de l architecture autour On peut tester avec une charge croissante et observer les temps de reponse

[Emma63]

Et peut etre qu on reagit comme si le dimensionnement etait le seul enjeu On peut envisager une approche hybride une couche ecriture tamponnee ou du partitionnement Bref on ne tranche pas tout de suite dimensionnement