Escalabilidade do banco de dados com aplicação de gravação pesada

Question

Eu tenho um aplicativo pesado para gravação. O aplicativo é melhor comparado às pesquisas - o cliente cria questionários personalizados e isso é salvo no banco de dados. A maioria das solicitações é de seus usuários que enviam esses formulários. Mais tarde, nossos clientes fazem relatórios e gráficos complexos sobre esses envios.

Certificando-se de que nosso servidor de aplicativos (PHP) e o servidor da Web (Nginx) são muito fáceis, o problema é dimensionar o servidor de banco de dados em vários servidores.

Muitas aplicações são mais lidas, então tipicamente você terá uma configuração de replicação mestre-escravo onde todas as escritas vão para um único mestre, mas as leituras são distribuídas para os escravos. Para nós, isso não funciona porque estamos escrevendo a maior parte do tempo.

Eu já vi menção a uma configuração mestre-mestre, mas isso normalmente atinge um obstáculo com chaves primárias incrementadas automaticamente. A solução é tipicamente ter um servidor fazendo números ímpares e o outro igual. Eu quero evitar isso.

Em algumas perguntas semelhantes, vi a menção do Replicador de Tungstênio e como ele oferece muito mais flexibilidade com a replicação. Isso me ajudaria em tudo? Que tipo de benefícios isso me daria que a replicação embutida do MySQL não pode fornecer?

Existe também o MySQL Cluster, mas isso geralmente atinge um problema com bancos de dados muito grandes e consultas complexas (joins). Eu preciso ser capaz de executar relatórios complexos, então isso provavelmente não funcionará para mim.

Estou procurando redundância, failover automático, distribuição de solicitações e integridade de dados.

Existem outros RDMS que fornecem soluções melhores e adequadas para a Web?

    

Answer 1

Não existe o Grand Unified Database Layout. Se houver questionários personalizados, realmente precisam ser tabelas personalizadas. Caso contrário, você está em um caminho rápido para uma única tabela de 200 colunas de monstros VARCHAR (128) - sem-chaves-primárias fora do thedailywtf.com, o que é ineficiente, insuportável e irá prejudicá-lo no futuro .

O sharding, como recomendado pelo toppledwagon, pode ser uma coisa a considerar, mas, primeiro, verifique se o banco de dados foi projetado racionalmente. Se não é normalizado, então tem um muito bom, de preferência apoiado por testes, razão, porque não é. Se tiver centenas de tabelas, provavelmente está errado. Se tem uma única mesa, está definitivamente errado. Veja como você pode dividir seu problema em conjuntos independentes. Você vai gastar mais esforço na frente, mas o sistema será melhor para ele.

Milhões de linhas, digamos, com 2k de dados por linha (o que parece um monte de caracteres para uma pesquisa), são 2GB de memória. Se você puder lançar um pouco mais de hardware no seu problema, talvez consiga manter seus dados na RAM?

O que leva à próxima pergunta: qual é a sua carga em números absolutos? Solicitações de clientes por segundo, traduzidas para I / Os por segundo, divididas em leituras e gravações por segundo, quantos gigabytes de dados, com qual taxa de crescimento? Como sua carga é dimensionada com o número de solicitações? Linearmente? Exponencialmente? Você não precisa publicar seus dados, apenas escreva e pense sobre isso. O que é hoje, como você acha que vai parecer daqui a um ano ou dois?

Wikipedia diz que uma unidade SAS de 15k rpm oferecerá 175-210 IOps. Quantos você precisa no RAID 10 para satisfazer sua carga atual e projetada? Qual é o tamanho do seu conjunto de dados? Quantas unidades você precisa ajustar ao seu conjunto de dados (provavelmente muito menos do que atender ao requisito de IOs). Comprar um par (ou uma dúzia) de SSD seria justificável? O armazenamento local será OK, ou você vai saturar dois links de fibra de 8 Gb para um subsistema de armazenamento high-end?

Se atualmente você precisa de 1k IOps, mas tem três HDDs de 10k rpm no RAID 5, não há como seu hardware atender às suas necessidades. OTOH se o seu aplicativo tiver uma solicitação de usuário por segundo e trouxer uma besta de 32 GB de 256 GB de RAM, apoiada por um armazenamento de classe corporativa, então é provável que o problema não esteja nas capacidades de hardware.

    

Answer 2

master-master setup, but this typically hits a snag with auto incremented primary keys

Não - você acabou de configurar o incremento de incremento automático e desvio automático de incremento para evitar colisões

The solution is typically to have one server do odd numbers, and the other do evens. I want to avoid that.

Por quê? As chaves substitutas, por sua própria natureza, não estão relacionadas aos dados que elas indexam. Atribuir significado a tais valores é muito perigoso .

Uma rápida olhada no link da Tungsten que você forneceu não revela muito sobre o que ele faz - ele tem várias innacurácias (por exemplo: "você pode fazer múltiplas réplicas de mestres, o que é mais do que fazer com a replicação nativa do MySQL) "). No mesmo parágrafo, diz que não pode lidar com conflitos. Eu não estou cheio de confiança sobre a utilidade deste produto.

Assumindo que a replicação master-master (com ou sem federação para limitar a replicação) não atenda aos seus requisitos (mas você precise reexaminar sua opinião sobre os tipos de campo de incremento automático), poderá dividir os dados entre clusters nativos usando mysqlproxy ou use um banco de dados nosql.

    

Answer 3

Isso parece um bom argumento para sharding . Se os dados de uma pesquisa não precisarem de acesso imediato aos dados em outra pesquisa, será fácil particionar seus dados. Você configurará um banco de dados que tem basicamente uma chave de ID de usuário que aponta para um banco de dados de pesquisa. Você pode então configurar vários bancos de dados de pesquisa. Espero que você também escolha configurá-las em uma tupla replicada também. Seu aplicativo precisará de um pouco de retrabalho.

Execute seus relatórios e faça as junções no software. Se isso também for uma opção, o sharding é o caminho a ser seguido.