Tenho lido MUITO sobre as opções disponíveis. Eu também pus as mãos no MySQL 2ª edição de alto desempenho, que eu recomendo.
Isto é o que eu consegui juntar:
Agrupamento
O clustering no sentido geral é a distribuição de carga entre muitos servidores que aparecem para um aplicativo externo como um servidor.
Cluster NDB MySQL
O MySQL NDB Cluster é um mecanismo de armazenamento distribuído, na memória e sem compartilhamento com replicação síncrona e particionamento automático de dados (desculpe-me, peguei emprestado literalmente do livro High Performance, mas eles o colocaram muito bem lá). Pode ser uma solução de alto desempenho para alguns aplicativos, mas os aplicativos da Web geralmente não funcionam bem nele.
O principal problema é que, além de consultas muito simples (que tocam apenas uma tabela), o cluster geralmente terá que procurar dados em vários nós, permitindo que a latência da rede se infiltre e diminua significativamente o tempo de conclusão das consultas. Como o aplicativo trata o cluster como um computador, ele não pode dizer de qual nó buscar os dados.
Além disso, o requisito de memória não é viável para muitos bancos de dados grandes.
Sequoia Contínua
Esta é outra solução de cluster para MySQL, que atua como um middleware em cima do servidor MySQL. Oferece replicação síncrona, balanceamento de carga e failover. Ele também garante que as solicitações sempre obtenham os dados da cópia mais recente, escolhendo automaticamente um nó que tenha os dados atualizados.
Li algumas coisas boas nele, e no geral parece bastante promissor.
Federação
A federação é semelhante ao agrupamento, então eu a puxei aqui também. O MySQL oferece federação por meio do mecanismo de armazenamento federado. Semelhante à solução de cluster NDB, funciona bem apenas com consultas simples - mas ainda pior o cluster para as complicadas (já que a latência da rede é muito maior).
Replicação e balanceamento de carga
MySQL tem a capacidade de criar replicações de um banco de dados em diferentes servidores. Isso pode ser usado para muitas coisas - dividir a carga entre servidores, backups dinâmicos, criar servidores de teste e failover.
A configuração básica da replicação envolve um servidor mestre manipulando principalmente gravações e um ou mais escravos manipulando somente leituras. Uma variação mais avançada é a do master-master configuração, que permite escalar gravações também por ter vários servidores gravando ao mesmo tempo.
Cada configuração tem seus prós e contras, mas um problema que todos compartilham é o atraso de replicação - como a replicação do MySQL é assíncrona, nem todos os nós têm os dados mais recentes o tempo todo. Isso exige que o aplicativo esteja ciente da replicação e incorpore consultas com reconhecimento de replicação para funcionar conforme o esperado. Para alguns aplicativos, isso pode não ser um problema, mas se você sempre precisa dos dados mais recentes, as coisas ficam um pouco complicadas.
A replicação requer algum balanceamento de carga para dividir a carga entre os nós. Isso pode ser tão simples quanto algumas modificações no código do aplicativo ou usar soluções dedicadas de software e hardware.
Fragmentação e particionamento
A fragmentação é uma abordagem comumente usada para dimensionar soluções de banco de dados. Você divide os dados em fragmentos menores e os distribui em diferentes nós de servidor. Isso exige que o aplicativo esteja ciente da modificação no armazenamento de dados para funcionar com eficiência, pois precisa saber onde encontrar as informações necessárias.
Existem estruturas de abstração disponíveis para ajudar a lidar com fragmentação de dados, como Hibernate Shards , uma extensão para o Hibernate ORM (que infelizmente está em Java. Estou usando PHP). HiveDB é outra solução que também suporta o rebalanceamento de shard.
Outros
Esfinge
Esfinge é um mecanismo de pesquisa de texto completo, que pode ser usado para muito mais do que pesquisas de teste. Para muitas consultas, é muito mais rápido que o MySQL (especialmente para agrupamento e classificação), e pode consultar sistemas remotos em paralelo e agregar os resultados - o que o torna muito útil no uso com fragmentação.
Em geral, o sphinx deve ser usado com outras soluções de dimensionamento para obter mais hardware e infraestrutura disponíveis. A desvantagem é que, novamente, você precisa que o código do aplicativo esteja ciente da esfinge para usá-la com sabedoria.
Resumo
As soluções de dimensionamento diferem dependendo das necessidades do aplicativo que precisa. Para nós e para a maioria dos aplicativos da Web, acredito que a replicação (provavelmente multimestre) é o caminho a seguir com um balanceador de carga distribuindo a carga. A divisão de áreas problemáticas específicas (tabelas enormes) também é essencial para poder escalar horizontalmente.
Também vou dar uma chance ao Continuent Sequoia e ver se ele pode realmente fazer o que promete, pois envolverá a menor quantidade de alterações no código do aplicativo.
