Discussion :

[Ikebukuro]

Salut les experts SQL Server,

Je ne sais plus si j'ai posé la même question ici mais plus je lis à droite à gauche de choses sur SQL Server et moins c'est clair pour moi.

Quand je crée une table dite Clustered Table, elle a un Clustered Index, on est d'accord? Si oui, on a bien créé deux objets sur le disque dur : une table + un index et les données de la colonne indexée sont dupliquées, OK? A la différence de Oracle, les données dans la table sont triées : on insère pas les dans n'importe quel bloc : OK?

Dans le cas d'une table avec un index non clustered, on a bien créé deux objets sur le disque dur : une table + un index et les données de la colonne indexée sont dupliquées, OK? Et là, comme pour Oracle, les données dans la table ne sont pas triées : on insère dans n'importe quel bloc : OK?

Si j'ai bien compris : dans les deux cas on a bien deux objets de créés, une table et un index. Si c'est cela, j'avoue ne pas comprendre l'intérêt de la Clustered Table car pourquoi vouloir une table avec des données triées? Est-ce pour avoir un excellent Clustering Factor (terme Oracle)?

J'en suis au point où je pensais que la clustered table SQL Server était l'équivalent de la table IOT d'Oracle mais peut-être que je me trompe...

Merci pour vos réponses

[SQLpro]

Salut les experts SQL Server,

Je ne sais plus si j'ai posé la même question ici mais plus je lis à droite à gauche de choses sur SQL Server et moins c'est clair pour moi.

Quand je crée une table dite Clustered Table, elle a un Clustered Index, on est d'accord? Si oui, on a bien créé deux objets sur le disque dur : une table + un index et les données de la colonne indexée sont dupliquées, OK?

non. Un seul objet, pas de duplication, c'est un des intérêts de l'index CLUSTERED (littéralement EMPLACÉ (l'index étant emplacédans la table))

A la différence de Oracle, les données dans la table sont triées : on insère pas les dans n'importe quel bloc : OK?

Non, enfin pas tout à fait.... par défaut Oui, mais Oracle permet de créer la même chose avec un nom différent "Index Organized table"...

Dans le cas d'une table avec un index non clustered, on a bien créé deux objets sur le disque dur : une table + un index et les données de la colonne indexée sont dupliquées, OK? Et là, comme pour Oracle, les données dans la table ne sont pas triées : on insère dans n'importe quel bloc : OK?

oui

....J'en suis au point où je pensais que la clustered table SQL Server était l'équivalent de la table IOT d'Oracle mais peut-être que je me trompe...

Ben si !!!!

La grande différence c'est que le moteur de SQL Server est optimisé pour les tables clustered tandis que celui d'oracle est optimisé pour les tables en HEAP.... Et la différence est significative en terme de qualité du plan de requête et donc performance, car il ne passe quasiment jamais par la table en mode SCAN !!!!

Autre information importante, dans la littérature consacré au SGBDR on parle de pages, pas de blocs... La encore oracle se distingue pour embrouiller les pistes !

A +

[Waldar]

Ce n'est pas si mauvais que ça les IOT chez Oracle, mais c'est moins dans la culture des développeurs.
Il faut garantir un accès par la PK pour éviter de devoir construire des index additionnels, mais ça marche.
De mémoire la gestion des index additionnels est mieux réalisée chez MS, mais j'ai pas trop bricolé depuis la 11gR2 donc ça a peut-être évolué.

La différence important entre une table HEAP et IOT c'est qu'une HEAP peut être lue et chargée plus rapidement qu'une IOT (pas d'insert append, le fast index full scan est moins performant que le fast table full scan), et y'a sûrement aussi une meilleure compression pour les tables HEAP.

Dans un environnement OLTP, SQL-Server s'en sort mieux qu'Oracle DB car on ne fait que des accès avec quelques lignes sur les identifiants des clustered index, et comme sur SQL-Server dès qu'on ajoute une PK la table par défaut est en clustered index, ça marche très bien

Sur un environnement OLAP, Oracle DB s'en sort mieux que MS SQL-Server grâce aux fast table full scan (et si on a un Exadata les données sont en plus filtrées à la lecture) et aux hash joins plus aboutis, surtout quand on a beaucoup de colonnes en jointure. Mais on peut toujours coller des IOT sur des tables de référence.

[Ikebukuro]

Je vous remercie pour vos réponses

[SQLpro]

...
Sur un environnement OLAP, Oracle DB s'en sort mieux que MS SQL-Server grâce aux fast table full scan (et si on a un Exadata les données sont en plus filtrées à la lecture) et aux hash joins plus aboutis, surtout quand on a beaucoup de colonnes en jointure. Mais on peut toujours coller des IOT sur des tables de référence.

Tu devrais préciser pour Oracle de l'OLAP sur une base relationnelle et non sur un cube, car là SQL Server s'en sort mieux !

Mais depuis les index columstore en OLTP (ce que oracle ne fait pas) et avec le mode "batch" des opérations, je pense qu'aujourd'hui Oracle est largué !

A +

[Waldar]

Sur Oracle il n'y a jamais eu vraiment besoin de cube (ça existe mais c'est compliqué à mettre en œuvre et le gain de temps pas évident).
Le problème des cubes chez MS c'est qu'ils sont rapides à requêter mais quand même très long à rafraîchir.

Je n'ai pas regardé les index columnstore donc je ne peux pas trop en causer.
En googlant rapidement je suis tombé sur cette tentative de comparaison (qui au final dit qu'on ne peut pas trop comparer) :
https://www.brentozar.com/archive/20...server-oracle/

Faut voir, car le format colonne présente sont lot de challenges aussi.
Super efficaces en lecture, en stockage et en RAM, mais plus compliquées à rafraîchir, et coût CPU important si on doit reconstruire la ligne pour faire une jointure.

Pour la petite histoire sur teradata on fait du stockage lignes, colonnes ou hybride aussi mais en général le surcoût CPU n'est que peu profitable - sachant qu'on n'est pas du tout une base colonne au départ, on adapte le produit en conservant ce qui existe déjà.
On continue d'améliorer ce format mais l'effet waouh qui peut exister sur une requête type ne se retrouve pas forcément sur une production avec des besoins beaucoup plus divers.
Limite on est meilleur à lire des données stockées en colonnes sur Azure BLOB et à les remettre en lignes à la demande, mais c'est une autre histoire

[mikedavem]

Sur un environnement OLAP, Oracle DB s'en sort mieux que MS SQL-Server grâce aux fast table full scan (et si on a un Exadata les données sont en plus filtrées à la lecture) et aux hash joins plus aboutis, surtout quand on a beaucoup de colonnes en jointure. Mais on peut toujours coller des IOT sur des tables de référence.

Loin de mon intention de comparer Oracle et SQL Server ici mais je pense qu'il faudrait reconsidérer la question avec l'apparition des columnstore sous SQL Server et le mode batch comme stipulé par SQLPro. C'est devenu une fonctionnalité vraiment abouti depuis SQL Server 2016 et cela continue à s'améliorer au fur et à mesure des versions.

Pour en avoir mis quelques uns sur des DW ca a été le jour et la nuit au niveau performance.

Faut voir, car le format colonne présente sont lot de challenges aussi.
Super efficaces en lecture, en stockage et en RAM, mais plus compliquées à rafraîchir, et coût CPU important si on doit reconstruire la ligne pour faire une jointure.

Sur des environnements OLTP avec du "real-time operational analytics" (pour éviter justement le problème de rafraichissement des cubes), l'implémentation devient en effet un peu plus tricky même s'il est vrai qu'on peut limiter l'overhead lié à la construction des groupes de lignes / segments compressés avec des index columtores filtrés ou en retardant la compression des lignes. Le problème à mon avis n'est pas tellement ici et le plus gros challenge qu'on a dû faire face est l'influence des columnstore sur certaines opérations OLTP classiques qui ont été ralenti même si dans l'ensemble on a quand même drastiquement diminuer la consommation CPU de certaines requêtes de Reporting (vive la compression + mode batch). Pas encore eu le temps d'investiguer

++

[Waldar]

Loin de mon intention de comparer Oracle et SQL Server ici mais je pense qu'il faudrait reconsidérer la question avec l'apparition des columnstore sous SQL Server et le mode batch comme stipulé par SQLPro.

Y'a pas de mal à comparer
J'ai plutôt fait du Oracle DB dans ma carrière car c'est ce que mes clients avaient en majorité quand je faisais du consulting en SSII ou à mon compte, mais quand j'ai du faire du SQL-Server j'ai bien aimé aussi (après un petit temps d'adaptation).
Et au final je me retrouve chez encore un autre éditeur de SGBD

Merci pour le retour d'expérience en tout cas, toujours enrichissant !

[SQLpro]

... le plus gros challenge qu'on a dû faire face est l'influence des columnstore sur certaines opérations OLTP classiques qui ont été ralenti même si dans l'ensemble on a quand même drastiquement diminuer la consommation CPU de certaines requêtes de Reporting (vive la compression + mode batch)....

je confirme ! Dès que tu met du CLUSTERED COLUMNSTORE tu as intérêt à réviser toutes les autres requêtes.... Et souvent il y a des surprises !

A +

[Waldar]

Ca pourrait être intéressant d'avoir la table de fait en clustered index et une vue indexée en columnstore ?
Comme ça les opérations classiques notamment d'alimentation ou OLTP se font sur la table et les opérations d'agrégats sur la vue, et on laisse SQL-Server maintenir tout ça comme un grand ?