One place for hosting & domains

      Bancos

      Compreendendo bancos de dados relacionais


      Introdução

      Os sistemas de gerenciamento de banco de dados (SGDB, no inglês DMBS) são programas de computador que permitem que usuários interajam com um banco de dados. Um DBMS permite que os usuários controlem o acesso a um banco de dados, gravem dados, executem consultas e façam outras tarefas relacionadas ao gerenciamento de banco de dados.

      No entanto, para realizar qualquer uma dessas tarefas, o DBMS deve possuir algum modelo subjacente que defina como os dados são organizados. O modelo relacional é uma abordagem para organizar dados que vem sendo bastante usada em softwares de banco de dados desde que foram criados no final dos anos 60. Tanto é que, no momento em que este artigo está sendo escrito, quatro dos cinco DBMS mais populares são relacionais.

      Este artigo conceitual descreve o histórico do modelo relacional, como os bancos de dados relacionais organizam dados e como são usados hoje.

      História do modelo relacional

      Os bancos de dados são clusters de informações logicamente modelados, ou dados. Qualquer coleção de dados é um banco de dados, independentemente de como ou onde é armazenada. Mesmo um armário de arquivos que contém informações de folha de pagamento é um banco de dados, assim como uma pilha de formulários hospitalares ou uma coleção de informações de cliente de uma empresa espalhada em vários locais. Antes do armazenamento e gerenciamento de dados com computadores ser uma prática comum, bancos de dados físicos como esses eram os únicos disponíveis para as organizações governamentais e empresariais que precisavam armazenar informações.

      Em meados do século XX, pesquisas na área da ciência da computação levaram à criação de máquinas com maior poder de processamento, bem como maior capacidade de armazenamento local e externo. Esses avanços levaram os cientistas da computação a começar a reconhecer o potencial que essas máquinas tinham para armazenar e gerenciar quantidades cada vez maiores de dados.

      No entanto, não havia nenhuma teoria para explicar como os computadores poderiam organizar os dados de maneiras lógicas e significativas. Uma coisa é armazenar dados não ordenados em uma máquina, e outra, muito mais complicada, é projetar sistemas que permitam adicionar, recuperar, classificar e gerenciar os dados de maneira consistente e prática. A necessidade de uma estrutura lógica para armazenar e organizar dados levou a uma série de propostas sobre como tirar proveito dos computadores para gerenciar dados.

      Um modelo de banco de dados inicial foi o modelo hierárquico, no qual os dados são organizados em uma estrutura que se assemelha a uma árvore, semelhante aos sistemas de arquivos modernos. O exemplo a seguir mostra como o layout de parte de um banco de dados hierárquico usado para categorizar animais se pareceria:

      Exemplo de um banco de dados hierárquico: categorização de animais

      O modelo hierárquico foi amplamente implementado nos primeiros sistemas de gerenciamento banco de dados, mas também se mostrou um pouco inflexível. Neste modelo, mesmo que os registros individuais possam ter vários “filhos”, cada registro só pode ter um “pai” na hierarquia. Por conta disso, esses primeiros bancos de dados hierárquicos ficavam limitados a representar apenas relações “um a um” e “um para muitos”. Essa falta de relações”muitos para muitos” poderia levar a problemas quando se estivesse trabalhando com pontos de dados que você gostaria de associar a mais de um pai.

      No final dos anos 60, Edgar F. Codd, um cientista da computação que trabalhava na IBM, criou o modelo relacional de gerenciamento de banco de dados. O modelo relacional de Codd permitiu que registros individuais fossem associados a mais de uma tabela, permitindo assim relações “muitos para muitos” entre pontos de dados, além de relacionamentos “um para muitos”. Isso proporcionou maior flexibilidade do que outros modelos existentes no que diz respeito ao projeto de banco de dados. Isso fez com que os sistemas de gerenciamento de banco de dados relacionais (RDBMSs) pudessem atender a uma gama muito maior de necessidades de negócios.

      Codd propôs uma linguagem para gerenciar dados relacionais, conhecida como Alpha, que influenciou o desenvolvimento de linguagens de banco de dados posteriores. Dois dos colegas de Codd na IBM, Donald Chamberlin e Raymond Boyce, criaram uma dessas linguagens inspirada no Alpha. Eles deram a ela o nome de SEQUEL, abreviação de Structured English Query Language. No entanto, por causa de uma marca registrada existente, eles reduziram o nome de sua linguagem para SQL (conhecida mais formalmente como Structured Query Language).

      Devido às restrições de hardware, os primeiros bancos de dados relacionais ainda eram proibitivamente lentos, e foi necessário algum tempo até que a tecnologia se tornasse difundida. Mas em meados dos anos 80, o modelo relacional de Codd já havia sido implementado em diversos produtos de gerenciamento de banco de dados comercial tanto da IBM quando de seus concorrentes. Esses fornecedores também seguiram a iniciativa da IBM desenvolvendo e implementando seus próprios dialetos de SQL. Em 1987, tanto o American National Standards Institute quanto a International Organization for Standardization haviam ratificado e publicado padrões para SQL, solidificando seu status como a linguagem aceita para gerenciar RDBMSs.

      O uso difundido do modelo relacional em várias indústrias fez com que ele se tornasse reconhecido como o modelo padrão para o gerenciamento de dados. Mesmo com o surgimento de vários bancos de dados NoSQL nos últimos anos, os bancos de dados relacionais continuam sendo as ferramentas dominantes para armazenar e organizar dados.

      Como os bancos de dados relacionais organizam os dados

      Agora que você compreende de maneira geral a história do modelo relacional, vamos dar uma olhada mais de perto em como o modelo organiza os dados.

      Os elementos mais fundamentais no modelo relacional são as relações, que os usuários e RDBMS modernos reconhecem como tabelas. Uma relação é um conjunto de tuplas, ou linhas em uma tabela, com cada tupla compartilhando um conjunto de atributos, ou colunas:

      Diagrama exemplo de como as relações, tuplas e atributos se relacionam entre si

      Uma coluna é a menor estrutura organizacional de um banco de dados relacional e representa as diversas facetas que definem os registros na tabela. Daí seu nome mais formal, atributos. Você pode pensar em cada tupla como sendo uma instância única de qualquer tipo de pessoas, objetos, eventos ou associações que a tabela possua. Essas instâncias podem representar coisas como funcionários em uma empresa, vendas de um negócio on-line ou resultados de testes de laboratório. Por exemplo, em uma tabela que contenha registros de funcionário de professores em uma escola, as tuplas podem possuir atributos como name (nome), subjects (disciplinas), start_date (data de início), e assim por diante.

      Ao criar colunas, você especifica um tipo de dados que dita qual o tipo das entradas que são permitidas nessa coluna. Os RDBMSs muitas vezes implementam seus próprios tipos de dados únicos, que podem não ser diretamente intercambiáveis com tipos de dados semelhantes de outros sistemas. Alguns tipos de dados comuns incluem datas, strings, inteiros e booleanos.

      No modelo relacional, cada tabela contém pelo menos uma coluna que pode ser usada para identificar de maneira única cada linha, chamada de chave primária. Isso é importante, pois significa que os usuários não precisam saber onde seus dados ficam fisicamente armazenados em uma máquina. Em vez disso, seu DBMS pode manter o controle de cada registro e retorná-los conforme necessário. Por sua vez, isso significa que os registros não possuem ordem lógica definida, e os usuários têm a capacidade de retornar seus dados em qualquer ordem ou sob o efeito do filtro que quiserem.

      Se você tiver duas tabelas que gostaria de se associar uma com a outra, uma maneira de fazer isso é com uma chave estrangeira. Uma chave estrangeira é essencialmente uma cópia da chave primária de uma tabela (a tabela “pai”) inserida em uma coluna em outra tabela (o “filho”). O exemplo a seguir destaca a relação entre duas tabelas. Uma é usada para registrar informações sobre funcionários em uma empresa e a outra é usada para acompanhar as vendas dela. Neste exemplo, a chave primária da tabela EMPLOYEES (funcionários) é usada como a chave estrangeira na tabela SALES (vendas):

      Diagrama exemplo de como a chave primária da tabela de funcionários funciona como chave estrangeira da tabela SALES

      Se você tentar adicionar um registro à tabela filho e o valor inserido na coluna de chaves estrangeiras não existir na chave primária da tabela de origem, a declaração de inserção será inválida. Isso ajuda a manter a integridade de nível de relação, já que as linhas em ambas as tabelas sempre estarão relacionadas corretamente.

      Os elementos estruturais do modelo relacional ajudam a manter os dados armazenados de forma organizada, mas o armazenamento de dados só é útil se for possível recuperá-los. Para recuperar informações de um RDBMS, é possível emitir uma consulta, ou uma solicitação estruturada para um conjunto de informações. Como mencionado anteriormente, a maioria dos bancos de dados relacionais usa SQL para gerenciar e consultar dados. O SQL permite que você filtre e manipule os resultados da consulta com uma variedade de cláusulas, predicados e expressões, dando-lhe um controle fino sobre quais dados aparecerão no conjunto de resultados.

      Vantagens e limitações dos bancos de dados relacionais

      Com a estrutura organizacional subjacente de bancos de dados relacionais em mente, vamos considerar algumas de suas vantagens e desvantagens.

      Hoje em dia, tanto o SQL quanto os bancos de dados que o implementam se desviam do modelo relacional de Codd de várias maneiras. Por exemplo, o modelo de Codd determina que cada linha em uma tabela deve ser única, enquanto que, por razões de praticidade, a maioria dos bancos de dados relacionais modernos permite linhas duplicadas. Existem algumas pessoas que não consideram os bancos de dados SQL como verdadeiros bancos de dados relacionais se não conseguem aderir às especificações de Codd para o modelo relacional. No entanto, em termos práticos, qualquer DBMS que use SQL e de certa forma acate ao modelo relacional de dados provavelmente será referido como um sistema de gerenciamento de banco de dados relacional.

      Embora os bancos de dados relacionais tenham rapidamente crescido em popularidade, algumas das desvantagens do modelo relacional começaram a se tornar aparentes à medida que os dados se tornaram mais valiosos e as empresas começaram a armazenar uma maior quantidade deles. Por exemplo, pode ser difícil dimensionar um banco de dados relacional horizontalmente. O dimensionamento horizontal, ou ampliamento, é a prática de adicionar mais máquinas a uma pilha existente para espalhar a carga e permitir um maior tráfego e processamento mais rápido. Isso é muitas vezes contrastado com o dimensionamento vertical, que envolve atualizar o hardware de um servidor existente, geralmente adicionando mais RAM ou CPU.

      A razão pela qual é difícil dimensionar um banco de dados relacional de dados horizontalmente tem a ver com o fato de que o modelo relacional foi projetado para garantir a consistência, ou seja, clientes que consultarem o mesmo banco de dados sempre receberão os mesmos dados. Se você fosse dimensionar um banco de dados relacional horizontalmente em várias máquinas, tornaria-se difícil garantir a consistência, pois os clientes poderiam escrever dados em um nó mas não nos outros. Provavelmente haveria um atraso entre a gravação inicial e o momento em que os outros nós fossem atualizados para refletir as alterações, resultando em inconsistências entre eles.

      Outra limitação apresentada pelos RDBMSs é que o modelo relacional foi projetado para gerenciar dados estruturados, ou dados que se alinhem a um tipo de dados pré-definido ou que pelo menos estejam organizados de alguma forma pré-determinada, tornando-os facilmente categorizáveis e pesquisáveis. No entanto, com a propagação da computação pessoal e o aumento da internet no início dos anos 90, dados não estruturados — como mensagens de e-mail, fotos, vídeos, etc — se tornaram mais comuns.

      Nada disso é para dizer que os bancos de dados relacionais não são úteis. Muito pelo contrário, o modelo relacional ainda é a estrutura dominante para o gerenciamento de dados após mais de 40 anos. Sua prevalência e longevidade significam que os bancos de dados relacionais são uma tecnologia madura, que por si só é uma de suas principais vantagens. Existem muitos aplicativos projetados para trabalhar com o modelo relacional, bem como muitos profissionais administradores de banco de dados que são especialistas no assunto. Também há uma grande variedade de recursos disponíveis on-line e em livros para aqueles que querem começar com bancos de dados relacionais.

      Outra vantagem dos bancos de dados relacionais é que quase todos os RDBMS suportam transações. Uma transação consiste em uma ou mais declarações SQL individuais realizadas em sequência como uma única unidade de trabalho. As transações apresentam uma abordagem tudo ou nada, o que significa que cada declaração SQL na transação deve ser válida; caso contrário, toda a transação falhará. Isso é muito útil para garantir a integridade dos dados ao fazer alterações em várias linhas ou tabelas.

      Por fim, os bancos de dados relacionais são extremamente flexíveis. Eles foram usados para construir uma grande variedade de aplicativos diferentes e continuam funcionando de maneira eficiente, mesmo com grandes quantidades de dados. O SQL também é extremamente poderoso, permitindo adicionar e alterar os dados em tempo real, bem como alterar a estrutura de esquemas e tabelas do banco de dados sem afetar os dados existentes.

      Conclusão

      Graças à sua flexibilidade e design para a integridade dos dados, os bancos de dados relacionais ainda representam a principal maneira de os dados serem gerenciados e armazenados mais de cinquenta anos após terem sido concebidos pela primeira vez. Mesmo com o surgimento de diversos bancos de dados NoSQL nos últimos anos, compreender o modelo relacional e como trabalhar com RDBMSs é muito importante para quem quiser construir aplicativos que tirem proveito do poder dos dados.

      Para aprender mais sobre alguns RDBMSs populares de código aberto, recomendamos que você consulte nossa comparação entre vários bancos de dados SQL relacionais de código aberto. Se tiver interesse em aprender mais sobre bancos de dados de maneira geral, recomendamos que verifique nossa biblioteca completa de conteúdos relacionados a banco de dados.



      Source link

      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