L’avenir de SQL Server

Brian Moran : nous aimerions aider nos lecteurs à  comprendre
quelles sont les directions prises pour les évolutions de SQL Server, et connaître
les différents types de changement qu’il y aura dans Yukon [le nom de code de
la version post- SQL Server 2000]. Nous souhaiterions également passer en revue
toutes les fonctionnalités d’interopérabilité des différentes versions de SQL
Server.

Paul Flessner : nous pouvons évoquer les éléments de conception
de SQL Server 2000 que nous sommes en train de finaliser, ce qui nous conduira
tout naturellement vers l’avenir.
Nous avons plusieurs objectifs pour SQL Server 2000. Les retour que nous avons
eus sur SQL 7.0 ont été clairs. Nombreux sont les clients qui ont vraiment apprécié
l’ensemble de ses fonctionnalités, et qui pensent que SQL 7.0 est compétitif.
En quelques mots, voilà  ce qu’ils disaient : « Vous n’avez pas toutes les fonctionnalités
qu’offrent vos concurrents, mais l’ensemble que vous proposez couvre les éléments
clés du marché, comme par exemple OLTP (OnLine Transaction Processing) ainsi que
l’aide à  la décision ». Nous commençons à  travailler dans le domaine de la gestion
de la connaissance, avec, entre autres, notre fonctionnalité de recherche sur
du texte en clair. Nous avons eu un feedback très positif à  propos du processus
d’upgrade, de la compatibilité descendante et de la qualité globale. Je m’entretenais
l’autre jour avec un client à  propos de SQL 2000, et il me disait la chose suivante
: « vous méritez une excellente note, parce que sur une échelle de 1 à  10 en termes
de qualité, SQL Server obtiendrait 12 ». Nous savions donc que nous avions fait
du bon travail, mais dans certains domaines, les clients nous ont poussés à  aller
plus loin.

Nous savions que nous avions fait du bon travail, mais dans certains domaines,
les clients nous ont poussés à  aller plus loin

Nous nous sommes aussi attachés à  apporter un support Internet plus fourni avec
SQL Server 2000. L’Internet a explosé alors que nous étions en train de construire
SQL Server 7.0. Nous avons commencé à  écrire le code de la version 7.0 vers la
mi-95, pour une mise sur le marché fin 1998. Nous avons donc été amenés à  rajouter
des fonctionnalités pour l’Internet en toute hâte. Tout le monde apprécie ce que
nous faisons en matière de datawarehousing, mais voudrait une plus grande facilité
d’intégration en standard. Les clients nous ont également confié qu’ils sentaient
que nous était à  leur écoute. Nous invitons en effet 5 à  10 clients par semaine
dans nos centres de développement, et nous nous mettons tous autour d’une table,
et nous écoutons ce qu’ils ont à  dire.

Brian Moran : je dois admettre que vous cherchez beaucoup à  avoir
des retours de la part des clients que vous invitez, et que vous adaptez le produit
de façon à  aller dans le sens de leurs besoins. Mais je pense que l’utilisateur
moyen de SQL Server a souvent l’impression que Microsoft fait les choses dans
son coin, et qu’il n’y a pas de canal de feedback évident pour faire remonter
des informations jusqu’au niveau corporate de Microsoft.

Paul Flessner : on peut toujours en faire plus. Nous avons quelques
forums, comme par exemple MSDN (Microsoft Developper Network), qui est le plus
important. Cela coûte un peu d’argent d’adhérer à  MSDN, mais je pense que ce coût
n’est pas prohibitif, et n’arrêtera aucun développeur ou administrateur de bases
de données. C’est notre modèle pour toucher la population la plus large. On peut
poser toutes sortes de questions et obtenir des réponses sur ce forum. Ceci dit,
il me faut peut-être un peu plus de feedback sur notre cible.

Brian Moran : parlez-nous un peu de capacité de montée en charge.
Il est clair que les chiffres du TPC (Transaction Performance Processing Council)
en ont étonné plus d’un. Je pense que ces résultats ont pris Oracle par surprise.
Et la réponse d’Oracle consiste maintenant à  dire que le partitionnement en « scale-out »
(c’est-à -dire l’augmentation du nombre des serveurs. NdT) est la planche de salut,
mais la solution actuelle de Microsoft n’est pas très pratique dans de nombreuses
situations, en raison de la manière de laquelle il faut implémenter ce partitionnement.
Et bien sûr, Oracle affirme que son produit peut toujours bien mieux monter en
charge avec une seule machine SMP. En conséquence, quand verrons-nous les performances
TPC-C d’un serveur Windows 2000 Datacenter Server 32 noeuds ou 32 CPU ?

Paul Flessner : je voudrais reprendre un peu de hauteur par rapport
à  cela. Il y a essentiellement deux façons de monter en charge pour une base de
données, et deux éléments de conception fondamentaux dans l’architecture produit.
L’un est l’architecture de type « shared-everything » ou stratégie de type « scale-up »
(augmentation de la capacité du serveur). Ces scénarii sont ceux dans lesquels
ont voit des grosses machines SMP 32, 64 voire 96 voies, desquelles Oracle et
Sun aiment parler. Le modèle « shared everything » est parfait pour de nombreuses
-et disons même la plupart-applications. Mais en termes de montée en charge, ce
modèle est limité. Je ne peux pas donner de chiffre précis mettant en évidence
les insuffisances de débit des processeurs, car le modèle est complètement dépendant
de la charge de travail. En tout cas, les insuffisances de débit ne sont dues
ni au matériel ni au système d’exploitation. C’est la définition même de l’architecture
base de données qui est la cause des limitations de capacité de montée en charge
du modèle « shared-everything ».
Permettez-moi de vous donner un exemple. On entend beaucoup parler de parallélisme
des bases de données. Nous avons des opérations parallèles, telles que la création
d’index, les requêtes, les scans, les tris et une opération de lecture parallèle
pour les insertions et les mises à  jour. Ce dont on ne parle pas, ce sont les
I/O série, les accès à  la log série et au buffer série. A chaque fois qu’on en
a terminé l’une de ces opérations parallèles, on retourne à  une opération série.
Plus on a de processeurs, plus rapidement ils se mettent en file d’attente et
sont prêts à  traiter une de ces opérations série.
C’est donc une réalité que la capacité de montée en charge SMP, c’est à  dire la
montée en charge du matériel, n’est pas effective. Il arrive un moment où toutes
les applications touchent l’asphalte avec le genou, et alors on ne peut plus que
glisser. Tout ce qu’on fait alors, c’est donner un maximum d’argent à  Sun et Oracle,
qui s’en satisfont très bien. Ils sont tellement contents de passer à  la caisse
qu’ils font tout ce qu’ils peuvent pour dénigrer notre modèle économique, aussi
bien au niveau SMP qu’au niveau de notre stratégie « scale-out », que je vais évoquer
dans un instant.
La stratégie « shared-nothing » ou « scale-out » est un modèle éprouvé dans le monde
des dot.com et chez les éditeurs indépendants. Voyez la stratégie « scale-out »
de SAP. Le niveau médian est le modèle commun. On gères ses connections et sa
logique de traitement à  ce niveau et on n’a plus à  s’occuper de l’état des données,
qui sont gérées au niveau du back end. Et si on a besoin de plus de connections
ou de plus de débit, il suffit de rajouter un serveur d’applications. Ce modèle
économique a été validé à  maintes reprises. Nous défendons un modèle qui a fait
ses preuves et qui date de 20 ans.

Brian Moran : les limitations de ce modèle sont aujourd’hui liées
à  la capacité de gérer la partition scale-out. Et puis certains types d’applications
peuvent conduire naturellement au modèle partitionné, alors que d’autres non.
En d’autres termes, les bases de données fédérées de SQL Server constituent pas
une solutions universelle à  tous les problèmes.

Paul Flessner : j’ai été clair à  ce sujet, même au lancement
de Windows 2000 : cette solution se justifie économiquement dans le cadre de notre
stratégie « scale-out ». On bénéficie de transparence dans les requêtes de mise
à  jour, mais pas en termes de possibilités d’administration. Je n’essaye donc
pas de vendre la stratégie scale-out à  n’importe qui. Elle ne se destine pas à 
tous nos clients, mais uniquement à  une population très précise, qui exige ce
niveau de capacité de montée en charge.

Brian Moran : j’aimerais avoir votre vision d’Oracle et d’IBM.
Le modèle « shared-nothing » n’est pas le point fort d’Oracle, qui aurait certainement
quelques soucis pour migrer vers ce modèle. S’agissant de la technologie d’IBM
dans le « shared-nothing », il semblerait qu’il y ait un regain d’intérêt pour DB2
sur NT, et que DB2 ait quelques belles références en matière de gestion, du fait
qu’IBM a fait cela depuis plus longtemps que SQL Server.

Paul Flessner : tout d’abord, Oracle ne dispose pas de la technologie
« shared-nothing ». Ils n’ont que cette chose hybride appelée  » disque partagé « .

Brian Moran : et cela ne permet pas de monter en charge facilement.

Paul Flessner : c’est à  Oracle de décider s’il convient de faire
évoluer le modèle  » disque partagé  » ou de le justifier.

Brian Moran : Oracle a une bonne aura dans le marché des bases
de données. Oracle est perçu comme le leader, surtout dans le monde du e-business.
Mais si je m’en tiens à  la technologie, je trouve que certaines des technologies
que Microsoft lance, ou certaines qu’IBM a eues depuis longtemps, sont meilleures
que l’architecture d’Oracle. Y a t-il eu une évolution des esprits d’Oracle vers
Microsoft et IBM ? Alors que les capacités de monter réellement en charge deviennent
plus importantes, le débat autour du « shared-nothing » va-t-il contribuer à  cette
évolution des esprits ?

Paul Flessner : je vais certainement pointer le navire dans cette
direction. Bien qu’IBM ait disposé de la technologie « shared-nothing », la Compagnie
s’est plutôt intéressée à  l’aide à  la décision, pas à  OLTP, et cela les a limités.
Croyez-moi, s’ils avaient du OLTP oeuvrant pour le scale-out….

Brian Moran : …ils auraient déjà  publié leurs chiffres TPC.

Paul Flessner : il y a bien longtemps. IBM ne sait toujours pas à  quoi s’en tenir,
bien qu’elle soit en progrès. Honnêtement, je pense qu’IBM s’en sortira très bien.
Informix est sur la même voie. Ils avaient des éléments pour l’aide de décision
mais pas pour OLTP. On ne dispose donc pas non plus de chiffres pour Informix.
Mais je pense que c’est très clair : tant d’un point de vue capacité de montée
en charge pure que du point du vue strictement économique, la stratégie « scale-out »
va l’emporter. Pensez au malheureux responsable d’exploitation qui vient juste
d’obtenir auprès de sa Direction un budget de 20 millions de francs pour une machine
Sun, en expliquant qu’on ne le reverrait pas avant 2 ans. Et 4 mois plus tard,
le voilà  de retour, à  la recherche d’une autre machine. Ce n’est pas vraiment
l’objectif des clients.

Brian Moran : du point de vue interopérabilité et intégration,
je voudrais évoquer les architectures des différentes technologies de stockage
de données. Le data mining évoluant, SQL Server va être très intégré avec Commerce
Server. Il y a Host Integration Server. DTS (Data Transformation Services) est,
entre autres choses, un outil de transformation. Il y a des parties de BizTalk
Server qui font du mappping de schémas, de la transformation, et de la gestion
de workflow. Et XML commence entrer un peu partout. Avez-vous des projets pour
extraire des composants du noyau de SQL Server, comme DTS, et les intégrer au
système d’exploitation lui-même ?

Paul Flessner : on peut envisager l’intégration de différentes
façons. On peut la voir comme de l' »Enterprise Application Integration » (EAI),
depuis derrière un firewall. Et là , Host Integration Server est clairement essentiel
pour nous. Les requêtes hétérogènes sont également très importantes. DTS joue
sans aucun doute aussi un rôle. Puis, on commence à  passer le niveau du firewall,
et XML commence à  intervenir. BizTalk Server joue alors un rôle important, avec
la planification des messages XML et le workflow. A un certain moment, ces technologies
ont évidemment besoin d’un point d’intégration. Certains sont attachés à  un point
d’intégration central, comme un catalogue ou un répertoire. D’autres veulent la
souplesse d’un protocole auto-descriptif, ce que fournit XML. Notre entreprise
propose une plate- forme robuste, riche et diversifiée. De ce fait, nous aurons
des points d’entrée dans chacune de ces technologies.

La bonne vieille modélisation des données reste toujours une bonne chose.
La compréhension de SQL Server, du fonctionnement des procédures cataloguées et
des connections sont essentiels

Brian Moran : il semblerait que vous soyez en train de réinventer
la roue à  chaque fois. Autant que je comprenne, BizTalk Server n’utilise aucun
des composants COM fondamentaux disponibles pour DTS. Vous pourriez me répondre
que si DTS avait un provider XML parfait, BizTalk Server aurait pu l’utiliser.
Vos équipes produits travaillent-elles à  des rythmes différents sur les nouveaux
produits, et vont-elles créer des standards concurrents au sein même de Microsoft,
sans même tenir compte du reste de l’industrie ?

Paul Flessner : je pense qu’il y a effectivement quelques chevauchements,
mais pas autant que vous semblez le craindre. BizTalk par exemple, a la capacité
d’accepter différents formats de transactions et de les convertir au format XML.
L’objectif de DTS est la transformation de données plutôt que la transformation
de messages. On aura toujours besoin de cela. Ni DTS, ni BizTalk ne sont conçus
pour traiter les sources de données ADO et OLE DB et les fichiers textes, qui
sont importants sur le marché du datawarehousing. Y a t-il une possibilité de
convergence dans le futur ? Probablement. Dans un sens, si j’ai du XML partout,
je n’ai plus besoin d’aucune de ces technologies. SQL Server peut réaliser toutes
ces transformations, n’est ce pas ? Mais c’est loin d’être une réalité, et je
doute qu’un protocole unique arrive à  monopoliser tout le marché. Un monde XML
unifié, avec des niveaux de stockage de données différents, est une vision agréable
mais ce n’est pas pour demain.

Brian Moran : avez vous une idée de ce que les DBA des entreprises
devraient faire pour mettre leurs compétences à  niveau s’ils veulent rester compétitifs
sur le marché des professionnels de SQL Server dans les 6 à  12 mois à  venir ?

Paul Flessner : XML est certainement une technologie importante,
que nous allons voir progresser. On peut programmer en XML avec SQL Server 2000
de différentes façons. On peut le faire en mettant SQL au centre, ou dans une
perspective de développement XML et DOM (Document Object Model). Ce qui sème le
plus souvent le trouble chez les clients, c’est qu’ils ne n’ont pas de compréhension
des éléments fondamentaux du produit : ils se lancent dans une modélisation de
base de données à  la petite semaine, et ne pensent pas aux sauvegardes et à  la
restauration, ils ne s’intéressent pas aux verrouillages et aux déverrouillages
applicatifs, ils écrivent des ISAPI (Internet Server APIs) mal étudiées, ce qui
effondre les serveurs IIS, et ils ne comprennent pas les interactions entre IIS
et SQL Server. Dans Windows 2000 en particulier, nous avons apporté de grandes
améliorations de la robustesse de IIS 5.0 et du rôle que peut jouer COM+ en rendant
une application beaucoup plus rapide via le multithreading. La bonne vieille modélisation
des données reste toujours une bonne chose. La compréhension de SQL Server, du
fonctionnement des procédures cataloguées et des connections sont essentiels.
Je sais que c’est plus facile à  dire qu’à  faire.

Brian Moran, président du Capital Area SQL Server User’s Group, est architecte
de bases de données senior chez CrossTier.com. Il est formateur Windows NT et
SQL Server certifié par Microsoft, MCSEan MCSD, et MVP.