PostgreSQL maximise les performances du SSD
J'aurai une énorme base de données PostgreSQL 9.3 avec de nombreuses tables avec plus de 100 millions d'entrées par table. Cette base de données sera essentiellement en lecture seule (une fois que je remplirai toutes les tables nécessaires et que je construirai les index plus d'opérations d'écriture sur la base de données) et un accès pour un seul utilisateur (exécuter et comparer plusieurs requêtes depuis localhost), car la base de données sera utilisée uniquement à des fins de recherche. Les requêtes utiliseront toujours JOIN sur les champs de base de données entiers.
J'achèterai probablement un SSD (256-512 Go) à cet effet. Je n'ai jamais utilisé de SSD pour une base de données auparavant, y a-t-il quelque chose dont je devrais avoir peur? Puis-je mettre l'intégralité de la base de données sur le SSD, ou seulement les index? Y a-t-il des conseils/tutoriels particuliers requis pour régler PostgreSQL pour les SSD? Notez que j'ai un bon poste de travail avec un i7 et 32 Go de RAM, alors vous pouvez peut-être aussi y donner des conseils.
y a-t-il quelque chose dont je devrais avoir peur?
Ne pas avoir de sauvegardes. Comme tout périphérique de stockage, il peut mourir. Gardez des sauvegardes.
Si le chargement des données va prendre des années, je sauvegarderais la base de données en lecture seule une fois que j'aurais effectué le chargement des données, en l'arrêtant et en le copiant. De cette façon, si quelque chose tournait mal, il serait plus facile de recréer plus tard.
Puis-je mettre l'intégralité de la base de données sur le SSD, ou seulement les index?
S'il convient, stockez l'intégralité de la base de données.
Si ce n'est pas le cas, placez un espace disque logique sur le SSD et utilisez-le pour stocker les index et autant de tables fortement interrogées que possible.
Y a-t-il des conseils/tutoriels particuliers requis pour régler PostgreSQL pour les SSD?
La plupart des avantages des disques SSD sont pour les charges d'écriture OLTP. Le principal avantage des charges en lecture seule est la recherche rapide, et slardiere a couvert cela.
Vous souhaiterez peut-être définir effective_io_concurrency = 5 ou quelque chose pour refléter le fait que les SSD peuvent effectuer des lectures aléatoires rapides et fortement pipelinées ... mais cela n'affecte que les analyses d'index bitmap, et dans la pratique random_page_cost intègre déjà cela.
Pour une charge en lecture seule, cela ne fait aucune différence.
Pour le chargement initial des données, voir:
- https://stackoverflow.com/q/12206600/39867
- https://stackoverflow.com/q/758945/39867
- https://stackoverflow.com/q/9407442/39867
Notez que j'ai un bon poste de travail avec un i7 et 32 Go de RAM, alors vous pouvez peut-être aussi y donner des conseils.
Définissez un grand maintenance_work_mem pour le chargement des données. J'utiliserais au moins 8GB.
Définissez un grand work_mem pour le travail d'interrogation. La taille appropriée dépend un peu de la complexité de la requête. Commencer avec 500MB et montez à partir de là.
Augmentez votre checkpoint_segments (massivement) pour le chargement initial des données.
N'oubliez pas de désactiver VM overcommit! (Voir le manuel PostgreSQL: http://www.postgresql.org/docs/current/static/kernel-resources.html )
Concernant les SSD, le conseil principal est de réduire 'random_page_cost' à 1 (égal à 'seq_page_cost') dans postgresql.conf, en plus des autres paramètres habituels.