One place for hosting & domains

      Bancos

      Como Gerenciar Bancos de Dados e Chaves no Redis


      Introdução

      O Redis é um datastore ou armazenamento de dados open-source de chave-valor na memória. Um datastore de chave-valor é um tipo de banco de dados NoSQL no qual chaves servem como identificadores exclusivos para seus valores associados. Qualquer instância Redis inclui um número de bancos de dados, cada um dos quais podendo conter muitas chaves diferentes de uma variedade de tipos de dados. Neste tutorial, veremos como selecionar um banco de dados, mover chaves entre bancos de dados e gerenciar e excluir chaves.

      Como Utilizar Este Guia

      Este guia está no formato de referência rápida com trechos de linha de comando independentes. Recomendamos que você pule para qualquer seção que seja relevante para a tarefa que você está tentando concluir.

      Os comandos mostrados neste guia foram testados em um servidor Ubuntu 18.04 executando a versão 4.0.9 do Redis. Para configurar um ambiente semelhante, você pode seguir o Passo 1 do nosso guia Como Instalar e Proteger o Redis no Ubuntu 18.04. Vamos demonstrar como esses comandos se comportam executando-os com redis-cli, a interface de linha de comando do Redis. Observe que se você estiver usando uma interface Redis diferente — Redli, por exemplo — a saída exata de certos comandos pode ser diferente.

      Como alternativa, você pode provisionar uma instância de banco de dados Redis gerenciada para testar esses comandos, mas observe que, dependendo do nível de controle permitido pelo seu provedor de banco de dados, alguns comandos neste guia podem não funcionar como descrito. Para provisionar um banco de dados gerenciado na DigitalOcean, siga nossa documentação de produto para Managed Databases. Então, você deve instalar ou o Redli ou configurar um túnel TLS para conectar-se ao banco de dados gerenciado por TLS.

      Gerenciando Bancos de Dados

      Nativamente, uma instância do Redis suporta 16 bancos de dados lógicos. Esses bancos de dados são efetivamente isolados um do outro e, quando você executa um comando em um banco de dados, ele não afeta nenhum dado armazenado em outros bancos de dados na sua instância do Redis.

      Os bancos de dados Redis são numerados de 0 a 15 e, por padrão, você se conecta ao banco de dados 0 quando se conecta à sua instância Redis. No entanto, você pode alterar o banco de dados que está usando com o comando select após conectar-se:

      Se você selecionou um banco de dados diferente de 0, ele será refletido no prompt do redis-cli:

      Para trocar todos os dados mantidos em um banco de dados pelos dados mantidos em outro, use o comando swapdb. O exemplo a seguir trocará os dados mantidos no banco de dados 6 pelos dados no banco de dados 8, e quaisquer clientes conectados a quaisquer dos bancos de dados poderão ver as alterações imediatamente:

      O swapdb retornará OK se a troca for bem-sucedida.

      Se você deseja mover uma chave para uma instância diferente do Redis, você pode executar migrate. Este comando garante que a chave exista na instância de destino antes de excluí-la da instância de origem. Quando você executa migrate, o comando deve incluir os seguintes elementos nesta ordem:

      • O nome do host ou o endereço IP do banco de dados de destino
      • O número da porta do banco de dados de destino
      • O nome da chave que você deseja migrar
      • O número do banco de dados em que você deseja armazenar a chave na instância de destino
      • Um tempo limite, em milissegundos, que define a quantidade máxima de tempo de inatividade de comunicação entre as duas máquinas. Observe que este não é um limite de tempo para a operação, apenas que a operação deve sempre fazer algum nível de progresso dentro do período definido

      Para ilustrar:

      • migrate 203.0.113.0 6379 key_1 7 8000

      Além disso, o migrate permite as seguintes opções que você pode adicionar após o argumento de tempo limite:

      • COPY: Especifica que a chave não deve ser excluída da instância de origem
      • REPLACE: Especifica que, se a chave já existir no destino, a operação migrate deve excluí-la e substituí-la
      • KEYS: Em vez de fornecer uma chave específica para migrar, você pode inserir uma string vazia ("") e, em seguida, usar a sintaxe do comando keys para migrar qualquer chave que corresponda a um padrão. Para mais informações sobre como funciona o keys, consulte nosso tutorial How To Troubleshoot Issues in Redis.

      Gerenciando Chaves

      Existem vários comandos Redis que são úteis para gerenciar chaves, independentemente do tipo de dados que elas mantêm. Vamos abordar alguns deles nesta seção.

      O rename renomeará a chave especificada. Se for bem sucedido, ele retornará OK:

      Você pode utilizar o randomkey para retornar uma chave aleatória do banco de dados selecionado no momento:

      Output

      "any_key"

      Use type para determinar que tipo de dados a chave fornecida contém. A saída deste comando pode ser string, list, hash, set, zset, ou stream:

      Output

      "string"

      Se a chave especificada não existir, o type retornará none.

      Você pode mover uma chave individual para outro banco de dados na sua instância do Redis com o comando move. O move pega o nome de uma chave e o banco de dados para o qual você deseja mover a chave como argumentos. Por exemplo, para mover a chave key_1 para o banco de dados 8, você executaria o seguinte:

      move retornará OK se a movimentação da chave foi bem-sucedida.

      Excluindo Chaves

      Para excluir uma ou mais chaves de qualquer tipo de dados, use o comando del seguido por uma ou mais chaves que você deseja excluir:

      Se este comando excluir as chaves com êxito, ele retornará (integer) 1. Caso contrário, ele retornará (integer) 0.

      O comando unlink executa uma função semelhante a del, com a diferença de que del bloqueia o cliente enquanto o servidor recupera a memória ocupada pela chave. Se a chave que está sendo excluída estiver associada a um objeto pequeno, a quantidade de tempo que leva para o del recuperar a memória é muito pequena e o tempo de bloqueio pode nem ser perceptível.

      No entanto, isso pode ser inconveniente se, por exemplo, a chave que você está excluindo estiver associada a muitos objetos, como um hash com milhares ou milhões de campos. A exclusão de uma chave desse tipo pode demorar muito e você não poderá executar outras operações até que seja totalmente removida da memória do servidor.

      O unlink, no entanto, primeiro determina o custo de desalocar a memória ocupada pela chave. Se for pequeno, o unlink funciona da mesma maneira que o del para a chave, enquanto também bloqueia o cliente. No entanto, se houver um alto custo para desalocar a memória de uma chave, o unlink excluirá a chave de forma assíncrona, criando outra thread e recuperando progressivamente a memória em segundo plano sem bloquear o cliente:

      Como ele é executado em segundo plano, geralmente é recomendável que você use o unlink para remover chaves do seu servidor para reduzir erros em seus clientes, embora o del também seja suficiente em muitos casos.

      Atenção: Os dois comandos a seguir são considerados perigosos. Os comandos flushdb e flushall excluirão irreversivelmente todas as chaves em um único banco de dados e todas as chaves em todos os bancos de dados no servidor Redis, respectivamente. Recomendamos que você execute esses comandos apenas se tiver certeza absoluta de que deseja excluir todas as chaves do seu banco de dados ou servidor.

      Pode ser do seu interesse renomear esses comandos (veja o Passo 5) para algo com menor probabilidade de ser executado acidentalmente.

      Para excluir todas as chaves no banco de dados selecionado, use o comando flushdb:

      Para excluir todas as chaves em todos os bancos de dados em um servidor Redis (incluindo o banco de dados atualmente selecionado), execute flushall:

      Ambos flushdb e flushall aceitam a opção async, que lhe permite excluir todas as chaves em um único banco de dados ou todos os bancos de dados no cluster de forma assíncrona. Isso permite que eles funcionem de maneira semelhante ao comando unlink, e eles criarão uma nova thread para liberar incrementalmente a memória em segundo plano.

      Fazendo Backup do seu Banco de Dados

      Para criar um backup do banco de dados selecionado atualmente, você pode usar o comando save:

      Isso exportará um instantâneo ou snapshot do dataset atual como um arquivo .rdb, que é um arquivo de dump de banco de dados que mantém os dados em um formato interno de serialização compactado.

      O save é executado de forma síncrona e bloqueará quaisquer outros clientes conectados ao banco de dados. Portanto, a documentação do comando save recomenda que esse comando quase nunca seja executado em um ambiente de produção. Em vez disso, sugere o uso do comando bgsave. Isso indica ao Redis para fazer um fork do banco de dados: o pai continuará a servir os clientes enquanto o processo filho salva o banco de dados antes de sair:

      Observe que se os clientes adicionarem ou modificarem dados enquanto a operação bgsave estiver ocorrendo, essas alterações não serão capturadas no snapshot.

      Você também pode editar o arquivo de configuração do Redis para que o Redis salve um snapshot automaticamente (conhecido como modo snapshotting ou RDB) após um certo período de tempo, se um número mínimo de alterações tiver sido feito no banco de dados. Isso é conhecido como salvar ponto. As seguintes configurações de ponto de salvamento são ativadas por padrão no arquivo redis.conf:

      /etc/redis/redis.conf

      . . .
      save 900 1
      save 300 10
      save 60 10000
      . . .
      dbfilename "nextfile.rdb"
      . . .
      

      Com essas configurações, o Redis exportará um snapshot do banco de dados para o arquivo definido pelo parâmetro dbfilename a cada 900 segundos, se pelo menos 1 chave for alterada, a cada 300 segundos, se pelo menos 10 chaves forem alteradas e a cada 60 segundos, se pelo menos 10000 chaves forem alteradas.

      Você pode usar o comando shutdown para fazer backup de seus dados do Redis e depois fechar sua conexão. Este comando bloqueará todos os clientes conectados ao banco de dados e executará uma operação save se pelo menos um ponto de salvamento estiver configurado, o que significa que exportará o banco de dados em seu estado atual para um arquivo .rdb, impedindo que os clientes façam quaisquer alterações.

      Além disso, o comando shutdown liberará as alterações no arquivo append-only do Redis antes de sair se o modo append-only estiver ativado.O arquivo append-only (AOF) envolve a criação de um log de todas as operações de gravação no servidor em um arquivo que termina em .aof após cada snapshot. Os modos AOF e RDB podem ser ativados no mesmo servidor e o uso dos dois métodos de persistência é uma maneira eficaz de fazer backup de seus dados.

      Resumindo, o comando shutdown é essencialmente um comando save bloqueador que também libera todas as alterações recentes no arquivo append-only e fecha a conexão com a instância Redis:

      Atenção: O comando shutdown é considerado perigoso. Ao bloquear os clientes do servidor Redis, você pode tornar seus dados indisponíveis para usuários e aplicações que dependem deles. Recomendamos que você execute este comando apenas se estiver testando o comportamento do Redis ou tiver certeza absoluta de que deseja bloquear todos os clientes do seu servidor Redis.

      Pode ser do seu interesse renomear esses comandos (veja o Passo 5) para algo com menor probabilidade de ser executado acidentalmente.

      Se você não configurou nenhum ponto de salvamento, mas ainda deseja que o Redis execute uma operação save, acrescente a opção save ao comando shutdown:

      Se você configurou pelo menos um ponto de salvamento, mas deseja desligar o servidor Redis sem executar um salvamento, é possível adicionar o argumento nosave ao comando:

      Observe que o arquivo append-only pode crescer muito ao longo do tempo, mas você pode configurar o Redis para reescrever o arquivo com base em certas variáveis, editando o arquivo redis.conf. Você também pode instruir o Redis a reescrever o arquivo append-only executando o comando bgrewriteaof:

      O bgrewriteaof criará o menor conjunto de comandos necessários para trazer o banco de dados de volta ao seu estado atual. Como o nome deste comando implica, ele será executado em segundo plano. No entanto, se outro comando de persistência já estiver sendo executado em um processo em segundo plano, esse comando deverá terminar antes que o Redis execute bgrewriteaof.

      Conclusão

      Este guia detalha vários comandos usados para gerenciar bancos de dados e chaves. Se houver outros comandos, argumentos ou procedimentos relacionados que você queira ver neste guia, peça ou faça sugestões nos comentários abaixo.

      Para obter mais informações sobre comandos Redis, consulte nossa série de tutoriais Como Gerenciar um Banco de Dados Redis.



      Source link

      Entendendo Bancos de Dados Gerenciados


      Introdução

      Armazenamento de dados seguro e confiável é uma necessidade para quase todas as aplicações modernas. No entanto, a infraestrutura necessária para um banco de dados local autogerenciado pode ser proibitivamente cara para muitas equipes. Da mesma forma, funcionários que possuem as habilidades e a experiência necessárias para manter um banco de dados de produção com eficiência podem ser difíceis de contratar.

      A disseminação dos serviços de computação em nuvem reduziu as barreiras de entrada associadas ao provisionamento de um banco de dados, mas muitos desenvolvedores ainda não têm tempo nem conhecimento necessários para gerenciar e ajustar um banco de dados para atender às suas necessidades. Por esse motivo, muitas empresas estão recorrendo aos serviços de banco de dados gerenciados para ajudá-las a criar e dimensionar seus bancos de dados de acordo com seu crescimento.

      Neste artigo conceitual, veremos o que são bancos de dados gerenciados e como eles podem ser benéficos para muitas empresas. Também abordaremos algumas considerações práticas que devem ser feitas antes de criar sua próxima aplicação em cima de uma solução de banco de dados gerenciada.

      Bancos de Dados Gerenciados em Poucas Palavras

      Um banco de dados gerenciado é um serviço de computação em nuvem no qual o usuário final paga um provedor de serviços em nuvem para acessar um banco de dados. Ao contrário de um banco de dados típico, os usuários não precisam configurar ou manter um banco de dados gerenciado por conta própria; em vez disso, é responsabilidade do provedor supervisionar a infraestrutura do banco de dados. Isso permite que o usuário se concentre em criar sua aplicação, em vez de gastar tempo configurando seu banco de dados e mantê-lo atualizado.

      O processo de provisionamento de um banco de dados gerenciado varia de acordo com o provedor, mas, em geral, é semelhante ao de qualquer outro serviço baseado em nuvem. Depois de registrar uma conta e fazer login no painel, o usuário revisa as opções de banco de dados disponíveis – como o engine do banco de dados e o tamanho do cluster – e escolhe a configuração certa para elas. Depois de provisionar o banco de dados gerenciado, você pode se conectar a ele por meio de uma GUI ou de um cliente e, em seguida, pode começar a carregar dados e a integrar o banco de dados à sua aplicação.

      As soluções de dados gerenciadas simplificam o processo de provisionamento e manutenção de um banco de dados. Em vez de executar comandos a partir de um terminal para instalar e configurar, você pode implantar um banco de dados pronto para produção com apenas alguns cliques no navegador. Ao simplificar e automatizar o gerenciamento de banco de dados, os provedores de nuvem facilitam para todos, até mesmo os usuários de bancos de dados iniciantes, a criação de aplicações e websites orientados a dados. Esse foi o resultado de uma tendência de décadas para simplificar, automatizar e abstrair várias tarefas de gerenciamento de banco de dados, que por si só era uma resposta à aflição sentida pelos administradores de banco de dados.

      Pontos Críticos dos Bancos de Dados Locais e Auto-Gerenciados

      Antes do surgimento do modelo de computação em nuvem, qualquer empresa que necessitasse de um data center precisava fornecer todo o tempo, espaço e recursos necessários para configurar um. Uma vez que seu banco de dados estava funcionando, elas também precisavam manter o hardware, manter seu software atualizado, contratar uma equipe para gerenciar o banco de dados e treinar seus funcionários sobre como usá-lo.

      Como os serviços de computação em nuvem cresceram em popularidade nos anos 2000, tornou-se mais fácil e mais acessível provisionar a infraestrutura do servidor, já que o hardware e o espaço necessário para ele não precisavam mais ser de propriedade da empresa ou gerenciados por aqueles que o usavam. Da mesma forma, configurar um banco de dados inteiramente dentro da nuvem tornou-se muito menos difícil; um empresa ou desenvolvedor precisaria apenas requisitar um servidor, instalar e configurar o sistema de gerenciamento de banco de dados escolhido e começar a armazenar dados.

      Embora a computação em nuvem tenha facilitado o processo de configuração de um banco de dados tradicional, ela não resolveu todos os seus problemas. Por exemplo, na nuvem, ainda pode ser difícil identificar o tamanho ideal da área de cobertura da infraestrutura de um banco de dados antes de começar a coletar dados. Isso é importante porque os consumidores de nuvem são cobrados com base nos recursos que consomem e correm o risco de pagar mais do que o necessário, se o servidor que eles provisionam for maior que o necessário. Além disso, como ocorre com os bancos de dados locais tradicionais, o gerenciamento do banco de dados na nuvem pode ser um esforço dispendioso. Dependendo de suas necessidades, você ainda pode precisar contratar um administrador de banco de dados experiente ou gastar uma quantidade significativa de tempo e dinheiro treinando sua equipe atual para gerenciar seu banco de dados de forma eficaz.

      Muitos desses problemas são agravados para empresas menores e desenvolvedores independentes. Enquanto uma grande empresa geralmente pode contratar funcionários com um conhecimento profundo de bancos de dados, equipes menores geralmente têm menos recursos disponíveis, deixando-as apenas com o conhecimento institucional existente. Isso torna tarefas como replicação, migrações e backups ainda mais difíceis e demoradas, pois podem exigir muito aprendizado no trabalho, além de tentativa e erro.

      Os bancos de dados gerenciados ajudam a resolver esses pontos problemáticos com uma série de benefícios para empresas e desenvolvedores. Vamos examinar alguns desses benefícios e ver como eles podem impactar as equipes de desenvolvimento.

      Benefícios dos Bancos de Dados Gerenciados

      Os serviços de banco de dados gerenciados podem ajudar a reduzir muitas das dores de cabeça associadas ao provisionamento e ao gerenciamento de um banco de dados. Os desenvolvedores criam aplicações sobre os serviços de banco de dados gerenciados para acelerar drasticamente o processo de provisionamento de um servidor. Com uma solução autogerenciada, você deve obter um servidor (local ou na nuvem), conectar-se a ele a partir de um cliente ou terminal, configurá-lo e protegê-lo e, em seguida, instalar e configurar o software de gerenciamento de banco de dados antes de poder iniciar o armazenamento de dados. Com um banco de dados gerenciado, você só precisa decidir sobre o tamanho inicial do servidor, configurar opções adicionais específicas do provedor e terá um novo banco de dados pronto para ser integrado à sua aplicação ou website. Isso geralmente pode ser feito em apenas alguns minutos através da interface de usuário do provedor.

      Outro apelo de bancos de dados gerenciados é a automação. Bancos de dados autogerenciados podem consumir uma grande quantidade de recursos de uma organização porque seus funcionários precisam executar todas as tarefas administrativas — do dimensionamento até a execução de atualizações, executar migrações e criar backups — manualmente. Com um banco de dados gerenciado, no entanto, essas e outras tarefas são executadas automaticamente ou sob demanda, o que reduz drasticamente o risco de erro humano.

      Isso está relacionado ao fato de que os serviços de banco de dados gerenciados ajudam a simplificar o processo de escalonamento do banco de dados. Escalar um banco de dados autogerenciado pode consumir muito tempo e recursos. Quer você escolha sharding, replicação, balanceamento de carga ou qualquer outra coisa como estratégia de dimensionamento, se você gerenciar a infraestrutura por conta própria, será responsável por garantir que nenhum dado seja perdido no processo e que a aplicação continue funcionando corretamente. No entanto, se você integrar sua aplicação a um serviço de banco de dados gerenciado, poderá escalonar o cluster de banco de dados sob demanda. Em vez de precisar trabalhar de antemão com o tamanho ideal do servidor ou o uso da CPU, você pode provisionar rapidamente mais recursos dinamicamente. Isso ajuda a evitar o uso de recursos desnecessários, o que significa que você também não pagará pelo que não precisa.

      Soluções gerenciadas tendem a ter alta disponibilidade integrada. No contexto da computação em nuvem, um serviço é considerado de alta disponibilidade se for estável e passível de ser executado sem falhas por longos períodos de tempo. A maioria dos produtos de provedores de nuvem respeitáveis vem com um contrato de nível de serviço (SLA), um compromisso entre o provedor e seus clientes que garante a disponibilidade e a confiabilidade de seus serviços. Um SLA típico especificará quanto tempo de inatividade o cliente deve esperar e muitos também definirão a compensação para os clientes se esses níveis de serviço não forem atingidos. Isso fornece garantia para o cliente de que o banco de dados não irá falhar e, se isso acontecer, poderá pelo menos esperar algum tipo de reparação do provedor.

      Em geral, os bancos de dados gerenciados simplificam as tarefas associadas ao provisionamento e à manutenção de um banco de dados. Dependendo do provedor, você ou sua equipe ainda precisarão de algum nível de experiência ao trabalhar com bancos de dados para provisionar um banco e interagir com ele à medida que você cria e escala sua aplicação. Por fim, a experiência específica em banco de dados necessária para administrar um banco de dados gerenciado será muito menor do que com a solução autogerenciada.

      É claro que os bancos de dados gerenciados não são capazes de resolver todos os problemas e podem não ser a opção ideal para alguns. Em seguida, examinaremos algumas das possíveis desvantagens que devemos considerar antes de provisionar um banco de dados gerenciado.

      Considerações Práticas

      Um serviço de banco de dados gerenciado pode aliviar o estresse de implantar e manter um banco de dados, mas ainda há algumas coisas a serem consideradas antes de se comprometer com um. Lembre-se de que o principal atrativo dos bancos de dados gerenciados é que eles abstraem a maioria dos aspectos mais tediosos da administração do banco de dados. Para este fim, um provedor de banco de dados gerenciado tem como objetivo fornecer um banco de dados rudimentar que satisfaça os casos de uso mais comuns. Assim, essas ofertas de banco de dados não apresentam muitas opções de personalização ou recursos exclusivos incluídos em softwares de banco de dados mais especializados. Por causa disso, você não terá tanta liberdade para adaptar seu banco de dados e estará limitado ao que o provedor de nuvem tiver a oferecer.

      Um banco de dados gerenciado é quase sempre mais caro do que um autogerenciado. Isso faz sentido, já que você está pagando ao provedor de nuvem para dar suporte a você no gerenciamento do banco de dados, mas pode ser um motivo de preocupação para equipes com recursos limitados. Além disso, o preço para bancos de dados gerenciados é geralmente baseado em quanto armazenamento e RAM o banco de dados usa, quantas leituras ele manipula e quantos backups do banco de dados o usuário cria. Da mesma forma, qualquer aplicativo que utilize um serviço de banco de dados gerenciado que manipule grandes quantidades de dados ou tráfego, será mais caro do que se fosse usado um banco de dados autogerenciado na nuvem.

      Deve-se também refletir sobre o impacto que a mudança para um banco de dados gerenciado terá em seus fluxos de trabalho internos e se eles poderão ou não se ajustar a essas mudanças. Um provedor é diferente de outro e, dependendo do seu SLA, pode assumir a responsabilidade por apenas algumas tarefas de administração, o que seria problemático para os desenvolvedores que procuram uma solução de serviço completo. Por outro lado, alguns provedores podem ter um SLA proibitivo ou tornar o cliente totalmente dependente do provedor em questão, uma situação conhecida como vendor lock-in.

      Por último, e talvez mais importante, deve-se considerar cuidadosamente se algum serviço de banco de dados gerenciado que você está considerando usar atenderá ou não às suas necessidades de segurança. Todos os bancos de dados, incluindo bancos de dados locais, são propensos a determinadas ameaças de segurança, como ataques de injeção de SQL ou vazamentos de dados. No entanto, a dinâmica de segurança é muito diferente para bancos de dados hospedados na nuvem. Usuários de banco de dados gerenciados não podem controlar a localização física de seus dados ou quem tem acesso a eles, nem podem garantir a conformidade com padrões de segurança específicos. Isso pode ser especialmente problemático se o seu cliente tiver necessidades de segurança elevadas.

      Para ilustrar, imagine que você é contratado por um banco para criar uma aplicação em que seus clientes possam acessar registros financeiros e efetuar pagamentos. O banco pode estipular que o aplicativo deve ter criptografia de dados em repouso e permissões de usuário com escopo adequado, e que devem estar em conformidade com determinados padrões de regulamentação, como PCI DSS. Nem todos os provedores de bancos de dados gerenciados aderem aos mesmos padrões regulatórios ou mantêm as mesmas práticas de segurança, e é improvável que adotem novos padrões ou práticas para apenas um de seus clientes. Por esse motivo, é essencial garantir que qualquer provedor de banco de dados gerenciado do qual você dependa para tal aplicação seja capaz de atender às suas necessidades de segurança, bem como às necessidades de seus clientes.

      Conclusão

      Os bancos de dados gerenciados têm muitos recursos que atraem uma ampla variedade de empresas e desenvolvedores, mas um banco de dados gerenciado pode não resolver todos os problemas ou atender às necessidades de todos. Alguns podem achar que o conjunto limitado de recursos e as opções de configuração de um banco de dados gerenciado, o aumento de custos e a flexibilidade reduzida superam qualquer uma de suas possíveis vantagens. No entanto, benefícios atraentes como facilidade de uso, escalabilidade, backups e upgrades automatizados e alta disponibilidade levaram a uma maior adoção de soluções de banco de dados gerenciado em vários setores.

      Se você estiver interessado em aprender mais sobre os Bancos de Dados Gerenciados da DigitalOcean, recomendamos que você confira nossa documentação de produto.



      Source link