Em uma aplicação web que suporte a usuários mais de 5000, postgres está se tornando o gargalo de garrafa.
É preciso mais do que um minuto para adicionar um novo usuário. (Mesmo depois de otimizações e no Win 2k3)
Assim, como um problema de design, que outro DB pode ser melhor?
Em primeiro lugar, gostaria de fazer se as otimizações são, de fato, útil. Por exemplo, se você tiver vários índices, por vezes, adicionar ou modificar um registro pode demorar muito tempo. Eu sei que existem vários projetos grandes que funcionam sobre PostgreSQL, então dê uma olhada neste assunto.
PostgreSQL escala melhor do que a maioria, se você estiver indo para ficar com um banco de dados relacional, a Oracle seria ele. ODBMS dimensionar melhor, mas eles têm seus próprios problemas, como na medida em que está mais perto de programação para configurar uma.
Yahoo usa PostgreSQL , que deve dizer-lhe algo sobre é a escalabilidade.
Eu sugiro olhar aqui para obter informações sobre o desempenho do PostgreSQL: http://enfranchisedmind.com/blog/2006/11/04/postgres-for-the-win
Qual versão do PG você está correndo? Como os lançamentos têm progredido, o desempenho melhorou muito.
Ithink sua melhor escolha ainda é PostgresSQL. Passe o tempo para certificar-se de sintonizar corretamente seu aplicativo. Depois de sua confiança que você tenha atingido os limites do que pode ser feito com tuning, começar cacheing tudo o que puder. Depois disso, começar a pensar em mudar-se para uma configuração assíncrona escravo mestre ... Também você está correndo funcionalidade tipo OLAP no mesmo banco de dados de seu fazer OLTP on?
Muito provavelmente, não é PostgreSQL, é o seu design. Sapatas em mudança provavelmente não vai torná-lo um melhor dançarina.
Você sabe o que está causando lentidão? É contenção, tempo para atualizar índices, os tempos de busca? São todos os 5.000 usuários tentando escrever a tabela de usuário, ao mesmo tempo exato que você está tentando inserir usuário 5001? Isso, eu posso acreditar que pode causar um problema. Você pode ter que ir com algo apropriado para suportar extrema concorrência, como Oracle.
MySQL (me disseram) pode ser otimizado para fazer mais rápido do que lê PostgreSQL, mas ambos são muito ridiculamente rápido em termos de transacções # / seg eles apóiam, e não soa como esse é o seu problema.
PS Nós estávamos tendo uma pequena discussão nos comentários a uma resposta diferente - note que alguns dos maiores, armazenamento-wise, bases de dados no mundo são implementados usando Postgres (embora eles tendem a ajustar as partes internas do motor). Postgres escalas de tamanho de dados extremamente bem, por concorrência melhor que a maioria, e é muito flexível em termos do que você pode fazer com ele.
Eu gostaria que houvesse uma resposta melhor para você, 30 anos depois que a tecnologia foi inventada, devemos ser capazes de fazer os usuários têm menos conhecimento detalhado do sistema, a fim de tê-lo funcionar sem problemas. Mas, infelizmente, o pensamento extensa e ajustes é necessário para todos os produtos Eu sou ciente. Pergunto-me se os criadores de StackOverflow poderia compartilhar como eles lidaram com a simultaneidade db e escalabilidade? Eles estão usando SQLServer, eu sei que muito.
PPS Assim como teria chance que eu bati de cabeça em um problema de concorrência no Oracle ontem. Eu não estou totalmente certo de que tem direito, não sendo um DBA, mas o que os caras explicada foi algo como isto: Tivemos um grande número de processos que ligam para o DB e examinar o dicionário do sistema, que, aparentemente, obriga a um curto bloqueio sobre ele , apesar do fato de que é apenas uma leitura. Analisando consultas faz a mesma coisa .. então tivemos (em um sistema multi-tera com 1000s de objetos) um monte de tempo de espera forçada porque os processos foram bloqueio uns aos outros para fora do sistema. Nosso dicionário sistema também era excessivamente grande, pois contém uma cópia separada de todas as informações para cada partição, dos quais não pode haver milhares por mesa. Isto não é realmente relacionado com PostgreSQL, mas o takeaway é - além de verificar o seu design,
Se você quiser mudar longe de PostgreSQL, Sybase SQL Anywhere é o número 5 em termos de preço / desempenho na lista de benchmark TPC-C . É também a opção de menor preço (de longe) na lista top 10, e é a única entrada não-Microsoft e não-Oracle.
Ele pode facilmente escalar para milhares de usuários e terabytes de dados.
Divulgação completa: Eu trabalho no SQL Anywhere equipe de desenvolvimento.
Deixe-me apresentar-lhe a maneira mais simples, mais prático para escalar quase qualquer servidor de banco de dados se o projeto de banco de dados é verdadeiramente ideal: basta dobrar sua ram para um impulso instantâneo no desempenho. É como mágica.
Por favor, altere o sistema operacional em que você executar Postgres - a porta do Windows, embora imensamente útil para a expansão da base de usuários, ainda não está em pé de igualdade com os (muito mais velho e mais maduro) Un * x portas (e especialmente o Linux um).
Precisamos de mais detalhes: Qual versão você está usando? Qual é o uso de memória do servidor? Você está limpando o banco de dados? Seus problemas de desempenho pode ser não-relacionadas com PostgreSQL.
Se você tem muitas leituras sobre as gravações, você pode querer tentar MySQL assumindo que o problema é com Postgres, mas seu problema é um problema de escrita.
Ainda assim, você pode querer olhar em seu projeto de banco de dados, e possivelmente considerar sharding. Para realmente um grande banco de dados que você ainda pode ter que olhar para os acima de 2 questões independentemente.
Você também pode querer olhar para os servidores de banco de dados não-RDBMS ou documento orientados como Mensia e CouchDB, dependendo da tarefa em mãos. Sem única ferramenta irá gerenciar todas as tarefas, então escolha sabiamente.
Só por curiosidade, você tem quaisquer procedimentos armazenados que podem estar causando esse atraso?
Como destacado acima, o problema não é com o banco de dados específico que você está usando, ou seja, PostgreSQL, mas um dos seguintes procedimentos:
Uma maneira pragmática para descobrir o que está acontecendo é analisar os arquivos de log PostgeSQL e descobrir o que consulta em termos de:
Uma rápida revisão irá dizer-lhe onde concentrar seus esforços e você provavelmente irá resolver seus problemas rapidamente. Não há nenhuma bala de prata, você tem que fazer algum trabalho de casa, mas isso vai ser pequena em comparação com a mudar o seu fornecedor db.
Boas notícias ... há muitas utilidades para analayse seus arquivos de log que são fáceis de usar e produzir fácil de interpretar os resultados, aqui são dois:
Oi teve o mesmo problema anteriormente com a minha empresa atual. Quando entrei pela primeira vez, suas consultas eram enormes e muito lento. Demora 10 minutos para executá-los. Eu era capaz de otimizá-los para alguns milissegundos ou 1 a 2 segundos. Eu aprendi muitas coisas durante esse tempo e vou compartilhar alguns destaques neles.
Verifique a sua primeira consulta. juntar-se a fazer um interior de todas as tabelas que você precisa sempre levar algum tempo. Uma coisa que eu sugiro é sempre começar com a tabela com o qual você pode realmente cortar os seus dados para aqueles que você precisa.
por exemplo SELECT * FROM (SELECT * FROM pessoa ONDE pessoa ilike '% abc') COMO pessoa;
Se você olhar para o exemplo acima, isso vai cortar seus resultados para algo que você sabe que você precisa e você pode refiná-los mais fazendo uma junção interna. Este é um dos a melhor maneira de acelerar a sua consulta, mas há mais de uma maneira de esfolar um gato. Eu não posso explicar todos eles aqui, porque há demasiados mas a partir do exemplo acima, você só precisa modificar que de acordo com sua necessidade.
Depende da sua versão postgres. postgres mais velhos não otimizar internamente a consulta. no exemplo é que em Postgres 8.2 e abaixo, em declarações são mais lentas do que 8.4 do.
EXPLAIN ANALYZE é seu amigo. se sua consulta está lento, fazer uma explicam analisar para determinar qual está causando a lentidão.
Vácuo sua base de dados. Isso irá garantir que as estatísticas sobre o banco de dados será quase coincidir com o resultado real. Grande diferença nas estatísticas e real irá resultar na sua consulta de execução lenta.
Se tudo isso não ajudá-lo, tente modificar seu postgresql.conf. Aumentar a memória compartilhada e tentar experimentar com a configuração para melhor atendam às suas necessidades.
Espero que isso ajude, mas é claro, estes são apenas para otimização postgres.
btw. 5000 usuários não são muito. Meu DB contém usuários com cerca de 200k de um milhão de usuários.
