Stratégie pour conserver des bases de données distinctes en synchronisation

Question

J'ai une base de données NoSQL que nous utilisons pour le traitement des données, car elle peut être utilisée pour mon application plus rapidement que SQL. Je traite notre base de données NoSQL presque comme un cache d'informations, le SQL étant l'autorité des données, et le magasin NoSQL étant mis à jour avec les changements. Pour l'instant, cela se fait via notre application, donc quand une requête arrive pour une modification, elle est faite dans la base de données SQL, et dans la base de données NoSQL. Cela échoue parfois, car la mise à jour NoSQL échoue parfois, ou d'autres situations entraînent une désynchronisation de la base de données NoSQL.

Je pourrais faire une mise à jour par lot toutes les X minutes, mais il y a beaucoup d'informations dans les magasins de données, et cela prendrait des heures pour s'assurer qu'elles sont synchronisées. Nous avons quelques timestamps pour faire une différence sur ce qui a été changé, mais ce n'est pas toujours exact.

Je me demande quelle est la stratégie recommandée pour conserver un magasin de données (cache de base de données secondaire) en synchronisation avec mon magasin principal?

Answer 1

Je sais que j'en ai déjà fait avec la messagerie - en particulier JMS avec ActiveMQ. Je voudrais envoyer les mises à jour à un magasin NoSQL (Mongo) en utilisant une file d'attente. De cette façon, les messages pourraient s'accumuler dans la file d'attente et si la connexion au magasin NoSQL était interrompue, elle pourrait reprendre là où elle s'était arrêtée.

Cela a très bien fonctionné car ActiveMQ était vraiment stable et simple à utiliser.

J'ai toujours vu cela avec des différences comme vous l'avez mentionné. Vous introduisez des champs de date partout et gardez trace de la dernière synchronisation. La bonne chose à propos de cette approche est qu'elle vous permet facilement de relire les transactions en modifiant la dernière date de synchronisation. Un dernier conseil ... écrivez de bons outils autour du pompage des données du point A au point B (dans ce cas SQL vers NoSQL). J'ai écrit plusieurs outils pour charger en vrac le magasin NoSQL de SQL à mon dernier travail et cela a rendu la vie facile si quelque chose a vraiment vraiment désynchronisé. Entre les scripts et les processus de chargement en masse, je pourrais toujours récupérer.