O PostgreSQL maximiza o desempenho do SSD

Eu terei um enorme banco de dados do PostgreSQL 9.3 com muitas tabelas com mais de 100 milhões de entradas por tabela. Esse banco de dados será basicamente somente leitura (depois de preencher todas as tabelas necessárias e construir os índices, não haverá mais operações de gravação no banco de dados) e acesso de usuário único (executar e comparar várias consultas do host local), pois o banco de dados será usado apenas para fins de pesquisa. As consultas sempre usarão JOIN em campos inteiros do banco de dados.

Provavelmente comprarei um SSD (256-512GB) para esse fim. Eu não usei um SSD para um banco de dados antes, então há algo que eu deva ter medo? Posso colocar o banco de dados inteiro no SSD ou apenas os índices? É necessário algum conselho / tutorial específico para ajustar o PostgreSQL para SSDs? Observe que eu tenho uma boa estação de trabalho com um i7 e 32 GB de RAM, então talvez você possa oferecer alguns conselhos também.

então tem algo que eu deva ter medo?

Não tendo backups. Como qualquer dispositivo de armazenamento, ele pode morrer. Mantenha backups.

Se o carregamento de dados demorar várias vezes, eu faria o backup do banco de dados somente leitura depois de fazer o carregamento dos dados, parando-o e copiando-o. Dessa forma, se algo desse errado, seria mais fácil recriar mais tarde.

Posso colocar o banco de dados inteiro no SSD ou apenas os índices?

Se encaixar, armazene o banco de dados inteiro.

Caso contrário, coloque um espaço de tabela no SSD e use-o para armazenar os índices e quantas tabelas pesadas forem necessárias.

É necessário algum conselho / tutorial específico para ajustar o PostgreSQL para SSDs?

A maioria dos benefícios dos SSDs são para cargas de gravação OLTP. A principal vantagem para cargas somente leitura é a busca rápida, e a slardiere cobriu isso.

Você pode definir effective_io_concurrency = 5ou algo para refletir o fato de que os SSDs podem fazer leituras aleatórias rápidas e com pipeline pesado ... mas isso afeta apenas as verificações de índice de bitmap e, na prática, random_page_costjá o incorpora.

Para uma carga somente leitura, não faz muita diferença.

Para o carregamento inicial de dados, consulte:

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

Observe que eu tenho uma boa estação de trabalho com um i7 e 32 GB de RAM, então talvez você possa oferecer alguns conselhos também.

Defina um grande valor maintenance_work_mempara o carregamento de dados. Eu usaria pelo menos 8GB.

Defina um valor alto work_mempara o trabalho de consulta. O tamanho apropriado depende um pouco da complexidade da consulta. Comece com 500MBe suba a partir daí.

Aumente sua checkpoint_segmentscarga (massivamente) para o carregamento inicial de dados.

Lembre-se de desativar a supercomprometimento da VM! (consulte o manual do PostgreSQL: http://www.postgresql.org/docs/current/static/kernel-resources.html )

Sobre os SSDs, o principal conselho é reduzir 'random_page_cost' para 1 (igual a 'seq_page_cost') no postgresql.conf, além de outras configurações usuais.