Como escolher um armazenamento de dados para a próxima novidade brilhante

Observação: esta é uma postagem de blog técnica escrita pela engenheira-chefe Silvia Botros e apareceu pela primeira vez no blog Sysadvent em 25 de dezembro de 2017.

Bancos de dados podem ser difíceis. Sabe o que é mais difícil? Escolhendo um em primeiro lugar. Isso é desafiador se você está em uma nova empresa que ainda está encontrando seu produto/mercado fit ou em uma empresa que encontrou seu público e está simplesmente expandindo a oferta de produtos.

Ao construir uma coisa nova, uma das primeiras partes desse processo de design é quais armazenamentos de dados devemos usar e devem ser um único ou um plural? Devemos usar armazenamentos relacionais ou precisamos escolher um armazenamento de valor-chave? E as opções de tempo? Devemos também polvilhar em algum replay de log distribuído?

Assim. Vários. Opções…

Tentarei neste artigo descrever um processo que, esperançosamente, orientará essa decisão e, quando aplicável, explicar como o tamanho e a maturidade de sua organização podem afetar essa decisão.

Requisitos de linha de base

Os dados são a alma de qualquer produto. Mesmo se estivermos planejando no design usar mais tecnologia de ponta para armazenar o estado do aplicativo (porque MySQL ou Postgres não são mais "legais"), o que quer que escolhamos ainda é um armazenamento de dados e, portanto, exige que apliquemos rigor quando fazendo nossa seleção.

O importante é lembrar que nada é de graça. Todos os armazenamentos de dados vêm com comprometimentos e, se você não estiver sendo explícito sobre quais comprometimentos está assumindo como risco comercial, estará assumindo um risco desconhecido que se mostrará no pior momento possível.

É improvável que seu gerente de produto saiba ou mesmo precise se importar com o que você usa para seu armazenamento de dados, mas eles irão direcionar as necessidades que reduzem a lista de opções. Às vezes, até isso precisa de um empurrãozinho da equipe de desenvolvimento. Aqui está uma lista de coisas que você precisa pedir à equipe de produto para ajudar a direcionar suas opções:

• Taxa de crescimento: como os dados em si ou o acesso a eles devem mudar ao longo do tempo?
• Como a equipe de cobrança usará esses novos dados?
• Como a equipe de ETL usará esses dados?
• Quais requisitos de precisão/consistência são esperados para esse novo recurso?
• Qual intervalo de tempo para essa consistência é aceitável? A correção pós-processamento é aceitável?

Encontre o contexto que não é dito

A escolha do armazenamento de dados não é uma escolha reservada ao DBA ou à equipe de operações ou mesmo apenas ao engenheiro que escreve o código.

Organizações maduras com um mercado conhecido e endereçável precisam chegar a uma decisão das partes interessadas de toda a organização.

Se os requisitos da equipe de produto se encaixam em uma dúzia de armazenamentos de dados, como você determina os requisitos não mencionados explicitamente?

Você precisa trazer à tona os requisitos tácitos o mais rápido possível, porque é o caminho para as expectativas fracassadas no futuro.

Muitas coisas implícitas podem fazer você falhar nessa armadilha de 'muitas escolhas'. Isso inclui, mas não se limita a:

• Listas de recursos incompletas
• Requisitos de desempenho que não estão listados explicitamente
• Necessidades de consistência que são assumidas
• Taxa de crescimento não especificada
• Necessidades de consulta de faturamento ou ETL que ainda não estão disponíveis/conhecidas

Essas são todas as maneiras possíveis que podem deixar uma equipe de engenharia girando demais, examinando uma longa lista de opções de armazenamento de dados simplesmente porque os critérios explícitos com os quais estão trabalhando são muito permissivos ou incompletos.

Para produtos mais 'greenfield', como mencionei antes, seu objetivo é flexibilidade. Portanto, um armazenamento de dados de propósito mais geral, de qualidade conhecida, ajudará você a se aproximar de uma entrega, sabendo que, no futuro, talvez seja necessário migrar para um armazenamento de dados mais adequado à sua nova escala.

Faça sua lista

É hora de filtrar soluções potenciais por sua lista de requisitos. A lista resultante não precisa ser mais do que um punhado de armazenamentos de dados possíveis. Se a lista de bancos de dados em potencial que você pode usar for maior do que isso, seus requisitos são muito permissivos e você precisa voltar e descobrir mais informações.

Para empresas mais jovens e menos maduras, os requisitos de armazenamento de dados são a área mais desconhecida. Você possivelmente está construindo uma coisa nova que ninguém oferece ainda e, portanto, coisas como tamanho total do mercado endereçável e taxa de crescimento podem ser relativamente desconhecidas e difíceis de quantificar.

Nesse caso, o que você precisa é não se restringir muito cedo na vida útil de sua nova empresa usando um armazenamento de dados de pônei de um truque. Sim, em algum momento seus dados crescerão de maneiras novas e inesperadas, mas o que você precisa agora é de flexibilidade ao tentar encontrar seu nicho de mercado e aprender como será o crescimento de seus dados e quais recursos de escalabilidade específicos se tornarão cruciais para seu crescimento.

Se você é uma empresa maior com um número crescente de clientes pagantes, sua tarefa aqui é reduzir a lista de opções para, preferencialmente, armazenamentos de dados que você já possui e mantém. Quando você já tem muitos clientes pagantes, o risco de adicionar novos armazenamentos de dados com os quais sua equipe não está familiarizada se torna maior e, dependendo do contexto dos dados, simplesmente inaceitável.

Outra coisa a ter em mente é quais ferramentas já existem para armazenamentos de dados e o que a adoção de uma nova significaria no trabalho inicial que sua equipe precisa fazer. Gerenciamento de configuração, scripts de backup, scripts de recuperação de dados, novas verificações de monitoramento, novos painéis para construir e se familiarizar. A lista de custos operacionais de um novo armazenamento de dados, independente do risco, não é trivial.

Escolha seu veneno

Então aqui está um segredo mal guardado que os DBAs guardam. Os bancos de dados são terríveis em alguma coisa. Existe até um teorema inteiro sobre isso. Não apenas bancos de dados no sentido tradicional, mas qualquer tecnologia que armazene estado será horrível de uma maneira exclusiva de como você a usa.

Isso é apenas um fato da vida que é melhor você internalizar agora. Não, não estou dizendo que você deve evitar o uso de qualquer uma dessas tecnologias, estou dizendo que mantenha suas expectativas sãs e saiba que VOCÊ e somente você e sua equipe são os que cumprem as promessas que você faz.

O que isso significa em termos não abstratos? Depois de ter uma ideia sólida de quais armazenamentos de dados farão parte do que você está construindo, comece conhecendo os pontos fracos desses armazenamentos de dados. Esses pontos fracos incluem, mas não estão limitados a:

• Este armazenamento de dados funciona bem em consultas de varredura?
• Esse armazenamento de dados conta com um protocolo de fofocas para replicação de dados? em caso afirmativo, como ele lida com partições de rede? Quantos dados estão envolvidos nessa fofoca?
• Este armazenamento de dados tem um único ponto de falha?
• Quão maduros são os motoristas da comunidade para falar com ele ou você precisa fazer o seu próprio?
• Esta lista pode ser enorme

Pensar nos pontos fracos das soluções potenciais ainda em sua lista deve eliminar mais opções da lista. Isso agora é realidade atendendo às altas promessas da tecnologia.

Planilha e asse!

Quando sua lista de opções estiver reduzida a um punhado pequeno, é hora de colocá-las todas em uma planilha e começar a cavar um pouco mais fundo. Você precisa de uma coluna de prós e uma coluna de contras e, neste ponto, você precisará gastar algum tempo na documentação de cada banco de dados para descobrir detalhes minuciosos sobre como realizar determinadas tarefas.

Se esses são os dados que você espera ter uma grande taxa de crescimento, você precisa saber qual dessas opções é mais fácil de escalar. Se esse é um recurso que faz muita pesquisa difusa, você precisa saber qual armazenamento de dados pode lidar melhor com varreduras ou pesquisas em um grande número de linhas e com qual design. O objetivo neste estágio é reduzir a lista para, idealmente, 2 ou 3 opções apenas por meio da documentação, porque se esse novo recurso for crítico o suficiente para o sucesso da empresa, você terá que avaliar todos os três.

Por que benchmark você diz? Porque duas empresas não usam o mesmo armazenamento de dados da mesma maneira. Porque às vezes a documentação implica advertências que só são expostas nas histórias de guerra de outras pessoas.

Porque ninguém possui a estabilidade, a confiabilidade e a previsibilidade desse armazenamento de dados além de você.

Projete seu benchmark com antecedência. Idealmente, você configura uma instância completa dos armazenamentos de dados em sua lista com especificações de nível de produção e produz dados de teste que não são muito pequenos para tornar o teste de carga inútil. Certifique-se de não apenas avaliar a 'carga normal', mas também testar alguns cenários de falha.

A esperança é que, por meio do benchmark, você possa descobrir quaisquer ressalvas que sejam graves o suficiente para fazer com que você revisite a lista de opções agora, em vez de mais tarde, quando todo o código estiver escrito e você estiver na fase de simulação de incêndio com muito tempo e esforço comprometido com a escolha que você fez.

Documente sua escolha

Não importa o que você faça, você deve documentar e divulgar internamente o método pelo qual chegou à sua escolha e as alternativas que foram investigadas no caminho para essa decisão. Presumindo que haja um plano de arquitetura abrangente de como esse novo recurso será criado e todos os seus componentes, você cria uma seção dedicada ao armazenamento de dados que alimenta esse novo recurso com links para todos os benchmarks feitos para chegar à decisão que a equipe tomou .

Isso não é apenas para o benefício de futuras contratações, mas também para o benefício de sua equipe agora. Um documento que as pessoas podem ler de forma assíncrona e desenvolver opiniões fornece uma maneira de manter o processo de decisão transparente, aumentar o senso de melhor intenção entre os membros da equipe e pode trazer críticas de perspectivas que você não previu.

Aprendizado

Essas etapas não apenas levarão a decisões informadas por dados ao aumentar a oferta de negócios, mas também levarão a uma infraestrutura robusta e uma abordagem mais disciplinada para quando e onde você usa um campo cada vez maior de tecnologias para agregar valor ao seu pagamento. clientes.