Nous avons pré-annoncé aujourd’hui la préversion publique d’Azure SQL Database Hyperscale. SQL Database Hyperscale est un nouveau niveau de service basé sur SQL et hautement évolutif, conçu pour des bases de données uniques s’adaptant à la demande aux besoins de votre charge de travail. Avec SQL Database Hyperscale, les bases de données peuvent rapidement adapter automatiquement leur échelle jusqu’à 100 To, ce qui élimine la nécessité de pré-approvisionner des ressources de stockage, et augmente considérablement le potentiel de croissance des applications sans contrainte de taille de stockage. La préversion publique sera disponible le 1er octobre 2018.

En comparaison des niveaux de service d’Azure SQL Database, Hyperscale fournit les fonctionnalités supplémentaires suivantes :

• Prise en charge des tailles de base de données jusqu’à 100 To
• Montée/descente en puissance et restauration dans le temps rapides, quelle que soit la taille de la base de données
• Débit de journalisation supérieur aux niveaux de service actuels
• Montée en charge de la charge de travail en lecture seule avec des réplicas à l’échelle de lecture sans copie de données

Azure SQL Database Hyperscale est construit sur la base d’une nouvelle architecture cloud qui dissocie le calcul, la journalisation et le stockage.

Nœuds de calcul

Les nœuds de calcul ressemblent à ceux d’un serveur SQL traditionnel, mais sans fichiers de données ou fichiers journaux locaux. Le nœud de calcul principal écrit les journaux transactionnels sur le service de journal, et extrait des pages de données des serveurs de pages si elles ne figurent pas dans le cache de données local ou dans RBPEX (Resilient Buffer Pool Extension).

Service de journal

Le service de journal externalise le journal transactionnel à partir d’une base de données Hyperscale. L’instance de calcul principale écrit le journal sur le service de journal. Les serveurs de pages et les instances de calcul secondaires utilisent le journal du service de journal. Le service de journal décharge également les enregistrements de journal vers un stockage à long terme plus économique afin de prendre en charge la restauration dans le temps.

Serveurs de pages

Les serveurs de pages hébergent et gèrent les fichiers de données. Ils consomment le flux de journal des services de journal, et appliquent les modifications de données décrites dans le flux de journal aux fichiers de données. Les demandes de lecture de pages de données non trouvées dans le cache de données local ou le RBPEX de calcul sont envoyées via le réseau aux serveurs de pages propriétaires des pages. Dans les serveurs de pages, les fichiers de données sont conservés dans Stockage Azure et massivement mis en cache via RBPEX.

Plusieurs serveurs de pages seront créés pour une base de données volumineuse. Lorsque la base de données croît et que l’espace disponible dans les serveurs de pages existants passe sous un seuil, un nouveau serveur de pages est automatiquement ajouté à la base de données. Les serveurs de pages fonctionnant de manière indépendante, nous pouvons augmenter la taille de la base de données sans contrainte de ressource locale.

Sauvegarde et restauration dans le temps automatisées

Dans une base de données Hyperscale, des captures instantanées des fichiers de données des serveurs de pages sont prises régulièrement pour remplacer la sauvegarde en continu classique. Cela nous permet de sauvegarder une très grande base de données en seulement quelques secondes. Conjointement avec les enregistrements de journal stockés dans le service de journal, vous pouvez restaurer la base de données à tout moment de la période de rétention (7 jours en préversion publique) très rapidement, quelle que soit sa taille.

Nous sommes enthousiasmés par les nouveaux niveaux d’extensibilité introduits par SQL Database Hyperscale.  Depuis le 1er octobre, vous pouvez créer une base de données Hyperscale dans 12 régions Azure différentes. Pour plus d’informations, consultez la documentation sur Azure SQL Database.