Conception de base de données, traitement en temps réel ou par lots

Question

Je suis confronté à deux options de mise à jour de la base de données, et je ne sais pas laquelle est la meilleure pour ma situation. Il y a trois tables dans la base de données, qui sont utilisées pour lire/stocker certaines informations de l'utilisateur, telles que l'historique de l'URL ou certaines entrées. En temps réel, la base de données est accessible aux utilisateurs tout le temps, de sorte que les changements apportés à la base de données peuvent être vus immédiatement par cet utilisateur. Le traitement par lots cache la "mise à jour" de l'utilisateur, la base de données est mise à jour en analysant les fichiers journaux, et un tel processus s'exécute toutes les X heures. Ainsi, l'utilisateur ne peut voir leurs modifications qu'après X heures. En plus de l'avantage/désavantage des mises à jour synchronisées/asynchrones que l'utilisateur peut voir. Quels sont les autres avantages de choisir des méthodes de mise à jour de traitement en temps réel ou par lots pour la mise à jour de la base de données?

Merci

Answer 1

Je vous suggère d'utiliser EDA (Architecture Event Driven) qui utilise un middleware pour « colle » tout cela.

http://searchsoa.techtarget.com/definition/event-driven-architecture

Un conseil: Conserver à l'écart des processus de traitement par lots.

Aujourd'hui, tout tend à être de plus en plus en temps réel. Imaginez si vous receviez ma réponse dans X heures ... seriez-vous satisfait? :)

Si vous nous donnez plus d'informations, nous pourrions aussi vous aider.

Je vois que votre entrée provient d'un fichier journal? Cela peut-il être changé? Vous pouvez également implémenter le modèle d'observateur.

Answer 2

Tout dépend de la quantité de trafic que vous attendez. Si vous souhaitez dimensionner votre application, un traitement asynchrone est toujours recommandé. Mais cela ne signifie pas que vos utilisateurs doivent attendre X heures. Vous pouvez faire fonctionner le processus toutes les 5 minutes ou même toutes les minutes. De cette façon, vous réduirez les problèmes de simultanéité et en même temps les utilisateurs pourront voir leur historique mis à jour avec un peu de retard.

Voir les meilleures pratiques pour l'évolutivité dans le livre Scalability Rules