- Filas para gerenciar atualizações de inventário para cada canal.
Isso não é necessariamente um problema de banco de dados. Você pode ser melhor olhar para um sistema de mensagens (por exemplo, RabbitMQ)
- Tabela de inventário que tem um instantâneo correto da alocação em cada canal.
- Manter IDs de sessão e outros dados de acesso rápido em um cache.
os dados da sessão provavelmente devem ser colocados em um banco de dados separado mais adequado para a tarefa (por exemplo, memcached, redis, etc) Não existe um banco de dados de tamanho único
- Fornecer um painel do tipo facebook(XMPP) para manter o vendedor atualizado o mais rápido possível.
Minhas restrições são:1. As atualizações de inventário não podem ser perdidas.
Existem 3 formas de responder a esta pergunta:
-
Esse recurso deve ser fornecido pelo seu aplicativo. O banco de dados pode garantir que um registro inválido seja rejeitado e revertido, mas não garante que todas as consultas sejam inseridas. O aplicativo terá que ser inteligente o suficiente para reconhecer quando ocorrer um erro e tentar novamente.
-
alguns bancos de dados armazenam registros na memória e, em seguida, liberam a memória para o disco periodicamente, isso pode levar à perda de dados em caso de falha de energia. (por exemplo, o Mongo funciona dessa maneira por padrão, a menos que você ative o journaling. O CouchDB sempre anexa aos registros (mesmo uma exclusão é um sinalizador anexado ao registro, portanto, a perda de dados é extremamente difícil))
-
Alguns BDs são projetados para serem extremamente confiáveis, mesmo que ocorra um terremoto, furacão ou outro desastre natural, eles permanecem duráveis. estes incluem Cassandra, Hbase, Riak, Hadoop, etc
A que tipo de durabilidade você se refere?
- As filas de tarefas devem ser executadas em ordem e, de preferência, nunca perdidas.
A maioria das soluções noSQL prefere ser executada em paralelo. então você tem duas opções aqui.1. use um banco de dados que bloqueie a tabela inteira para cada consulta (mais lenta)2. crie seu aplicativo para ser mais inteligente ou organizado (fila sequencial do lado do cliente)
- Desenvolvimento fácil/rápido e manutenção futura.
geralmente, você descobrirá que o SQL é mais rápido para desenvolver no início, mas as alterações podem ser mais difíceis de implementar. NoSQL, pode exigir um pouco mais de planejamento, mas é mais fácil fazer consultas ad hoc ou alterações de esquema.
As perguntas que você provavelmente precisa se fazer são mais como:
-
"Precisarei ter consultas intensas ou análises profundas para as quais um Map/Reduce é mais adequado?"
-
"precisarei alterar meu esquema com frequência?
-
"meus dados são altamente relacionais? De que maneira?"
-
"o fornecedor por trás do meu banco de dados escolhido tem experiência suficiente para me ajudar quando eu precisar?"
-
"precisarei de recursos especiais, como indexação geoespacial, pesquisa de texto completo, etc?"
-
"Quão perto do tempo real precisarei dos meus dados? será ruim se eu não ver os registros mais recentes aparecerem em minhas consultas até 1 segundo depois? Qual nível de latência é aceitável?"
-
"o que eu realmente preciso em termos de failover"
-
"qual é o tamanho dos meus dados? caberão na memória? caberão em um computador? cada registro individual é grande ou pequeno?
-
"com que frequência meus dados serão alterados? isso é um arquivo?"
Se você vai ter vários clientes (canais?) cada um com seus próprios esquemas de inventário, um banco de dados baseado em documentos pode ter suas vantagens. Lembro-me de uma vez que olhei para um sistema de comércio eletrônico com estoque e ele tinha quase 235 tabelas! Então, novamente, se você tiver certos dados relacionais, uma solução SQL pode realmente ter algumas vantagens também.
Eu certamente posso ver como eu poderia construir uma solução usando mongo, couch, riak ou orientdb com as restrições fornecidas. Mas quanto a qual é o melhor? Eu tentaria falar diretamente com fornecedores de banco de dados e talvez assistir as fitas nosql
