mesas grandes MySQL

votos
3

Para uma aplicação web que estou desenvolvendo, eu preciso armazenar um grande número de registros. Cada registro será composto de uma chave primária e uma única (de curto ish) valor da cadeia. Eu espero ter sobre o armazenamento de 100GB disponíveis e gostaria de ser capaz de usar tudo isso.

Os registros serão inseridos, apagados e ler com freqüência e eu devo usar um banco de dados MySQL. A integridade dos dados não é crucial, mas o desempenho é. Quais as questões e armadilhas eu sou provável encontrar e qual mecanismo de armazenamento seria mais adequado para a tarefa?

Muito obrigado, J

Publicado 09/12/2008 em 20:58
fonte usuário
Em outras línguas...                            


6 respostas

votos
5

Seja qual for a solução que você usa, desde que você dizer que seu banco de dados será write-pesado você precisa se certificar de toda a tabela não fique preso nas gravações. Isto exclui MyISAM, que alguns têm sugerido. MyISAM irá bloquear a tabela em uma atualização, excluir ou inserir. Isso significa que qualquer cliente que queira ler da tabela terá que esperar para a gravação para terminar. Não sei o que o INSERT IGNORE PRIORIDADE BAIXA faz embora, provavelmente algum hack em torno de bloqueio de mesa :-)

Se você simplesmente deve usar o MySQL, você vai querer InnoDB, que não bloqueia a gravação. Eu não sei como o MySQL faz tabelas InnoDB de vácuo (InnoDB é MVCC como PostgreSQL e por isso precisa limpar) ... mas você vai ter que levar isso em consideração se você está fazendo um monte de atualizações ou exclusões.

Respondeu 25/02/2009 em 22:23
fonte usuário

votos
3

Tudo depende do padrão de leitura / gravação a sua aplicação está a gerar, e o nível de precisão que você deseja obter. Por exemple, se você realmente não me importo de ter todas as últimas linhas inseridas imediatamente disponíveis, considere o uso INSERIR IGNORE PRIORIDADE BAIXA pode ajudar SELECTs. Se o tamanho do texto é relativamente pequeno, você pode usar um tipo CHAR fixo, que vai ajudar a indexação de um monte e reduzir o tempo de seleciona Se seu aplicativo gera um monte de atualizações, você vai preferir mecanismo de armazenamento InnoDB, que permite bloquear apenas uma linha quando actualização (vs toda a tabela MyISAM). Por outro lado, o seu mais intensivo da CPU, por isso, se você não usar transações e que o seu padrão de atualização é relativamente pequena, considere o uso myisam

Respondeu 10/12/2008 em 17:07
fonte usuário

votos
1

Se você estiver usando indexação (e mesmo se você não é) você pode encontrar escalar questões. Você pode tentar particionamento para tentar reduzir esses efeitos.

Em meu próprio projeto, a integridade não é crucial, mas o desempenho é bem. O que fizemos foi relaxar todos os requisitos transacionais, relaxar requisitos de sincronização de disco, e comprometer inserções em lote e nós realmente melhorou nossas velocidades de gravação.

Além disso, certifique-se de fazer seus próprios testes para ajustar seus tamanhos de memória. Acredito MySQL tem alguns tipos diferentes de caches de que você pode configurar o tamanho.

Respondeu 09/12/2008 em 21:05
fonte usuário

votos
0

Você é muito melhor se o "string shortish" está em uma coluna de comprimento fixo para que a tabela tenha sido fixada linhas de comprimento. MySQL com MyISAM irá operar de forma bastante eficiente para você, então. Alocar mais memória que puder para o buffer de chaves de modo que a maior parte do índice na memória. Seu objetivo deve ser um único acesso aleatório ao disco para recuperar uma linha - você não pode fazer melhor do que a dada 100GB de dados e 8GB de memória. Você não deve esperar para conseguir mais do que algumas centenas de tais consultas por segundo, porque isso é tudo o aleatório acessa um disco pode fazer.

Você pode estar interessado no meu motor de armazenamento personalizado MySQL (descrito aqui ). Ele gerencia a memória de forma diferente de MyISAM, embora o perfil da sua aplicação não é exatamente o que o meu motor foi otimizado para.

Respondeu 21/03/2009 em 14:47
fonte usuário

votos
0

consultas grandes MySQL fazer o meu acidente Quad Core / 8GB de RAM Servidor DB ...

solução é usar PostgresSQL (SQL Server, se você puder pagar)

Respondeu 09/12/2008 em 21:20
fonte usuário

votos
0

Você definitivamente quer usar MyISAM para o mecanismo de armazenamento. Mas você diz que você espera 100 GB e só irá conter um valor de cadeia curta-ish. Você definitivamente quero usar um int de 64 bits para a sua identidade de chave / primária.

Mas a minha verdadeira pergunta é. Você está usando isso para armazenar informações de sessão do web site? Se assim que você quer quer usar memcache em vez do MySQL.

Respondeu 09/12/2008 em 21:16
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more