[spip-dev] sqlite ou mysql, je ne sais plus ?

Dev
1

Hello les développeurs,

Désolé de poster ici mais je suis perdu ! Et c'est bien aux développeurs que je m'adresse.

Je vais installer une série de nouveau SPIP, bonne, bonne, me dis-je... je vais profiter de la sortie de Spip 3.0.4 pour le faire.

D'après ce que j'avais lu ou compris sur différentes listes Spip, Sqlite était "meilleur" que MySQL, mon choix était donc facile à l'install, d'autres intégrateurs me confirment également avoir compris cela !

Depuis le doute me gagne... j'ai lu des choses pas très glorieuses sur Sqlite... pas de fonction now, pas de repair, pas de base de grande taille, pas de trop de connexions simultanées, ...

Mes questions sont simples :

Sqlite est "le" nouveau choix de Spip par défaut, si oui pourquoi ?

MySQL sera-t-il maintenu par la dev-core ?

Désolé de vous embêter avec cela, mais cela me semble important pour bien comprendre la "future" direction que prend Spip 3 et si je suis à côté de la plaque, il suffit de me le dire aussi :slight_smile:
Si un lien existe sur le net, je ne l'ai pas trouvé... juste ceci => http://contrib.spip.net/Portage-de-SPIP-en-SQLite mais qui date un peu.

Merci le core qui a certainement autre chose à faire pour l'instant :wink:

2

Bonjour,

Je ne suis pas dans le dev, mais voici ce que j'ai compris comme utilisateur :

Non, SQlite n'est pas "mieux" que MySQL, et ce n'est pas le choix par défaut de SPIP.
SPIP s'étend à tous les systèmes de base de données disponibles, pour l'instant MySQL (historique), PostgreSQL (plus costaud je crois), et SQLite plus léger.

L'intérêt de SQLite est que sa gestion est intégré à Php5, sans installation de moteur de BD supplémentaire comme MySQL, ET que la base est incluse dans un unique fichier.
Donc si tu as besoin de déplacer ou sauvegarder régulièrement ton site, c'est plus facile.

Voilà, à compléter...

3

Hello

2012/8/29 Paul <paul@hmpnet.be>

Hello les développeurs,

Désolé de poster ici mais je suis perdu ! Et c’est bien aux développeurs que je m’adresse.

Je vais installer une série de nouveau SPIP, bonne, bonne, me dis-je… je vais profiter de la sortie de Spip 3.0.4 pour le faire.

D’après ce que j’avais lu ou compris sur différentes listes Spip, Sqlite était « meilleur » que MySQL, mon choix était donc facile à l’install, d’autres intégrateurs me confirment également avoir compris cela !

Non, sqlite n’est pas meilleur que mysql en terme de performances.
La différence sera cependant négligeable si ton site est à faible trafic (dans le cas contraire, les accès concurrents sur ton fichier peuvent ralentir ton site).

Cela dit, je recommande toujours de garder mysql comme base de données
A mon avis le passage de sqlite par défaut est une régression, car :

  • on perturbe trop les utilisateurs par rapport à l’'historique
  • ceux-ci achètent/louent généralement un hébergement Apache/php/mysql avec phpmyadmin (pas d’outils d’admin sqlite)
  • mysql est une base reconnue comme fiable/stable/la plus répandue et l’utilisateur se voit proposée un base qu’il ne connait généralement pas et dont il ne peut comparer la fiabilité/perf (trop lié à l’usage)

Conclusion : tu hésites entre sqlite et mysql ? Alors utilises mysql car je vois aucune raison de ne pas l’utiliser. Ai-je tord ?

.Gilles

4

Gilles,

Pourtant on pas pas restaure un site en spip3 actuellement en mysql.

Repondu depuis mon android.

5

A priori, les 3 systèmes (MysSQL, SQLite et Postges) seront maintenu. SPIP propose par défaut SQLite car il ne nécéssite pas d'identifiant.

En revanche, sauf pour des sites trèés particulier, je déconseille de l'utiliser, pour 3 raisons :
- pb de perf lors des accès en écriture (même si SPIP gère cela normalement)
- pas de logiciel de gestion facile (un extension FF je crois)
- pas de possibilité de passer simplement à un autre système.

Perso, je l'utilise pour un besoin seulement : une BDD de carte que je gère en SPIP et que j'ai besoin de synchroniser régulièrement.

6

là c'est autre chose Pierre : il faut distinguer comment est stocké la base et comme elle est sauvegardé. Que je sache SPIP n'a jamais utilisé le dump.xml comme base de donné, mais juste comme sauvegarde.

C'est la même chose pour SPIP 3 avez SQLite : SQLite est juste le système utilisé pour sauvegarder la base de donnée.

Maïeul
http://blog.maieul.net
http://geekographie.maieul.net

7

2012/8/29 Maïeul <maieul@maieul.net>

Hello les développeurs,

Désolé de poster ici mais je suis perdu ! Et c’est bien aux développeurs
que je m’adresse.

Je vais installer une série de nouveau SPIP, bonne, bonne, me dis-je…
je vais profiter de la sortie de Spip 3.0.4 pour le faire.

D’après ce que j’avais lu ou compris sur différentes listes Spip, Sqlite
était « meilleur » que MySQL, mon choix était donc facile à l’install,
d’autres intégrateurs me confirment également avoir compris cela !

Depuis le doute me gagne… j’ai lu des choses pas très glorieuses sur
Sqlite… pas de fonction now, pas de repair, pas de base de grande
taille, pas de trop de connexions simultanées, …

Mes questions sont simples :

Sqlite est « le » nouveau choix de Spip par défaut, si oui pourquoi ?

MySQL sera-t-il maintenu par la dev-core ?

A priori, les 3 systèmes (MysSQL, SQLite et Postges) seront maintenu. SPIP propose par défaut SQLite car il ne nécéssite pas d’identifiant.

Ce n’est pas une raison suffisante pour justifier un changement de base de données par défaut, si ?
Tout le monde a les identifiants FTP et MySQL de son hébergement. Certes on gagne une étape d’installation, mais si c’est pour se poser plein de problèmes par la suite, cela me semble largement discutable !
En plus si on voit exploser le nombre de message de type « mon hébergement rame depuis son passage sous SPIP3 », le changement de la base de données y est peut-être pour quelque chose.

Quels sont les vrais arguments qui ont changé l’ordre de proposition des formats entre la 2.1 et la 3.0 ?

Je rajouterai un argument contre l’utilisation de sqlite :

  • les hébergeurs mettent parfois les données utilisateur sur un serveur à part; pratique pour des sauvegardes mais pas en terme de perf : c’était le cas d’Ouvaton par exemple, qui a un moment avait des problème de performance à cause d’un cache d’accès disques (filer) sous-dimensionné. En tout cas on rajoute du temps
  • il est possible via mysql de booster son hébergement en choisissant des config différentes pour la base de données, alors que c’est impossible pour sqlite (en tout cas sur un mutu). Si je prends le cas d’OVH, mysql n’y est peut-être pas forcément tip top mais l’utilisation à faible coût d’hébergement SQL Pro permet d’avoir un hébergement vraiment confortable.

La problématique de stockage des données est surtout une problématique de fiabilité (donc avec des configurations de type RAID5 sur des NAS externes). A contrario la problématique de mysql est un accès rapide (donc des caches mémoire, des disques durs rapides et des bases répliquées). Utiliser sqlite revient à devenir dépendant des temps d’accès de disques hébergeant les données, et d’une structure pas toujours pensée pour de la performance.

Maintenant quand on est en dédié on peut faire n’importe quoi (comme utiliser une partition virtuelle de type ramfs pour sqlite) mais ça ne concerne pas du tout l’utilisateur lambda

8

Maieul, dans ce cas quand tu fait une sauvegarde via SPIP tu peux pas la réimporter via SPIP, même version, ?

9

Hop, point de tentative de troll dans mes questions ou réactions :slight_smile:

Je précise aussi que je n'ai pas de "préférence" pour MySQL ou SQLite.

Tout le monde a les identifiants FTP et MySQL de son hébergement. Certes on
gagne une étape d'installation, mais si c'est pour se poser plein de
problèmes par la suite, cela me semble largement discutable !

Quels problèmes ?

Le/la user lambda qui a un site qui tourne chez un gros hébergeur dont je ne citerai pas le nom, dispose de SQLite par défaut.

En plus si on voit exploser le nombre de message de type "mon hébergement
rame depuis son passage sous SPIP3", le changement de la base de données y
est peut-être pour quelque chose.

On avait je pense autant, et même certainement plus, de messages du type :

Pourquoi mon site m'affiche un message d'erreur comme quoi le serveur SQL ne répond plus ?

Tout simplement parce que les bases de données MySQL des offres de base chez les gros hébergeurs sont souvent ultra limitées en nombre de connexion simultanées. Et ça, le user lambda il n'y peut rien, à moins de sortir la carte de crédit et de se lancer dans des manips un peu techniques.

Quels sont les vrais arguments qui ont changé l'ordre de proposition des
formats entre la 2.1 et la 3.0 ?

Là dessus je laisse les autres membres de la team donner leur avis, explications, etc.

Je rajouterai un argument contre l'utilisation de sqlite :
- les hébergeurs mettent parfois les données utilisateur sur un serveur à
part; pratique pour des sauvegardes mais pas en terme de perf : c'était le
cas d'Ouvaton par exemple, qui a un moment avait des problème de
performance à cause d'un cache d'accès disques (filer) sous-dimensionné. En
tout cas on rajoute du temps

Perso, j'ai testé une install SQLite sur un compte milieu de gamme chez un hébergeur du nord et cela fonctionne plutôt bien je trouve. Le site ne rame pas et je n'ai pas eu de retours à propos de lenteurs de la part des rédacteurs.

Peut être faudrait-il faire une série de benchs pour avoir des chiffres à comparer plutôt que de simples impressions.

10

2012/8/29 Bruno Bergot <brunobergot@gmail.com>

gagne une étape d’installation, mais si c’est pour se poser plein de
problèmes par la suite, cela me semble largement discutable !

Tout le monde a les identifiants FTP et MySQL de son hébergement. Certes on
Quels problèmes ?

Le/la user lambda qui a un site qui tourne chez un gros hébergeur dont je ne citerai pas le nom, dispose de SQLite par défaut.

Certains hébergeur bloquent sqlite.
C’est le cas de Free par exemple qui est assez utilisé dans le monde de SPIP me semble-t-il.
Ce qui est suffisant pour qu’on s’en inquiètes, non ?

Après les perfs de sqlite ou mysql dépendent beaucoup comme tu l’as dis de la configuration limitée par l’hébergeur. Il faudrait regarder hébergeur par hébergeur pour comparer.

En tout cas ce qui perturbe à mon avis c’est quand même ce choix par défaut d’une base qui n’est pas très connue (en tout cas pas trop mise en avant par les hébergeurs)

Je ne vois pas pourquoi on a changé cela et j’espère ne pas être le seul.
C’est possible de revenir en arrière ?

.Gilles

11

Je crois que l'idée derrière ce choix par défaut c'est :
sqlite simplifiera la vie aux ignares de l'internet.

Et ceux qui savent faire la différence
choisiront en connaissance de cause.

Mais je n'exclus pas que le raisonnement soit incomplet.

JLuc

12

2012/8/29 Bruno Bergot <brunobergot@gmail.com>

gagne une étape d’installation, mais si c’est pour se poser plein de
problèmes par la suite, cela me semble largement discutable !

Tout le monde a les identifiants FTP et MySQL de son hébergement. Certes on
Quels problèmes ?

Le/la user lambda qui a un site qui tourne chez un gros hébergeur dont je ne citerai pas le nom, dispose de SQLite par défaut.

Certains hébergeur bloquent sqlite.

Auquel cas on rebascule sur le choix par défaut de mySQL

C’est le cas de Free par exemple qui est assez utilisé dans le monde de SPIP me semble-t-il.
Ce qui est suffisant pour qu’on s’en inquiètes, non ?

Après les perfs de sqlite ou mysql dépendent beaucoup comme tu l’as dis de la configuration limitée par l’hébergeur. Il faudrait regarder hébergeur par hébergeur pour comparer.

En tout cas ce qui perturbe à mon avis c’est quand même ce choix par défaut d’une base qui n’est pas très connue (en tout cas pas trop mise en avant par les hébergeurs)

Je ne vois pas pourquoi on a changé cela et j’espère ne pas être le seul.

Parce qu’au moment de la première installation pour un débutant c’est plus facile car il n’a pas à chercher un login et un mot de passe de connexion à la base de donnée (alors qu’il ne sait même pas ce que c’est)
Parce que ça lui permet de copier tout son site (avec la base inclue) par une simple copie de fichier.
Parce que SQLite suffit en terme de performance pour 95% des sites sous SPIP existant, et que les 5% pour qui ça ne suffit effectivement pas ont les compétences pour le savoir

C’est possible de revenir en arrière ?

Toujours…

Cédric

13

Je reviens sur le cas particulier de Free.fr

2012/8/29 Cédric Morin <cedric.morin@yterium.com>

Certains hébergeur bloquent sqlite.

Auquel cas on rebascule sur le choix par défaut de mySQL

C’est le cas de Free par exemple qui est assez utilisé dans le monde de SPIP me semble-t-il.
Ce qui est suffisant pour qu’on s’en inquiètes, non ?

Juste une screencast pour montrer que le choix par défaut est bien sqlite sous Free :
http://screencast.com/t/Rj2WqDDJ

Le problème je pense est que lors de la création de l’espace perso on peut activer SQL ou MySQL ou Postgresql : du coup les 3 sont compilés dans PHP, alors qu’on ne peut en utiliser qu’un seul.

Dans le cadre de ma démo, c’est mysql qui est activé. Et bien entendu les autres options échouent.

Bon, le message d’erreur indique qu’il faut se référer à la doc de l’hébergeur, on peut considérer que l’utilisateur reviendra sur la bon choix.

Je reste quand même mitigé sur le choix sans explication. Peut-être qu’une intro expliquant à quoi correspondent ces bases peut être utile ?

PS.: ce problème impacte aussi la sauvegarde du site, dont le déroulement échoue sans explication (si ce n’est une erreur de squelette pas très rassurant) : http://screencast.com/t/dlUvnvN78
(testé sur la version stable de spip3.04)

.Gilles

14

Oups message envoyé par erreur en privé à Gilles :

Je reviens sur le cas particulier de Free.fr

2012/8/29 Cédric Morin <cedric.morin@yterium.com
<mailto:cedric…morin@yterium.com>>

    Certains hébergeur bloquent sqlite.

    Auquel cas on rebascule sur le choix par défaut de mySQL

    C'est le cas de Free par exemple qui est assez utilisé dans le
    monde de SPIP me semble-t-il.
    Ce qui est suffisant pour qu'on s'en inquiètes, non ?

Si on ne parle que de free peut-être faudrait-il attendre qu'ils aient mis à jour la version de php (prévue après le remplacement de tous leurs serveurs, en cours) pour voir si le choix par défaut fonctionne mieux ?

Juste une screencast pour montrer que le choix par défaut est bien
sqlite sous Free :
http://screencast.com/t/Rj2WqDDJ

Par contre attention chez free une fois qu'ils seront en php 5.3 il faudrait être bien sûr que l'option par défaut est mysql parce qu'ils interdisent explicitement les appels à des fichiers à la place de base sql.

Le problème je pense est que lors de la création de l'espace perso on
peut activer SQL ou MySQL ou Postgresql : du coup les 3 sont compilés
dans PHP, alors qu'on ne peut en utiliser qu'un seul.

Dans le cadre de ma démo, c'est mysql qui est activé. Et bien entendu
les autres options échouent.

Bon, le message d'erreur indique qu'il faut se référer à la doc de
l'hébergeur, on peut considérer que l'utilisateur reviendra sur la bon
choix.

Je reste quand même mitigé sur le choix sans explication. Peut-être
qu'une intro expliquant à quoi correspondent ces bases peut être utile ?

PS.: ce problème impacte aussi la sauvegarde du site, dont le
déroulement échoue sans explication (si ce n'est une erreur de squelette
pas très rassurant) : http://screencast.com/t/dlUvnvN78
(testé sur la version stable de spip3.04)

Le message d'erreur du squelette je l'ai aussi sous ovh, mais il est trop fugace et je ne vois pas ce qu'il dit vraiment. Chez ovh pour l'instant j'ai un souci avec la sauvegarde de base un peu grosse (euh relativement une 40ne de Mo) où elle n'arrive pas à se terminer sans erreurs. Je suis obligé de passer par phpmyadmin mais je n'ai pas eu trop le temps d'approfondir.

Cordialement,
Jacques

15

Hop,

16

Bah oui mais c'est l'annonce de SPIP 4 ça déjà :wink: