A look at two databases that have made claims to the Kubernetes native label: TiDB and DataStax Astra DB.  A revolução da computação em nuvem inspirou e se beneficiou de várias tendências inter-relacionadas. A disponibilidade de infraestrutura de nuvem pública de autoatendimento ajudou a impulsionar a adoção de arquiteturas de microsserviços e práticas de DevOps, incluindo automação e observabilidade.  O impulso para a conteinerização e a orquestração de contêineres levou à adoção generalizada do Kubernetes como um ambiente para gerenciar aplicativos nativos da nuvem.  Mas uma das áreas atrasadas nessa revolução são os dados e a infraestrutura de dados. Por muito tempo, os dados foram algo que viveu fora do Kubernetes, levando a muito esforço extra e complexidade para os desenvolvedores na implantação de aplicativos nativos da nuvem.  Um axioma frequentemente repetido nos primeiros anos do Kubernetes era que ele ainda não estava pronto para cargas de trabalho com estado. Felizmente, uma grande mudança está em andamento e atingiu um ponto de maturidade.  A transformação aconteceu lentamente inicialmente, começando com esforços para contentorizar os bancos de dados existentes. Isso funcionou relativamente bem em pequenos bancos de dados executados em um único nó de computação ou bancos de dados projetados em um mundo nativo da nuvem, como Apache Cassandra e DynamoDB, mas os desafios permaneceram.  Nos últimos dois a três anos, surgiu uma nova geração de bancos de dados. Esses bancos de dados “nativos do Kubernetes” foram projetados desde o início para serem executados nesse sistema de orquestração de código aberto.  Aqui, definiremos as qualidades que tornam um banco de dados nativo do Kubernetes e os benefícios de adotar um banco de dados nativo do Kubernetes. Para fazer isso, veremos dois bancos de dados que reivindicam o rótulo nativo do Kubernetes: TiDB e DataStax Astra DB.  MySQL nativo do Kubernetes com TiDB  Primeiro, vamos examinar um banco de dados com ênfase relacional:   (abreviação de Titanium Database). O TiDB é um sistema de código aberto desenvolvido pela PingCAP que fornece um   e um banco de dados colunar para suportar processamento transacional e analítico híbrido (conhecido como HTAP, para abreviar). TiDB banco de dados compatível com MySQL  Conforme mostrado na Figura 1 abaixo, o TiDB tem um design de microsserviço. A camada de consulta TiDB, bancos de dados TiKV MySQL, bancos de dados colunares TiFlash, nós Spark e gerenciamento de metadados são implantados como microsserviços escaláveis em seus clusters. Esse design separa o trabalho intensivo de computação do trabalho intensivo de armazenamento, pois as camadas de consulta e banco de dados são escalonáveis de forma independente.   Um compromisso crítico que os criadores do TiDB assumiram foi que o banco de dados só roda no Kubernetes.   Isso é suficiente para torná-lo nativo do Kubernetes?  Vamos cavar um pouco mais fundo.  Primeiro, o TiDB é implantado e gerenciado por um operador do Kubernetes usando   (CRDs). Os CRDs do TiDB incluem o TiDBCluster, que permite especificar o dimensionamento e a configuração de cada microsserviço e como os componentes da camada de banco de dados usam o armazenamento por meio dos volumes persistentes do Kubernetes. CRDs adicionais são usados para implantar ferramentas de monitoramento e gerenciar tarefas operacionais como backup e restauração. recursos personalizados    que faz interface com o agendador K8s padrão para tomar decisões de agendamento mais conscientes do aplicativo. Essa ênfase no uso dos recursos existentes do Kubernetes, quando disponíveis, é a marca de um banco de dados nativo do Kubernetes. O TiDB também possui uma extensão de agendador opcional  Kubernetes Native Cassandra com DataStax Astra DB  Agora, observe outro banco de dados nativo do Kubernetes e observe algumas semelhanças e diferenças.    que foi um dos primeiros a afirmar ser nativo da nuvem, mas como é implantar o Cassandra no Kubernetes?  é um banco de dados NoSQL altamente escalável O Cassandra    que foi fatorada em microsserviços, conforme mostrado na Figura 2.  é uma versão do Cassandra O DataStax Astra DB  Assim como o TiDB, o banco de dados inclui microsserviços relacionados ao processamento de consultas e armazenamento de dados, bem como serviços para controle de identidade e acesso, reparo de dados e backup/restauração.  Os serviços de dados são particularmente interessantes em seu uso de   , com Volumes Persistentes do Kubernetes usados apenas para armazenamento em cache e armazenamento de objetos usado para persistência de longo prazo. Separar a compactação em seu serviço permite que esse processamento intensivo de computação ocorra em segundo plano sem afetar o desempenho dos serviços de dados que atendem ao tráfego de leitura e gravação.  armazenamento  O Astra DB é oferecido como um serviço gerenciado disponível em várias regiões de nuvem. Cada região contém um plano de dados composto pelos serviços mencionados acima, gerenciados por um operador Kubernetes, bem como serviços de infraestrutura, incluindo a pilha   para observabilidade e   para gerenciamento de metadados. Kube-Promethus etcd  Os planos de dados são gerenciados por um plano de controle que pode ser executado em uma ou mais nuvens para gerenciar contas e bancos de dados de clientes e provisionar clusters Kubernetes em novas regiões.    na qual vários bancos de dados de usuários podem compartilhar os mesmos microsserviços e infraestrutura de suporte, diminuindo a economia de unidade para usuários de menor escala. Um aspecto inovador do Astra DB é sua arquitetura multilocatária,  À medida que os usuários aumentam seus aplicativos, eles podem migrar para recursos dedicados para obter o desempenho ideal em escala, tudo com base no “   ”. pagamento conforme o uso  Princípios do banco de dados nativo do Kubernetes  Com base em nossas observações de TiDB e Astra DB, podemos obter algumas ideias sobre o que torna um banco de dados Kubernetes nativo. Muitos deles correspondem a uma lista de princípios para dados nativos da nuvem, que descrevi em um   : artigo anterior    primeiro, um banco de dados dividido em microsserviços constituintes permite que cada serviço seja dimensionado de forma independente. Alguns tipos de processamento intensivo de computação podem até ser dimensionados para zero para uma verdadeira solução sem servidor, especialmente quando combinados com um design multitenant. Arquitetura de microsserviços combináveis:    os microsserviços compostos de um banco de dados nativo do Kubernetes devem fazer uso máximo das APIs do Kubernetes para gerenciar os recursos fundamentais dos aplicativos nativos da nuvem: recursos de computação, como   , entrada e serviços do Kubernetes para expor o acesso à rede aos dados e muito mais. Isso inclui aproveitar os recursos já presentes no Kubernetes, como etcd para gerenciamento de metadados, em vez de trazer componentes com funcionalidade duplicada. Trate a computação, a rede e o armazenamento como mercadorias: StatefulSets e implantações para gerenciar cargas de trabalho, o subsistema Persistent Volume para armazenamento    seguir padrões comuns para aplicativos Kubernetes trará vários benefícios operacionais, por exemplo,   . Por padrão, o próprio Kubernetes define um ótimo exemplo que os bancos de dados devem seguir para saber como ser seguro: usando Kubernetes Secrets para distribuir credenciais de segurança, expondo apenas as portas conforme necessário e assim por diante. Aproveite as melhores práticas do Kubernetes: expor verificações de vivacidade e prontidão em cada microsserviço para ajudar na disponibilidade e expor métricas por meio da API Prometheus PromQL para observabilidade    um banco de dados nativo do Kubernetes deve incorporar os princípios do Kubernetes de gerenciamento declarativo por meio de operadores e recursos personalizados, em vez de depender de UIs e CLIs de gerenciamento de banco de dados herdado. Quando necessário,   . O objetivo é uma separação clara da funcionalidade do plano de dados (gerenciamento de dados) da funcionalidade do plano de controle (gerenciamento do banco de dados). Gerenciamento declarativo por meio de operadores: os pontos de extensão do Kubernetes, como extensões do agendador, podem ser usados para adicionar comportamento específico do aplicativo  Bancos de dados e outras infraestruturas de dados que adotam fielmente esses princípios trarão benefícios, incluindo   , menor complexidade operacional resultando em menor tempo de lançamento no mercado e soluções em conformidade com os padrões que atendem às demandas atuais de alta disponibilidade e segurança. alto desempenho para custo ideal em todas as escalas  O futuro da infraestrutura de dados nativa do Kubernetes  Ainda há muito progresso a ser feito e não se limita apenas aos bancos de dados. Os princípios nativos do Kubernetes podem ser aplicados a outros tipos de infraestrutura de dados, incluindo streaming, análise e aprendizado de máquina.  As soluções nativas do Kubernetes continuarão avançando em implantações multicluster e multinuvem para escalar globalmente e adotarão princípios de multilocação e sem servidor para melhor otimização de custos.  O próprio Kubernetes tem espaço para melhorias ao adicionar mais flexibilidade aos StatefulSets e suporte para federação de vários clusters.  A chave para o progresso contínuo é a colaboração aberta. A   é um grupo altamente ativo de geeks de dados que reúne criadores de aplicativos com uso intensivo de dados e a infraestrutura que os suporta. comunidade Data on Kubernetes  Junte-se a nós para falar sobre ideias como desenvolver operadores reutilizáveis que podem gerenciar vários bancos de dados ou definir um conjunto comum de CRDs para conceitos como backup/restauração e carregamento de dados. Juntos, continuaremos expandindo o horizonte da computação em nuvem para o benefício de todos.   Saiba mais sobre os bancos de dados nativos do Kassandra e muito mais no encontro digital   em 14 de março de 2023. Cassandra Forward       Este artigo é baseado no Capítulo 7, “The Kubernetes Native Database,” do livro O'Reilly “ Managing Cloud Native Data on Kubernetes ” de Jeff Carpenter e Patrick McFadin.  [   Por Jeff Carpenter, DataStax   Jeff Carpenter trabalhou como engenheiro e arquiteto de software em vários setores e como defensor do desenvolvedor na DataStax, ajudando os engenheiros a obter sucesso com o Apache Cassandra. Ele está envolvido em vários projetos de código aberto nos ecossistemas Cassandra e Kubernetes, incluindo Stargate e K8ssandra. Ele é coautor dos livros da O'Reilly "Cassandra: The Definitive Guide" e "Managing Cloud Native Data on Kubernetes".

The writer was physically present in relevant location(s) to this story.

DataStax Astra DB is the vector database for getting GenAI apps into production, fast. Try it for free today!

DataStax

Este áudio é produzido no idioma original da história!

Banco de dados nativo do Kubernetes: TiDB vs. Data Stax Astra DB

About Author

COMENTARIOS

Rótulos

ESTE ARTIGO FOI APRESENTADO EM

Related Stories

Digital Nomads Ouçam: O que você precisa saber sobre o novo visto DTV da Tailândia

Quer ganhar um concurso de redação do HackerNoon? Aqui está o que os vencedores do concurso #crypto-api recomendam

Criando produtos criptográficos centrados no usuário: a importância do feedback do cliente

Vazamento do prompt do sistema Claude Sonnet 3.5: uma análise forense

Digital Nomads Ouçam: O que você precisa saber sobre o novo visto DTV da Tailândia

Quer ganhar um concurso de redação do HackerNoon? Aqui está o que os vencedores do concurso #crypto-api recomendam

Criando produtos criptográficos centrados no usuário: a importância do feedback do cliente

Vazamento do prompt do sistema Claude Sonnet 3.5: uma análise forense

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps