Por que NÃO particionar?


10

Quando um NÃO deseja particionar um banco de dados? (pensando no particionamento do MySQL )

No meu caso

  • Vou começar com alguns milhões de linhas, deve crescer a partir daí.
  • Chave primária em um campo de caractere que serve como a restrição de consulta mais frequente (e as pesquisas são frequentes - pelo menos algumas por segundo).
  • A chave primária seria hash para servir como chave de partição
  • Serão feitas atualizações em todas as linhas extraídas das consultas frequentes mencionadas acima
  • Pesquisas menos frequentes (em colunas de data ou outras) precisarão atingir todas as partições

Mesmo para o último ponto, a pesquisa não ocorre paralelamente e, em todos os casos, isso é uma vitória ? Quais são as desvantagens do particionamento? Por que não é algo que TODOS usam por padrão, pelo menos quando você está vendo mais de um milhão de registros?

ATUALIZAÇÃO - Selecionei a resposta do zgguy, mas observe que adicionei minha própria resposta aos resultados de minha própria pesquisa, incluindo um link para uma resposta realmente boa em uma pergunta semelhante que foi muito útil para mim.

Respostas:


5

Não existe uma bala de prata para problemas de desempenho, e o particionamento também não.

Cada partição é essencialmente uma tabela para si. Portanto, as consultas escritas de forma a permitir que o banco de dados procure linhas em apenas uma partição se tornam mais rápidas. A diferença pode ser enorme para consultas que precisariam verificar a tabela grande inteira, mas podem restringir-se a verificar apenas uma partição na tabela particionada. Para pesquisas de chave exclusivas, a diferença é muito menor.

No entanto, as consultas que usam pesquisas de índice de uma maneira que exige que o banco de dados visite todas ou a maioria das partições de tabela (índice) serão consideravelmente mais lentas.

A execução paralela é um tópico para si. Se você executar grandes lotes noturnos e tiver toda a máquina para executar esse trabalho único, sua paralelização será uma coisa boa. No entanto, em um sistema OLTP em que o banco de dados atende constantemente a consultas de muitos usuários simultâneos, você não deseja que um usuário ocupe todos os recursos.


Portanto, as pesquisas de chave primária / única não terão muita melhoria (se houver alguma) porque o índice PK é mais rápido? Isso é generalizado - há momentos em que um índice PK é mais lento? E se as pesquisas forem distorcidas para PKs adicionadas mais recentemente? Uma partição baseada no PK (acho que algo da chave de partição precisaria ser de módulo ou semelhante e NÃO hash, certo?) Que faz com que a maioria das atividades atinja apenas uma partição, seja útil?
chell

As pesquisas principais / exclusivas serão, na melhor das hipóteses, uma pequena melhoria no desempenho. Por outro lado, se seu objetivo é reduzir a contenção de instruções DML, você deve particionar de uma maneira que o DML seja distribuído igualmente por todas as partições, em vez de focar em algumas delas.
Zgguy

desculpe-me por voltar 10 dias depois, mas você levantou um ponto-chave - Você forneceu um bom motivo para ver o particionamento como possivelmente desnecessário; no entanto , meu cenário inclui a atualização de todos os registros após a leitura (vários por segundo). A necessidade de tantas gravações cria um argumento mais convincente para partições (com distribuição uniforme) para que a carga de gravação seja espalhada?
Chell

Também estou tentando entender seu comentário sobre consultas que atingem muitas partições (que são mais lentas). Se as consultas forem contra o PK, que também é usado (hash) como a chave da partição, o banco de dados não sabe imediatamente a qual partição ir com base no hash da pesquisa? Obrigado pela ajuda!
Chell

Desculpe, não foi possível visitar a troca de pilhas recentemente. A resposta que você vinculou é ótima. Eu acredito que responde a ambas as suas perguntas.
Zgguy

2

A resposta aqui é bem escrita e apresenta argumentos semelhantes à resposta do zgguy , que o particionamento não lhe traz muitos benefícios, se houver algum, para um cenário de máquina única, onde as pesquisas mais frequentes são baseadas na chave primária ou algo semelhante (porque pesquisas indexadas devem ser igualmente rápidas).

De fato, um conselho comum parece ser que o principal motivo para particionar é tangencial e principalmente relacionado ao gerenciamento: por exemplo, separe seus dados com base na data, se você precisar limpar registros antigos de vez em quando. Embora tenha sido observado que isso também pode beneficiar o desempenho da pesquisa se os dados forem tais que quase todas as consultas atinjam apenas registros adicionados recentemente.

Também vi menção de que o MySQL nunca faz nada em paralelo (seria bom ver alguns links ou mais explicações sobre isso).

Ninguém viu falar se a atividade de gravação adiciona ou não considerações diferentes.


Não acho que as gravações alterem sua resposta. Você mencionou 2 dos 4 casos de uso que encontrei. Ainda não há paralelismo, mesmo no 8.0.
Rick James

1

A primeira coisa que vem à mente é a poda de partição ; se isso não for algo que suas consultas possam usar.

Você precisará remover grande quantidade de dados da tabela, pois o particionamento o ajudaria. Embora antigo, mas este post de Peter tem alguns pontos a considerar.

e outra coisa em que podemos pensar é a facilidade de uso para tabelas simples ... o particionamento precisa de trabalho e manutenção adicionais.


As versões mais recentes têm uma sintaxe para limitar explicitamente a consulta a uma partição. Não consigo pensar em uma razão válida para sempre usá-la.
Rick James
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.