Eu uso o MySQL há um bom tempo e estou confortável com sua estrutura e consultas SQL, etc.
Atualmente construindo um novo sistema no AWS e tenho pesquisado o DynamoDB. Atualmente só sei um pouco sobre isso.
É um melhor que o outro?
Quais são as vantagens do DynamoDB?
como é a transição das consultas MySQL, etc., para este banco de dados de estilo simples?
Respostas:
Você pode ler a explicação da AWS sobre isso aqui .
Resumindo, se você tiver principalmente consultas de pesquisa (e não consultas de junção), DynamoDB (e outro banco de dados NoSQL) é melhor. Se você precisar lidar com muitos dados , ficará limitado ao usar o MySQL (e outros RDBMS).
Você não pode reutilizar suas consultas MySQL nem seu esquema de dados, mas se você se esforçar para aprender NoSQL, adicionará uma ferramenta importante à sua caixa de ferramentas. Existem muitos casos em que o DynamoDB está oferecendo a solução mais simples.
Na verdade, o DynamoDB e o MySQL são maçãs e laranjas. DynamoDB é uma camada de armazenamento NoSQL, enquanto o MySQL é usado para armazenamento relacional. Você deve escolher o que usar com base nas necessidades reais de seu aplicativo. Na verdade, alguns aplicativos podem ser bem atendidos com o uso de ambos.
Se, por exemplo, você estiver armazenando dados que não se adaptam bem a um esquema relacional (estruturas de árvore, representações JSON sem esquema, etc.) que podem ser consultados em uma única chave ou uma combinação de chave / intervalo, em seguida, DynamoDB ( ou alguma outra loja NoSQL) provavelmente seria sua melhor aposta.
Se você tiver um esquema bem definido para seus dados que pode se encaixar bem em uma estrutura relacional e precisar de flexibilidade para consultar os dados de várias maneiras diferentes (adicionando índices conforme necessário, é claro), o RDS pode ser uma solução melhor .
O principal benefício de usar o DynamoDB como um armazenamento NoSQL é que você obtém uma taxa de transferência de leitura / gravação garantida em qualquer nível necessário, sem ter que se preocupar com o gerenciamento de um armazenamento de dados em cluster. Portanto, se seu aplicativo requer 1000 leituras / gravações por segundo, você pode apenas provisionar sua tabela do DynamoDB para esse nível de taxa de transferência e não precisar realmente se preocupar com a infraestrutura subjacente.
O RDS tem muito do mesmo benefício de não ter que se preocupar com a infraestrutura em si, no entanto, se você acabar precisando fazer um número significativo de gravações até o ponto em que o maior tamanho de instância não será mais compatível, você ficará sem opções (você pode escalar horizontalmente para leituras usando réplicas de leitura).
Nota atualizada: o DynamoDb agora oferece suporte à indexação secundária global, então agora você tem a capacidade de realizar pesquisas otimizadas em campos de dados que não sejam o hash ou combinação de chaves hash e de intervalo.
Acabamos de migrar todas as nossas tabelas DynamoDB para RDS MySQL.
Embora usar o DynamoDB para tarefas específicas possa fazer sentido, construir um novo sistema com base no DynamoDB é realmente uma má ideia. Melhores planos etc., você sempre precisa daquela flexibilidade extra de seu banco de dados.
Aqui estão nossas razões para deixar o DynamoDB:
Agora usamos o DynamoDB como backup para alguns sistemas e tenho certeza que usaremos no futuro para tarefas específicas e bem definidas. Não é um banco de dados ruim, apenas não é o banco de dados para servir 100% do seu sistema central.
Quanto às vantagens, eu diria escalabilidade e durabilidade. Ele é escalonado de forma incrível e transparente e está (meio que) sempre para cima. Esses são recursos realmente ótimos, mas não compensam de forma alguma os aspectos negativos.
Ao usar o DynamoDB, você também deve saber que os itens / registros no DynamoDB são limitados a 400 KB (consulte os limites do DynamoDB ). Para muitos casos de uso, isso não funcionará. Portanto, o DynamoDB será bom para algumas coisas, mas não para todas. O mesmo vale para muitos dos outros bancos de dados NoSQL.