Critérios para escolher um arquivo de dados

  • Artigo

Este artigo descreve critérios de comparação para utilizar quando avalia um arquivo de dados. O objetivo é ajudá-lo a determinar quais os tipos de armazenamento de dados que cumprem os requisitos da sua solução.

Considerações gerais

Tenha em atenção as seguintes considerações quando fizer a sua seleção.

Requisitos funcionais

  • Formato de dados: Que tipo de dados pretende armazenar? Os tipos comuns incluem dados transacionais, objetos JSON, telemetria, índices de pesquisa ou ficheiros simples.
  • Tamanho dos dados: qual é o tamanho das entidades que precisa de armazenar? Estas entidades terão de ser mantidas como um único documento ou podem ser divididas em vários documentos, tabelas e coleções?
  • Dimensionamento e estrutura: Qual é a quantidade global de capacidade de armazenamento de que precisa? Prevê a criação de partições de dados?
  • Relações de dados: os seus dados terão de suportar relações um-para-muitos ou muitos para muitos? As próprias relações são uma parte importante dos dados? Terá de associar ou combinar dados a partir do mesmo conjunto de dados ou de conjuntos de dados externos?
  • Modelo de consistência: Qual é a importância de as atualizações efetuadas num nó aparecerem noutros nós antes de serem efetuadas novas alterações? Pode aceitar a consistência eventual? Precisa de garantias ACID para as transações?
  • Flexibilidade de esquema: que tipo de esquemas irá aplicar aos seus dados? Vai utilizar um esquema fixo, uma abordagem de esquema de escrita ou uma abordagem de esquema de leitura?
  • Simultaneidade: que tipo de mecanismo de simultaneidade pretende utilizar quando atualiza e sincroniza dados? A aplicação irá efetuar muitas atualizações que podem potencialmente entrar em conflito? Se for o caso, poderá exigir o bloqueio de registos e o controlo de simultaneidade pessimista. Em alternativa, suporta controlos de simultaneidade otimistas? Em caso afirmativo, o controlo de simultaneidade baseado no carimbo de data/hora é suficiente ou precisa da funcionalidade adicionada do controlo de simultaneidade multiversion?
  • Movimento de dados: a sua solução terá de realizar tarefas ETL para mover dados para outros arquivos ou armazéns de dados?
  • Ciclo de vida dos dados: os dados são escritos uma vez, são muitos lidos? Podem ser movidos para um armazenamento esporádico ou amovível?
  • Outras funcionalidades suportadas: precisa de outras funcionalidades específicas, como a validação do esquema, a agregação, a indexação, a pesquisa em texto completo, o MapReduce ou outras capacidades de consulta?

Requisitos não funcionais

  • Desempenho e escalabilidade: Quais são os seus requisitos de desempenho de dados? Tem requisitos específicos para as taxas de ingestão de dados e as taxas de processamento de dados? Quais são os tempos de resposta aceitáveis para consulta e agregação de dados depois de ingeridos? Para que tamanho vai precisar de aumentar verticalmente o arquivo de dados? A sua carga de trabalho centra-se mais na leitura ou na escrita?
  • Fiabilidade: Que contrato de nível de serviço global precisa de suportar? Que nível de tolerância a falhas precisa de fornecer aos consumidores de dados? Qual o tipo de cópia de segurança e capacidades de restauro que precisa?
  • Replicação: os seus dados terão de ser distribuídos entre várias réplicas ou regiões? Que tipo de capacidades de replicação de dados precisa?
  • Limites: os limites de um arquivo de dados específico suportarão os seus requisitos de dimensionamento, número de ligações e débito?

Gestão e custo

  • Serviço gerido: sempre que possível, utilize um serviço de dados gerido, a menos que necessite de capacidades específicas que só podem ser encontradas num arquivo de dados alojado na infraestrutura como um serviço (IaaS).
  • Disponibilidade da região: para serviços geridos, o serviço está disponível em todas as regiões do Azure? A sua solução tem de ser alojada em regiões específicas do Azure?
  • Portabilidade: os seus dados terão de ser migrados para o local, datacenters externos ou outros ambientes de alojamento na cloud?
  • Licenciamento: tem uma preferência de um tipo de licença proprietário versus OSS? Existem outras restrições externas referentes ao tipo de licença que pode utilizar?
  • Custo global: Qual é o custo global da utilização do serviço na sua solução? Quantas instâncias terão de ser executadas para suportar os seus requisitos de tempo de atividade e débito? Considere os custos de operações neste cálculo. Um motivo para preferir os serviços geridos é o custo operacional reduzido.
  • Relação custo/eficácia: pode criar partições dos seus dados para armazená-lo de forma mais económica? Por exemplo, pode mover objetos grandes de uma base de dados relacional dispendiosa para um arquivo de objetos?

Segurança

  • Segurança: De que tipo de encriptação precisa? Precisa de encriptação para dados inativos? Qual o mecanismo de autenticação que pretende utilizar para se ligar aos dados?
  • Auditoria: Que tipo de registo de auditoria precisa de gerar?
  • Requisitos de rede: precisa de restringir ou gerir de outra forma o acesso aos seus dados a partir de outros recursos de rede? Os dados têm de estar acessíveis apenas a partir do ambiente do Azure? Os dados têm de estar acessíveis a partir de sub-redes ou endereços IP específicos? Precisam de estar acessíveis a partir de aplicações ou serviços alojados no local ou noutros datacenters externos?

DevOps

  • Conjunto de competências: existem linguagens de programação, sistemas operativos ou outras tecnologias que a sua equipa esteja a utilizar? Conhece outros com os quais a sua equipa teria dificuldades em trabalhar?
  • Clientes: Existe um bom suporte de cliente para as linguagens de desenvolvimento?

Passos seguintes