Microsoft offre une version candidate de SQL Server 2022 au monde Linux

Version imprimable

09/09/2022, 12h36
Bill Fassinou

1 pièce(s) jointe(s)

Microsoft offre une version candidate de SQL Server 2022 au monde Linux
Microsoft offre une version candidate de SQL Server 2022 au monde Linux
elle comprend des fonctionnalités comme Azure Synapse Link et Azure Active Directory Authentication

Microsoft a annoncé cette semaine la disponibilité d'une version candidate de SQL Server 2022 pour certains systèmes d'exploitation Linux. SQL Server 2022 RC 0 est désormais disponible pour les systèmes d'exploitation Red Hat Enterprise Linux (RHEL) et Ubuntu. En plus des nouvelles fonctionnalités ajoutées dans la RC 0, cette version pour Linux prend également en charge les fonctionnalités telles que Azure Synapse Link et Azure Active Directory Authentication. Pour télécharger les dernières images de conteneur RC 0, vous devez utiliser les balises '2022-latest' pour les images de conteneur basées sur RHEL et Ubuntu.

Microsoft a lancé son portage Linux de SQL Server en 2016 et a embrassé le monde de l'open source depuis, abandonnant la position de l'ex-PDG Steve Ballmer selon laquelle "Linux est un cancer". Critiquant la licence open source, il a déclaré en 2001 : « Linux est un cancer qui se fixe, au sens de la propriété intellectuelle, à tout ce qu’il touche ». Steve Ballmer ajouta encore qu’avec la façon dont sa licence est écrite, « si vous utilisez un logiciel open source, vous devez rendre le reste de votre logiciel open source ». Bien sûr, Ballmer a changé d'avis depuis et a même félicité Microsoft pour sa décision de porter SQL Server sur Linux.

Pièce jointe 625149

La version Linux de SQL Server 2022 comprend non seulement les fonctionnalités incluses dans SQL Server 2022 RC 0 dévoilé le 23 août pour Windows, mais prend également en charge plusieurs fonctions cloud liées à Azure. Les fonctionnalités incluses dans la RC 0 comprennent Query Store pour surveiller les performances du système en capturant automatiquement l'historique des requêtes, des plans et des statistiques d'exécution. Les développeurs peuvent y accéder et les examiner, et les capacités de gestion sont renforcées par des accélérations intégrées et des sauvegardes instantanées.

La RC 0 comporte également des ajouts de langage, notamment Approx Percentile Disc qui, selon Microsoft, "renvoie la valeur de l'ensemble des valeurs d'un groupe en fonction du centile et des spécifications de tri fournis", et Approx Percentile Cont, qui "renvoie une valeur interpolée approximative de l'ensemble des valeurs d'un groupe en fonction de la valeur du centile et des spécifications de tri". En ce qui concerne Azure, la version Linux de SQL Server 2022 prend en charge les fonctions suivantes :
- Azure Synapse Link : permet aux développeurs d'utiliser Azure Synapse Analytics pour accéder facilement et directement au magasin analytique Azure Cosmos DB. Le runtime d'intégration (IR) ne peut pas être installé sur l'environnement Linux, vous devrez donc exécuter l'IR sur une machine Windows qui se trouve sur le même réseau que la machine Linux qui exécute l'instance SQL Server à laquelle il se connecte ;
- Azure Active Directory Authentication (ADD) - SQL Server on Linux inclut désormais la prise en charge de l'AAD. Pour l'instant, les conteneurs SQL Server ne prennent pas en charge cette fonctionnalité ;
- Pour les groupes de disponibilité distribués, la modification de REQUIRED SYNCHRONIZED SECONDARIES TO COMMIT est prise en charge.
Microsoft continue à ajouter des caractéristiques et des fonctions à SQL Server for Linux et à en faire une partie croissante de ses services de cloud d'entreprise Azure, ce qui est logique dans un monde informatique en évolution rapide, de plus en plus axé sur le cloud computing et la distribution. Selon des données publiées en août dernier par la société d'études de marché Statista, SQL Server se classait au troisième rang, derrière Oracle et MySQL, dans la liste des systèmes de gestion de bases de données (SGBD) les plus populaires, devant des systèmes tels que PostgreSQL, MongoDB et Redis.

En mai, le développeur d'applications mobiles AppInventiv a également placé SQL Server en troisième position, derrière Oracle et MySQL, dans une liste des meilleures bases de données pour les applications Web, en soulignant ses atouts, tant sur site que dans le cloud, sa présence dans les systèmes Windows et Linux, et sa prise en charge des données structurées, semi-structurées et spatiales. « Il n'est pas aussi inventif ou avancé que d'autres systèmes de gestion de bases de données modernes et populaires, mais il a fait l'objet d'améliorations et de révisions considérables au fil des ans », écrit la société de développement.

Cependant, même si Microsoft a porté SQL Server sur Linux, le logiciel n'est pas open source, ce qui pourrait empêcher son adoption à grande échelle par la communauté open source. Selon les analystes, les ingénieurs logiciels se penchent sur les bases de données open source. Une enquête menée cette année par Stack Overflow auprès de quelque 70 000 programmeurs a révélé que la quasi-totalité d'entre eux utilise l'un des deux principaux SGBD open source, PostgreSQL (46,5 %) ou MySQL (45,7 %), ainsi que d'autres systèmes.

Source : Microsoft

Et vous ?

:fleche: Quel est votre avis sur le sujet ?
:fleche: Que pensez-vous du portage de SQL Server sur Linux ?

Voir aussi

:fleche: Steve Ballmer aime Linux, l'ancien PDG de Microsoft change d'opinion sur Linux, quinze ans après l'avoir traité de « cancer »

:fleche: .NET 6 est maintenant disponible dans Ubuntu 22.04 et dans les conteneurs Ubuntu simplifiés, dans le cadre d'un nouveau partenariat entre Microsoft et Canonical

:fleche: Debian Linux remplace Google par DuckDuckGo comme moteur de recherche par défaut pour Chromium. Bientôt, le navigateur Chromium de Debian aura DuckDuckGo comme moteur de recherche par défaut

:fleche: La distribution chinoise Deepin Linux est-elle à la hauteur pour remplacer Windows 11 sur les PC ? La version 20.7 est disponible, et ravive le débat Windows contre Linux sur le desktop
09/09/2022, 13h35
Invité

Quitte à travailler sous Linux, mieux vaut opter pour PostgreSQL qui dispose de bien plus d'outils sur cet OS.
15/09/2022, 18h02
SQLpro

5 pièce(s) jointe(s)

Citation:

Envoyé par Jeff_67

Quitte à travailler sous Linux, mieux vaut opter pour PostgreSQL qui dispose de bien plus d'outils sur cet OS.

Oui c'est vrai.... par exemple PostGreSQL propose un diagnostic automatique des index à créer pour optimiser tes bases comme SQL Server :

Pièce jointe 625483

Ah non ??? Dommage !tu va passer 15 jours à relever des traces de requêtes lentes et te faire chier à faire des test pour trouver les 598 index manquants que SQL Server te fournit grace à ses analyses automatiques !

Oui c'est vrai.... par exemple PostGreSQL propose des dizaines de rapports de diagnostics permettant d'auditer rapidement ce qui ne va pas, comme dans Microsoft SQL Server...

Pièce jointe 625487

Pièce jointe 625488

Ah non ??? Dommage !tu va devoir installer tout un tas de d'outils que ne communique pas entre eux piour n'avoir que le 10e de ce que te propose Microsoft SQL Server gratuitement avec SSMS !

Oui c'est vrai.... par exemple PostGreSQL propose de transformer automatiquement tes tables les plus sollicités en tables IN MEMORY, comme dans Microsoft SQL Server...

Pièce jointe 625489

Ha non ??? Comment, PostGreSQL n'a pas de table in memory ? Pas de tables de graphe ???

Pièce jointe 625490

Bref trêve de plaisanterie... Quand on ne sait pas de quoi on parle ...

Voici maintenant la liste des manque de PostgeSQL face à SQL Sever... Juste une cinquantaine !
http://mssqlserver.fr/postgresql-vs-...ed-comparison/

Et les mauvaises performance de PostgeSQL ! Sidérantes... Jusqu'à 1 500 fois plus lent ! Vive le gratuit...
http://mssqlserver.fr/postgresql-vs-...s-pour-le-dba/
http://mssqlserver.fr/postgresql-vs-...es-avec-count/

Et globalement, en ce qui concerne les performances voici les principaux points noirs...

Pas de stockage dédié dans PostGreSQL. Que ce soit dans Oracle ou Microsoft SQL Server le stockage est gérer de manière directe par des accès qui ne s'effectuent pas dans l'OS mais utilise des API spécifique d'accès aux disques, ce qui permet d'accélérer les écritures et lectures physiques.
Pas d'index pour les grosses volumétries dans PostGreSQL. Les techniques modernes d'indexation de grosses volumétries passent par des index verticaux ("columstore" par opposition aux index "rowstore"). Que PG n'est pas capable de proposer. Oracle les réservent pour l'OLAP, et Microsoft SQL Server aussi bien pour l'OLTP que pour l'OLAP.
Pas de compression des données dans PostGreSQL PG ne dispose pas de méthodes de compression des données relationnelles (tables et index) permettant de préserver toutes les fonctionnalités de recherche et d'accès tant en lecture qu'en écriture. Microsoft SQL Server dispose par exemple de 4 modes de compression (sparse columns, vardecimal, row ou page).
Parallélisme embryonnaire dans PostGreSQL. Le parallélisme qui permet d'accéder par de multiple thread à de grosses quantité des données à extraire est embryonnaire dans PostGreSQL et manuel (seul 8 algorithmes des plans d'exécution sur une trentaine sont gérés). Dans SQL Server, le parallélisme est automatique et concerne presque toutes les opérations d'un plan de requête (plus de 100 algorithmes). Dans Oracle, ce module est manuel et payant.
Pas de tables "in memory" dans PostGreSQL. Pour accélérer certains accès, le recours aux tables en mémoire peut s'avérer très payant (jusqu'à 30 fois plus rapide). PG ne dispose pas de ce genre de chose en standard, sauf à utiliser des version payantes spécifique comme celle de Fujitsu). Le "In Memory" existe dans Oracle (limité à la BUI) et dans MS SQL Server (LOAP/OLTP).
Pas de procédures compilées natives dans PostGreSQL. Cette fonctionnalité qui permet d'accélérer notablement les écritures des tables "in memory" n'existe pas dans PG. Elle existe dans MS SQL Server.
Optimiseur limité... Qui dit volume dit souvent requête complexes. En pratique l'optimiseur de PG n'est pas capable d'aller au-delà de 8 jointure GEQO prend le relai et pisse des plans aléatoirement bon... ou mauvais ! La ou la R&D de Microsoft ou Oracle est irremplaçable.
Tag de requête interdit dans PostGreSQL. Dès que le plan de requête devient très complexe, alors il faut parfois donner un coup de pouce en utilisant un "hint" (tag de requête) pour forcer le moteur à adopter une certaines stratégie algorithmique. Bien que le recours à ce stratagème ne soit pas toujours très conseillé, il est utile, notamment en urgence ou pour corriger un plan déficient. PG interdit ce genre de choses (c'est le seul SGBDR a avoir cette position radicale et imbécile). Mais certaines versions payantes de PG le propose...
Pas de possibilité de correction de plan d'exécution dans PostGreSQL. Certains SGBDR possèdent de nombreux outil pour corriger les plans de requêtes anormalement lent. C'est sous la forme d'un module d'auto apprentissage. Par exemple sous SQL Server (Query Store + Intelligent Query Processing). Tous les plans de requêtes sont stockés, analysé et surveillé et en cas de dérive un plan plus adapté est forcé... Cela n'existe pas dans PG.
Très faible niveau de récriture de requête dans PostGreSQL. Le moteur relationnel de Microsoft SQL Sever permet récrit les requêtes pour obtenir des plans d'exécution plus rapide. Cela passe par différentes adaptation (jointures adaptative, exécution entrelacée des variables table, mode d'exécution "batch" algorithmique, enlignement des fonctions scalaires...)
Limitation des collations dans PostGreSQL. Les recherches insensibles à la casse ou aux accents sont plus que limitées et parfois impossible dans PG. Alors que SQL Server présente plus de 5000 collations avec gestion des sensibilités ou non à la casse, aux diacritiques, aux kanatypes, à la largeur du caractères (2=² ?), etc.
Statistiques d'optimiseur très limitées dans PostGreSQL. PostGreSQL ne permet pas de créer des statistiques combinées sur plusieurs colonnes ce qui fait qu’en cas de restriction (clause WHERE, HAVING, prédicats des JOINs...) portant sur de nombreux critères d’une même table, l’optimiseur est incapable d’estimer correctement les cardinalités et produit des plans ineptes. De même d'ailleurs pour les requêtes LIKE '%toto%'...
Pas de cache pour les requêtes ad hoc dans PostGreSQL. Contrairement à la concurrence, PostGreSQL ne propose pas de mettre en cache les plans des requêtes « ad hoc » pour réutilisabilité, sauf à explicitement modifier le code applicatif en obligeant toute requête à passer par une phase de préparation, ce qui alourdit le code et augmente le temps de traitement.
VACUMM PostGreSQL bloquant. MVCC crée des lignes fantômes liées au versionnement du verrouillage optimiste. Ces lignes sont créées dans les mêmes pages que les lignes "vivantes", ce qui les alourdi considérablement. Il faut alors allez nettoyer ces pages des lignes fantômes, mais cela nécessite un verrou bloquant les pages durant le nettoyage (opération VACUUM). En pratique cette opération s'avère lourde et génère de nombreux verrous mortel. Impossible à utiliser dans une base fortement transactionnelle.
Opérateur COUNT lent dans PostGreSQL. Du fait même du MVCC, le comptage d'occurrence nécessite un parcours exhaustif des lignes des pages. Dans les SGBDR dont les lignes fantômes sont gérées en dehors des pages le comptage d'occurrence peut se faire par la lecture des entêtes des pages sans devoir les parcourir. Le résultat est que PG s'avère le plus lent des SGBDR sur la plupart des cas de comptage. SQL Server s'avérant le plus rapide devant même Oracle.

... !

A +