Sua organização deseja simplificar o DevOps de banco de dados?
Seu banco de dados está se tornando um gargalo para inovar rapidamente?
Deseja economizar milhões de $$ em custos de licenciamento de banco de dados?
Continue lendo!
Estado do DevOps de banco de dados
Estado do DevOps de banco de dados é uma pesquisa sobre as taxas de adoção de DevOps entre os profissionais do SQL Server. Mais de 1000 profissionais do SQL Server responderam à pesquisa. Os entrevistados vieram de todo o mundo e representam uma ampla gama de cargos, tamanhos de empresas e setores.
Há algumas conclusões positivas nos resultados da pesquisa. Vale a pena destacar aqui algumas conclusões importantes:
o maior desafio da integração das alterações no banco de dados em um processo de DevOps ainda seria a sincronização das alterações no aplicativo e no banco de dados
Outro ...
A maior desvantagem identificada no desenvolvimento tradicional de bancos de dados em silos é o maior risco de falhas nas implementações ou tempo de inatividade ao introduzir alterações. Isso é seguido de perto pelos ciclos lentos de desenvolvimento e lançamento e pela incapacidade de responder rapidamente às mudanças nos requisitos comerciais
E outro ...
Aumentar a velocidade da entrega de alterações no banco de dados e liberar os desenvolvedores para fazer um trabalho de maior valor agregado são os principais motivadores da automação da entrega de alterações no banco de dados
Os desafios destacados aqui não são mencionados apenas no contexto do SQL Server, mas são aplicáveis a qualquer banco de dados relacional. Você pode estar usando Oracle, Postgres, MySQL, MariaDB ou qualquer outro banco de dados relacional e estará enfrentando esses problemas. Por quê?
Por que o banco de dados relacional não é adequado para DevOps de banco de dados?
É comum que um aplicativo opere com dados de várias tabelas em um RDBMS. Por exemplo, a realização de um pedido pode usar as tabelas Customer (Cliente), Order (Pedido) e Product (Produto). Cada tabela tem várias colunas com tipos de dados padrão específicos de um banco de dados. As tabelas podem ter restrições de chave primária, de referência e estrangeira. Os desenvolvedores que criam aplicativos usando um banco de dados relacional normalmente usam um Mapeador Objeto-Relacional (ORM), como o Hibernate ou a Java Persistence API para desenvolvedores Java. Também existem ORMs semelhantes para outras linguagens. Os ORMs capturam a complexa estrutura subjacente do banco de dados e permitem que os programadores criem aplicativos naturalmente usando sua linguagem.
Os ORMs também usam um provedor de persistência e permitem que seu aplicativo seja independente do banco de dados subjacente. Esse provedor de persistência cria uma ligação entre a classe específica do idioma e a estrutura do banco de dados. Por exemplo, ele mapeia uma classe para uma tabela ou várias tabelas, vincula os tipos de dados da linguagem aos tipos definidos no banco de dados e captura o relacionamento entre as tabelas. Teoricamente, um programador pode usar um provedor de persistência diferente para usar um RDBMS diferente para o aplicativo. Mas isso está longe de ser uma experiência prática!
Qualquer alteração no banco de dados exige que as classes ORM sejam atualizadas, caso contrário, o aplicativo pode não funcionar. Por exemplo, adicionar uma nova tabela pode significar uma nova classe Java ou atualizar uma classe existente. A alteração de um tipo de dados em uma coluna exige que a definição da classe seja atualizada; caso contrário, o aplicativo nem sequer será compilado. Adicionar uma nova coluna significa adicionar um novo campo na classe. Qualquer alteração exige que as classes sejam atualizadas e o aplicativo precisa ser reempacotado.
Mudanças na estrutura do banco de dados são necessárias o tempo todo para atender às necessidades de evolução dos negócios. Mas se os DBAs fizerem uma alteração no banco de dados e as classes ORM não forem atualizadas, haverá uma desconexão. A implementação do aplicativo precisa ser coordenada com a atualização do esquema do banco de dados. Existem ferramentas como Flyway, Liquibase e outros que integram a implementação de aplicativos e bancos de dados. Mas os desenvolvedores geralmente não têm permissão para fazer alterações diretas no banco de dados de produção. Uma desconexão faria com que seu aplicativo não funcionasse e os negócios fossem prejudicados. As práticas de DevOps podem, sem dúvida, ajudar a resolver esses problemas, pois exigem uma estreita colaboração entre os desenvolvedores que estão criando aplicativos e os DBAs que estão atualizando os scripts do banco de dados.
Mas, como informa a pesquisa, mais de 50% dos entrevistados não adotam o DevOps atualmente.
Há desafios mesmo se você integrar as alterações no banco de dados em um processo de DevOps.
Sincronizar as alterações no aplicativo e no banco de dados em que as classes ORM precisam ser sincronizadas com a estrutura do banco de dados de back-end é o maior desafio. Os DBAs podem querer estruturar o banco de dados de uma determinada maneira, o que pode não ser ideal para o desenvolvimento de aplicativos. A aplicação da consistência no desenvolvimento de aplicativos e bancos de dados é o próximo grande desafio para garantir um DevOps de banco de dados perfeito.
Um desenvolvimento em silos tem sérios problemas em sua capacidade de inovar rapidamente e agregar valor à sua empresa.
Conforme mostrado nesta imagem, as implementações fracassadas ao introduzir mudanças, os ciclos lentos de desenvolvimento/liberação e a incapacidade de responder às necessidades comerciais são responsáveis por mais de 60% das desvantagens.
A velocidade de entrega das alterações no banco de dados é a maior preocupação do DevOps de banco de dados.
Então, o que você faz?
Como o NoSQL simplifica o DevOps do banco de dados?
O banco de dados de documentos NoSQL ajuda a simplificar o DevOps do banco de dados!
Como o NoSQL simplifica o DevOps do banco de dados?
- Flexibilidade do esquema - Os desenvolvedores precisam de um único banco de dados que possa armazenar dados estruturados, semiestruturados e não estruturados que mudam rapidamente. O banco de dados de documentos NoSQL oferece flexibilidade de esquema, permitindo que os desenvolvedores operem diretamente nos dados JSON e extraiam significado deles
- Sem incompatibilidade de impedância - Sem ORM para o aplicativo, não há incompatibilidade de impedância entre as classes de domínio e a estrutura do banco de dados. Somente o código do aplicativo precisa ser atualizado e não é necessária nenhuma coordenação com as alterações do esquema
- Escalabilidade - Uma das desvantagens mencionadas no relatório é a incapacidade de se adaptar às mudanças nos requisitos comerciais. Isso destaca a escalabilidade como um grande desafio de DevOps. Se o volume de dados, o número de consultas ou os tipos de índices necessários para dar suporte ao aplicativo mudarem, o banco de dados precisará mudar para acomodar essas mudanças. Não em semanas ou meses, mas hoje mesmo! Nenhum banco de dados SQL é executado em hardware de commodity e tem uma arquitetura scale-out, em vez de scale-up com RDBMS. A fragmentação pode ajudar na escalabilidade do RDBMS, mas essa é uma complexidade extra que agora precisa ser resolvida.
Saiba mais sobre por que as empresas migram para o NoSQL.
Que Banco de dados NoSQL é preferido pela GE, Marriott, Verizon, United, LinkedIn, DIRECTV e muitos outros?
Quais são alguns outros vantagens do Couchbase?
- Arquitetura distribuída homogênea - sem mestre/escravo
- Linguagem de consulta do tipo SQL para consultar documentos JSON
- Armazenamento automático usando vBuckets
- Arquitetura que prioriza a memória reduz a necessidade de uma camada adicional de cache
- Replicação entre centros de dados
- Vários SDKs
- Banco de dados no servidor ou no dispositivo móvelcom uma sincronização completa entre eles
- Diferentes Estruturas de orquestração de contêineres
O NoSQL não é uma panaceia de forma alguma. Se você estiver criando um sistema que precise de lógica de transação complexa ou armazenamento de dados em tempo real, o RDBMS pode ser mais adequado. No entanto, ele aborda suas preocupações de escalabilidade e agilidade e simplifica o DevOps do banco de dados.
Aqui está um ótimo vídeo sobre a migração de um banco de dados relacional para o NoSQL:
Aqui está outro vídeo interessante que mostra por que a Marriott fez a transição do sistema relacional para o NoSQL:
Muitos outros vídeos estão disponíveis em Couchbase Connect 2016.
E alguns blogs mais relevantes:
- Fazendo a mudança do sistema relacional para o NoSQL: Como começar (whitepaper)
- Mudança do banco de dados Oracle para o Couchbase
- Mudança do MySQL para o Couchbase
- Mudança do SQL Server para o Couchbase - Parte 1 (modelagem de dados), Parte 2 (migração de dados), Parte 3 (em breve)
- Mudança do MongoDB para o Couchbase
- Migre seu MongoDB com a API REST do Mongoose para o Couchbase com o Ottoman
- Migração do banco de dados relacional para o Couchbase
- Os 5 principais motivos que levam as empresas a substituir a Oracle pelo Couchbase
Fale conosco:
[...] Fonte: blog.couchbase.com/nosql-simplifies-database-devops/ [...]