Sugestões para linguagem de programação e banco de dados para um sistema de consulta de banco de dados de ponta (50 milhões de consultas por dia)?

Question

Estes requisitos são vagos no momento, mas irão agradecer quaisquer insights. Estamos explorando o que seria necessário para construir um sistema capaz de lidar com 50 milhões de consultas de banco de dados por dia - especificamente da linguagem de programação e da escolha do banco de dados

Não é um site típico, mas uma API / banco de dados acessando pela internet. A velocidade é crítica. O aplicativo receberá principalmente essas entradas (cerca de alguns kb cada) e terá que abordar cada uma delas por meio da consulta ao banco de dados. Apenas alguns kb serão devolvidos.

O servidor será executado em https / ssl.

Adicionado:
* sim, haverá alguns milhares de inserções também. não tenha uma visão disso ainda, mas digamos 10-50.000 / dia.
* Pode haver atualizações também, mas não vamos complicar o problema ainda
* Não, não vai ser distribuído uniformemente durante o dia. como típico, durante o horário de trabalho / vigília, a carga será maior? talvez seguindo uma curva normal - ainda não sabe.
O tamanho do banco de dados será de 1,5 bilhão de entradas. * o cliente termina não enviará consultas SQL, mas um número para recuperar a entrada do banco de dados.

    

Answer 1

OK, vamos ver.

• Idioma: Irrelevante. Mesmo. Você fala de front ends agrupados de qualquer maneira, e se você os construir corretamente, é praticamente algo que você pode dimensionar tanto quanto quiser. Dito isto, obviamente fique longe de linguagens INTERPRETADO (como PHP "stock") e vá com aqueles que são pelo menos apenas no tempo compilado (existe um para PHP - não tenho certeza). Se você quiser que a API adira aos padrões, isso significa um front-end baseado em SOAP / REST - o ASP.NET / C # pode ser uma boa opção aqui, porque o sistema tem um suporte muito strong para os serviços da web. Não só consumindo-os. Você também pode querer olhar para OData ( link ) para algumas coisas. Não tenho certeza de como um bom suporte para hospedagem de serviços da Web é em outros sistemas - mas você pode querer alguns dos pontos mais complexos e MS está empurrando muito bem serviços da web.

• Banco de dados: parece que você está lendo pesado. Isso é bom porque significa que você pode trabalhar em uma configuração hub / spoke com um banco de dados centralmente, levando todas as gravações e replicando as alterações para outros computadores. As leituras podem ser distribuídas entre elas. Dito isto, você fala de configuração massiva aqui.

Agora, oo carregamento. Você fala de um pico de possivelmente 100.000 a 250.000 consultas por minuto (depende de quão alto seus picos são - se muitas pessoas usam isso durante o início do trabalho, ele será bastante grande). Isso é cerca de 4166 consultas por segundo.

Pessoalmente, acho que você está no spce para clustering do SQL Server / Oracle. De qualquer forma, no SQL Server você possivelmente iria com:

• Um cluster de banco de dados central (2 instâncias enterpris edition, possivelmente padrão, mas que precisa de mais detalhes - sob contrato de licença SPLA) mirado + um pequeno como testemunha) para manipular a cópia mestre e também fazer gravações. Se você usa uma configuração mestre / escravo, deve-se realmente ter um licenciamento livre. Se você conseguir viver com a edição padrão - não é tão caro. Mas você precisa de uma janela de manutenção para a reogra- nização do índice, se a necessidade chegar. O pequeno banco de dados (testemunha de espelhamento) pode ser um dos servidores da web. É meramente usado como "terceiro voto", que servidor de banco de dados deve usar em caso de dúvida (como partes de rede caindo). Em seguida, decide qual dos servidores será encerrado.

Se isso não for suficiente para lidar com a carga - mas pode ser, se você fizer o projeto do db corretamente e obter alguns sistemas finais mais avançados (opterons duplos de seis núcleos). É possível instalar todo o hardware de uma unidade em uma gaiola com 2 unidades de rack - o Supermicro tem alguns que têm espaço para 24 discos rígidos de 2,5 ". Não é preciso ir SAS - os WD Velociraptors devem ser mais eficientes e obter um SSD rápido e um controlador RAID Adaptado e você obtém o SSD como buffer de leitura;) Deve ser mais que suficiente para lidar com sua carga.

Se isso não funcionar bem o suficiente, basicamente você precisa de mais recursos.

• Um cluster de cópias replicadas do banco de dados. Você possivelmente poderia usar a edição da Web aqui, que aceita ser um destino de replicação e é muito barato de usar. Aqueles que não receberiam atualizações / inserções e seriam apenas cópias de leitura. Você pode facilmente usar um balanceador de carga na frente deles (que janelas tem fora da caixa).

Configurações semelhantes devem ser possíveis com - bem ... não tenho certeza. Oracle - sim. MySQL - alguém pode entrar e responder.

    

Answer 2

Sua taxa média de consultas por segundo é 600. O que você sabe sobre o padrão de tráfego? Será que todas as consultas ocorrerão na hora do almoço, somente durante o horário de expediente em um fuso horário específico, o que?) Assumindo que todas as consultas sejam distribuídas uniformemente por um dia útil de 8 horas, você planeja um pico de 2k consultas por segundo .

Banco de dados? Se você precisa. Um armazenamento de chave / valor simples teria um desempenho mais alto. Registros de 1,5B de (digamos) 4kB cada um é de 6 TB. Experimente esta arquitetura:

5 frontends falando com um conjunto duplicado de armazenamentos de dados. Talvez use 40 servidores para isso, armazenando 300 GB cada. Isso significa que você pode perder qualquer host e continuar a servir. Se você for servir um novo resultado na maioria das vezes, eu dobraria isso para 80 servidores: você estará incorrendo em pelo menos uma busca de disco para cada consulta e eu não estaria tão otimista a ponto de esperar por um sustentado 50 procura um segundo.

A linguagem de programação é irrelevante.

    

Answer 3

Construir um sistema de banco de dados que possa lidar com 50 milhões de consultas por dia não é uma tarefa difícil. Com um grande servidor de cassandra, conseguimos obter ~ 100 leituras por segundo por núcleo e ~ 25 gravações por segundo por núcleo. Baseado no seu número 50M eu sugeriria 2 sistemas 8core. Para obter os números de desempenho, você precisará ajustar o sistema operacional, a configuração do disco e as especificações de memória.

O pré-carregamento de memória por família de colunas e o ajuste de layout (sem esquema) precisarão ser feitos.

Outras opções na grande área de cluster relacional não são tão escalonáveis e os custos serão escandalosos.

    

Answer 4

Você está analisando cerca de 30.000 solicitações por minuto, supondo que a carga seja distribuída ao longo do dia (improvável). Isso é muito, não importa o design do sistema.

No entanto, você subespecificado o problema. Nós não sabemos quão grande é o banco de dados em si, ou quão amenas as consultas são para o cache. Nós não sabemos a interface que você está dando às pessoas; você precisa aceitar o SQL ou a linguagem de consulta é decidível? Também não sabemos com que frequência o banco de dados será atualizado e como essas atualizações são críticas para as consultas subsequentes.

Quanto mais maneiras você puder restringir o problema, melhor você será.

    

Answer 5

Como você não forneceu muitos detalhes, também vou manter esse resumo. A linguagem depende mesmo de você, embora o C Sharp / ASP.NET se encaixe bem aqui. Eu usaria um banco de dados noSQL como o cassandra: link

Por último, com esse número de leituras versus gravações, planeje seu hardware (especificamente a velocidade da sua unidade) de acordo.

    

Answer 6

A questão que não foi discutida é qual é o mix de consultas que está acontecendo aqui. Muitas vezes você pode resolver metade do problema por meio do redesenho da aplicação.

Por exemplo, se um hit de página produzir 100 consultas, otimizar o código para fazer apenas 20 consultas, se a página for muito afetada, também pré-calcule o conteúdo da página e só recompute conforme necessário (mesmo cada minuto produziria muito mais eficiência). Isso pode produzir 100 a 1000 vezes mais eficiência. Em uma aplicação desse tamanho, você DEVE colocar tanto trabalho nos padrões de acesso aos dados do aplicativo quanto a implementação real, ou será muito mais caro para a organização. Além disso, se o desempenho for ruim no momento da implementação, você está solicitando problemas à medida que o aplicativo cresce. Eu literalmente vi execuções de banco de dados reduzidas de 6 horas para 3 minutos, aplicando princípios de design de banco de dados e aplicativos maduros, e não apenas uma vez.

Existem especialistas substanciais disponíveis no campo; é simplesmente uma questão de saber com quem falar. As pessoas que trabalham em organizações que lidam com esses tipos de aplicativos de tamanho normalmente têm acesso a esses especialistas, daí o comentário acima.

    

Answer 7

O MySQL pode lidar com milhares de consultas por segundo em hardware decente e, se o aplicativo for codificado para separar as consultas de leitura das consultas de atualização, é realmente fácil configurar escravos somente leitura para redimensionar as leituras. Seja qual for o idioma, verifique se o aplicativo suporta conexões persistentes e / ou pool de conexões.

    

Answer 8

Qual é o tamanho total do seu banco de dados e quais são suas especificações de hardware? Acima de dois pontos são mais cruciais para responder à sua pergunta, porque em hardware de baixa qualidade e configuração não decente você não obteria a marca de desempenho que está procurando.