Réplication - Synchronisation de la plupart des données de temps en temps

Question

J'ai des données qui ne sont pas correctement "partitionnées" (faute d'un meilleur mot).

Tous les insertions, traitements et rapports se produisent sur la même table. La majeure partie du traitement arrive peu de temps après l'insertion et peu de temps après, elle devient immuable (nous parlons des jours).

Je pouvais faire toutes les insertions et le traitement sur une nouvelle table que je réplique à l'ancienne table. Lorsque je détecte que les données sont devenues immuables, je supprime les données de la nouvelle table, mais je modifie la procédure de suppression de la réplication stockée afin que la suppression ne soit pas répliquée.

À quel point est-ce une mauvaise idée? < edit1> C'est-à-dire, éditer la procédure stockée de réplication. </edit1>

Il semble attrayant pour le moment (je n'ai pas encore dormi dessus) car il pourrait atténuer un problème de performance avec seulement de très petits changements dans l'application. Il semble aussi que ce soit un bon moyen de me tirer une balle dans le pied.

Edit1:

J'aime l'idée d'insérer dans deux tables parce que je peux éviter la vue et la fenêtre de maintenance décrit dans la réponse de Jono. Sans vouloir t'offenser, Jono, j'utilise cette technique ailleurs. Je pourrais vouloir utiliser la réplication parce qu'une table pourrait être dans une autre base de données (je sais, je n'ai pas mentionné cela) et ainsi je n'ai pas à m'inquiéter de commettre à deux tables, je laisse juste la réplication manipuler cette. Mon problème actuel (que je n'ai pas clarifié) est que la modification de la procédure stockée de réplication pourrait finir par être un casse-tête de déploiement/maintenance.

Answer 1

Je ne préconiserais pas la réplication pour résoudre un problème de performance (à moins que ce soit un problème de distribution physique des données); si quelque chose va ralentir votre système que les changements sont propagés à leur destination. Si vous utilisez un seul serveur, je suggère d'ajouter une deuxième table avec le même schéma que la première, mais avec vos index optimisés pour le type de travail que vous faites dans votre phase de traitement. Créez ensuite une vue qui sélectionne à partir des deux tables et utilisez cette vue dans toute requête où vous souhaitez l'union des deux tables. Vous pourriez alors lancer plus de matériel à la deuxième table (je pense à un groupe de fichiers séparé sur plus de broches) et ensuite migrer les données sur un délai hebdomadaire dans la première table, pendant une fenêtre de maintenance disponible.