Le verrou global à la table est un peu ch.. en effet, mais dans le cas d'un site comme Lexpage, avec peu d'update (et surtout peu de concurrence), ce n'est pas gênant. Pour les transactions et la récupération, ce n'est plus un souci dans Aria (le fork de MyISAM pour MariaDB) si j'ai bien lu. Je vais essayer de trouver quelques benchmarks pour voir l'overhead de base d'InnoDB (enfin, son équivalent pour MariaDB). Si c'est léger, autant adopter cet engine dès maintenant...

C'est marrant, j'ai le même collègue qui veut me faire passer mes bases innoDB en MyISAM, car "ça sert à rien de complexifier mysql, faut l'utiliser pour sa force, sa très grande rapidité sans gérer de transaction" (sous entendu pour tout le reste : postgres)

J'ai résisté car "autre chose à foutre", et moyennement convaincu, et surtout je comprend assez mal les deux systèmes. y'a de la doc quelque part sur les forces et faiblesses des deux ?

Pour info, c'est suite à une explosion de mon MySQL qui a fait exploser en vol son clone de réplication par la même occasion : impossible de rattrapper le serveur, il était plus que dans les choux, impossible à arrêter et même après un arrêt crade impossible à redémarrer. Et donc mon serveur de réplication aussi était mort. Il a fallu faire un rollback complet de la veille (et là, t'es moyennement jouasse !). Du coup la discussion a été "ça te sert en rien l'innoDB enfin, à part la réplication, t'aurais été en MyISAM tu choppait les fichiers, tu les remettait et roule ma poule".

Mon avis à moi c'est que si on a pas besoin d'ACIDitité, ben on utilise pas un SGBD. Un store key-value type Redis ou une base orientée document type MongoDB fait bien le boulot, en (beaucoup) plus rapide.

Si on décide de faire une base relationnelle un minimum pérenne, ben on modélise aussi les clés étrangères, on les fait respecter et on se met à la gestion des transactions parce que c'est bien et qu'on est des pros

MyISAM c'est un peu le pire de tous les mondes. Son seul avantage est d'être le moteur historique et d'être le mieux compris par les admins un peu fainéant (genre l'utilisation des fichiers et du disque).

Sinon pour la comparaison, tout est dit sur Wikipédia. Pour achever MyISAM, on notera que celui-ci n'est plus sous développement actif par Oracle.
Même MariaDB préconise d'utiliser "Aria" plutôt que MyISAM. En revanche je n'ai pas de retour d'expérience sur celui-ci (mais une bonne méfiance tout de même).

Addendum : PostgreSQL, c'est formidable aussi, moi j'adore. Mais on sous-estime souvent MySQL, en grande partie à cause de MyISAM et de nos propres mauvaises pratiques.

Effectivement, MyISAM n'est plus développé ni maintenant. Cela dit, je rejoints un peu Tchou : si je veux vraiment faire du beau relationnel avec toutes ces subtilités, je partirai sur Postgresql plutôt que Mysql/MariaDB, même équipé d'InnoDB.

Si je n'avais pas un ORM pour interagir avec la db, c'est clair que j'aurai opté pour autre chose, probablement Postgres, avec support des clés étrangères, et une gestion "manuelle" des transactions. Là, dans le cas présent, j'ai une couche objet qui fait déjà cela et qui me suffit. Je pense que l'important, c'est d'avoir une technologie en phase avec ses besoins, pas de sortir l'artillerie lourde quand ce n'est pas nécessaire.

[Edit : cela dit, pour moi, Postgres = faire les choses proprement, à grande échelle si besoin ; mysql = faire les choses rapidement, à moyenne échelle ; sqlite = faire les choses très très rapidement, à petite/moyenne échelle. Sqlite reste pour moi l'un des meilleurs compromis en terme de performances/fonctionnalités (les mauvaises langues diront que le dénominateur tend vers 0, ce qui aide )]

Pour MongoDB, j'ai fait quelques expérimentations avec. C'est sympathique, mais j'ai encore un peu de mal avec cette "trop-de-flexibilité" : j'aime bien avoir mes schémas, bien définis, élégants, bla bla, et les respecter. La souplesse, je la prends à l'usage (via un ORM, ou autre), pas au stockage. Par contre, dans l'absolu, je n'avais pas été spécialement impressionné par ses performances.

Guybrush si je veux vraiment faire du beau relationnel avec toutes ces subtilités, je partirai sur Postgresql plutôt que Mysql/MariaDB, même équipé d'InnoDB.

C'est respectable mais pas indispensable : InnoDB fait ça très bien, dans de très nombreux cas (à l'aise, 99% des cas)
Je fais tourner dessus des sites e-commerce trèèès complexes et d'autres applications métiers über lourdes, ce n'est jamais InnoDB qui pose problème. Et ça convient tout aussi bien aux modèles ultra simples avec deux ou trois tables.
Reste que PostgreSQL est une super techno, que je préfère moi aussi à MySQL. Un peu plus difficile à héberger et à configurer, voilà tout.

GuybrushSi je n'avais pas un ORM pour interagir avec la db, c'est clair que j'aurai opté pour autre chose

Un ORM est fait pour abstraire la modélisation relationnelle au développeur objet, pas pour la rendre défaillante. Les relations inter-entités dans le modèle objet doivent être modélisées sous forme de clé étrangère dans ta BDD, tous les ORMs font ça très bien. Le plan d'exécution des requêtes est très souvent basé sur ces contraintes.
De plus, ton ORM ne sera peut être pas à terme le seul composant de ton application à accéder à la BDD.

En bref, je veux bien que vous n'ayez pas envie d'utiliser les transactions ou les contraintes d'intégrités, encore que vu ce que ça coûte, c'est un peu dommage. Par contre, je ne vois toujours pas l'intérêt d'une migration InnoDB > MyISAM, dans le sens où tous les prétendus avantages de simplicité sont compensés par des grosses défaillances ailleurs . Rien que le table-level lock, c'est dévastateur pour les perfs (un update tourne sur une table, tous les selects qui touchent à cette table sont bloqués).

InnoDB c'est pas spécialement une artillerie lourde, c'est juste un moteur de stockage qui fait son boulot

FabeDe plus, ton ORM ne sera peut être pas à terme le seul composant de ton application à accéder à la BDD.

Rien ne m'empêchera de changer de moteur à ce moment.

FabeEn bref, je veux bien que vous n'ayez pas envie d'utiliser les transactions ou les contraintes d'intégrités, encore que vu ce que ça coûte, c'est un peu dommage. Par contre, je ne vois toujours pas l'intérêt d'une migration InnoDB > MyISAM, dans le sens où tous les prétendus avantages de simplicité sont compensés par des grosses défaillances ailleurs . Rien que le table-level lock, c'est dévastateur pour les perfs (un update tourne sur une table, tous les selects qui touchent à cette table sont bloqués).

Les contraintes d'intégrité sont imposées par l'ORM, qui, en tant que seul composant accédant à la database pour l'instant (j'anticipe ta question passée, oui c'est tordu ), est suffisant. Cela dit, j'ai parlé de migration InnoDB -> MyISAM simplement parce que j'y voyais un gain de performances. Dans l'absolu, Lexpage repose déjà en MyISAM (sauf pour Piwik qui a créé ses tables en InnoDB). Je ne compte à priori pas changer cela lors de la migration des données du Lexpage (à part que ce sera Aria plutôt que MyISAM) puisque cela me convient pour l'instant. Sauf si, d'ici là, je trouve des informations qui montrent que l'overhead d'un autre engine (XtraDB, par exemple, il me semble que c'est "l'InnoDB de MariaDB") est négligeable.

FabeInnoDB c'est pas spécialement une artillerie lourde, c'est juste un moteur de stockage qui fait son boulot

Pour de petites db avec une faible concurrence, il me semble (de mémoire) qu'on parlait presque d'un facteur 2 sur de simples lookups de PK.

Après, on est tous d'accord, tout dépend du besoin. Et héberger la lexpage est loin d'être un truc complexe.

Ce topic est super intéressant, j'avoue m'être rarement posé la question du moteur. Cela dit, innoDB ou pas, j'ai déjà réussi l'exploit de planter un mysql au delà du réparable ! :D (et là, clairement une connerie de ma part, je l'ai floodé au delà du raisonnable pendant plusieurs heures)

Un facteur 2 entre myISAM et innoDB dans certains cas ?

TchouAprès, on est tous d'accord, tout dépend du besoin. Et héberger la lexpage est loin d'être un truc complexe.

Clairement. Le site offre finalement peu de fonctionnalités, peu d'accès concurrent, et les requêtes sont assez usuelles et simples. Cela dit, de ce que j'ai pu voir, Aria et XtraDB proposent des performances relativement proches, même dans un environnement faiblement sollicité. Je pense donc opter pour ce dernier pour mes premiers tests.

Dans l'absolu, je sais qu'un VPS sera largement suffisant pour Lexpage. Mais tant qu'à faire, je préfère minimiser au possible la consommation du site et de ce qu'il y a autour, afin de garder un maximum de ressources pour des services éventuels (et au passage, je vais enfin pouvoir faire quelques essais de minichat en websocket ).

TchouUn facteur 2 entre myISAM et innoDB dans certains cas ?

De ce que j'ai trouvé, c'est principalement sur des petits systèmes à faible concurrence, et ce serait plutôt de l'ordre de 20% que de 200% Cela dit, et j'ai pu en faire l'expérience dans le cadre de ma thèse, faire un vrai benchmark pour une base de données, c'est vraiment, vraiment, vraiment pas facile

Effectivement, dans certains certains contextes, je doute pas que MyIsam trouveras la ligne en 10ms et InnoDb en 12ms
De là à dire que MyIsam est plus performant

Bon après c'est clair qu'on est pas sur des applis énorme dans le cadre que tu posais au début et auquel je n'ai pas répondu :-P
Soyons d'accord que lexpage sera tout aussi performant en MyIsam qu'en InnoDb, ce que je dis, c'est que quand on veut faire "propre" on garde InnoDb
My 2 cents of course, je vais pas épiloguer des heures, chacun fait son choix

Bah juste pour te contredire, je pense fortement partir sur XtraDB
Je n'ai rien trouvé de pertinent à propos de son overhead par rapport à Aria (et comme je compte brancher MariaDB plutôt que MySQL, le choix se fait bien entre ces deux-là ).

Bon, il me reste encore à trouver des avis sur les VPS, et puis voir si je peux migrer la gestion des e-mails de mon hébergement actuel vers un plan mail, comme ça je dois pas m'emm... avec ça sur le VPS Ensuite, essayer d'identifier comment je vais organiser les différents sites pour que ça marche (parce qu'entre des trucs en Python, les nombreuses rewrite rules et le PHP "obsolète" de certains sites, ça va pas être la joie )

Concernant le VPS proprement dit.
J’utilise depuis quelques mois un VPS Cloud 2 (4 vCores / 4 Go de RAM)
RAS, c’est très stable, pas eut une seule indisponibilité.
(Mais ce n’est pas pour de l’hébergement web proprement dit et j’ai besoin de Windows Server)

Je ne comprends pas ton souci de quota pour les mails ?
Sur l’hébergement pro 2014 du club, ça fonctionne sans soucis. (Une vingtaine de message envoyé par jour … que ce soit via le formulaire de contact ou des mails automatisé du forum)
Normalement le quota se fixe par compte et pas par ip.
Si le support est à côté de la plaque, poste sur le forum ovh ou contacte directement Oles .. Ce n’est pas normal que tu doives migrer sur un VPS pour un truc aussi basique que l’envoi de mail automatisé.