Mon beau sapin
Le stockage est sans doute le point le plus épineux de l’architecture de bases de données. Où sont stockées vos données dans les années 2010 si vous les hébergez en interne et pas chez un hébergeur plus ou moins cloud ? Peut-être sur quelques disques durs exclusivement liés à un serveur. Peut-être, si vous avez des besoins plus importants, dans un ou plusieurs SAN (storage area network). Ce SAN, cette baie de disques, est dotée d’un cache et peut comprendre un mix de disques SSD et de disques durs plus ou moins rapides (Fiber Channel , SATA). Sur les baies modernes vous pouvez laisser la configuration se faire "au mieux" même si un administrateur de stockage est toujours nécessaire pour un paramétrage optimal. En tous cas vos données sont sur un ou plutôt des supports physiques en tenant compte du niveau de redondance interne. Elles sont éventuellement répliquées dans un deuxième site dans le cadre d’un plan de reprise d’activité. Ces mécanismes ne vous dispensent pas de réaliser des sauvegardes de vos données sur un support physique distinct dédié.
Oui mais pour mon SGBD ?
Ouh pas si vite il y a bien des couches logiques à considérer avant le SGBD ! Sans parler du découpage propre au SAN (raidgroup, LUN) vous avez peut-être de la virtualisation de stockage (Vplex, SVC etc.) qui intervient avant de présenter le "physique" à vos serveurs. Ensuite votre éventuelle virtualisation serveur permettra probablement des accès "physiques" au stockage pour ne pas être un goulot d’étranglement. Des mécanismes de gestion logique des volumes, LVM (logical volume manager), permettent ensuite au niveau des systèmes d’exploitation de faciliter la gestion du stockage. Un ou plusieurs physical volume(s) (volume physique) constituent un volume group (groupe de volume) que vous découpez en logical volumes (volume logique). Sur un logical volume vous montez un filesystem (système de fichier) ayant le type de votre choix (ext2, ext3, zfs etc.) selon ce qui est disponible pour votre système d’exploitation.
Oui mais pour mon SGBD ???
Pas d’impatience ça vient. Si vous utilisez un système de fichiers votre SGBD va pouvoir stocker ses tables, indexes etc. dans...ben....des fichiers. Ces fichiers sont découpés et regroupés dans des structures logiques propres au SGBD. Par exemple avec Oracle une table est "physiquement" un segment constitué d’extents (extensions) constitués de blocks Oracle (blocs). Toute cette organisation est de plus en plus automatisée mais vous choisissez de placer les tables non pas dans des fichiers de données mais "logiquement" dans des tablespaces. Le tablespace ... cette couche logique Oracle est très utile car elle permet de ne plus avoir de place alors qu’on a encore de la place dans le filesystem. Cela provoque de belles interruptions de service et donne du travail aux équipes de support. Je plaisante...à moitié car le tablespace plein est un incident qui n’est pas si rare. Les filesystems sont souvent mieux surveillés même en l’absence de supervision dédiée et sérieuse (un simple "df" suffit pour voir qu’un filesystem est saturé ou en passe de l’être) alors qu’il faut mettre en place une supervision un peu plus complexe pour le tablespace Oracle.
Place à PostgreSQL
PostgreSQL s’appuie davantage qu’Oracle sur les couches inférieures apparues au fil du temps. Les données sont stockées dans des pages (le bloc pour Oracle). A chaque table correspondent un ou plusieurs fichiers créés automatiquement au fur et à mesure que la table grossit. Ces fichiers bénéficient des mécanismes classiques de sécurité OS, voire de mécanismes plus avancés proposés au niveau filesystem (encryption etc.) Vous pouvez éventuellement choisir une taille pour ces fichiers supérieure à la taille par défaut (paramètre PostgreSQL segment_size) afin d’avoir moins de fichiers plus gros. Si vous voulez aller très loin étudiez si votre filesystem est plus à l’aise avec beaucoup de petits fichiers ou quelques gros fichiers mais vous avez peu de risque d’être limité. Un filesystem Ext4 peut par exemple stocker 4 milliards de fichiers. En restant loin de cette limite théorique de 4 milliards je vous laisse calculer la taille de votre base avec 1 million de fois moins de fichiers, c’est à dire 4000 fichiers de 1Go.
Le tablespace fantôme
On retrouve aussi avec PostgreSQL la notion de tablespace mais, attention, cela ne recouvre pas la même chose que les tablespaces Oracle. Pour simplifier, les tablespaces PostgreSQL permettent de nommer les filesystems au niveau du SGBD. C’est par exemple utile pour séparer les données temporaires des autres données et éviter une saturation si une requête venait à consommer beaucoup d’espace temporaire. C’est léger et suffisant depuis que LVM est généralisé. PostgreSQL se repose en effet sur les couches logiques inférieures pour permettre l’extension de l’espace à chaud etc.
Mince nos clients en veulent pour leur argent mais que peut-on trouver de plus ?
Revenons à Oracle : les tablespaces Oracle constituent une couche logique complète. Ils sont constitués d’un ou plusieurs fichiers...ou d’un ou plusieurs raw devices (un volume brut).
Oracle Database est donc capable de traiter directement les aspects physiques au contraire de PostgreSQL, ce qui était intéressant avant LVM. Cependant gérer directement la couche physique au niveau du tablespace était ardu pour le DBA. Depuis la version 10g Oracle a introduit ASM (Automatic Storage Management). ASM est un produit assez complexe par rapport à un filesystem classique mais permet de travailler globalement pour tous les fichiers de vos bases Oracle, voire tous les fichies en général (ACFS). Au niveau base cela permet de retrouver les performances du raw device sans les inconvénients et la complexité de gestion. Avec ASM (Automatic Storage Management) vous avez une couche logique permettant de s’interfacer directement avec la couche physique, cette couche logique ayant nativement conscience de la nature des fichiers stockés si ce sont des fichiers de bases de données Oracle.
Oui mais en vrai ?
Le joli discours marketing est terminé et je me dis que c’est génial ! Il me faut Oracle sinon je vais avoir des performances pourries. J’étais jadis naïf et toujours surpris de voir qu’ASM n’était pas utilisé. Et pourtant, bizarrement, tout fonctionnait très bien tout de même. Je vois encore régulièrement des bases Oracle de taille intermédiaire (1 à 2To) sur AIX, filesystem JFS2 avec un découpage en fichiers de 2Go (limite de la taille de fichier avec certains anciens filesystems ou pour pouvoir utiliser cpio) ou encore 8Go (pour pouvoir utiliser la version classique de tar) sans aucun souci de performance I/O.
Poc poc poc qui est là ?
Quel pourcentage de performance supplémentaire permet d’avoir l’organisation logique Oracle et surtout ASM par rapport à l’organisation logique PostgreSQL avec des fichiers placés dans des filesystems classiques comme Ext4, ZFS, NTFS, JFS2 ? Demandez des preuves. Faites ou faites réaliser vos propres essais avec vos propres batches. J’ai fait les miens sur du matériel IBM (Power 7 + SAN High End) en faisant tourner de gros batches maison. L’organisation logique Oracle est très jolie sur le papier mais n’a rien apporté en pratique. Il ne faut pas en tirer de généralités mais ASM ne transforme pas un âne en cheval de course. Ce qui fait gagner ou perdre des performance c’est le "vrai" physique (activez et désactivez le cache de votre baie dans la phase de test) et le "logique" au sens applicatif. Autrement dit si votre système de stockage n’a PAS ou PLUS les capacité IOPS (entrés/sorties par seconde) suffisantes alors ce n’est pas une couche logique un peu optimisée qui changera quelque chose. Votre baie de disque fait au final ce qu’elle veut et surtout ce qu’elle peut. Les choses sont un peu différentes avec un Exadata qui est une machine Oracle avec du stockage dédié et des algorithmes logiciels uniques qui implémentent la Business Intelligence des bases de données dans le stockage (sic).
Il ne faut pas EXAgérer
Ah mais c’est génial il me faut un Exadata ! Hum...attendez un peu avant de casser votre tirelire. En avez-vous le besoin ? Et puis cette machine spécialisée qui ne vous servira qu’à Oracle Database peut-elle battre un ensemble serveurs + SAN haut de gamme ? Sûrement pas au niveau des capacités brutes et ce ne sont pas des "algorithmes logiciels uniques" qui dispenseront les développeurs et DBA de réfléchir de toute façon. Si vous demandez 1000 fois trop d’I/O par rapport à ce qui est nécessaire au vu des traitements effectués les performances ne suivront pas, Exadata ou pas. Au final, pour avoir des performances, dimensionnez votre stockage de préférence en vous appuyant sur des expériences réelles collectées auprès de votre intégrateur par exemple. A défaut, si c’est pour un nouveau besoin, réalisez des tests de montée en charge, voire une préproduction à échelle réduite et extrapolez à échelle complète. Optimiser les I/O se fait bien plus au niveau du développement applicatif (indexation pertinente etc.). C’est là que réside la vraie "Business Intelligence". Si vos développeurs prennent le soin d’optimiser, ils auront du répondant au niveau de PostgreSQL qui est déjà bien armé et toujours en amélioration.
Maintenir le cap
Et le suivi des performances ? Le DBA est un généraliste et il se doit de savoir si un problème de performance relève de sa compétence avant de faire appel à un spécialiste. Pour les I/O comme pour le reste il ne faut pas s’intéresser aux performances uniquement quand il y a un souci. Il faut au contraire prendre des mesures automatiquement quand tout va bien afin de connaître le profil de charge normal et pouvoir effectuer des comparaisons. Si vous connaissez la répartition des temps d’attente au niveau des sessions des utilisateurs entre I/O, CPU, réseau vous pourrez détecter si quelque chose cloche tout à coup à un niveau particulier. Si à charge constante, plans d’exécution habituels etc. les performances chutent avec des temps d’attente I/O qui explosent il y a un goulot d’étranglement à identifier en collaboration avec un administrateur système ou de stockage. Si les temps d’attente I/O sont importants mais que vous ne connaissez pas le profil de charge habituel alors avoir sous la main un test synthétique est utile. Vous connaîtrez les résultats acceptables de ce test sur un système de stockage qui n’est pas à saturation, ce qui vous permettra d’identifier un problème évident. Le tout est toujours d’avoir du concret à donner aux administrateurs système et stockage.
Conclusion
Bâtir une architecture I/O performante et fiable avec PostgreSQL est possible, surout si vous vous appuyez en complément du SGBD sur des technologies à présent largement répandues comme LVM par exemple. Si un vendeur vous explique que sa solution X est la seule possible pour votre besoin alors demandez et obtenez des preuves concrètes basées de préférence sur vos propres traitements plutôt que sur des tests synthétiques. Gardez en tête que PostgreSQL fait tourner les bases de très grosses applications commerciales comme le site leboncoin.fr ou encore 70% des bases de Meteo France, consultez les témoignages à ce sujet. Vos besoins sont-ils supérieurs ?