Banco de dados de documentos NoSQL como uma fila de mensagens

5

Estou pensando em usar um banco de dados NoSQL Document como uma fila de mensagens.

Aqui está o porquê:

  • Eu quero que um cliente publique uma mensagem (algum objeto serializado) no servidor e não precise esperar por uma resposta síncrona.
  • Eu quero ser capaz de extrair mensagens da "fila" com base em alguns critérios, que podem ser mais sofisticados do que apenas um nível de prioridade (estou trabalhando em um aplicativo da Web hospedado, por isso desejo dar a todos os meus clientes uma boa quantia de "tempo de computação", e não permitir que um cliente adote todo o processamento).
  • Eu quero que a fila seja durável - se o servidor ficar inativo, quero que todas as mensagens restantes sejam tratadas quando ele voltar.

Então, estou pensando em usar o MongoDB ou o RavenDB como uma fila de mensagens. O cliente pode postar o objeto de mensagem em um serviço da web que o grava no banco de dados. Então - o serviço que faz o trabalho pode extrair os vários tipos de mensagem com base em qualquer critério que possa surgir. Eu posso criar índices em torno dos cenários para torná-lo mais rápido.

Então - eu estou procurando alguém para fazer um buraco nisso. Alguém conseguiu fazer isso com sucesso? Alguém tentou isso e falhou de alguma forma?

    
por MattW 07.03.2013 / 21:06
fonte

3 respostas

4

Confira a resposta aceita nesta pergunta: link

Acredito que ter trabalhado com os dois tipos de bancos de dados é que as vantagens reais do NoSQL estão na sua escalabilidade. Eles são adequados para blobs cada vez maiores de coisas que precisam existir em muitos nós. Afinal, estas são as aplicações que nasceram do (Facebook, Google ...).

Eles também têm desvantagens e são específicos para a implementação. Pessoalmente, sofri com alguns erros de replicação quando vários nós eliminavam e preenchiam objetos em um curto período de tempo. Eu não estou necessariamente sugerindo que é sempre difundido, mas a vantagem de velocidade geralmente vem com menos garantias de consistência (ou seja, você terá consistência eventual , mas você não quer depender disso) .

Se tudo o que você está fazendo é construir uma fila, então não vejo nada específico para o NoSQL que os torne uma escolha preferida. A velocidade / fiabilidade / eficiência do mesmo irá descer mais para a configuração de qualquer implementação que você decida ir.

    
por 07.03.2013 / 21:15
fonte
2

Não há buracos visíveis, pois sua lista de requisitos é muito curta :-). Basicamente, quanto maior a lista de requisitos, maiores são as chances de encontrar falhas na sua própria redação.

Na minha opinião, o uso de um banco de dados NoSQL para esse cenário seria adequado:

  1. se os requisitos não forem para uma fila de recursos completos
  2. se o aplicativo não precisar mover do modelo de recepção para um modelo de envio (fila v pub / sub)
  3. a estrutura das mensagens é bastante variável e muda com o tempo
  4. o aplicativo precisa receber mensagens com base em critérios diferentes
  5. reutilizar o banco de dados NoSQL reduziria o número de sistemas dos quais o aplicativo dependeria

Como uma nota lateral, eu (tendenciosamente) encorajo você a também dar uma olhada no RethinkDB.

    
por 08.03.2013 / 23:04
fonte
1

Concordo com o MrFox. É necessário considerar que, se você tiver vários encadeamentos atualizando os mesmos dados na fila, seu banco de dados deverá suportar transações ACID verdadeiras ou você arriscará que o mesmo item na fila seja processado mais de uma vez, além de obter duplicatas do mesmo item a fila.

Se o total de dados que você publicar na fila não estiver em tamanho grande de dados (> PB) de dados, aconselho a seleção de outro tipo de banco de dados, pelo menos um banco de dados que suporte consistência verdadeira.

A fila de processos será mais adequada para um tipo de banco de dados OLTP, já que você está basicamente fazendo mais inserções / atualizações do que qualquer outra coisa.

    
por 08.03.2013 / 09:32
fonte