Recomendações para o Sistema de Alta Transação [fechado]

Question

Sou administrador e desenvolvedor de banco de dados do SQL Server e também tenho muitos anos de experiência como desenvolvedor de aplicativos. Atualmente, tenho um cliente com um projeto muito grande que me procura orientação.

O cliente iniciou o desenvolvimento do lado do cliente do sistema usando o Microsoft Access e diz que essa parte está quase concluída. Perguntei por que o MS Access foi usado e recebi a informação de que os responsáveis no momento conheciam o MS Access e achavam que era fácil de usar e poderoso o suficiente para fazer o trabalho, pois era apenas do lado do cliente e já tinha sido testado com dados simulados ( Eu suponho uma quantidade muito limitada de dados fictícios e nenhum teste de estresse / carga real, mas a lógica do lado do cliente está funcionando como desejado).

Mas agora o cliente precisa de orientação e virou-se para mim. Eles parecem pensar que o resto do quebra-cabeça é simples e tudo no lado "banco de dados". Eles percebem que precisarão ser servidores e comunicação entre o aplicativo cliente e o banco de dados, mas não têm a menor idéia do que realmente precisa ser feito ou como.

Eu sei como desenvolver aplicativos, especialmente aplicativos de servidor cliente. E eu sei como projetar e construir bancos de dados e todos os processos do lado do servidor e funcionalidade de lógica de negócios. Mas não tenho certeza exatamente do que o cliente precisa neste caso específico.

O cliente está solicitando que este sistema se comunique entre o cliente e o servidor via conexão sem fio celular 3G.

O sistema precisará ser escalonável porque haverá transações altas, embora as transações possam ser "em lote".

Haverá vários locais e cada local terá 2000 - 5000 usuários.

Cada usuário se comunicará com o servidor automaticamente a cada dez minutos.

Cada comunicação do usuário com o servidor passará cerca de 60 transações. (5000 usuários passando 60 transações a cada 10 minutos = 300.000 transações a cada dez minutos [ou 30 mil transações por minuto; 500 transações por segundo])

Minhas perguntas para este grupo são:

1. Qual é o melhor design para um sistema transacional tão alto que é dimensionável à medida que o número de transações aumenta e aumenta o número de locais?

2. Qual seria a melhor linguagem de desenvolvimento para o aplicativo cliente? (o MS Access funcionará?)

3. Eu sei que o Microsoft SQL Server é poderoso o suficiente para lidar com a carga de trabalho, especialmente com vários servidores e particionamento de dados, etc. E eu tenho certeza que o MySQL também funcionaria. Mas estas duas bases de dados são a melhor escolha (por favor, esclareça a sua resposta com razões objetivas claras e não apenas preferência pessoal ou opinião)?

4. O cliente mencionou que a GoDaddy oferece vários bancos de dados MySQL por um valor específico por mês, mas isso não exige um site / aplicativo da Web? O GoDaddy não hospeda apenas bancos de dados para aplicativos de servidor cliente, não é?

5. Esse sistema pode funcionar corretamente através de conexões sem fio de celular 3G entre o (s) servidor (es) e até 5.000 clientes nos valores de transação mencionados anteriormente?

Seus pensamentos e sugestões serão apreciados.

Obrigado

    

Answer 1

O SQL Server e o MySQL podem lidar com esse tipo de carga de trabalho sem problemas. 500 transações por segundo não são uma carga de trabalho muito alta.

Quanto ao serviço de celular 3G, você vai querer usar os telefones celulares para obter acesso à internet e, em seguida, fazer com que eles entrem em contato com o servidor da web pela Internet normal.

Você não deseja que o aplicativo se conecte ao banco de dados diretamente, a menos que tenha uma conexão VPN dos usuários finais para o data center do seu aplicativo. Em vez disso, você desejará configurar um aplicativo da web em um servidor da web (ou vários servidores da web por trás de um balanceador de carga) e ter os métodos da web de chamada do aplicativo final no servidor da web, que então fala com o servidor de banco de dados.

Embora o GoDaddy possa lidar com isso, para algo dessa escala você provavelmente desejará servidores dedicados. Começando com algo como o RackSpace, o EC2 ou o Azure, passando depois para servidores dedicados no seu próprio centro de dados ou centro de dados.

    

Answer 2

Eu costumava ganhar massa como desenvolvedor do MSAccess - é muito fácil criar aplicativos simples, e uma vez que você tem que lidar com o VB ainda é relativamente rápido para desenvolver lógica complexa, no entanto, uma frustração constante estava tentando aumentar a escala para vários usuários - obtendo a versão correta do software / middleware do cliente de tempo de execução funcionando e configurada na máquina do usuário, classificando o bloqueio de registro e obtendo desempenho aceitável de bancos de dados remotos. Muito em breve se torna um pesadelo. E isso foi feito com cerca de 30 usuários no mesmo site.

O pensamento de tentar suportar milhares de usuários distribuídos em vários sites me faria sair do prédio gritando!

Each user will communicate with the server automatically about every ten minutes. ... Each user communication with the server will pass about 60 transactions

Então você está realmente falando sobre um banco de dados distribuído - OMG !!!!!!! VOCÊ NÃO QUER ESTE DOR!

Como mrdenny diz - a carga de trabalho do lado do servidor é baixa - e praticamente qualquer SGBD multi-usuário deve ser capaz de acomodar o nível de transações.

Mas se fosse eu, não haveria nenhuma maneira de tentar implementar a interface do usuário usando o MS Access.

Você não deu muita informação sobre o relacionamento entre os sites / usuários / rede. Parece estranho que você tente conectar sites com 3G em vez de usar uma WAN / VPN convencional, mas também parece estranho que você tenha clientes em um site se comunicando via 3G. Também é incomum encontrar um dispositivo 3G capaz de executar o MSAccess.

Se eu supor que existe uma infraestrutura convencional dentro de cada site e que os sites estão conectados via 3G, então eu usaria um banco de dados local em cada site - com um front-end baseado na Web (implantação zero). Em seguida, preocupe-se em consolidar / publicar dados entre os sites separadamente (tanto o MySQL quanto o MSSQL possuem ferramentas para facilitar isso - com o Oracle, é um pouco mais difícil).

Claro, se você tem milhares de sites e milhares de usuários, essa é uma história diferente. E se você puder somente conectá-los via 3G, então pode ser mais eficaz agrupar os dados no cliente - o que é bastante complicado usando navegadores mais antigos, mas perfeitamente possível com o armazenamento local do GoogleGears / HTML5. / p>

Mesmo que você possa redistribuir gratuitamente o cliente de tempo de execução do MSAccess, o custo de reimplementação do sistema em PHP ou ASP provavelmente será menor do que o custo de implantação e gerenciamento de todas as instâncias do MSAccess (supondo que os dispositivos clientes executem o MSAccess ).

The customer mentioned GoDaddy

Oh querida. Soa como uma das empresas sobre as quais você lê todos os dias no dailyWTF .