Início / dba / Perguntas / 126408
Accepted
oriaj
Asked: 2016-01-16 13:06:55 +0800 CST

Otimização do banco de dados do construtor de formulário dinâmico Postgresql

  • 772

Olá tenho um projeto que cria formulários dinamicamente utilizo um modelo como o seguinte:

forms
-----
  id (PK)
  name
  (other fields)

form_fields
-------------
  id (PK)
  form_id (FK to forms.id)
  label (nome to the field)

form_submits (form inserted by someone user)
-------------
  id (PK)
  form_id (FK to forms.id)
  user_id (FK to users.id)

form_submits_fiels 
-------------
  id (PK)
  form_fields_id (FK to form_fields.id)
  form_submit_id (FK to form_submit.id)
  data

Agora estou tendo sérios problemas com o desempenho no servidor de produção porque a form_elementtabela tem mais de 1.500.000 linhas; o número continua crescendo e a função que retorna todos os registros de um formulário demora mais que 20 segundos, a questão é como otimizar o modelo ou a consulta para levar menos tempo

Tenho algumas ideias mas acho que não resolvem o problema:

  • Paginar: se eu pudesse paginar as consultas o desempenho seria muito melhor, mas acho que não é possível porque os dados não estavam em ordem.
  • MongoDB: Se usar um modelo não relacional, o desempenho talvez seja melhor, mas não tenho certeza se o mach pode ser melhor com o Mongo e é uma solução tão cara
database-design postgresql

1 respostas

  1. Best Answer

    Se eu tivesse mais reputação, adicionaria um comentário pedindo para você descrever seus índices. Do jeito que está, vou assumir que você não tem índices, já que não os mencionou.

    Primeiro, considere usar EXPLAINem suas consultas para analisar as decisões tomadas pelo planejador. Linhas de 1,5 m não devem levar 20 segundos com qualquer tipo de combinação razoável de hardware e indexação. Consulte a documentação do EXPLAINmodificador para começar a usá-lo. Você deve incluir (ANALYZE on)para ver a divisão de custos e as informações de tempo da execução real da consulta e, mais importante, os processos individuais que entram em cada estágio.

    Em segundo lugar, um esquema como esse se beneficiaria não apenas de índices, mas de algum uso limitado de índices de várias colunas. (Consulte a CREATE INDEXdocumentação .) Considere criar índices em:

    • form_fields.formid, form_fields.id
    • form_submits.formid, form_submits.id

    e outros. Depende muito do que seu código está fazendo. Duplique o banco de dados para outro servidor e crie diferentes configurações de índices e execute seu código nele. ( EXPLAIN (ANALYZE on)novamente aqui!) Os índices de várias colunas são ótimos porque ajudam o planejador a verificar vários critérios de filtragem/classificação em uma passagem do índice.

    Em terceiro lugar, para abordar seus últimos pontos, não tenho certeza de que a paginação ou a mudança para um modelo não relacional ajudará. O fato de você estar usando chaves estrangeiras, na verdade, aponta para um conjunto de dados fortemente relacional. Você pode, é claro, experimentar o MongoDB gratuitamente e ver como é o desempenho.

    • 1

relate perguntas