BTRFS est-il adapté pour les bases de données d'analyse ? Non.
Intéressant benchmarking.
Shorter: l'utilisation du copy-on-write plombe les performances de 50%, quelque soit le système de fichier qui l'emploi. Mais en plus, BTRFS, à cause de sa popote interne obtient une variabilité impressionnante dans les perfs.
Moralité ? Si on veut faire du live-snapshot sans outil couteux (ou base de données très chère qui le gère en interne) il vaut mieux utiliser un autre système de fichier COW compatible ou directement du LVM Linux.
L'avantage de ce dernier, c'est aussi de pouvoir passer en COW que lorsque nécessaire, donc d'impacter les performances la nuit quand la base est à peu près au repos.
TT-RSS, c'est vraiment un très bon agrégateur.
Cependant, le moteur est vraiment super mal foutu : le schéma SQL n'est pas du tout optimisé (au niveau des index notamment, mais pas que : toute la logique de lecture/écriture est à refaire)
Si bien que j'ai des valeurs totalement aberrantes dans l'analyseur de MySQL. Exemple, depuis 12 jours, j'ai obtenu 206 millions de lecture de "l'élément suivant" d'une table… 40 millions de lectures basées sur une position fixe…
Bref, comme solution temporaire, je joue avec les tables temporaires et la taille des différents caches d'InnoDB/MySQL. Mais il reste que le schéma est vraiment pas terrible => pas de passage à l'échelle.
P.S : l'auteur indique lui-même sur son site qu'il a fait ça dans son coin, pour lui au départ, et qu'il n'a pas envisagé de faire un truc performant au départ. Si je maitrisais le SQL + le back en PHP, je lui filerais bien un coup de main pour refondre ça au propre. Parce que c'est vraiment un très bon boulot à part ces quelques soucis.
EDIT : WOUAH !!! Les IO de mes disques ont littéralement chuté rien qu'en augmentant des caches. J'entendais un bruit de disque permanent, il a disparu tout d'un coup… Punaise.
10gen, développeur de MongoDB, lève 150 m$ pour atteindre 1.2M$ en valorisation. Pas mal pour du NoSQL.
Oracle serait intéressé ?