PostgreSQL maximiza el rendimiento SSD

Tendré una enorme base de datos PostgreSQL 9.3 con muchas tablas con más de 100 millones de entradas por tabla. Esta base de datos será básicamente de solo lectura (una vez que complete todas las tablas necesarias y cree los índices, no más operaciones de escritura en la base de datos) y acceso de un solo usuario (ejecutar y comparar múltiples consultas desde localhost), ya que se utilizará la base de datos solo para fines de investigación. Las consultas siempre utilizarán JOIN en los campos de DB de enteros.

Probablemente compraré un SSD (256-512GB) para este propósito. No he usado un SSD para una base de datos antes, entonces, ¿hay algo que deba temer? ¿Puedo poner todo el DB en el SSD, o solo los índices? ¿Se requiere algún consejo / tutorial particular para ajustar PostgreSQL para SSD? Tenga en cuenta que tengo una buena estación de trabajo con un i7 y 32 Gb de RAM, por lo que quizás pueda ofrecer algunos consejos allí también.

Entonces, ¿hay algo que deba temer?

No tener copias de seguridad. Como cualquier dispositivo de almacenamiento, puede morir. Mantener copias de seguridad.

Si la carga de datos demorará años, haría una copia de seguridad de la base de datos de solo lectura una vez que haya realizado la carga de datos, deteniéndola y copiándola. De esa manera, si algo saliera mal, sería más fácil recrearlo más tarde.

¿Puedo poner todo el DB en el SSD, o solo los índices?

Si cabe, almacene todo el DB.

Si no es así, coloque un espacio de tabla en el SSD y úselo para almacenar los índices y todas las tablas muy consultadas que quepan.

¿Se requiere algún consejo / tutorial particular para ajustar PostgreSQL para SSD?

La mayoría de los beneficios de los SSD son para cargas de escritura OLTP. La principal ventaja de las cargas de solo lectura es la búsqueda rápida, y Slardiere lo ha cubierto.

Es posible que desee configurar effective_io_concurrency = 5o algo para reflejar el hecho de que los SSD pueden realizar lecturas aleatorias rápidas y muy canalizadas ... pero solo afecta a los escaneos de índice de mapa de bits, y en la práctica random_page_costya lo incorpora.

Para una carga de solo lectura, no hay mucha diferencia.

Para la carga de datos inicial, consulte:

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

Tenga en cuenta que tengo una buena estación de trabajo con un i7 y 32 Gb de RAM, por lo que quizás pueda ofrecer algunos consejos allí también.

Establecer un gran maintenance_work_mempara la carga de datos. Yo usaría al menos 8GB.

Establecer un gran work_mempara el trabajo de consulta. El tamaño apropiado depende un poco de la complejidad de la consulta. Comience con 500MBy suba desde allí.

Aumente su checkpoint_segments(masivamente) para la carga de datos inicial.

¡Recuerde desactivar VM overcommit! (consulte el manual de PostgreSQL: http://www.postgresql.org/docs/current/static/kernel-resources.html )

Acerca de los SSD, el consejo principal es reducir 'random_page_cost' a 1 (igual a 'seq_page_cost') en postgresql.conf, además de otras configuraciones habituales.