mongodb - transfer - price dynamo db




DynamoDB vs MongoDB NoSQL (6)

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

Eu estou tentando descobrir o que eu posso usar para um projeto futuro, nós planejamos armazenar cerca de 500k registros por mês no primeiro ano e talvez mais para os próximos anos este é um aplicativo vertical, então não há necessidade de usar um banco de dados para isso, essa é a razão pela qual eu decidi escolher um armazenamento de dados noSQL.

A primeira opção que me veio à mente foi o mongo db já que é um produto muito maduro com muito apoio da comunidade mas por outro lado conseguimos um novo produto que oferece um serviço gerenciado em performance de topo, vou desenvolver este mas não há plano de manutenção (pelo menos por enquanto), então acho que isso será uma grande vantagem, já que a Amazon oferece uma forma elástica de escalar.

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

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


Eu sei que isso é antigo, mas ainda aparece quando você procura pela comparação. Nós estávamos usando o Mongo, nos mudamos quase inteiramente para o Dynamo, que é nossa primeira escolha agora. Não porque tem mais recursos, não tem. O Mongo tem uma linguagem de consulta melhor, você pode indexar dentro de uma estrutura, há muitas pequenas coisas. A superioridade do Dynamo está no que o OP declarou 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, fica complicado. Você pode ir a uma das empresas de hospedagem, mas isso também não é barato. Com o Dynamo, se você precisar de mais taxa de transferência, basta clicar em um botão. Você pode escrever scripts para escalar automaticamente. Quando é hora de atualizar o Dynamo, ele é feito para você. Isso tudo é muito esforço e tempo preciosos não gastos. Se você não tem pessoas dedicadas, o Dynamo é excelente.

Então, agora estamos indo no Dynamo por padrão. Mongo, talvez, se a estrutura de dados é complicada o suficiente para justificar isso, mas provavelmente voltaríamos a um banco de dados SQL. O Dynamo é obtuso, você realmente precisa pensar sobre como você irá construí-lo, e provavelmente você usará o Redis no Elasticcache para fazer com que ele funcione para coisas complexas. Mas com certeza é bom não ter que cuidar disso. Você codifica. É isso aí.


Lembre-se, eu só experimentei o MongoDB ...

Pelo que tenho lido, o DynamoDB já percorreu um longo caminho em termos de recursos. Costumava ser um armazenamento de valor-chave super-básico com capacidade de armazenamento e consulta extremamente limitada. 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 aumenta a cada mês. Os novos recursos do DynamoDB são expandidos here .

Muitas das comparações entre o MongoDB e o 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, ou seja, que é simples, baixa manutenção e, geralmente, de baixo custo. Outra discussão aqui sobre opções de banco de dados foi interessante de ler, embora um pouco antiga.

Meu takeaway: se você está fazendo consultas de banco de dados sérias ou trabalhando em linguagens não suportadas pelo DynamoDB, use o MongoDB. Caso contrário, fique com o DynamoDB.




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: Eu não usei o MongoDB para consultas, mas a partir de abril de 2015, o DynamoDB ainda é muito prejudicado quando se trata de qualquer coisa além das consultas de chave / valor mais básicas. Eu adoro isso para as coisas básicas, mas se você quiser linguagem de consulta, em seguida, olhar para uma solução de banco de dados SQL real.

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

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

In a response, DynamoDB returns all the matching results within
the scope of the Limit value. For example, if you issue a Query 
or a Scan request with a Limit value of 6 and without a filter
expression, the operation returns the first six items in the 
table that match the request parameters. If you also supply a
FilterExpression, the operation returns the items within the 
first six items in the table that match the filter requirements.

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

Opinião de especialistas: Na cúpula da AWS em 9 de abril de 2015, Brett Hollman, gerente de arquitetura de soluções da AWS em seu discurso sobre escalar para seus primeiros 10 milhões de usuários defende começar com um banco de dados SQL e usar NoSQL apenas 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.





amazon-dynamodb