Récemment, je construis une API REST dans le cadre d'une affectation où je suis supposé incrémenter un compteur dans la table de la base de données, en supposant que la table n'a qu'une seule colonne, je suis supposé déclencher comme 1000 requêtes par seconde vers cette API REST pour incrémenter le compteur et à la fin, les données doivent être cohérentes, c'est-à-dire que si initialement la valeur du compteur dans DB est 0, alors après l'exécution réussie de 1000 requêtes simultanées, elle devrait être 1000.
Pas de soucis jusqu'à présent, je l'ai réalisé via le verrouillage au niveau des lignes de la base de données, une autre manière pourrait être l'utilisation de transaction (avec l'isolation la plus élevée) autour du code qui incrémente le compteur, mais ce que j'ai observé est que cela est réalisable à maintenir cohérence mais cela se fait au prix d'une latence élevée par exemple, je lance un test Jmeter avec 1000 req / s pendant 5 secondes et toutes les requêtes sont remplies en environ 26 secondes, ce qui est vraiment une latence énorme.
Cela a maintenant créé beaucoup de questions dans mon esprit -
Il doit y avoir des scénarios ou des applications en temps réel où ce niveau de une forte concurrence est gérée avec une faible latence, n'est-ce pas?
Est-ce toujours la limitation avec la base de données relationnelle et pourrait être a résolu une base de données nosql non relationnelle d'une manière ou d'une autre?
Merci d'avance, toute aide appréciée.
3 Réponses :
Ceci est une limitation avec les bases de données relationnelles et toute base de données avec de fortes garanties de concurrence en général. Vous ne pouvez pas vraiment le contourner, sauf en augmentant le matériel.
Tout cela se résume aux opérations d'E / S. Pour garantir que votre transaction est écrite à 100% et ne peut pas être perdue, les bases de données vident généralement les données sur le disque. En fonction de vos disques, cela prend très longtemps, de l'ordre de quelques millisecondes.
Donc à vos questions:
Vous pourrez peut-être atteindre votre objectif en passant aux disques SSD en tant que disques, théoriquement ceux-ci peuvent atteindre 1000 s io / seconde, alors qu'un disque rotatif fait au plus 100 s io / seconde. Ensuite, vous devez convaincre votre base de données de faire le moins d'iops possible pour une requête.
Brautigam en augmentant le matériel, vous vouliez passer uniquement au SSD, non? ou il y a d'autres façons dont vous parlez?
@Bruce_Wayne Il y a quelques options. Vous pouvez introduire SSD, vous pouvez essayer d'utiliser plusieurs périphériques dans une sorte de configuration RAID, soit en logiciel, soit en matériel. Vous pouvez utiliser du matériel de stockage externe spécialisé avec des iops élevés.
Il doit y avoir des scénarios ou des applications en temps réel où ce niveau de concurrence élevée est géré avec une faible latence, n'est-ce pas?
Vous souhaitez consulter la littérature sur l'utilisation de la structure de données de tampon en anneau pour messagerie par LMAX.
La réponse courte est que, dans certains scénarios, le groupage de vos écritures peut vous sauver, en supposant que vous puissiez organiser le problème de telle sorte que d'autres contraintes soient satisfaites.
La "limitation" n'a rien à voir avec le fait que les bases de données soient "relationnelles" (ou non).
L'essence de votre scénario est que vous ne pouvez pas commencer à ajouter 1 (par exemple pour obtenir 3) avant que l'acteur précédent ait fini d'ajouter 1 pour obtenir 2, et ait complètement terminé et validé ce changement. Si 2 + 1 = 3, vous ne pouvez pas démarrer le calcul tant que et jusqu'à ce que les deux des valeurs sur le LHS soient disponibles et fiables. Donc, si le 2 est le résultat d'une autre action, vous ne pourrez pas démarrer tant que cette autre action ne sera pas complètement terminée.
C'est [parfois] appelé "syndrome du convoi" et cela peut se produire dans n'importe quelle technologie.
Il y a des magasins où ils font des choses apparemment similaires avec une "haute conurrency", mais non plus ils y parviendront en évitant toute forme de ressource centrale partagée causant le syndrome de convoi (comme votre compteur) ou ils y parviendront en sacrifiant votre "doit finir avec 1000 "garantie.