Des minima sociaux par contre.
Une discussion SQL pas académie française svp :)
Version imprimable
Des minima sociaux par contre.
Une discussion SQL pas académie française svp :)
Pour ton information, au cours d'un show Microsoft à la Porte Mailot au palais des congrès il y a un peu plus de 10 ans, le directeur de la R&D de Microsoft qui est un français, avait balancé en pleine discussion devant un millier d'auditeurs que Microsoft cherchait depuis plusieurs années à avoir un langage aussi productif que PHP… Et envisageaient d'abandonner ce projet pour apporter des éléments complémentaires à PHP. C'est ainsi que l'on a vu venir, peu après, des pilotes spécifique de SQL Server pour PHP…. Et c'est ainsi que Microsoft est passé d'un monde fermé (avec Steve Ballmer) à un monde ouvert (Satya Nadela) et est devenu aujourd'hui l'un des plus gros contributeur du libre…Citation:
Envoyé par Sodium
L'orientation de Microsoft est claire. C'est "Cloud First". Maintenant, je vous laisse deviner que est le système d'exploitation derrière SQL Azure par exemple...
A +
Ca c'est facile c'est du Linux :)Citation:
Envoyé par SQLpro
taquineur, va !! ;)Citation:
Envoyé par MaitrePylos
Et donc ça pour toi c'est une preuve de la compétence de Microsoft niveau serveurs ? On sait pas faire donc on va arrêter d'essayer ? Et donc c'est les meilleurs ? Non mais c'est une défense originale y a pas à dire.Citation:
Envoyé par SQLpro
Ben oui ils vendent leurs services ils ne vont pas utiliser l'OS d'en face... Donc c'est ton deuxième argument ? Les serveurs Microsoft sont supérieurs parce qu'ils sont utilisés par Microsoft ? Tu es trop fort, tu devrais te lancer comme négociateur dans les brigades anti-terroriste, tu as un avenir radieux.Citation:
Envoyé par SQLpro
Ca tombe à point : https://www.reddit.com/r/PostgreSQL/..._of_databases/
Mais non de toute façon Postgres c'est nul, c'est pas utilisé sur les serveurs Azure, il te faut quelle preuve de plus ? :weird:
contribue à quoi?Citation:
Envoyé par SQLpro
kde?
libreoffice?
openjdk?
gcc?
linux autrement que leur driver?
eclipse?
Apache HTTP Server?
postgres?
mariadb?
comment jugé de la qualité d'un commit? combien de ligne ajouté? combien d'enlevé?
des stats de marketeux de patron pressé de github, on sait ce que ça vaut
Setup
J'ai fait un test sur une machine Ryzen 1800, 32GB DDR4 3000.
Dual-boot : Windows 10 OEM à jour, Ubuntu 19.10 à jour.
SQL Server express (2018 ?) tout frais téléchargé à l'instant.
PostgreSQL 12.2 (Ubuntu 12.2-1.pgdg19.10+1) on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 9.2.1-9ubuntu2) 9.2.1 20191008, 64-bit
Au passage sqlserverexpress+ssms c'est environ 1.5GB de téléchargement; postgres+pgadmin4 installé depuis le dépôt pgdg c'est dans les 150MB.
Je n'ai touché absolument à rien à la configuration de SQLServer (j'ai lu superficiellement qu'il pouvait utiliser toute la mémoire par défaut); j'ai augmenté à 500MB les shared_buffers dans pg_hba.conf. C'est une partie que je ne maîtrise pas du tout.
Construire un jeu de données un peu plus intéressant
Quel cruel manque de datasets libres au passage...data.gouv.fr est plutôt risible....
J'ai pris grosso modo toute la comédie humaine de Zola et ai mis chaque mot dans une ligne de la table :
ebook-convert vient de la super liseuse Calibre.Code:
2
3
Le travail de préparation des données, c'est à des années lumière plus professionnel côté linux avec notamment les coreutils et les pipes unix...
Cela donne un csv d'environ trois millions de lignes.
Question clicougnette, l'import du csv prend 20 clics sur ssms, et littéralement 2 sur pgadmin4 - ce dernier outil est développé très rapidement depuis quelques mois, il commence à me bluffer, alors que je contribue à pgModeler.
Alors c'est prêt, on y va :
Côté postgres
Côté sqlserverCode:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
A noter :Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20CREATE TABLE T (ID BIGINT PRIMARY KEY, DATUM NVARCHAR(256) COLLATE French_CI_AI); create index i on T(datum); set statistics time on select count(*) from t where datum='a'; set statistics time off Temps d'analyse et de compilation de SQL Server : , Temps UC = 0 ms, temps écoulé = 0 ms. SQL Server \endash Temps d'exécution : , Temps UC = 16 ms, temps écoulé = 114 ms. Rows Executes StmtText StmtId NodeId Parent PhysicalOp LogicalOp Argument DefinedValues EstimateRows EstimateIO EstimateCPU AvgRowSize TotalSubtreeCost OutputList Warnings Type Parallel EstimateExecutions 1 1 SELECT COUNT(*) FROM [t] WHERE [datum]=@1 1 1 0 NULL NULL NULL NULL 1 NULL NULL NULL 0,2515709 NULL NULL SELECT 0 NULL 0 0 |--Compute Scalar(DEFINE:([Expr1002]=CONVERT_IMPLICIT(int,[Expr1004],0))) 1 2 1 Compute Scalar Compute Scalar DEFINE:([Expr1002]=CONVERT_IMPLICIT(int,[Expr1004],0)) [Expr1002]=CONVERT_IMPLICIT(int,[Expr1004],0) 1 0 0 11 0,2515709 [Expr1002] NULL PLAN_ROW 0 1 1 1 |--Stream Aggregate(DEFINE:([Expr1004]=Count(*))) 1 3 2 Stream Aggregate Aggregate NULL [Expr1004]=Count(*) 1 0 0,0359357 11 0,2515709 [Expr1004] NULL PLAN_ROW 0 1 59892 1 |--Index Seek(OBJECT:([test].[dbo].[T].[i]), SEEK:([test].[dbo].[T].[DATUM]=CONVERT_IMPLICIT(nvarchar(4000),[@1],0)) ORDERED FORWARD) 1 4 3 Index Seek Index Seek OBJECT:([test].[dbo].[T].[i]), SEEK:([test].[dbo].[T].[DATUM]=CONVERT_IMPLICIT(nvarchar(4000),[@1],0)) ORDERED FORWARD NULL 59892 0,149597 0,0660382 9 0,2156352 NULL NULL PLAN_ROW 0 1
- par défaut, sql server qui crée un clustered_index est effectivement beaucoup plus rapide, d'un facteur 3 à 4.
- avec index des deux côtés, je suis assez loin de fanfaronner sur la "domination de postgres par rapport à son clone privatif", je concluerai pour ma part que les deux sont plutôt équivalents sur ce cas précis - sqlserver fait un index seek, le planner de postgres opte pour un bitmap index scan, le parcours matriciel fait sens vu le rapport volume de résultat/volume de recherche.
Par ailleurs, je doute d'avoir envie de lire 90 pages comme celle ouvrant cette enfilade :
- un bon benchmark a un description rigoureuse des configurations matérielle, système et logicielle,
- un protocole de test et des résultats détaillés, synthétiques et jolis ...
- ...sur un SCM.
C'était une expérience intéressante et m'a fait entrevoir la vague envie de considérer à continuer sur un blog ici / un site dédié / une suite publique téléchargeable sur docker/guix orchestré.
Tu as mal lu, SQL Server Express est limité à 1 Go.Citation:
Envoyé par MaximeCh
C'est d'ailleurs LE truc qui freine son utilisation quand on veut du 100% gratuit : cette limite est facilement atteinte et pénalise grandement les performances.
Cependant, ici la table reste toute petite, donc 1 Go de mémoire est amplement suffisant.
Pour ce qui est d'importer des données dans SQL Server, il y a la commande BULK INSERT https://docs.microsoft.com/fr-fr/sql...l-server-ver15
Ça évite les 20 clics et probablement bien plus rapide (et scriptable).
Pour le reste, il serait intéressant de refaire le test avec SQL Server et PostGreSQL sous le même OS.
L'un et l'autre peuvent tourner sous Windows et sous Linux indifféremment.
SSMS n'existe pas sous Linux, mais les outils en ligne de commande sont largement suffisants pour faire ce bench.
https://docs.microsoft.com/fr-fr/sql...l-server-ver15
Très intéressant. Et je suis d'accord avec ta conclusion, la différence est trop faible pour affirmer qu'un test très légèrement différent ne donnerait pas le résultat inverse.Citation:
Envoyé par MaximeCh
Pendant que tu y es, histoire de clôturer la bataille de méthodologie, est-ce que tu pourrais refaire le même test en remplaçant l'usage de la collation par la fonction unaccent, et même la fonction écrite en SQL? Dans les deux cas, avec et sans index? Juste histoire d'enfoncer le clou et de prouver qu'il faut comparer juste ce qui est comparable, et que donc le test de SQLPro était biaisé (je me doute bien que la fonction en SQL sera plus lente, mais ça m'intéresse de savoir de combien).
Évidemment rien ne m'empêche de faire le test moi-même, seulement ce serait bien que tous les tests soient faits sur la même machine.
De plus, les collations non déterministes ne sont disponibles que sur PostgreSQL 12, donc celui qui est bloqué à une version plus ancienne peut avoir besoin d'utiliser une autre méthode. Surtout si on se retrouve avec un cas non traité par les collations ou par unaccent (une langue rare par exemple, ou un ordre de tri spécifique à un métier). Donc même si l'usage des collations est l'idéal, ce n'est pas toujours possible.
Même si avoir tout en mémoire favorise le serveur qui utilise cette technique, je reste dubitatif sur la viabilité de cette méthode en utilisation réelle: il faudrait avoir un jeu de données nettement plus gros que la mémoire disponible (on pourrait refaire le test sur une vieille bécane avec moins de 1 GO de RAM). Parce que dans la vie réelle, je doute qu'on ait toujours plus de RAM que de données à traiter.Citation:
Envoyé par MaximeCh
ça porte un autre nom mais ça existe aussi pour PostgreSQLCitation:
Envoyé par StringBuilder
Bonjour,
J'ai quelques questions à propos de PostgreSql version 12.
Histoire de voir ce que donnent les différents benchs sur ma machine, je tente de l'installer sur une VM.
Lorsque je regarde la documentation de SQL Server, je vois que parmi les versions préconisés, il y a ubuntu 16.04 LTS. https://docs.microsoft.com/fr-fr/sql...l-server-ver15
J'ai pas bien compris pourquoi il n'y a pas la version 18.04 ou 19.01 mais après être resté bloqué avec une Debian puis avoir galeré avec la ubuntu 18.04 je préfère rester dans les clous de l'éditeur cette fois.
Je me lance donc dans l'installation de PostgreSQL.
Je suis bêtement cette doc indiquant comment installer PG sur ubuntu 16.04 : https://www.digitalocean.com/communi...n-ubuntu-16-04
Rien de bien surprenant :
Et là, c'est le drame : ça m'installe une version 9.5Code:apt-get install postgresql postgresql-contrib
Donc la version "officielle" de PG, c'est 9.5 ou 12 ? Quel est le statut de la 12 ? Elle est LTS ? Beta ? Où sont passés les versions 10 et 11 ?
Toutes les versions de PostgreSQL sont supportées 5 ans à partir de la sortie de la version officielle (pas de la béta). Il n'y a donc pas de différence entre une LTS et une autre, ou alors toutes sont des LTS.Citation:
Envoyé par StringBuilder
La dernière stable c'est la 12, mais les 9.4, 9.5, 10 et 11 sont encore maintenues, mais uniquement pour corriger des bugs ou failles de sécurité. Pour les nouvelles fonctionnalités, c'est la 13 qui n'en est même pas encore à la béta.
En effet, le fait que Ubuntu 16.04 soit en LTS signifie qu'elle met à jour les logiciels mais uniquement pour les corrections (bugs ou failles de sécurité), pas les versions majeures!Citation:
Envoyé par StringBuilder
Donc si la dernière stable en avril 2016 était la 9.5, seules les mises à jour mineures (de 9.5.0 à actuellement 9.5.21) seront apportées par la distribution.
C'est d'autant plus vrai avec PostgreSQL pour une autre raison: migrer une base de la version 9.5 à la version 12 n'est pas une opération qui peut être faite automatiquement. Donc le gars qui a installé une Ubuntu en 2016 n'a peut-être pas envie de passer du temps à migrer toutes ses bases ... sauf évidemment quand PostgreSQL 9.5 passera en phase out, et vu le rythme de sortie, Ubuntu aura produit une nouvelle LTS d'ici là.
Par contre, une chose qui est très bien avec Debian (et donc avec Ubuntu qui en est dérivée) c'est qu'il est assez facile de faire cohabiter la version 9.5 proposée par la distribution et la version 12, même simultanément (avec d'autres distributions c'est toujours possible mais pas forcément aussi facile), ce qui est très bien pour des tests comparatifs ou de non régression par exemple. C'est exactement ce que j'ai fait pour le test que je détaille dans un message précédent, car je ne souhaitais pas migrer des bases en cours d'utilisation. La seule chose à faire, c'est qu'avant de faire l'installation dans Ubuntu, il faut ajouter manuellement le repository de PostgreSQL en complément de celui d'Ubuntu (petite précision, même si cette page parle de la version 11, le repository ne change pas, il pointe désormais sur la 12). Ensuite, si une ancienne version est déjà installée, il se débrouillera pour installer la 12 avec un port différent, ce qui leur permet de cohabiter facilement.
Citation:
Envoyé par esperanto
A noter : ni unaccent(), ni remove_fr_accents() ne s'intéressent à la casse, l'ensemble retourné est donc plus petit qu'avec la collation 'CI AI'.Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
Une équipe neutre qui fait vivre une suite de cas d'usage, avec données ouvertes.
Une équipe SQL Server, une autre PostgreSQL : chacune montre le meilleur actuel de sa solution par rapport aux besoins.
L'équipe neutre analyse, synthétise et publie les résultats.
Est-ce que ça ne serait pas un super moyen pour y voir plus clair?
Merci Maxime, les tests sont très intéressants
La première chose qu'on constate, c'est que quand l'index est créé correctement (avec la fonction, contrairement à ce qu'avait fait SQLPro) les performances sont largement comparables à l'usage de la collation (40 ms contre 34 ms). Le plus surprenant étant encore que la fonction remove_fr_accents, après indexation, ait les mêmes performances que unaccent2 qui fait pourtant appel à du code C.
Par contre ça montre bien qu'une fonction en SQL ne peut rivaliser avec une fonction C, au moins avant indexation, en témoigne la différence entre unaccent (314 ms sans index) et unaccent2 (5162 ms, là je suis un peu surpris quand même). Et aussi bien sûr l'importance de bien choisir son index, l'usage d'indexes sur fonction s'avérant très efficace.
Et quand bien même, on se rend compte qu'avec de vraies données (quand l'index comprend un peu plus de deux valeurs uniques), le rapport de 1 pour 300 000 est purement fantaisiste, tout au plus on est à 1 pour 250 dans le pire des cas (29 secondes sans index ni collation contre 116 ms avec collation et index de l'autre...)
C'est vrai il faudrait peut-être essayer de combiner avec lower, y compris dans l'index bien évidemment...Citation:
Envoyé par MaximeCh
Ce que je comprends c'est que le coût d'exécution de la fonction est déporté au moment de la création de l'index. Pendant la requête, le parcours ou la recherche dans l'index retourne les valeurs pré-calculées stockées dans l'index lui-même.Citation:
Envoyé par esperanto
Exact. Ça vaudrait le coup de rajouter le coût de la création de l'index (en activant \timing on dans le client psql) du coupCitation:
Envoyé par MaximeCh
Code:
2
3
4
5
6
7
Sauf erreur de ma part, cela n'a rien de surprenant :Citation:
Envoyé par esperanto
Lorsque tu crées un index utilisant une fonction, le temps d'interrogation de la colonne est le même que ce soit une colonne calculée ou non.
Donc ici, la seule différence mesurable, c'est le temps qu'ont mis les fonctions à traiter les valeurs littérales 'a'
A ce moment, on se rend compte que les quelques millisecondes sont énormes, puisque c'est la différence nécessaire pour traiter une seule chaîne d'un seul caractère.
On peut en déduire par conséquent que la fonction d'indexation sera fortement pénalisée par la fonction SQL par rapport à la fonction C.