sqllite vs mysql

Hello,

à l'époque d'après ce que j'avais lu le gros intérêt d'sqlite c'était les bases avec peu d'écriture. Pour un catalogue de produits par exemple, c'est très performant.

Le soucis se pose plus au niveau des contraintes technique je dirais : base de données obligatoirement sur la même machine. Pas de cluster, pas d'accès distant.
Aucun contrôle des types de données : je ne sais pas si c'est toujours le cas, mais mettre "bonjour" dans un champ date, ça passe. Dans certains cas ça peut être gênant.

Une des utilisations suggérée était en temps que frontend pour la base de données principale. En gros un cache de données "fichier", en beaucoup plus souple et avec de très bonnes performances.

Maintenant, je n'ai jamais vraiment essayé sur un site.

Le soucis justement avec du mutualisé, c'est qu'il s'agit parfois d'un cluster. Les fichiers sont alors souvent stockés en NFS sur un filer, et là tu risques soit d'avoir des performances "limitées" à cause du système de verrou soit de corrompre tes données par le manque de verrou.

J'ai la bouse ancestrale de ovh sur mes dediés, mis a jour avec mysql4
Y a toujours des patch a passer, plus ou moins stables et finalisés d'ailleurs
Des ip de pirates a bannir avec iptables.
Faut surveiller qmail, la partition /, surveiller l'etat des disques, les slots apache, ...

Ca me prend pas des heures par jour bien sur. Mais ca me prend bien trop de temps. Et c'est de toute facon pas sur a 100%.
Avec un mutualisé, y a vraiment nettement moins de souci. J'ai d'ailleurs externalisé mes images, vignettes, photos, ... sur un mutu ovh.
J'aimerai externaliser d'autres petites fonctionnalités non cruciales (liens contextuels, adserver simplifié, ...)
Mais a priori, les clusters sont pas adaptés pour faire du sqlite.

Je me lancerai bien dans une grande migration chez un pro de l'infogerance comme bool. Le changement d'adresse ip m'inquiete beaucoup pour que je me décide...

(la dernière fois que j'ai touché à yum, il a fallut réinstaller plesk )

JE suis sur Debian, ça me coûte que dalle en temps d'administration sur mon dédié. Le seul truc que j'ai compilé c'est Apache / PHP, et lorsqu'il y a une nouvelle version, je mets 10 minutes à l'installer.

Ce qui faut voir avec un dédié, c'est surtout le fait qu'on peut s'organiser comme on veut.
* Si par exemple tu peux mettre tes petites bases en tmpfs (donc que pour de la lecture), tu seras à mon avis au moins 10x plus rapide que sur du MySQL.
* Si tu as un serveur qui n'a pas beaucoup de trafic mais qui consomme beaucoup en ressources (solution pro), tu limites le nombre de connexions Apache à 5/10.

Pour devtribu, le changement d'infogérence avec l'adresse IP, c'est vraiment pas un problème. Tu commences par lui donner la gestion de tes DNS, il réduit l'intervalle de rafraichissement des réponses DNS à 5/10s. Vous faites un premier rsync de tout à l'arrache. Et une belle nuit, vous coupez tout pendant 5 minutes, vous commencez à tout synchronisé (les bases de données surtout), vous changer les entrées DNS et vous relancez sur la machine cible.
Si c'est bien fait, ça prend vraiment 3 minutes.

D'autre part, OVH a fait le choix magique de fonctionner sous Red Hat et de gérer eux même leur patch, y'a pas plus chiants. Leur patchs sont mal foutus : c'est des versions de "release" incrémentielles, on va pouvoir télécharger 3 versions d'Apache, les compiler et les installer à la suite. Et ça nous bousille la version d'Apache qu'on a compilé avec nos options sans scrupule.
Mais le problème, c'est que ce sont les même release qui corrigent des failles de sécurité dans le kernel.