Rick James's questions

Estou tendo dificuldade em entender a ideia dos prós e contras do particionamento de tabelas. Estou prestes a começar a trabalhar em um projeto que teria 8 tabelas e uma delas será a tabela de dados principal que conterá 180-260 milhões de registros. Como vai ser tabela devidamente indexada, então estou pensando em limitar os registros da tabela para 20 milhões desta forma eu teria que criar de 9 a 13 tabelas.

Mas não tenho certeza de como isso melhorará o desempenho porque eles estarão na mesma máquina (32 GB de RAM)?

Estou usando o MySQL e as tabelas seriam MyISAM e a tabela grande teria um índice no campo id e não há mais complexidades como pesquisa de texto completo, etc.

Por favor, também esclareça o particionamento de tabela versus o particionamento de banco de dados.

Introdução Eu deriguei esta pergunta da minha pergunta anterior Single Drive vs Multiple Drives

Depois de obter uma resposta muito detalhada de um membro muito útil RolandoMySQLDBA e aprender o fato de que várias unidades podem ajudar muito em alguns casos. Comecei a procurar em várias unidades para minha configuração, que é apenas um bit em comparação com o que encontrei.

Mais informações Encontrei armazenamentos bastante grandes como

http://www.newegg.com/Product/Product.aspx?Item=N82E16811152212

Enquanto alguns vídeos mostram até GBs de velocidade de gravação desse tipo de equipamento

• http://www.youtube.com/watch?v=Xjgw2ENYF6w
• http://www.youtube.com/watch?v=PniGlSI900k
• http://www.youtube.com/watch?v=I8ToJ4Blw74

Pergunta real Desde que haja RAM suficiente para armazenar índices, o MySQL ou outro RDBMS de código aberto (não RDBMS de nível empresarial como o Oracle, porque sua execução em SAN é bastante comum) pode ser executado nessas bestas facilmente?

PORQUE eles contêm uma verdadeira configuração de vários drives e dezenas de cabeçotes estão disponíveis.

Tenho certeza de que não seria tão simples porque, se fosse tão fácil, por que a maioria das configurações corporativas usa servidores comuns. Então, quais problemas são enfrentados ao usar essas soluções de armazenamento extremas?

Geralmente, o gargalo do desempenho do RDBMS (eu sou um usuário do MySQL) é o acesso ao disco. O SSD oferece excelente desempenho em comparação com unidades de fuso convencionais.

Descrição: É possível melhorar o desempenho conectando vários drives de espaço reduzido, pois assim mais cabeçotes estarão disponíveis para leitura dos dados?

Como substituir a unidade de 2 TB e 7,2 mil RPM por 4 unidades de 500 GB e 7,2 mil RPM?

É possível fazer o InnoDB usar índices iguais aos do MyISAM em vez do índice clusterizado devido à limitação da RAM enquanto obtém o benefício de seu desempenho de simultaneidade?

Recentemente, tenho procurado otimizar meu banco de dados e seu tamanho é de 7 GB. Eu tenho uma opção para particionar uma tabela grande. Mas o particionamento apenas dividiria a tabela grande em pequenas enquanto permaneceria na mesma máquina para que os mesmos recursos estivessem disponíveis.

Você acha que a tabela de partição na mesma máquina traria algum efeito positivo no desempenho?

Minha outra pergunta pode ter informações relevantes também. Quando os índices de hash se tornam razoáveis?

A importância da RAM é um fato estabelecido, mas muito menos material está disponível sobre a importância dos núcleos e multithreading quando se trata do uso da CPU pelo MySQL. Estou falando sobre a diferença de executar o MySQL em 4 núcleos vs 6 núcleos vs 8 núcleos e assim por diante.

Diferentes mecanismos de armazenamento usam a CPU de maneira diferente?

Quais são os benefícios do bloqueio de nível de tabela usado pelo mecanismo de armazenamento MyISAM? O bloqueio de nível de linha tem muitos benefícios, como atualizações simultâneas e leituras que não bloqueiam a tabela.

Editar É amplamente considerado que o bloqueio no nível da tabela evita bloqueios. Mas como a prevenção de impasses ao custo da simultaneidade vale a pena?

Alguns dias atrás, eu tinha uma tabela com 7 GB de dados e mostrava 63 MB de sobrecarga no phpMyAdmin e, por engano, iniciei sua otimização e, depois de trabalhar por mais de 40 minutos, ela corrompeu toda a tabela.

Quais são as práticas seguras para evitar o travamento da tabela?

MySQL nativamente não suporta índices de hash. Então, fazer uma pseudo coluna hash e criar um índice em uma coluna hash requer algum pensamento.

E parece ser amplamente entendido que, se o campo de texto for longo, os hashes valem a sobrecarga que exigem. Mas quanto tempo deve ser o texto para começar a pensar em hash?

Se eu pretendo usar hash de 128 bits, o limite de quantos caracteres seria um mínimo suficiente para uma coluna de texto?

Editar detalhes listados em minha outra pergunta pode ser útil https://stackoverflow.com/questions/7403167/index-on-url-or-hashing-considering-ram

Eu sei que esse problema pode ser resolvido usando restrição de chave exclusiva na coluna e alguma variação do comando de inserção.

Mas eu quero saber exatamente por que a seguinte abordagem às vezes dá errado e uma entrada duplicada é adicionada:

1. um valor é verificado na coluna
2. se o registro retorna for > 0, então a atualização é emitida, caso contrário, comando de inserção simples

Na maioria das vezes funciona. Você pode dizer mais de 98%, mas por que às vezes falha?

Eu só quero entender onde está a falha nessa abordagem porque a existência do registro é verificada primeiro.