Compartilhar via

Critérios para escolher um armazenamento de dados

Este artigo descreve os critérios de comparação para você usar ao avaliar um armazenamento de dados. A meta é ajudá-lo a determinar quais tipos de armazenamento de dados podem atender aos requisitos da solução.

Considerações gerais

Tenha em mente as considerações a seguir ao fazer sua seleção.

Requisitos funcionais

  • Formato de dados: Que tipo de dados você pretende armazenar? Os tipos comuns incluem dados transacionais, objetos JSON, telemetria, índices de pesquisa ou arquivos simples.
  • Tamanho dos dados: qual é o tamanho das entidades que você precisa armazenar? Essas entidades precisarão ser mantidas como um único documento ou podem ser divididas entre vários documentos, tabelas e coleções?
  • Escala e estrutura: Qual é a quantidade geral de capacidade de armazenamento que você precisa? Você prevê o particionamento de seus dados?
  • Relações de dados: seus dados precisarão dar suporte a relações um para muitos ou muitos para muitos? Os próprios relacionamentos são uma parte importante dos dados? Será necessário unir ou combinar dados de dentro do mesmo conjunto de dados ou de conjuntos de dados externos?
  • Modelo de consistência: qual é a importância das atualizações feitas em um nó aparecerem em outros nós antes que novas alterações possam ser feitas? É possível aceitar uma consistência eventual? Você precisa de garantias ACID para transações?
  • Flexibilidade de esquema: que tipo de esquema você aplicará aos seus dados? Você usará um esquema fixo, uma abordagem de esquema na gravação ou de esquema na leitura?
  • Simultaneidade: Que tipo de mecanismo de simultaneidade você deseja usar ao atualizar e sincronizar dados? O aplicativo executará muitas atualizações que podem entrar em conflito? Nesse caso, talvez você precise de bloqueio de registros e controle de concorrência pessimista. Como alternativa, você pode dar suporte a controles de simultaneidade otimista? Se for o caso, o controle de simultaneidade simples baseado em carimbo de data/hora é suficiente ou é necessário a funcionalidade adicional de controle de simultaneidade de múltiplas versões?
  • Movimentação de dados: sua solução precisará executar tarefas ETL para mover dados para outros repositórios ou data warehouses?
  • Ciclo de vida de dados: os dados são gravados uma vez, lidos muitas vezes? Pode ser movido para armazenamento fresco ou frio?
  • Outros recursos com suporte: você precisa de outros recursos específicos, como validação de esquema, agregação, indexação, pesquisa de texto completo, MapReduce ou outros recursos de consulta?

Requisitos não funcionais

  • Desempenho e escalabilidade: quais são seus requisitos de desempenho de dados? Você tem requisitos específicos para taxas de ingestão de dados e taxas de processamento de dados? Quais são os tempos de resposta aceitáveis para consulta e agregação de dados depois de ingeridos? Até que tamanho você precisará escalar verticalmente o armazenamento de dados? Sua carga de trabalho é mais focada em leitura ou em gravação?
  • Confiabilidade: qual acordo geral de nível de serviço precisa ser apoiado? Que nível de tolerância a falhas você precisa fornecer para os consumidores de dados? De que tipo de recursos de backup e restauração você precisa?
  • Replicação: seus dados precisarão ser distribuídos entre várias réplicas ou regiões? Que tipo de recursos de replicação de dados você precisa?
  • Limites: os limites de um armazenamento de dados específico darão suporte aos seus requisitos de escala, número de conexões e taxa de transferência?

Gerenciamento e custo

  • Serviço gerenciado: quando possível, use um serviço de dados gerenciado, a menos que você exija recursos específicos que só possam ser encontrados em um armazenamento de dados hospedado em IaaS (infraestrutura como serviço).
  • Disponibilidade da região: para serviços gerenciados, o serviço está disponível em todas as regiões do Azure? Sua solução precisa ser hospedada em determinadas regiões do Azure?
  • Portabilidade: seus dados precisarão ser migrados para datacenters locais, externos ou outros ambientes de hospedagem na nuvem?
  • Licenciamento: você tem uma preferência de um tipo de licença proprietário versus OSS? Há outras restrições externas sobre que tipo de licença você pode usar?
  • Custo geral: Qual é o custo geral de usar o serviço em sua solução? Quantas instâncias serão necessárias para dar suporte aos requisitos de tempo de atividade e capacidade de processamento? Considere os custos de operações neste cálculo. Um motivo para preferir serviços gerenciados é o custo operacional reduzido.
  • Custo-benefício: você pode particionar seus dados para armazená-los de forma mais econômica? Por exemplo, você pode mover objetos grandes de um banco de dados relacional caro para um repositório de objetos?

Segurança

  • Segurança: Que tipo de criptografia você precisa? Você precisa de criptografia em repouso? Qual mecanismo de autenticação você deseja usar para se conectar aos seus dados?
  • Auditoria: Que tipo de log de auditoria você precisa gerar?
  • Requisitos de rede: você precisa restringir ou gerenciar o acesso aos seus dados de outros recursos de rede? Os dados precisam ser acessíveis somente de dentro do ambiente do Azure? Os dados precisam ser acessíveis de endereços IP ou sub-redes específicos? Ele precisa ser acessível de aplicativos ou serviços hospedados localmente ou em outros datacenters externos?

DevOps

  • Conjunto de habilidades: há linguagens de programação, sistemas operacionais ou outra tecnologia que sua equipe é hábil em usar? Há outros que seriam difíceis para sua equipe trabalhar?
  • Clientes: Há um bom suporte ao cliente para seus idiomas de desenvolvimento?

Próximas etapas