DB de alto desempenho para leitura rápida e escrita rápida. Sem actualizar ou apagar [fechado]
Este armazenamento é usado para armazenar o registo como informação importante em vários sistemas. Talvez possamos arquivar os dados em muito tempo, mas isso é algo com que podemos lidar.
eu tentei olhar para diferentes fontes para entender diferentes bases de dados NoSql, a opinião dos especialistas é sempre melhor:)
Must Have:
1. Fast Read without fail
2. Fast Write without fail
3. Random access Performance
4. Replication kinda feature, one goes down, immediately another should be up and working
5. Concurrent write/read data
Good to Have:
1. Search content like analysing the data for auditing with/without Indexes
Don't required:
1. Transactions are not required at all
2. Update never happens
3. Delete never happens
4. Joins are not required
referido: http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis
3 answers
Certifique-se de considerar Aérospike; Aérospike domina no espaço adtech onde alta capacidade lê e escreve é um requisito. Aerospike é frequentemente considerado como tendo " a velocidade de Redis com a escalabilidade de Cassandra."Para pesquisar / questionar veja a documentação do índice secundário da Aerospike.
Para mais informações, ver a discussão/artigos abaixo:
Por último, verifique o seu desempenho com o um milhão de TPS nas instruções do EC2 .
Disclaimer: Eu não digo que Cassandra é melhor do que os outros porque eu nem sei tão profundamente mongo/redis/qualquer coisa e eu não quero mesmo entrar neste tipo de coisas.
A razão pela qual sugiro a Cassandra é porque as suas necessidades correspondem perfeitamente com o que a Cassandra oferece e a sua "lista não necessária" é um conjunto de funcionalidades que ou não são suportadas em Cassandra (junta para instâncias) ou consideradas um anti-padrão (apaga e em algumas situações atualiza).
Da tua lista "deve ter", ponto por ponto
leitura rápida sem falha: apoiado. Você pode escolher o nível de consistência de cada operação de leitura decidir o quanto é importante para recuperar a informação mais fresca e o quanto é importante é a velocidade
escrita rápida sem falha: o mesmo que o ponto 1
acesso aleatório Desempenho: Quando chegar no Cassandra mundo, você tem que considerar vários parâmetros para obter um desempenho de acesso aleatório, mas o mais importante que vem na minha mente é o modelo de dados -- se você criar um modelo de dados que as escalas horizontal (dar uma olhada aqui) e evitar hotspots você conseguir o que você precisa. Se modelar o seu DB de uma forma correcta deverá ter O (1) para cada operação, uma vez que os dados estão estruturados para ser questionado
replicação: Nesta Cassandra é ainda melhor do que aquilo que possas pensar. Se um nó cair nada muda para o aglomerado e tudo(*) continuar funcionando perfeitamente. Cassandra não vê um único ponto de fracasso. Posso dizer-te com a versão mais velha da Cassandra que tive um tempo de funcionamento de mais de 3 anos.
Dados de gravação/leitura simultâneos: Cassandra usa a Política lww (Last-write-wins) para lidar com escritas simultâneas em a mesma chave. O sistema suporta múltiplas leituras-write e com novos protocolos também operações async.
Existem muitas outras características interessantes que Cassandra oferece: escala horizontal linear é o que eu aprecio mais, mas também há o fato de que você pode saber o instante em que cada pedaço de dados foi atualizado (o timestamp de lww), contadores recursos e assim por diante.
(*) - Se você não usar o nível de consistência tudo o que, imho, nunca deve ser usado num tal sistema.
Http://www.aerospike.com/hybrid-memory/
Http://www.aerospike.com/docs/architecture/storage.html
Acho que toda a gente tem razão em termos de combinar o DB específico com o seu caso de uso específico. Por exemplo, a Aérospike é ideal para dados de valor-chave. Outras opções podem ser melhores.
Por analogia, lembrar-me-ei sempre. há décadas, uma irmã minha pediu emprestado o meu computador e escreveu o seu trabalho no Microsoft Excel. Linha após linha era uma linha diferente de uma planilha. Parecia muito feio, mas ... está bem. Ela fez a tarefa. Ela amaldiçoou e jurou como era difícil editar a coisa. A sério?Escolher a base de dados NoSQL certa para a tarefa certa fará do seu trabalho uma brisa, ou poderá fazer com que amaldiçoe uma maré de sorte azul se decidir pela ferramenta básica errada para a tarefa em mao.
Claro que todos os vendedores vão defender o seu produto. Acho que é melhor a comunidade responder à pergunta. Aqui está outro tópico de sobrecarga de pilha respondendo a uma pergunta semelhante:Alguém trabalhou com o Aerospike? Como se compara ao MongoDB?
[[1]}Btw: você tem alguma visão mais específica para nós sobre que tipo de problema você está tentando resolver?