DynamoDB vs MongoDB NoSQL [fechado]


172

Estou tentando descobrir o que posso usar para um projeto futuro. Planejamos armazenar cerca de 500 mil registros por mês no primeiro ano e talvez mais nos próximos anos esse seja um aplicativo vertical, portanto não há necessidade de usar um banco de dados para isso, essa é a razão pela qual decidi escolher um armazenamento de dados noSQL.

A primeira opção que me veio à cabeça foi o mongo db, pois é um produto muito maduro, com muito apoio da comunidade, mas, por outro lado, temos um novo produto que oferece um serviço gerenciado com o melhor desempenho, vou desenvolver isso aplicação, mas não há plano de manutenção (pelo menos por enquanto), então acho que será uma grande vantagem, pois a Amazon oferece uma maneira elástica de escalar.

Minha principal preocupação é com a estrutura da consulta, ainda não examinei os recursos de consulta do dynamoDB, mas como é o armazenamento de dados ak / v, sinto que isso pode ser mais limitado que o mongo db.

Se alguém teve a experiência de mover um projeto do mongoDB para o DynamoDB, qualquer conselho será totalmente apreciado.


3
Se você deseja aconselhamento sobre a estrutura de consulta, sugiro fornecer um exemplo de seu esquema, juntamente com seus casos de uso para acessar dados. Sem estes, é difícil fazer um julgamento de forma adequada.
James Wahlin 29/07

De fato, como você está consultando os dados pode influenciar drasticamente a seleção do banco de dados de back-end. Quão hierárquica seria minha pergunta nº 1.
fácil

3
Estou surpreso que esta pergunta ainda não tenha sido encerrada pelo ranking de pessoas SO. Geralmente, as perguntas que procuram aconselhamento são encerradas porque não estão pedindo ajuda com um problema muito específico.
LS

Respostas:


67

Recentemente, migrei meu MongoDB para o DynamoDB e escrevi 3 blogs para compartilhar algumas experiências e dados sobre desempenho, custo.

Migrar do MongoDB para o AWS DynamoDB + SimpleDB

7 razões para usar o MongoDB sobre o DynamoDB

3 razões para usar o DynamoDB sobre o MongoDB


obrigado por postar seus artigos aqui que me ajudou a ter uma visão mais clara e que é definitelly vai me ajudar no momento em que eu vou fazer uma desition
jack.the.ripper

1
lendo os três motivos pelos quais você deve usar o dínamo sobre o mongo, há uma empresa que oferece um serviço gerenciado mais caro comparado ao dínamo, mas isso pode ser levado em consideração caso você não tenha uma pessoa encarregada da manutenção do nosql , o nome da empresa é mongoLab
jack.the.ripper

2
@ Pedro Muito obrigado pelo lembrete. Talvez eu esteja usando o MongoDB de forma ineficiente. Eu tenho 1,4 milhões de registros e ocupei o disco 8G, mas depois de transferido para o DynamoDB, ocupei apenas 300 milhões de armazenamento. Posso precisar de um teste e ver o que o armazenamento se eu migrar esses dados para MongoLab :)
Mason Zhang

1
Os links estão quebrados?
fedorqui 'Então, pare de prejudicar' 21/03

@MasonZhang Será muito interessante ver qual o armazenamento se você migrar esses dados para o MongoLab.
fuiiii 20/08/14

164

Eu sei que isso é antigo, mas ainda aparece quando você pesquisa a comparação. Estávamos usando o Mongo, mudamos quase totalmente para o Dynamo, que é a nossa primeira escolha agora. Não porque tem mais recursos, não. O Mongo tem uma linguagem de consulta melhor, você pode indexar dentro de uma estrutura, existem muitas pequenas coisas. A superioridade do Dynamo está no que o OP afirmou em seu comentário: é fácil. Você não precisa cuidar de nenhum servidor. Quando você começa a configurar uma solução fragmentada do Mongo, ela fica complicada. Você pode ir a uma das empresas de hospedagem, mas isso também não é barato. Com o Dynamo, se você precisar de mais produtividade, basta clicar em um botão. Você pode escrever scripts para dimensionar automaticamente. Quando é hora de atualizar o Dynamo, está pronto para você. Isso é muito estresse precioso e tempo não gasto. Se você não

Então, agora vamos no Dynamo por padrão. Mongo talvez, se a estrutura de dados for complicada o suficiente para justificá-la, mas provavelmente voltaríamos ao banco de dados SQL. O Dynamo é obtuso, você realmente precisa pensar em como irá construí-lo e provavelmente usará o Redis no Elasticcache para fazê-lo funcionar em coisas complexas. Mas com certeza é bom não ter que cuidar disso. Você codifica. É isso aí.


35
Se for necessário comparar banco de dados com banco de dados, é preciso comparar apenas os recursos do banco de dados. A solução hospedada não é um recurso de banco de dados. Se você está procurando um MongoDB hospedado, vá para o MongoHQ e eles fazem todo o trabalho pesado que você pode querer evitar enquanto se concentra no seu trabalho principal.
Kabeer

12
É verdade, embora a comparação inicial de custos que fizemos demonstrou que o dínamo é um bom negócio. A outra questão é que, se você precisar aumentar / reduzir o dínamo, basta clicar em um botão. Se você precisar adicionar um disco ou redimensionar um servidor mongo, há um tempo de inatividade envolvido, se você precisar fazer isso ou outra pessoa.
CargoMeister

@ Kabeer Concordo 100% com você tecnicamente, mas no mundo real o pacote inteiro é importante para tomar uma decisão de negócios. Em última análise, esta é uma decisão de negócios.
Poitroae

59

Com documentos de 500 mil, não há motivo para escalar de maneira alguma. Um laptop típico com um SSD e 8 GB de memória RAM pode fazer facilmente 10 milhões de registros, por isso, se você está tentando escolher por causa da escala, sua escolha não importa. Sugiro que você escolha o que mais gosta e, talvez, onde possa encontrar o suporte mais on-line.


sim minha preocupação prefeito é de cerca de ampliação e manutenção ao longo do tempo para ser honesto, pessoalmente, sinto que mongoDB pode fazer o trabalho eu só estou pensando em termos de médio e manutenção a longo prazo
jack.the.ripper

10
Derick, outro fator importante na escala é a utilização, não apenas a contagem de documentos ou o tamanho do banco de dados. O @jack não "sente", mas confia em testes, incluindo a plataforma e o hardware da implantação final; uma semana passada enchendo algumas variantes de banco de dados com dados e benchmarking deve levar a decisões informadas, economizando muita dor.
zanlok

3
Fornecer um produto / serviço profissional vai muito além da simples solução "isto pode fazer isso". Só porque uma máquina barata pode rodar Linux, MongoDB e milhões de registros por quase nenhum dinheiro não é igual a um ótimo desempenho no mundo real. Os registros de 500K (com um esquema SIMPLE) provavelmente seriam um bom candidato ao DynamoDB, simplesmente porque o OP não teria custo de manutenção (pelo menos para hardware) e a cobrança mensal provavelmente seria muito menor que o custo de um servidor ao longo de um ano ou dois.
Cbmeeks


16

Resposta curta: Comece com SQL e adicione NoSQL somente quando / se necessário. (a menos que você não precise de nada além de consultas muito simples)

Minha experiência pessoal: não usei o MongoDB para consultas, mas desde abril de 2015 o DynamoDB ainda está muito prejudicado quando se trata de algo além das consultas mais básicas sobre chave / valor. Adoro as coisas básicas, mas se você quiser uma linguagem de consulta, procure uma solução real de banco de dados SQL.

No DynamoDB, você pode consultar um hash ou uma chave de hash e intervalo e pode ter vários índices globais secundários. Estou fazendo consultas em uma única tabela com 4 possíveis parâmetros de filtro e classificando os resultados, isso é suportado (apenas) pelo uso dos índices secundários globais com expressões de filtro. O problema surge quando você tenta obter o total de resultados correspondentes ao filtro, não pode apenas procurar os 10 primeiros itens correspondentes ao filtro, mas verifica 10 itens e você pode obter 0 resultados válidos, forçando-o a continuar digitalizar a partir da tecla continuar - dor no pescoço e consome muito da sua cota de leitura da tabela para um cenário simples.

Para ser específico sobre o problema do limite de filtros na consulta, é dos documentos ( http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/QueryAndScan.html#ScanQueryLimit ):

Em uma resposta, o DynamoDB retorna todos os resultados correspondentes dentro
o escopo do valor limite. Por exemplo, se você emitir uma Consulta
ou uma solicitação de verificação com um valor limite de 6 e sem filtro
expressão, a operação retorna os seis primeiros itens no 
tabela que corresponde aos parâmetros de solicitação. Se você também fornecer um
FilterExpression, a operação retorna os itens dentro do 
primeiros seis itens da tabela que correspondem aos requisitos de filtro.

Minha conclusão é que as consultas que envolvem FilterExpressions são utilizáveis ​​apenas em ocasiões muito raras e não são escalonáveis, porque cada consulta pode facilmente ler a maioria ou a totalidade da sua tabela, o que consome muitas unidades de leitura do DynamoDB. Depois de usar muitas unidades de leitura, você será otimizado e verá um desempenho ruim.

Opinião de especialista: Na cúpula da AWS em 9 de abril de 2015, Brett Hollman, gerente de arquitetura de soluções da AWS, em sua palestra sobre os seus primeiros 10 milhões de usuários, defende começar com um banco de dados SQL e usar o NoSQL somente quando e se fizer sentido. Porque mais cedo ou mais tarde você provavelmente precisará de um servidor SQL em algum lugar da sua pilha. Seus slides estão aqui: http://www.slideshare.net/AmazonWebServices/deep-dive-scaling-up-to-your-first-10-million-users Veja o slide 28.


Você realmente deve verificar o quão fácil é integrar a pesquisa em nuvem com fluxos dynamodb e lambda para obter consultas com texto completo ou com base em localização.
MrTJ

4
Escolha seu banco de dados de acordo com suas necessidades. Esta não é uma escolha entre SQL e noSQL, mas entre DB orientado a documentos, DB orientado a gráfico, DB de valor-chave, RDMBS .... Não há opção de ouro, e SQL certamente não.
precisa

14

Escolhemos uma combinação do Mongo / Dynamo para um produto de assistência médica. Basicamente, o mongo permite uma melhor pesquisa, mas o Dynamo hospedado é ótimo porque é compatível com HIPAA sem nenhum trabalho extra. Portanto, hospedamos a parte mongo sem dados pessoais em uma configuração padrão e permitimos que a amazon lide com a parte HIPAA em termos de infraestrutura. Podemos consultar certos itens do mongo que exibem documentos com ponteiros (IDs) do documento Dynamo relacionado.

A principal razão pela qual escolhemos fazer isso usando o mongo em vez de hospedar o aplicativo inteiro no dínamo foi por 2 razões. Primeiro, precisávamos realizar pesquisas baseadas em localização, nas quais o mongo é ótimo no momento, o Dynamo não era, mas elas têm uma opção agora.

Em segundo lugar, alguns documentos não foram estruturados e não sabíamos antecipadamente quais seriam os dados. Por exemplo, digamos que o usuário a insira um documento na coleção "form" assim: {"nome de usuário": "usuário1", " email ":" me@me.com "}. E outro usuário coloca isso na mesma coleção {"phone": "813-555-3333", "location": [28.1234, -83.2342]}. Com o mongo, podemos pesquisar qualquer um desses campos dinâmicos e desconhecidos a qualquer momento. Com o Dynamo, você poderia fazer isso, mas teria que fazer um índice sempre que um novo campo fosse adicionado, que você desejasse pesquisável. Portanto, se você nunca teve um campo telefônico no documento do Dynamo antes e, de repente, alguém o adiciona, é completamente insondável.

Agora isso traz outro ponto em que você mencionou. Às vezes, escolher a solução certa para o trabalho nem sempre significa escolher o melhor produto para o trabalho. Por exemplo, você pode ter um cliente que precisa e usará o sistema criado por mais de 10 anos. Usar uma solução SaaS / IaaS que seja boa o suficiente para fazer o trabalho pode ser uma opção melhor, pois você pode contar com a amazon para manter e manter seus sistemas a longo prazo.


9

Eu trabalhei em ambos e tipo de fã de ambos.

Mas você precisa entender quando usar o quê e para que finalidade.

Não acho que seja uma boa ideia mover todo o seu banco de dados para o DynamoDB, porque a consulta é difícil, exceto nas chaves primárias e secundárias, a indexação é limitada e a varredura no DynamoDB é dolorosa.

Eu usaria um tipo híbrido de banco de dados, em que dados extensos para consulta deveriam estar lá, o MongoDB, com todos os recursos que você nunca sentiria constrangido a fornecer aprimoramentos ou modificações.

O DynamoDB é extremamente rápido (mais rápido que o MongoDB), portanto o DynamoDB é frequentemente usado como uma alternativa às sessões em aplicativos escalonáveis. As práticas recomendadas do DynamoDB também sugerem que, se houver muitos dados menos usados, mova-os para outra tabela.

Então, suponha que você tenha artigos ou feeds. As pessoas têm maior probabilidade de procurar coisas da semana passada ou deste mês. as chances são realmente raras para as pessoas visitarem dados de dois anos. Para esses fins, o DynamoDB prefere ter dados armazenados por mês ou anos em diferentes tabelas.

O DynamoDB é aparentemente escalável, algo que você precisará fazer manualmente no MongoDB. no entanto, você perderia o desempenho do DynamoDB, se não entender sobre a partição de taxa de transferência e como o dimensionamento funciona nos bastidores.

O DynamoDB deve ser usado onde a velocidade é crítica, o MongoDB, por outro lado, possui muitas mãos e recursos, algo que falta ao DynamoDB.

por exemplo, você pode ter um conjunto de réplicas do MongoDB de forma que uma das réplicas contenha uma instância de dados com 8 (ou o que) horas de duração. Realmente útil, se você estragou algo importante no seu banco de dados e deseja obter os dados como estão antes.

Essa é a minha opinião.


1
E uma combinação de Redis e MongoDB? Isso é incrível, eu acho.
Ismaestro 23/11

Eu acho que sim, eu não tenho experiência prática no Redis, mas com certeza é amplamente usado por causa de seu desempenho, os DBs de memória quase sempre têm melhor desempenho do que os DBs baseados em disco. Então, acho que os dados que precisam ser acessados ​​com grande demanda e alta frequência devem ir para o Redis. Por outro lado, para grandes dados letárgicos, o MongoDB deve ser usado.
precisa

7

Tenha em mente, eu só experimentei o MongoDB ...

Pelo que li, o DynamoDB percorreu um longo caminho em termos de recursos. Costumava ser um armazenamento de valores-chave super básico, com recursos extremamente limitados de armazenamento e consulta. Desde então, cresceu, agora suportando tamanhos maiores de documentos, suporte a JSON e índices secundários globais . A diferença entre o que o DynamoDB e o MongoDB oferece em termos de recursos diminui a cada mês. Os novos recursos do DynamoDB são expandidos aqui .

Muitas das comparações entre MongoDB e DynamoDB estão desatualizadas devido à recente adição dos recursos do DynamoDB. No entanto, este post oferece alguns outros pontos convincentes para escolher o DynamoDB, a saber, que é simples, de baixa manutenção e, geralmente, de baixo custo. Outra discussão aqui sobre as opções de banco de dados foi interessante de ler, embora um pouco antiga.

Meu argumento: se você estiver fazendo consultas sérias no banco de dados ou trabalhando em idiomas não suportados pelo DynamoDB, use o MongoDB. Caso contrário, fique com o DynamoDB.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.