Discussion :

[AvenirN]

Bonjour à tous.
Aujourd’hui nous sommes face à un défi d'architecture nouveau pour nous.
Nous devons faire évoluer un site ecommerce vers l'international.
Là ou cela bloque le plus c'est concernant la bd.
Pour le moment nous avons adapté notre code pour le marché US et CA.
Nous avons déjà un frontend au Canada et un autre en France. Une ferme de serveur donc.
Le problème, et on s'en doutait, c'est la lenteur de communication avec le serveur SQL qui lui est en France.
Nous somme en .NET, IIS, MSSQL.
Il faut donc que l'on se dirige vers un cluster SQL en réplication. Enfin j'imagine ?
Ma question est, comment font les autres ?
Comment fait Amazon par exemple pour distribuer ses data au travers le monde ?
Si vous avez de l'expérience sur le sujet je suis preneur !

[mikedavem]

Hello,

Dans les grandes lignes, il faut d'abord définir tes flux de réplication (unidirectionnel / bidirectionnel), les objets de ta (tes ?) base(s) concernée(s) et si sur chaque site (FR / CA / US), la fréquence de réplication de ces objets (une fois par jour / temps réel ...) et si un mode offline est obligatoire (site HS, coupure réseau entre 2 sites etc ...)

1) Par expérience, tu peux te baser sur la réplication SQL Server qui est un grand classique dans ce type de scénario avec une (plusieurs) base(s) de données sur chaque site pour minimiser les latences d'accès. Cependant en fonction du type de réplication (transactionnelle / fusion / snapshot) des contraintes de schémas seront à prévoir. L'application doit pouvoir aussi s'adapter à ce type d'architecture sous peine d'avoir à gérer des multitudes de conflits lors des mises à jour de données depuis les différents sites (si configuration multi-master).

L'utilisation des AG avec cluster geo-distribué est aussi envisageable avec réplication asynchrone si tes flux de réplication restent unidirectionnelles avec plusieurs secondaires en RO sur chaque site.

2) Tu peux aussi envisager une architecture Cloud. Si les mises à jour ne se font que depuis un seul site, pourquoi quoi utiliser une architecture Azure SQL DB avec de la géo-réplication et des secondaires en RO sur chaque site. Si le multi-master est obligatoire, pourquoi pas faire du sharding avec les données distribuées en fonction de leur localité (FR / CA / US). Dans ce dernier cas, l'application devra certainement être mise à jour pour supporter le sharding.

++

[AvenirN]

Merci du retour aussi détaillé.
Nous avons besoin dans notre scénario de pouvoir ecrire des deux côtés donc pas de RO.
Le offline est acceptable.
Ma crainte c'est de devoir transformer toute nos primary key en uniqueid, elles sont actuellement en int incrémentale comment gérer ce point ?
Une autre question en passant : nous avons l'habitude d'avoir nos serveurs FrontEnd et SQL directement sur internet (front wan) pour faire de la replication il faut obligatoirement les intaller dans un VPN?

[mikedavem]

Merci du retour aussi détaillé.
Nous avons besoin dans notre scénario de pouvoir ecrire des deux côtés donc pas de RO.
LLe offline est acceptable.
Ma crainte c'est de devoir transformer toute nos primary key en uniqueid, elles sont actuellement en int incrémentale comment gérer ce point ?

Pour la réplication de fusion (BOL), une clé primaire n'est pas nécessaire. Seul l'ajout d'une colonne UNIQUEIDENTIFIER avec la propriété ROWGUIDCOL (et indexée) est requise pour les articles qui seront répliquées.

Une autre question en passant : nous avons l'habitude d'avoir nos serveurs FrontEnd et SQL directement sur internet (front wan) pour faire de la replication il faut obligatoirement les intaller dans un VPN?

Le VPN n'est pas obligatoire. La web synchro (avec HTTPs) existe également (BOL). A voir en fonction de ton contexte.

++