Cohérence des données WebSocket et latence

Question

Supposons que j'ai un frontal JavaScript (Angular.js, par exemple), un back-end Java (Spring, fonctionnant sur Tomcat, par exemple) et un système de gestion de base de données (SAP HANA In-Memory, dans mon cas). Par exemple, j'ai des graphiques qui peuvent changer relativement rapidement. Je me demande à quoi pourrait ressembler une architecture efficace et rapide. Envoyez-vous généralement une collection complète d'objets à l'interface utilisateur ou envoyez-vous simplement des deltas? Dans mon cas, la cohérence des données sur l'interface utilisateur est très importante pour le bon fonctionnement de l'application, mais également pour les temps de latence réduits, en particulier pour les fusions de données. En ce qui concerne la cohérence, j'ai souvent tendance à faire un SELECT à partir de la base de données sur un insert et à relire toute la collection d'objets, mais je crains que cela ne soit pas à l'échelle.

Existe-t-il une approche générique de ce problème ou même des frameworks existants?

Édition: Actuellement, ce sont environ 300 objets avec un couple d'attributs entiers et de références croisées qui peuvent changer et réorganiser en une milliseconde, mais qui pourraient aller jusqu'à 10000 dans le futur. Mon défi ici est la communication entre front-end et back-end, de sorte que le front-end a toujours un jeu de données cohérent en temps réel.

Answer 1

Quelle est la distance entre le client et le serveur? Est-ce un mile/km ou des centaines/milliers de kilomètres? Le client est-il sur Internet ou sur un VPN haute performance? Êtes-vous proche de l'épine dorsale ou des dizaines de houblon? Normalement, vous n'obtiendrez pas systématiquement une latence de 1 milliseconde sur le Web si vous faites confiance à Internet. Si vous êtes sur un réseau d'entreprise interne et que le client est physiquement proche du serveur, par exemple la même machine, le même réseau local, vous pouvez obtenir une latence de ms à un seul chiffre avec WebSocket (j'ai personnellement obtenu 3-4 ms centres de données internes dans une grande banque d'investissement).

Ne pas optimiser trop tôt. C'est généralement une mauvaise chose. Bien que avec toute interface utilisateur haute performance, il est toujours bon de simplement envoyer les deltas.

Vous pouvez envisager une sorte de mécanisme d'événement pour réduire votre interrogation de la source de données. Ensuite, vous ne mettrez à jour les données que lorsque celles-ci auront été modifiées.