Dans mon secteur, nous utilisons MySQL en version 5.0 avec plus de 11 milliards (vous avez bien lu) d'enregistrements pour une taille totale d'environ 1 To. Mais nous sommes confrontés à un problème de ressources.
Nous souhaitons pouvoir bénéficier des avantages suivants :
1. bases stockées sur plusieurs disques voire plusieurs serveurs
2. parallélisation des requetes
3. rapidité dans l'exécution des requetes (surtout pour les insertions et les updates)
4. accès (connexions) massifs simultanés
5. temps de réponse très court (enfin, selon la taille des données...)
6. load balancing (optionnel)
7. SGBD au mieux gratuit au pire payant (mais pas trop cher )
SQL Server sera la solution la moins chère à ce niveau :
1. bases stockées sur plusieurs disques voire plusieurs serveurs
SQL Serveur peut répartir une base jusqu'à 32 000 fichiers donc 32 000 disques... Bien évidemment ce sera plutôt sur un SAN qu'autre chose.
De même on peut partitionner logiquement les lignes des tables (mettre les clients de A à N sur un disque et ceux de M à Z sur un autre...) idem pour les index.
On peut aussi réserver l'espace des fichiers afin que le SGBDR n'ait pas d'acquisition de place à faire pour loger les données.
2. parallélisation des requetes
jusqu'à 64 processeur dans SQL Server. On peut aussi piloter le parralélisme en le limitant globalement ou pour chaque requête
3. rapidité dans l'exécution des requetes (surtout pour les insertions et les updates)
SQL Server dispose d'un des optimiseurs les plus puissante du marché. Ceci combiné à la stratégie de fichier et notamment en prétaillant ses fichiers permet d'aller très vite. J'ai fait cette démo ici :
http://blog.developpez.com/sqlpro?ti..._fichiers_et_t4. accès (connexions) massifs simultanés
Jusqu'à 32 000 connexions simultanée. le nombre de requêtes en // dépend du nombre de CPU. Avec 64 CPU on peut compter sur plus de 1000 threads simultané
5. temps de réponse très court (enfin, selon la taille des données...)
Cela dépend essentiellement de la RAM et de la fenêtre des données et pour ce dernier paramètres de l'organisation physico logique de vos lignes dans les pages. Lisez la série d'article que j'ai écrit sur l'optimisation :
http://sqlpro.developpez.com/optimisation/6. load balancing (optionnel)
Aucun SGBDR au monde ne peut réellement faire du LOAD balancing. En effet les données ne sont présente qu'à un seul endroit à la fois. Il est donc impossible d'opérer dans ce mode. Il est en revanche possible de répliquer les données sur différents serveur afin d'offrir une surface d'attaque plus grande (scale out), mais ce sera toujours asynchrone. Mais cette solution ne doit être envisagé qu' après avoir épuisé les ressources du scale up (donc 64 processeur 2 To de RAM). Elle est en effet plus couteuses à tous les niveaux : administration, cout de licence, cout de matériel, diminution du MTBF...
7. SGBD au mieux gratuit au pire payant (mais pas trop cher )
Ne rêvez pas. En matière de gratuit, vous n'aurez aucune chance d'obtenir satisfaction. Reste grosso modo Oracle, DB2 ou SQL Server....
Or SQL Server est l'un des moins cher surtout dans ce genre de configuration. Il est 10 à 12 fois moins cher qu'Oracle.. Quand à IBM DB2, inutile d'en parler !
Quelques exemples de très grosses solutions en ligne avec SQL Server :
1) Euridile (INPI : les entreprises et les marques en France. Pointes à 30 000 utilisateurs)
2) fnac.com : le plus gros site web de commerce en France
3) Castorama : entrepôt de données de 3 To
4) ooshop : 1er supermarché en ligne (Carrefour)
A +
1 |
0 |