Régulièrement on me dit que MS SQL Server est un jouet comparé à Oracle ou TerraData.
Pourtant mon activité professionnelle m’a conduit à conseiller des clients ayant plusieurs téraoctets de données tant dans des bases relationnelles que décisionnelles.
Je me suis donc demandé quelles était les plus grosses bases de données hébergées par des serveurs Microsoft Windows / SQL Server…
Dépassant le To, on parle de VLDB (Very Large DataBase), mais en Po que doit-on dire ?
1) Pann Starrs – Recherche spatiale
Pann Starrs est l’acronyme de Panoramic Survey Telescope and Rapid Response System.
Système de relevé astronomique qui effectue de l’astrométrie et de la photométrie (résolution 1.4-gigapixel) d’une grande partie du ciel quasiment en continu. En détectant toute différence par rapport aux observations précédentes des
mêmes zones du ciel, Pann STARRS découvre un très grand nombre de nouveaux astéroïdes, comètes, étoiles variables et autre objets célestes (350 milliards de nouveaux objets découverts fin 2011). Sa mission principale est de détecter les objets géocroiseurs qui pourraient provoquer des impacts cosmiques. Sa base de données comprend tous les objets visibles depuis Hawaï (les trois quarts du ciel) jusqu’à une magnitude apparente de 24.
Taille de la base : Plusieurs Po (plus de 1 Po par an) de données célestes. Catalogue astronomique de 100 To environ.
Machines : 12 noeuds SQL Server 2008.
2) Myspace.com
Un des réseaux sociaux les plus visités au monde. 25% des américains y adhère. 280 millions d’utilisateurs dans le monde.
Taille de la base : > 1 Po
Nombre de serveurs SQL : 450
Travaux : 18 000 messages traités par seconde par serveur.
Infrastructure : 9 000 serveurs Web + 1 000 serveurs de cache (Windows et .net)
MySpace.com était au 5e rang mondial des sites web les plus visités du monde en 2008 en nombre d’utilisateurs unique. Le classement était le suivant (tous sites confondus) :
1 Google 145 243
2 Yahoo 139 181
3 Microsoft 128 255
4 AOL LLC 108 917
5 MySpace 85 119 (dont MySpace)
3) CENTIPEDE – Informatique
Centipede est le nom de code d’un projet d’un systèmpe opérationnel de traitement de très gros volumes de données et fournit à titre d’ISV.
Il est utilisé par plusieurs clients dont la plupart dépassent 100 To de données.
Taille de la base : plus de 500 To (plus grosse base cliente) sur 9 noeuds
Technologie : un serveur SQL « master node » (métadonnées), des serveurs esclave « data nodes ». Vues partitionnées ditsribuées (Distributed Partitioned Views) partitionnement d’index et de données(Data and Index Partitioning) Réplication transactionnelles (Transactional Replication) et cluster de secours (Failover Clustering). La charge de travail est répartie sur les différents nÅ“uds. Des requêtes concurrentes peuvent être envoyées sur le même nÅ“ud ou sur des nÅ“uds distribués.
NOTA : le but est la transparence des données. Ajout, suppression remplacement des nÅ“uds facile et rapide. Rapidité de chargement et de migration des données des nÅ“uds (plusieurs To en moins d’une journée). Les machines sont standardisées (la plupart du temps 16 cÅ“urs et 64 Go de RAM).
4) Hotmail Рcourrier ̩lectronique
Dimensions du système : 1,3 milliards de boîtes aux lettres, données : 155 Po, grossissement : 2 Po par mois
Taille des bases SQL : 500 To
Nombre de serveurs SQL : 16 000 sur 160 clusters
Caractéristiques des machines SQL : 2 Xeon CPUs avec 4Go de RAM jusqu’à 2 quad-core Xeon CPUs avec 16Go RAM
Haute disponibilité : mirroring des bases de données.
5) Itaù – banque
Itaù est l’une des 15 plus grandes banque du monde (Brasil’S Banco Itaù) et héberge une base de données de gestion des risques de trésorerie chargée de calculer les position journalières et calculer les scores des risques de plus de 4,5 millions de transactions financières en portefeuille. Les évaluations de risque utilise SQL CLR (des calculs effectués en .net sous la responsabilité du serveur SQL) et concernent 4 milliards de calculs effectués chaque jour (environ 500 par transactions) sur une machine à 64 processeurs au rythme de 3 000 transactions financières par seconde…
Taille de la base : 50 To
BI : 180 millions de faits nouveau chaque jour
NOTA : le système a été migré d’Oracle pour lequel il prenait plus de 24 heures de traitement pour procéder au calcul journalier des risques. Il ne prends plus aujourd’hui que 1 heure, malgré l’absorption de la banque Unibanco par Itaù.
6) Webtrends – Analyse de trafic de site web
Taille de la base : données relationnelles 50 To, décisionnelles : 5 To
7) VimpleCom РT̩l̩communication (Russie)
bases de données des analyses de risque et traque de fraude des communications. Grossit chaque jour de 500 Go. Rétention de 40 jours dans la base.
Taille de la base : 20 To
8) First American – Assurance
L’un des plus grosse compagnie américaine d’assurance. Le système visé concentre les données des 50 entreprises du groupe dans une solution appelée First American Software Technology (FAST) développée sous plateforme Winows avec SQL
Server. L’entreprise génère 10 000 documents par jours et le système joue les intermédiaires entre les différentes applications informatiques.
Taille de la base : 8 To (la plus grosse, d’autres bases existent)
Nombre d’utilisateurs : 15 000
Utilisateurs concurrents : 7 000 en pointe
Nombre de batch : 15 000 par seconde en moyenne.
9) BWIN – jeux en ligne
Bwin est la plus grande compagnie de paris en ligne en Europe avec plus d’un million de paris par jour.
Taille de la base : plus de 4 To
Nombre de transactions : 30 000 par seconde en pic
haute disponibilité : 99,997% du temps (mesuré en réel)
Technologie : mirroring synchrone des serveurs entre deux datacenter éloignés de 12 miles
NOTA : Bwin est sponsor des clubs de football AC Milan et Real Madrid et figure dans le tube « poker face » de Lady gaga…
10) Gmarket – Boutique en ligne
Une des boutiques en ligne les plus prisée en Corée du sud. 12 millions de clients dont 3 millions réguliers. Près de 2 milliards de requêtes par jour. CA de 2 milliards de dollar par an.
Machine : HP Superdome doté de 64 processors et 512 Go de RAM
Transactions : 20 000 batch par seconde, pointes régulières à 23 000.
Quelques autres sociétés connues pour leurs VLDB :
En france :
Fnac.com
CDiscount
Vente privée
Dans le monde :
Hilton
Mediterranean Shipping Company (MSC)
Progressive (Assurances USA)
QR Limited (chemin de fer Australie / ERP SAP)
United Airlines (264 Go en 2010 en BI. Prévue pour 1,5 To)
Il en existe bien d’autres. mais la plupart ne veulent pas communiquer de chiffre.
Le site web sur le SQL et les SGBDR
Frédéric Brouard, alias SQLpro, ARCHITECTE DE DONNÉES
Expert S.G.B.D relationnelles et langage S.Q.L
Moste Valuable Professionnal Microsoft SQL Server
Société SQLspot : modélisation, conseil, formation,
optimisation, audit, tuning, administration SGBDR
Enseignant: CNAM PACA, ISEN Toulon, CESI Aix en Prov.
L’ntreprise SQL Spot
Il n’existe pas de base de données relationnelles active active sur l’ensemble des nÅ“uds de manière transparente. Même Oracle RAC, nécessite que l’application soit « RAC » compatible. Microsoft à choisit de ne pas implanter un système faisant croire à l’activation systématique de tous les nÅ“uds au même plan. Cependant il existe chez MS différents moyens pour gérer des bases de données de grande ampleur réparties sur plusieurs machines…. Mais premier point : à quoi sert de répartir sur plusieurs machines si sur une seule cela suffit. Et ce n’est pas la problématique de volumétrie qui est le plus important, mais le nombre de transaction essentiellement pour l’écriture (pas la lecture).
Autrement dit une base SQL Server avec 100 To de données, mais un maximum de 2000 utilisateurs en parallèle, cela se règle avec un bon serveur…. 1 To de RAM, 8 cartes réseau, un SAN dédié, le partitionnement, le stockage (froid, donc READ ONLY, chaud donc READ WRITE, très chaud donc IN MEMORY…), etc.
Mais avec 30 000 utilisateurs simultané, c’est déjà plus la même chose. Il faut alors ventiler les données sur différents serveurs qui coopèrent en même temps, par le biais de la réplication de données (RW/RW), services broker (RW/RW) ou encore du mirroring (RW / RO). Le système de cluster étant dédié à la haute disponibilité, pas au « scale out »…
Par exemple pour un site comme FNAC.com il y a une dizaines de serveurs actifs en « front office », chacun ayant une partie des données des clients (étanchéité). Un client avec ses commandes n’existe donc que sur un serveur. De même pour le Back office qui gère la facturation, les stocks, l’expédition….
les réplications de données étant les suivantes :
1) flux de commandes : des serveur FO vers BO, toutes les 5 minutes
2) flux des produits : des serveurs BO vers les serveurs FO, 2 fois par jour
3) flux des commentaires : entre serveurs FO, toutes les 30 minutes env.
Sachez que la réplication de données dans MS SQL Server est très en avancée sur les autres SGBDR (et ce depuis SQL Server 7 en 1999) et son code comporte aujourd’hui plus de lignes que le moteur SQL Lui même… La réplication de données supporte 4 modes différents :
– transactionelle
– peer to peer
– snapshot
– fusion
En sus il y a « service broker » qui permet de gérer des bases de données collaboratives réparties grâce à une messagerie transactionnelle, sérialisée en mode asynchrone. Pasteur Mérieux ou la SNCF pour ses guichets utilise cela pour centraliser en continu les données d’une multitude de serveurs coopératifs afin d’alimenter un serveur central. On peut aussi faire du maillage avec ce système. Par exemple de manière linéaire (chaque serveur contient les mêmes données) ou bien de manière latérale : chaque serveur ayant une partie des données (exemple ERP ayant un serveur pour chaque pan fonctionnel de l’entreprise : commercial, production, stock, RH, compta…).
Enfin, par le biais du mirroring qui peut être multiple (une base active – master – envoie ses transactions en continu aux serveur esclaves) on peut lire les serveurs miroir, par exemple pour du reporting, ou encore pour soulager la charge du serveur pour les lectures. Le mirroring pouvant être sysnchrone, avec ou sans basculement automatique, ou asynchrone…
Enfin, on ne peut pas comparer les bases de données relationnelles qui supportent les transactions et dont ces dernières sont indispensable dans le domaine de l’informatique de gestion (vente, banque, comptabilité….) et les bases NoSQL faites pour le documentaire (site sociaux, édition en ligne de blog…) et ne présentant aucun aspect translationnel, donc un potentiel non négligeable de données perdues en cas de crash…
Bonjour,
Ca ne fait que quelques jours que je regarde les bds NoSQL et je cherche un peu les pour, les contre. En cherchant, je suis tombé sur ton article : « Les plus grosses bases de données MS SQL Server actuelles sont en pétaoctets… ».
Dans cet article tu parles de noeuds SQL Server. De ce que je connais de ce produit, on n’a pas de réél cluster : les instances sont actives seulement sur un et un seul noeud à la fois. Du coup si tu as seulement une instance et deux noeuds, seul un travail pour les requêtes, l’autre sert simplement de backup et prend la relève en cas de crash. Une facon d’exploiter les deux est de créer une autre instance pour avoir du actif / actif (MSCS). Ainsi c’est pas SQL Server qui distribue ses données / requêtes mais le programme.
Est-ce ce dernier mécanisme qui est utilisé sur N noeuds (Suis-je dans le flou ?) ? Si oui, n’est-ce pas trop de travail pour quelque chose qui pourrait être géré par le SGBD ?
Merci d’avoir pris le temps de lire
et encore plus si tu me sors de ce flou !