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 le réglage de PostgreSQL pour les SSD? Notez que j'ai une bonne station 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 de table 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 le réglage de PostgreSQL pour les SSD?

La plupart des avantages des disques SSD concernent les charges d'écriture OLTP. Le principal avantage pour les charges en lecture seule est la recherche rapide, et slardiere a couvert cela.

Vous voudrez peut-être définir effective_io_concurrency = 5ou 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, il random_page_costintègre déjà cela.

Pour une charge en lecture seule, cela ne fait aucune différence.

Pour le chargement initial des données, voir:

• /programming//q/12206600/398670
• /programming//q/758945/398670
• /programming//q/9407442/398670

Notez que j'ai une bonne station 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_mempour la charge de données. J'utiliserais au moins 8GB.

Définissez un grand work_mempour le travail d'interrogation. La taille appropriée dépend un peu de la complexité de la requête. Commencez par 500MBet montez à partir de là.

Augmentez checkpoint_segments(massivement) votre charge de données initiale.

N'oubliez pas de désactiver la surcharge de VM! (voir le manuel PostgreSQL: http://www.postgresql.org/docs/current/static/kernel-resources.html )

À propos des SSD, le principal conseil est de réduire «random_page_cost» à 1 (égal à «seq_page_cost») dans postgresql.conf, en plus des autres paramètres habituels.