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.
Comment configurer sa base de données avec un SSD ?
Réponse rapide (pour InnoDB mais généralisable) :
- Sur disque rotatif (HDD) : REDO logs, BIN logs, tablespace (system ou general), buffer data
- Sur disque solide (SSD) : UNDO logs, table files (donc les table-space si on utilise separate table-space)
C'est assez dingue en soit : ça veut dire que les bases de données sont largement optimisées pour fonctionner sur disque classique, et que seule une petite partie du traitement est à accès aléatoire (donc déplaçable sur SSD).
Random i/o oriented:
- Table files (*.ibd)
- UNDO segments (ibdata)
Sequential write oriented:
- REDO log files (ib_logfile*)
- Binary log files (binlog.XXXXXX)
- Doublewrite buffer (ibdata)
- Insert buffer (ibdata)
- Slow query logs, error logs, general query logs, etc
D'ailleurs, fait intéressant dans l'article : il obtient une perf meilleure en HDD + SDD que en dual SSD. Peut-être parce que les SSD sont en bus SATA commun et que ce dernier sature, alors que ses HDD sont en bus SAS (donc séparé).
Pour aller plus loin, et configurer proprement la base :
Oh, la pauvre femme. Son nom est J. Null. Oui, son p-m-atronyme est Null. D'autant plus Null que cette valeur est bannie de la plupart des softs (je crois que même Windows l'interdisait pour les noms des dossiers jusqu'à XP) et en particulier des bases de données. Donc, pas de services en ligne qui nécessite son vrai nom, pas de réservation de billet d'avion, etc.
La plaie '-_-
Si réel… c'est d'ailleurs un truc qui est arrivé à mon travail.
Un conseil : MySQL avec innodb, désactiver l'autocommit pour les utilisateurs en shell (ceux qui bidouillent quoi)
Très bon historique des technologies de stockage de données. Où l'on voit que tout n'est qu'un problème de performance et de bottleneck.
Chez OVH, on ne paye pas en fonction de la taille des bases de données qu'on gère, mais en fonction des performances qu'on souhaite (ici, corrélé à la taille de la mémoire vive)
C'est une approche originale, qui du coup peut devenir vraiment très intéressante pour des cas d'usage particuliers.