Ao abordar as principais considerações no início do processo de arquitetura de dados, você pode evitar sérios problemas no futuro. Afinal, arquitetar aplicativos modernos é uma tarefa difícil. Contudo, arquitetar um modelo de dados sólido para aplicativos modernos é uma das partes mais difíceis, embora mais importantes, de uma arquitetura de aplicativo moderna.
Então, a falha em criar uma arquitetura de dados razoável pode fazer com que seu aplicativo falhe de muitas maneiras ruins. Ou seja, de problemas relacionados ao desempenho a problemas de integridade de dados, a soberania de dados e problemas de segurança de dados, a problemas de escalabilidade. Portanto, uma arquitetura de dados pobre pode deixar seu aplicativo e, consequentemente, sua empresa em péssimas condições.
Dessa forma, construir uma arquitetura de dados adequada é fundamental para o sucesso de longo prazo de todas as arquiteturas modernas. Para auxiliar no processo de modernização do aplicativo, aqui estão cinco regras a serem seguidas ao arquitetar – ou rearquitetar – os dados do aplicativo.
Use o tipo certo de banco de dados
A primeira e mais importante decisão ao arquitetar seus dados é entender que tipo de banco de dados você precisa para armazenar e acessar seus dados. Você precisará:
Armazenar dados altamente estruturados ou dados simples de valor-chave?
Manter os dados permanentemente ou apenas por um curto período de tempo?
Acessar os dados de forma aleatória ou sequencial?
Usar um esquema fixo, um esquema flexível ou um arquivo simples simples?
Use um banco de dados relacional que ofereça suporte a consultas SQL?
Você precisa de respostas a essas perguntas para determinar o tipo de banco de dados que você precisa usar. Afinal, dependendo dessas respostas, você pode escolher um:
- Banco de dados SQL;
- Armazenamento de valor-chave simples;
- Cache residente na memória;
- Armazenamento de objeto simples;
- Armazenamento de dados altamente estruturado.
Entretanto, o tipo de banco de dados que você selecionar determinará o que seu banco de dados é capaz de fazer e quão bem ele executará no caso de uso de seu aplicativo. Ou seja, sua escolha de banco de dados afeta coisas tão essenciais para o seu aplicativo quanto determinar seus requisitos de escalabilidade e disponibilidade.
Armazene os dados no local certo
Uma pergunta aparentemente simples, mas importante, é: onde os dados devem ser armazenados?
Afinal, dependendo dos dados e do seu aplicativo, você precisa armazenar os dados, por exemplo, no front-end do seu aplicativo ou no back-end?
Você pode armazenar os dados localmente para o consumidor ou precisa compartilhar os dados com muitos outros consumidores?
A maioria dos dados é armazenada no back end. No entanto, alguns dados devem ser armazenados na borda ou em um cliente. O armazenamento de dados no front-end geralmente é necessário para otimizar o desempenho, a disponibilidade, a confiabilidade e a escalabilidade.
Pense em dimensionar desde o início
Os aplicativos modernos devem ser escaláveis para atender às necessidades crescentes dos clientes de uma empresa. Isso é verdadeiro para todas as empresas e todos os aplicativos.
A parte mais difícil da arquitetura de dados é construir um aplicativo que pode ser dimensionado para atender às suas necessidades de expansão. E isso é particularmente desafiador em relação ao dimensionamento do armazenamento de dados. Seja para aumentar a quantidade de dados que você precisa armazenar para sua crescente base de clientes ou para permitir que mais pessoas usem seu aplicativo simultaneamente sem degradar o desempenho, o dimensionamento de dados é difícil, a menos que você o planeje desde o início.
No entanto, a maioria das arquiteturas de dados e aplicativos parece considerar o dimensionamento de dados como um requisito secundário. Contudo, o ajuste de escala à força em uma arquitetura de dados posteriormente é uma tarefa extremamente difícil. E ela se torna ainda mais difícil à medida que seu conjunto de dados aumenta de tamanho. Portanto, o momento mais fácil para criar escalabilidade é no início, antes que seu aplicativo precise ser escalado. Afinal, esperar até mais tarde pode tornar o dimensionamento mais difícil e potencialmente impossível, sem uma grande refatoração de dados.
Distribua seus dados entre os serviços
Vários especialistas em nuvem sugerem que centralizar os dados do seu aplicativo é o modelo certo para gerenciar um grande conjunto de dados para um grande aplicativo. Afinal, centralizar seus dados, eles argumentam, torna mais fácil aplicar o aprendizado de máquina e outras análises avançadas para obter informações mais úteis de seus dados.
No entanto, essa estratégia é falha. Afinal, dados centralizados são difíceis de escalar. Então, a maneira mais eficaz de dimensionar seus dados é descentralizá-los e armazená-los no serviço individual que possui os dados. Ou seja, se o seu aplicativo é composto de dezenas ou centenas de serviços distribuídos, armazenará seus dados em dezenas ou centenas de locais distribuídos.
Este modelo permite um dimensionamento mais fácil e oferece suporte a um modelo de propriedade de serviço completo. A propriedade do serviço permite que as equipes de desenvolvimento trabalhem de forma mais independente. Além disso, incentiva SLAs mais robustos entre os serviços. Isso promove serviços de alta qualidade e torna as alterações de dados mais seguras e eficientes por meio da localização.
Mas e se sua empresa precisar realizar análises ou aprendizado de máquina em todos esses dados? No entanto, para tornar seus dados úteis para análises e aprendizado de máquina, envie uma cópia dos dados relevantes para um sistema de data warehouse de back-end. Nesse sistema de data warehouse, estruture os dados de maneira apropriada para seus propósitos analíticos e use esta versão para seus algoritmos analíticos e de aprendizado de máquina. Essa versão do data warehouse é separada e distinta dos dados de registro do aplicativo, que ainda estão armazenados nos serviços individuais.
Distribua seus dados geograficamente
Finalmente, determine quem usará os dados e onde eles estarão localizados geograficamente. A determinação dos dados e da localização do usuário está se tornando cada vez mais importante. Principalmente à medida que o comércio global apresenta mais oportunidades, enquanto as restrições de governança de dados regionais tornam o gerenciamento de dados globais mais difícil.
Então, antes de criar sua arquitetura de dados, você deve responder a estas perguntas-chave:
É importante que seus dados estejam disponíveis globalmente ou uma versão regional dos dados será mais importante para o seu negócio? Por exemplo, você deseja dados iguais ou diferentes disponíveis nos Estados Unidos e na Alemanha?
Muitos aplicativos consideram que uma combinação dos dois modelos é importante e essa resposta é aceitável. Contudo, isso só é verdade desde que você saiba quais dados devem ser globalizados e quais devem ser regionalizados.
Você tem restrições regionais sobre quais dados você pode armazenar e onde pode armazená-los?
Algumas localidades têm restrições que evitam que os dados do cliente saiam do país onde o cliente reside. Outros têm restrições sobre quais dados podem ser transferidos através das fronteiras nacionais e regionais. Algumas áreas têm restrições de privacidade mais rígidas do que outras áreas. Então, quais restrições de dados se aplicam a quais partes de seus dados?
Para dados compartilhados entre regiões, quão importante é que os mesmos dados sejam mostrados em cada região? Em outras palavras, os dados precisam ser exatamente sincronizados entre as regiões?
Modelos diferentes colocam cargas diferentes em seu conjunto de dados. Um modelo de consistência eventual tem características de desempenho muito diferentes de um modelo de integridade transacional compatível com ACID (Atomicidade, Consistência, Isolamento e Durabilidade).
Regras que você deve lembrar
Você fornecerá dados globais ou regionais? Onde usar esses dados? Quando e como sincronizar os dados entre as regiões?
- A arquitetura de dados é uma parte crítica da arquitetura de um aplicativo moderno, altamente escalonado, disponível e acessível globalmente.
- Portanto, erros na arquitetura de dados podem causar problemas de escala, disponibilidade e até mesmo conformidade legal.
- Além disso, alterar sua arquitetura de dados após o crescimento do aplicativo é difícil e doloroso. É muito mais fácil atender seus principais requisitos de dados antecipadamente.
Seguindo essas cinco regras no início do processo de arquitetura de dados, você pode evitar problemas sérios no futuro.
