{"id":9355,"date":"2022-08-12T15:34:08","date_gmt":"2022-08-12T14:34:08","guid":{"rendered":"https:\/\/blog.capdata.fr\/?p=9355"},"modified":"2023-01-19T11:29:31","modified_gmt":"2023-01-19T10:29:31","slug":"stocker-ses-bases-de-donnees-dans-un-azure-blob-storage-limpossible-dilemme","status":"publish","type":"post","link":"https:\/\/blog.capdata.fr\/index.php\/stocker-ses-bases-de-donnees-dans-un-azure-blob-storage-limpossible-dilemme\/","title":{"rendered":"Stocker ses bases de donn\u00e9es dans un Azure Blob Storage : l’impossible dilemme ?"},"content":{"rendered":"\"twitter\"<\/a>\"linkedin\"<\/a>\"mail\"<\/a>

Depuis d\u00e9j\u00e0 longtemps, Microsoft propose que l’on stocke les donn\u00e9es de ses instances IaaS d’Azure dans un Storage Account.<\/p>\n

Cela veut dire qu’il n’y a plus de disque mont\u00e9 sur la VM qui sont acc\u00e9d\u00e9s par l’OS, mais SQL Server qui acc\u00e8de en HTTPS \u00e0 un Storage Account. Sur le papier, et avec quelques tests, cela fonctionne bien.<\/p>\n

Vraiment\u00a0 ? Et puis il existe plusieurs type de Storage Account : donc duquel parle-t-on ? Comment se comparent-ils en terme de performances ? \u00c9conomiquement ? Fonctionnellement ?<\/p>\n

 <\/p>\n

Protocole de tests :<\/h1>\n

Nous allons comparer 3 modes de stockages dans une VM Azure :<\/p>\n

    \n
  1. Un disque local premium P15 de 256 Go ( 1100 IOPS \/ 125 Mo\/s avec des bursts \u00e0 3500 IOPS et 170 Mo\/s)<\/li>\n
  2. Un storage account LRS de type “standard”<\/li>\n
  3. Un storage account LRS de type “premium”<\/li>\n<\/ol>\n

    La VM utilis\u00e9e de base sera une D4s_v3 (4 vCPU \/ 16 Go de RAM \/ 6400IOPS), avec comme base de donn\u00e9es un extrait de la base StackOverflow de 50 Go. Le disque local premium est configur\u00e9 pour avoir du cache en lecture seule, on ignorera le fait que le log transactionnel est sur le m\u00eame volume.<\/p>\n

    Gros clustered index scan\u00a0 :<\/h1>\n

    En faisant une requ\u00eate du type\u00a0 :<\/p>\n

     select avg(answercount) from posts <\/pre>\n
     <\/p>\n
    \"\"<\/p>\n
    Le temps d’ex\u00e9cution sur le Storage Account “standard” (HDD) est extr\u00eamement performant ! On atteint des d\u00e9bits de 400 Mo\/s. L\u00e0 o\u00f9 c’est plus surprenant, c’est que le storage \u00e9quivalent mais en Premium (SSD) n’offre pas du tout les m\u00eames performances ! On voit des intermittences de d\u00e9bits r\u00e9seaux :<\/p>\n
     <\/p>\n
    \"\"<\/p>\n
     <\/p>\n
    On voit \u00e9galement que les d\u00e9bits sont tellements \u00e9lev\u00e9s dans le cas d’un stockage “standard”, que le CPU est satur\u00e9 ! Cela pourrait aller encore plus vite, si la VM dispose d’assez de puissance CPU.<\/p>\n
    Indexation :<\/p>\n
    On peut ensuite tenter une indexation voir comment se comporte ces stockages :<\/p>\n
    create index Posts_LEDN ON POSTS(LastEditorDisplayName)<\/pre>\n
     <\/p>\n
    \"\"<\/p>\n
     <\/p>\n
    Ici \u00e9galement, on voit que le stockage le plus performant est le Storage Account “Standard”. Les d\u00e9bits disques sont sup\u00e9rieurs et battent le Premium qu’il soit distant ou local.<\/p>\n
    Clustered Index Seek :<\/h1>\n
    Le Storage Account Premium est vendu autours de l’argument des temps d’acc\u00e8s. On peut v\u00e9rifier cela en effectuant des seeks avec un buffer vide :<\/p>\n
     DBCC DROPCLEANBUFFERS ;\r\n\r\nselect * from Posts\r\nwhere LastEditorUserId = 12345 <\/pre>\n
     <\/p>\n
     <\/p>\n
     <\/p>\n
    \"\"<\/p>\n
     <\/p>\n
     <\/p>\n
    Ici les chiffres sont plus conformes \u00e0 ce que l’on pouvait s’attendre. Le stockage Premium (local ou distant) offre des temps de r\u00e9ponse inf\u00e9rieur au stockage “Standard”.<\/p>\n
    Interpr\u00e9tations et conclusions :<\/h1>\n
    Les r\u00e9sultats n’\u00e9taient pas ceux auxquels je m’attendais lors de ce benchmarks, pour \u00eatre honn\u00eate. J’avais r\u00e9alis\u00e9 des tests il y a quelques ann\u00e9es avec du stockage standard pour r\u00e9aliser des backups snapshots, et j’avais \u00e9t\u00e9 tr\u00e8s satisfait du niveau de performance. On pourrait donc s’attendre \u00e0 ce que les performances soient meilleures en SSD ? Mais il n’en est rien, curieusement. Microsoft, dans sa documentation recommande l’usage de disque locaux Premium : pour les data, avec le cache en read-only, pour la tempdb sur le volume temporaire D: (si la machine en poss\u00e8de un), et le log transactionnel sur un volume s\u00e9par\u00e9, sans cache.<\/p>\n
    Mais \u00e7a ne veut pas dire qu’il faut balayer d’un revers de main le stockage distant dans Azure :<\/p>\n