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 é ajudar você a determinar quais tipos de armazenamento de dados podem atender aos requisitos da sua solução.

Considerações gerais

Considere as informações a seguir ao fazer sua escolha.

Requisitos funcionais

  • Formato de dados: quais tipos de dados você pretende armazenar? Tipos comuns incluem dados transacionais, objetos JSON, telemetria, índices de pesquisa ou arquivos simples.
  • Tamanho dos dados: qual será o tamanho das entidades que você precisa armazenar? Essas entidades precisam ser mantidas como um único documento ou podem ser divididas em vários documentos, tabelas e coleções?
  • Escala e estrutura: qual é a quantidade total de capacidade de armazenamento de que você precisa? Você pretende particionar os dados?
  • Relação de dados: seus dados precisarão dar suporte a relações um para muitos ou muitos para muitos? São relações em si são uma parte importante dos dados? Você precisará ingressar ou combinar os dados de dentro do mesmo conjunto de dados ou de conjuntos de dados externos?
  • Modelo de consistência: o quão é importante que as atualizações realizadas em um nó apareçam em outros nós antes de permitir alterações adicionais? É possível aceitar consistência eventual? Você precisa de garantias de ACID para transações?
  • Flexibilidade do esquema: quais tipos 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: qual tipo de mecanismo de simultaneidade você deseja usar ao atualizar e sincronizar os dados? O aplicativo executará muitas atualizações que poderiam entrar em conflito? Em caso afirmativo, é possível exigir o bloqueio de registros e o controle de simultaneidade pessimista. Como alternativa, você pode dar suporte a controles de simultaneidade otimista? Nesse caso, é simples o suficiente controlar a simultaneidade baseada em carimbo de data/hora, ou você precisa de funcionalidade adicional de controle de simultaneidade de várias versões?
  • Movimentação de dados: sua solução precisará executar tarefas ETL para mover os dados para outros armazenamentos ou data warehouses?
  • Ciclo de vida dos dados: os dados são gravados apenas uma vez e lidos muitas vezes? Eles podem ser movidos para o armazenamento frequente ou esporádico?
  • Outros recursos compatíveis: você precisa de algum outro recurso específico, como validação de esquema, agregação, indexação, pesquisa de texto completo, MapReduce ou outras funcionalidades de consulta?

Requisitos não funcionais

  • Desempenho e escalabilidade: quais são seus requisitos de desempenho de dados? Você tem requisitos específicos para as 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 dos dados depois que eles são ingeridos? Até que tamanho você precisará aumentar o armazenamento de dados? Sua carga de trabalho tem leituras ou gravações mais frequentes?
  • Confiabilidade: com qual contrato geral de nível de serviço você precisa trabalhar? Qual nível de tolerância a falhas você precisa fornecer para os consumidores dos dados? De quais tipos de funcionalidades de backup e restauração você precisa?
  • Replicação: os dados precisarão ser distribuído entre várias réplicas ou regiões? De quais tipos de funcionalidades de replicação de dados você precisa?
  • Limites: os limites de um armazenamento de dados específico dará suporte aos seus requisitos de escala, número de conexões e taxa de transferência?

Gerenciamento e o custo

  • Serviço gerenciado: quando possível, use um serviço de dados gerenciados, a menos que você precise de funcionalidades específicas encontradas somente em um armazenamento de dados hospedado por IaaS (infraestrutura como serviço).
  • Disponibilidade de região: para serviços gerenciais, 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: os dados precisarão ser migrados para datacenters locais, externos ou outros ambientes com hospedagem em nuvem?
  • Licenciamento: você prefere um tipo de licença proprietária ou OSS? Há outras restrições externas sobre o tipo de licença que você pode usar?
  • Custo geral: qual é o custo geral de usar o serviço na sua solução? Quantas instâncias você precisará executar para dar suporte a seus requisitos de tempo de atividade e taxa de transferência? Considere os custos das operações neste cálculo. Um motivo para preferir serviços gerenciados é a redução dos custos operacionais.
  • Economia: você pode particionar seus dados para armazená-los de forma mais econômica? Por exemplo, você pode mover grandes objetos para fora de um banco de dados relacional caro e para um repositório de objetos?

Segurança

  • Segurança: de qual 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: qual tipo de log de auditoria você precisa gerar?
  • Requisitos de rede: você precisa restringir ou gerenciar o acesso aos 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íficas? Eles precisam ser acessíveis de aplicativos ou serviços hospedados localmente ou de outros datacenters externos?

DevOps

  • Conjunto de habilidades: há determinadas linguagens de programação, sistemas operacionais ou outras tecnologias que sua equipe tem experiência específica em usar? Há outras com as quais seria difícil sua equipe trabalhar?
  • Clientes: há suporte de cliente adequado para suas linguagens de desenvolvimento?

Próximas etapas