Réplication transactionnelle pour l'écriture de base de données de taille moyenne lourde

Question

Nous disposons d'une base de données d'une taille correcte et d'une taille d'environ 426 Go (y compris les index) et d'environ 300 millions de lignes. Nous collectons actuellement des données de localisation à partir de périphériques qui signalent à notre serveur toutes les quelques minutes, et nous servons environ 10 000 appareils - donc beaucoup d'écritures chaque seconde. La table de localisation qui stocke l'emplacement de chaque périphérique a environ 223 millions de lignes. Les données sont actuellement archivées par année.

Des problèmes se produisent lorsque les utilisateurs exécutent des rapports volumineux sur cette base de données, la base de données entière se ferme presque jusqu'à un arrêt. Je comprends que j'ai besoin d'une base de données de rapports, mais ma question est de savoir si quelqu'un a déjà utilisé SQL Server Transactional Replication sur une base de données de taille équivalente, et son expérience de l'utilisation de cette technologie?

Mon plan approximatif est de pointer tous les rapports de notre application vers la base de données de rapports, utilisez la réplication transactionnelle pour répliquer les données du maître vers l'esclave (base de données de rapports).

Quelqu'un at-il des idées sur cette stratégie et les problèmes que je peux rencontrer?

Merci beaucoup!

Answer 1

La réplication transactionnelle devrait fonctionner correctement dans ce scénario (le seul effet que la taille de la base de données aura est le temps nécessaire pour générer l'instantané initial). Cependant, cela peut ne pas résoudre votre problème. Je pense que le problème que vous aurez si vous optez pour la réplication transactionnelle est que le serveur esclave sera soumis à la même charge que la machine maître à mesure que les modifications sont appliquées - il continuera à explorer lorsque les utilisateurs exécuteront des rapports volumineux (en supposant c'est d'une spécification similaire).

En fonction de la latence acceptable de la transmission de données aux données en temps réel, cela peut être OK ou non pour vos utilisateurs.

Si une latence est acceptable, les performances de l'envoi de journaux peuvent être meilleures car les modifications sont appliquées par lots. Avant d'acquérir un serveur de rapports, une autre approche consiste à examiner les requêtes que vos utilisateurs exécutent et à modifier leur code ou la stratégie d'indexation pour mieux correspondre à ce qu'ils essaient de faire.

Answer 2

La réplication transactionnelle pourrait bien fonctionner pour vous. Les éléments à prendre en compte:

1. Les tables de la base de données cible doivent être en lecture seule.
2. Le serveur contenant la base de données cible doit être suffisamment résistant pour gérer le trafic SELECT des applications de génération de rapports.
3. Selon le trafic INSERT/UPDATE, vous devrez peut-être avoir un troisième serveur comme serveur de distribution.
4. Vous devez également prendre en compte la taille de la base de données de distribution. En fonction de ce que je lis ici, j'utiliserais un abonnement d'extraction du serveur Reporting pour décharger le trafic du serveur OLTP.

Vous pouvez ignorer le tourment d'un instantané en initialisant la base de données de génération de rapports à partir d'une sauvegarde de la base de données OLTP.Voir https://msdn.microsoft.com/en-us/library/ms151705.aspx

Il y aura un trafic INSERT/UPDATE/DELETE à partir de la réplication dans les bases de données Distribution et Subscriber. Cela nécessite d'être pris en compte, mais les problèmes de verrouillage/blocage ne devraient pas être pires (et probablement meilleurs) que l'exécution de ces rapports hors de OLTP. J'exécute plusieurs publications sur une base de données de 2,6 To avec 2,5 Go/jour de croissance, en utilisant à la fois transactionnel pur pour générer des rapports (à deux serveurs de rapports) et Peer-to-Peer Transactional pour répliquer des données dans une scale-out pour une offre SaaS (à trois serveurs de plus). Pour cette raison, nous avons un distributeur séparé.

Espérons que cela aide.

Merci John.