Discussion :

[rsql123]

Bonjour, tout le monde,

Depuis 4 ans, je développe un clone léger et simplifié de MS SQL Server.

J'ai toujours voulu que SQL Server tourne sur Linux, alors je me suis lancé pour développer un clone sur l'OS au pingouin.
Ceci dit, j'ai réussi aussi à le compiler sur Windows.

https://www.rsql.ch

Pour télécharger et essayer sur Windows:

https://www.rsql.ch/guide/download_page/
https://www.rsql.ch/guide/installation_windows/

Cela m'aiderait beaucoup si quelqu'un a un peu de temps pour l'essayer et me donner son avis ou une première impression.

Le programme n'est pas encore fini. J'en ai encore pour 6 mois ou plus.
Pour l'instant, il est achevé à 90% et contient 120'000 ligne de code en Golang https://golang.org/ et un peu de C.

Il est encore très lent parce que les indexes sont implémentés, mais les SELECTs ne les utilisent pas encore.
Donc, il fait un scan des tables, ce qui est très lent, surtout quand il y a des jointures.
Mais je suis en train de travailler sur l'optimiseur, justement ;-)

Et pour l'instant, ORDER BY et GROUP BY ne sont pas encore implémenté.

Je le redis, je n'implémente pas tout, c'est vraiment un clone simplifié.

Mon projet est de le publier sous licence libre quand il sera utilisable, l'année prochaine je pense.
Ca nous fera économiser le prix des licences ;-)))

[Invité]

J'ai toujours voulu que SQL Server tourne sur Linux, alors je me suis lancé pour développer un clone sur l'OS au pingouin.

Tu es au courant que la version Linux est prévue pour être disponible au grand public à la mi-2017 et qu'elle est déjà en cours de test avancé.

[rsql123]

Tu es au courant que la version Linux est prévue pour être disponible au grand public à la mi-2017 et qu'elle est déjà en cours de test avancé.

Je sais, mais le prix des licences sera certainement le même que sous Windows.
C'est-à-dire, très cher !

Et Microsoft ne mettra pas SQL Server sous licence libre. Après tout, SQL Server leur rapporte 7 milliards de $ de chiffre d'affaire par an...

[StringBuilder]

Vous vous êtes lancé dans un "clone de SQL Server", sous Linux.

Ok.

Mais dans le même temps, vous dites que pour le moment, les index ne sont pas utilisables, que order by et group by ne fonctionnent pas...

Et là, j'avoue que je sens comme une contradiction !

En effet, vous semblez en être à une étape encore moins avancée que l'utilisation d'un driver ODBC pour interroger un fichier CSV... Et vous prétendez cloner ce qui se fait à peu près de mieux sur le marché.

Postgre, qui est gratuit et open source, est bien plus proche du but que vous : il s'agit d'un "vrai" SGBD, qui supporte pas mal la norme SQL, y compris les éléments avancés des dernières moutures de la norme.

Pourquoi vous lancer dans un clone (qui ressemble plus à un bout de mue d'antenne) plutôt que d'utiliser ce qui se fait déjà ?

Car même si au final vous voulez un SGBD qui respecte à la virgule près le comportement de SQL Server, ce qu'est loin de faire Postgre, le travail sera toujours moins important de repartir d'un outil où 30 à 40% du boulot est déjà fait (notamment le moteur, qui est quand même le noeud gordien du bignou), plutôt que de repartir de la feuille blanche, et arriver, au bout de 5 ans à un truc qui n'a pas d'optimiseur, qui ne sait même pas trier des résultats ni encore moins faire des regroupements.

J'imagine donc que ça ne fait pas non plus :
- de gestion d'intégrité
- de déclencheurs
- de langage évolué type T-SQL ou PL/SQL
- de CTE
- de fonctions de fenpêtrage
- de fonctions analytiques
- de gestion des verrous concurrents
- etc.

Dites que vous faites un clone de Microsoft Jet, et même si vous en êtes certainement à moins de 5%, vous en serez certainement bien plus proche que d'un clone de SQL Server...

Sans vouloir dénigrer votre travail (juste la prétention que vous y mettez) votre topic me fait penser à :

Hey, je fais un clône de la fusée Arianne 5 : j'ai déjà peint "Agence Aérospaciale" sur un bout de carton !

[SQLpro]

Pour information, le coût de développement de SQL Server est approximativement de :

• 1000 années homme en R&D sur le moteur relationnel
• 400 années homme en R&D sur le moteur de stockage

Sans parler de tous les modules annexes comme par exemple la sauvegarde/restauration
{petit ajout debut} Jean-Claude DEVANT, architecte logiciel français chez MS et responsable de la partie réplication, nous avait indiqué que le nombre de ligne de code de l'ensemble des outils de réplication de Microsoft représentait un volume supérieur a celui du noyau relationnel... Donc ajoutez en sus un peu plus de 1000 années hommes en R&D pour ce module.... !!!! {petit ajout fin}
...
Lorsque vous en serez à 1% de cela, vous aurez donc consacré déjà 14 années de votre vie !!!

Bon courage !

A +

[julien94320]

Bonjour,

Belle initiative! Comme l'ont dit les autres membres je pense que votre travail est encore loins du but ...

Bon courage car le travail risque d'etre très long surtout seul. Et a la fin vous ne souhaiterez pas récupérer un peu d'argent de votre bien ?

Je vois un énorme avantage pour vous dans votre démarche : vous apprenez le moteur SQL et sa norme ce qui est déjà bien ( si vous faite votre travail correctement, ce que j'ose esperer ! )

Vous pourrez prétendre a une expertise SQL dans quelques temps

A+

Julien

[Donpi]

• 1000 années homme en R&D sur le moteur relationnel
• 400 années homme en R&D sur le moteur de stockage
  Lorsque vous en serez à 1% de cela, vous aurez donc consacré déjà 14 années de votre vie !!!

Aller... Un développeur seul et motivé doit avoir un rendement au moins 5 fois plus élevé que dans les grandes structures.

Je vous trouve tous très dur avec rsql123.

[mikedavem]

Je trouve l'initiative très ambitieuse pour ma part mais après tout pourquoi pas ...
C'est clair qu'il va falloir beaucoup de motivation car développer ce type de produit tout seul est relativement long et périlleux.
Je te souhaite bon courage dans ton entreprise en tout cas!

++

[Christophe LAPORTE]

Pour information, le coût de développement de SQL Server est approximativement de :

• 1000 années homme en R&D sur le moteur relationnel
• 400 années homme en R&D sur le moteur de stockage

Sans parler de tous les modules annexes comme par exemple la sauvegarde/restauration
{petit ajout debut} Jean-Claude DEVANT, architecte logiciel français chez MS et responsable de la partie réplication, nous avait indiqué que le nombre de ligne de code de l'ensemble des outils de réplication de Microsoft représentait un volume supérieur a celui du noyau relationnel... Donc ajoutez en sus un peu plus de 1000 années hommes en R&D pour ce module.... !!!! {petit ajout fin}
...
Lorsque vous en serez à 1% de cela, vous aurez donc consacré déjà 14 années de votre vie !!!

Bon courage !

A +

Jean-Yves !!!
Je ne crois plus qu'il soit encore en charge de la feature.

[François DORIN]

Bonjour,

Effort très louable, mais j'avoue que cette tâche me parait complètement démesuré pour un seul homme ! Il suffit de voir la taille des équipes travaillant sur les grands SGBD et la durée des projets. Même si tu peux bénéficier des résultats obtenus lors de la réalisation d'autres SGBD pour l'écriture du moteur, du stockage, etc... cela me semble tout simplement énorme.

As-tu envisagé de ne pas partir de zéro mais d'utiliser un SGBD existant et open-source (Postgresql, MariaDB, etc...) afin finalement de ne réaliser que la traduction du T-SQL vers le SQL du SGBD cible ? Cela me parait à la portée d'un seul homme, tout en bénéficiant d'un SGBD ayant déjà été éprouvé (car oui, je n'ai pas abordé la gestion des bugs et des risques encourus, notamment la perte de données).

Ou, si c'est possible, de remplacer le parser SQL d'un moteur existant par un parseur T-SQL (c'est une légère variante de ma suggestion précédente).

[rsql123]

Merci pour les encouragements ;-)

J'ai bien dit que je voulais faire un clone extrêmement simplifié de SQL Server, pas une copie de l'Enterprise Edition.
C'est-à-dire une petit truc assez puissant pour gérer des tables avec environ un million de record (dans mes essais, j'ai cependant chargé jusqu'à 100 millions de records dans une table).

Quant à la charge de travail que cela demande, SQLite est la base de données SQL la plus utilisée dans le monde et est pratiquement l'oeuvre d'un seul homme.
Ce que je veux faire, c'est une sorte de SQLite un peu plus puissant, qui puisse interpréter les bases de T-SQL, destinées aux petites et moyennes applications.

@dorinf:
Merci pour les suggestions, mais le code source de Postgresql ou MySQL est extrêmement complexe à comprendre.
J'ai essayé d'utiliser leur moteur de stockage, mais le lien entre l'évaluateur d'expression et le moteur de stockage est très grand (à cause des Sargs).
Et surtout, les type de données ne sont pas les mêmes.
Finalement, il s'est avéré beaucoup plus simple d'implémenter moi-même un cache, un btree et le logfile, ça m'a pris 6 mois, je crois.
Le plus dur à été d'écrire le compilateur SQL, car TSQL est un vrai langage de programmation avec des variables, des boucles et touçatouça, et d'implémenter les types de données et les fonctions.
La très grosse erreur que j'ai faite a été d'écrire le code en C. Quand je suis tombé sur les spécifications de Golang, j'ai compris que ce langage me simplifierait infiniment la vie (garbage collector, multithreading, etc). Mais la migration du code de C vers Golang m'a pris un an et demi.

Mais ça avance. Voilà un petit exemple de ce que mon petit clone arrive à exécuter:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
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
 
CREATE TABLE [dbo].[t] (
    [id] INT IDENTITY(1, 1) NOT NULL,
    [name] VARCHAR(20) NULL,
    CONSTRAINT [$sysidx$0] PRIMARY KEY CLUSTERED ([id])
);
 
GO
 
INSERT INTO t VALUES (‘Fred’), (‘Maria’), (‘Omer’);
 
SET NOCOUNT ON;
 
DECLARE @i INT = 0;
 
BEGIN TRAN;
 
WHILE @i<10
    BEGIN
    INSERT t(name) VALUES ('Row_' + CAST(@i AS VARCHAR));
    SET @i += 1;
    END
 
COMMIT;
 
SELECT * FROM t;

[François DORIN]

J'ai bien dit que je voulais faire un clone extrêmement simplifié de SQL Server, pas une copie de l'Enterprise Edition.

C'est là où est le problème de communication je pense D'un côté, tu as clone, de l'autre extrêmement simplifié. Avec clone, on s'attend à un logiciel équivalent et compatible. Ce que tu vises, c'est la compatibilité avec T-SQL. C'est très différent !

Du coup, je pense qu'on peut oublier :

• Le chargement d'un dump fait avec SQL Server ;
• Les procédures et fonctions CLR ;
• L'utilisation des connecteurs SQLServer pour interroger la BD.

Ensuite, tant que ton projet n'aura pas été soumis à rude épreuve pour l'éprouver, j'ai bien peur qu'il ne soit pas beaucoup utilisé.

[Invité]

J'admire ta persévérance.
C'est un projet un peu fou mais pourquoi pas !
Qu'importe ce que ça donnera vraiment au final, tu auras appris beaucoup de choses.

Et pour une fois, je n'ai mis aucun second degré dans ce message.