DBA bot Joe. Anatoly Stansler (Postgres.ai)

Como um desenvolvedor de back-end entende que uma consulta SQL funcionará bem em um “prod”? Em empresas grandes ou em rápido crescimento, nem todos têm acesso ao "produto". E com acesso, nem todas as solicitações podem ser verificadas sem problemas, e a criação de uma cópia do banco de dados geralmente leva horas. Para resolver esses problemas, criamos um DBA artificial - Joe. Já foi implementado com sucesso em várias empresas e ajuda mais de uma dezena de desenvolvedores.

Vídeo:

Olá a todos! Meu nome é Anatoly Stansler. eu trabalho para uma empresa postgres.ai. Estamos empenhados em acelerar o processo de desenvolvimento removendo os atrasos associados ao trabalho do Postgres de desenvolvedores, DBAs e QAs.

Temos grandes clientes e hoje parte do relatório será dedicada a casos que conhecemos trabalhando com eles. Vou falar sobre como os ajudamos a resolver problemas bastante sérios.

Quando estamos desenvolvendo e fazendo migrações complexas de alta carga, nos perguntamos: “Essa migração vai decolar?”. Usamos revisão, usamos o conhecimento de colegas mais experientes, especialistas em DBA. E eles podem dizer se ele vai voar ou não.

Mas talvez fosse melhor se pudéssemos testá-lo nós mesmos em cópias em tamanho real. E hoje falaremos apenas sobre quais são as abordagens de teste agora e como isso pode ser feito melhor e com quais ferramentas. Também falaremos sobre os prós e contras de tais abordagens e o que podemos corrigir aqui.

Quem já fez índices direto no prod ou fez alguma alteração? Um pouco de. E para quem isso levou ao fato de que os dados foram perdidos ou houve tempo de inatividade? Então você conhece essa dor. Graças a Deus há backups.

A primeira abordagem é testar em prod. Ou, quando um desenvolvedor está em uma máquina local, ele tem dados de teste, há algum tipo de seleção limitada. E nós lançamos para prod, e chegamos a esta situação.

Dói, é caro. Provavelmente é melhor não.

E qual é a melhor forma de o fazer?

Vamos pegar a encenação e selecionar alguma parte do prod lá. Ou, na melhor das hipóteses, vamos dar uma olhada real, todos os dados. E depois de desenvolvê-lo localmente, verificaremos adicionalmente a preparação.

Isso nos permitirá remover alguns dos erros, ou seja, impedir que eles fiquem em prod.

Quais são os problemas?

• O problema é que compartilhamos essa encenação com os colegas. E muitas vezes acontece que você faz algum tipo de alteração, bam - e não tem dados, o trabalho vai pelo ralo. O preparo era de vários terabytes. E você tem que esperar muito tempo para que ele suba novamente. E decidimos finalizá-lo amanhã. É isso, temos um desenvolvimento.
• E, claro, temos muitos colegas trabalhando lá, muitas equipes. E isso tem que ser feito manualmente. E isso é inconveniente.

E vale dizer que temos apenas uma tentativa, um tiro, se quisermos fazer alguma alteração no banco de dados, mexer nos dados, alterar a estrutura. E se algo der errado, se houver um erro na migração, não reverteremos rapidamente.

Isso é melhor do que a abordagem anterior, mas ainda há uma grande probabilidade de que algum tipo de erro vá para a produção.

O que nos impede de dar a cada desenvolvedor um banco de testes, uma cópia em tamanho real? Acho que está claro o que atrapalha.

Quem tem um banco de dados maior que um terabyte? Mais da metade da sala.

E é claro que manter máquinas para cada desenvolvedor, quando há uma produção tão grande, é muito caro e, além disso, leva muito tempo.

Temos clientes que perceberam que é muito importante testar todas as alterações em cópias em tamanho real, mas seu banco de dados é inferior a um terabyte e não há recursos para manter um banco de testes para cada desenvolvedor. Portanto, eles precisam baixar os dumps localmente em sua máquina e testar dessa maneira. Isso leva muito tempo.

Mesmo que você faça isso dentro da infraestrutura, baixar um terabyte de dados por hora já é muito bom. Mas eles usam dumps lógicos, baixam localmente da nuvem. Para eles, a velocidade é de cerca de 200 gigabytes por hora. E ainda leva tempo para sair do dump lógico, acumular os índices, etc.

Mas eles usam essa abordagem porque lhes permite manter o prod confiável.

O que podemos fazer aqui? Vamos baratear os bancos de teste e dar a cada desenvolvedor seu próprio banco de testes.

E isso é possível.

E nessa abordagem, quando fazemos clones finos para cada desenvolvedor, podemos compartilhá-los em uma máquina. Por exemplo, se você tiver um banco de dados de 10 TB e quiser entregá-lo a 10 desenvolvedores, não precisará ter bancos de dados de XNUMX x XNUMX TB. Você só precisa de uma máquina para fazer cópias finas e isoladas para cada desenvolvedor usando uma máquina. Eu vou te dizer como funciona um pouco mais tarde.

Exemplo real:

• DB - 4,5 terabytes.

• Podemos obter cópias independentes em 30 segundos.

Você não precisa esperar por uma bancada de teste e depender do tamanho dela. Você pode obtê-lo em segundos. Serão ambientes completamente isolados, mas que compartilham dados entre si.

Isso é ótimo. Aqui estamos falando de magia e um universo paralelo.

No nosso caso, isso funciona usando o sistema OpenZFS.

O OpenZFS é um sistema de arquivos copy-on-write que suporta instantâneos e clones prontos para uso. É confiável e escalável. Ela é muito fácil de controlar. Ele pode ser implantado literalmente em duas equipes.

Existem outras opções:

• lvm,

• Armazenamento (por exemplo, Pure Storage).

O Database Lab de que estou falando é modular. Pode ser implementado usando essas opções. Mas, por enquanto, nos concentramos no OpenZFS, porque havia problemas com o LVM especificamente.

Como funciona? Em vez de sobrescrever os dados toda vez que os alteramos, nós os salvamos simplesmente marcando que esses novos dados são de um novo ponto no tempo, um novo instantâneo.

E no futuro, quando quisermos reverter ou quisermos fazer um novo clone de alguma versão anterior, apenas dizemos: "OK, dê-nos esses blocos de dados marcados assim."

E esse usuário trabalhará com esse conjunto de dados. Ele os mudará gradualmente, fará seus próprios instantâneos.

E nós vamos ramificar. Cada desenvolvedor no nosso caso terá a oportunidade de ter seu próprio clone que edita, e os dados que forem compartilhados serão compartilhados entre todos.

Para implantar esse sistema em casa, você precisa resolver dois problemas:

• A primeira é a fonte dos dados, de onde você os retirará. Você pode configurar a replicação com produção. Você já pode usar os backups que configurou, espero. WAL-E, WAL-G ou Barman. E mesmo se você estiver usando algum tipo de solução em nuvem, como RDS ou Cloud SQL, poderá usar dumps lógicos. Mas ainda assim aconselhamos o uso de backups, pois com essa abordagem você também manterá a estrutura física dos arquivos, o que permitirá que você esteja ainda mais próximo das métricas que veria em produção para capturar os problemas que existem.

• A segunda é onde você deseja hospedar o laboratório de banco de dados. Pode ser Cloud, pode ser On-premise. É importante dizer aqui que o ZFS oferece suporte à compactação de dados. E faz isso muito bem.

Imagine que para cada um desses clones, dependendo das operações que fizermos com a base, algum tipo de dev crescerá. Para isso, o dev também precisará de espaço. Mas devido ao fato de termos tomado uma base de 4,5 terabytes, o ZFS irá comprimi-lo para 3,5 terabytes. Isso pode variar dependendo das configurações. E ainda temos espaço para dev.

Tal sistema pode ser usado para diferentes casos.

• São desenvolvedores, DBAs para validação de consultas, para otimização.

• Isso pode ser usado em testes de controle de qualidade para testar uma migração específica antes de lançá-la para produção. E também podemos criar ambientes especiais para QA com dados reais, onde podem testar novas funcionalidades. E levará segundos em vez de horas de espera, e talvez dias em alguns outros casos em que cópias finas não são usadas.

• E outro caso. Se a empresa não tiver um sistema de análise configurado, podemos isolar um clone fino da base de produtos e fornecê-lo a consultas longas ou índices especiais que podem ser usados ​​em análises.

Com esta abordagem:

1. Baixa probabilidade de erros no "prod", porque testamos todas as alterações em dados de tamanho real.

2. Temos uma cultura de testar, porque agora você não precisa esperar horas pelo seu estande.

3. E não há barreira, nem espera entre os testes. Você pode realmente ir e verificar. E será melhor assim à medida que acelerarmos o desenvolvimento.

• Haverá menos refatoração. Menos bugs acabarão em prod. Nós os refatoraremos menos depois.

• Podemos reverter mudanças irreversíveis. Esta não é a abordagem padrão.

1. Isso é benéfico porque compartilhamos os recursos das bancadas de teste.

Já está bom, mas o que mais poderia ser acelerado?

Graças a esse sistema, podemos reduzir bastante o limite para entrar em tais testes.

Agora existe um círculo vicioso, quando um desenvolvedor, para obter acesso a dados reais em tamanho real, deve se tornar um especialista. Ele deve ser confiável com tal acesso.

Mas como crescer se não estiver lá. Mas e se você tiver apenas um conjunto muito pequeno de dados de teste disponíveis? Então você não terá nenhuma experiência real.

Como sair desse círculo? Como primeira interface, conveniente para desenvolvedores de qualquer nível, escolhemos o bot Slack. Mas pode ser qualquer outra interface.

O que isso permite que você faça? Você pode pegar uma consulta específica e enviá-la para um canal especial para o banco de dados. Implantaremos automaticamente um clone fino em segundos. Vamos executar esta solicitação. Coletamos métricas e recomendações. Vamos mostrar uma visualização. E então este clone permanecerá para que esta consulta possa ser otimizada de alguma forma, adicionar índices, etc.

E o Slack também nos dá oportunidades de colaboração prontas para uso. Como este é apenas um canal, você pode começar a discutir essa solicitação ali mesmo no tópico para tal solicitação, ping de seus colegas, DBAs que estão dentro da empresa.

Mas há, claro, problemas. Como este é o mundo real e estamos usando um servidor que hospeda muitos clones ao mesmo tempo, precisamos compactar a quantidade de memória e a potência da CPU disponível para os clones.

Mas para que esses testes sejam plausíveis, você precisa resolver esse problema de alguma forma.

É claro que o ponto importante são os mesmos dados. Mas já temos. E queremos alcançar a mesma configuração. E podemos dar uma configuração quase idêntica.

Seria legal ter o mesmo hardware da produção, mas pode ser diferente.

Vamos relembrar como o Postgres trabalha com a memória. Temos duas caches. Um do sistema de arquivos e um Postgres nativo, ou seja, Cache de Buffer Compartilhado.

É importante observar que o cache de buffer compartilhado é alocado quando o Postgres é iniciado, dependendo do tamanho especificado na configuração.

E o segundo cache usa todo o espaço disponível.

E quando fazemos vários clones em uma máquina, descobrimos que gradualmente preenchemos a memória. E no bom sentido, o Shared Buffer Cache é 25% da quantidade total de memória disponível na máquina.

E acontece que, se não alterarmos esse parâmetro, poderemos executar apenas 4 instâncias em uma máquina, ou seja, 4 desses clones finos no total. E isso, claro, é ruim, porque queremos ter muito mais deles.

Mas por outro lado, o Buffer Cache é usado para executar consultas de índices, ou seja, o plano depende do tamanho de nossos caches. E se apenas pegarmos esse parâmetro e reduzi-lo, nossos planos podem mudar muito.

Por exemplo, se tivermos um cache grande em prod, o Postgres preferirá usar um index. E se não, haverá SeqScan. E de que adiantaria se nossos planos não coincidissem?

Mas aqui chegamos à conclusão de que, de fato, o plano no Postgres não depende do tamanho específico especificado no Shared Buffer no plano, depende do Effective_cache_size.

Effective_cache_size é a quantidade estimada de cache que está disponível para nós, ou seja, a soma do Buffer Cache e do cache do sistema de arquivos. Isso é definido pelo config. E essa memória não é alocada.

E devido a esse parâmetro, podemos meio que enganar o Postgres, dizendo que na verdade temos muitos dados disponíveis, mesmo que não tenhamos esses dados. E assim, os planos vão coincidir totalmente com a produção.

Mas isso pode afetar o tempo. E otimizamos as consultas por tempo, mas é importante que o tempo dependa de muitos fatores:

• Depende da carga que está atualmente em prod.

• Depende das características da própria máquina.

E esse é um parâmetro indireto, mas na verdade podemos otimizar exatamente pela quantidade de dados que essa query vai ler para chegar no resultado.

E se você quiser que o tempo seja próximo ao que veremos no prod, precisamos pegar o hardware mais semelhante e, possivelmente, ainda mais para que todos os clones caibam. Mas isso é um compromisso, ou seja, você obterá os mesmos planos, verá quantos dados uma determinada consulta irá ler e poderá concluir se essa consulta é boa (ou migração) ou ruim, ela ainda precisa ser otimizada .

Vamos dar uma olhada em como Joe é especificamente otimizado.

Vamos pegar uma requisição de um sistema real. Nesse caso, o banco de dados é de 1 terabyte. E queremos contar o número de novas postagens que tiveram mais de 10 curtidas.

Estamos escrevendo uma mensagem para o canal, um clone foi implantado para nós. E veremos que tal solicitação será concluída em 2,5 minutos. Esta é a primeira coisa que notamos.

B Joe mostrará recomendações automáticas com base no plano e nas métricas.

Veremos que a consulta processa muitos dados para obter um número relativamente pequeno de linhas. E algum tipo de índice especializado é necessário, pois notamos que há muitas linhas filtradas na consulta.

Vamos dar uma olhada no que aconteceu. De fato, vemos que lemos quase um gigabyte e meio de dados do cache do arquivo ou mesmo do disco. E isso não é bom, porque temos apenas 142 linhas.

E, ao que parece, temos uma varredura de índice aqui e deveríamos ter funcionado rapidamente, mas como filtramos muitas linhas (tivemos que contá-las), a solicitação funcionou lentamente.

E isso aconteceu no plano devido ao fato de que as condições da consulta e as condições do índice não correspondem parcialmente.

Vamos tentar tornar o índice mais preciso e ver como a execução da consulta muda depois disso.

A criação do índice demorou bastante, mas agora verificamos a consulta e vemos que o tempo, em vez de 2,5 minutos, é de apenas 156 milissegundos, o que é bom o suficiente. E lemos apenas 6 megabytes de dados.

E agora usamos apenas a varredura do índice.

Outra história importante é que queremos apresentar o plano de uma forma mais compreensível. Implementamos a visualização usando Flame Graphs.

Este é um pedido diferente, mais intenso. E construímos Flame Graphs de acordo com dois parâmetros: esta é a quantidade de dados que um determinado nó conta no plano e o tempo, ou seja, o tempo de execução do nó.

Aqui podemos comparar nós específicos uns com os outros. E ficará claro qual deles leva mais ou menos, o que geralmente é difícil de fazer em outros métodos de renderização.

Claro, todo mundo conhece o Explain.depesz.com. Uma boa característica dessa visualização é que salvamos o plano de texto e também colocamos alguns parâmetros básicos em uma tabela para que possamos classificar.

E os desenvolvedores que ainda não se aprofundaram neste tópico também usam o Explain.depesz.com, porque é mais fácil para eles descobrir quais métricas são importantes e quais não são.

Existe uma nova abordagem para a visualização - esta é o Explain.dalibo.com. Eles fazem uma visualização em árvore, mas é muito difícil comparar os nós entre si. Aqui você pode entender bem a estrutura, porém, se houver uma grande solicitação, você precisará rolar para frente e para trás, mas também uma opção.

colaboração

E, como eu disse, o Slack nos dá a oportunidade de colaborar. Por exemplo, se nos deparamos com uma consulta complexa que não está clara como otimizar, podemos esclarecer esse problema com nossos colegas em um tópico no Slack.

Parece-nos que é importante testar dados em tamanho real. Para isso, criamos a ferramenta Update Database Lab, que está disponível em código aberto. Você também pode usar o bot Joe. Você pode pegá-lo agora e implementá-lo em seu lugar. Todos os guias estão disponíveis lá.

Também é importante ressaltar que a solução em si não é revolucionária, pois existe o Delphix, mas é uma solução corporativa. Está completamente fechado, é muito caro. Nós nos especializamos especificamente em Postgres. Estes são todos produtos de código aberto. Junte-se a nós!

É aqui que termino. Obrigado!

perguntas

Olá! Obrigado pelo relatório! Muito interessante, principalmente para mim, porque resolvi o mesmo problema há algum tempo. E então eu tenho uma série de perguntas. Espero conseguir pelo menos uma parte.

Eu me pergunto como você calcula o lugar para este ambiente? A tecnologia significa que, sob certas circunstâncias, seus clones podem crescer até o tamanho máximo. Grosso modo, se você tiver um banco de dados de dez terabytes e 10 clones, será fácil simular uma situação em que cada clone pesa 10 dados exclusivos. Como você calcula esse lugar, ou seja, aquele delta de que você falou, onde esses clones vão morar?

Boa pergunta. É importante manter o controle de clones específicos aqui. E se um clone tiver uma mudança muito grande, ele começa a crescer, então podemos primeiro emitir um aviso ao usuário sobre isso ou parar imediatamente esse clone para que não tenhamos uma situação de falha.

Sim, eu tenho uma pergunta aninhada. Ou seja, como garantir o ciclo de vida desses módulos? Temos esse problema e toda uma história separada. Como isso acontece?

Há algum ttl para cada clone. Basicamente, temos um ttl fixo.

O que, se não for um segredo?

1 hora, ou seja, ocioso - 1 hora. Se não for usado, batemos nele. Mas não há surpresa aqui, já que podemos levantar o clone em segundos. E se precisar de novo, por favor.

Também me interesso pela escolha das tecnologias, porque, por exemplo, usamos vários métodos em paralelo por um motivo ou outro. Por que ZFS? Por que você não usou o LVM? Você mencionou que houve problemas com o LVM. Quais foram os problemas? Na minha opinião, a opção mais ideal é com armazenamento, em termos de desempenho.

Qual é o principal problema com o ZFS? O fato de que você deve executar no mesmo host, ou seja, todas as instâncias residirão no mesmo sistema operacional. E no caso de armazenamento, você pode conectar diferentes equipamentos. E o gargalo são apenas os blocos que estão no sistema de armazenamento. E a questão da escolha das tecnologias é interessante. Por que não LVM?

Especificamente, podemos discutir o LVM no encontro. Sobre o armazenamento - é apenas caro. Podemos implementar o sistema ZFS em qualquer lugar. Você pode implantá-lo em sua máquina. Você pode simplesmente baixar o repositório e implantá-lo. O ZFS está instalado em quase todos os lugares se estivermos falando do Linux. Ou seja, obtemos uma solução muito flexível. E o próprio ZFS oferece muito fora da caixa. Você pode carregar quantos dados quiser, conectar um grande número de discos, há instantâneos. E, como eu disse, é fácil de administrar. Ou seja, parece muito agradável de usar. Ele é testado, ele tem muitos anos. Ele tem uma comunidade muito grande que está crescendo. O ZFS é uma solução muito confiável.

Nikolai Samokhvalov: Posso comentar mais? Meu nome é Nikolay, trabalhamos junto com Anatoly. Concordo que o armazenamento é ótimo. E alguns de nossos clientes têm Pure Storage etc.

Anatoly observou corretamente que estamos focados na modularidade. E no futuro, você pode implementar uma interface - tirar um instantâneo, fazer um clone, destruir o clone. É tudo fácil. E o armazenamento é legal, se for.

Mas o ZFS está disponível para todos. DelPhix já é suficiente, eles têm 300 clientes. Destes, o fortuna 100 tem 50 clientes, ou seja, são voltados para a NASA, etc. E é por isso que temos um Core de código aberto. Temos uma parte da interface que não é open source. Esta é a plataforma que vamos mostrar. Mas queremos que seja acessível a todos. Queremos fazer uma revolução para que todos os testadores parem de adivinhar em laptops. Temos que escrever SELECT e ver imediatamente que ele é lento. Pare de esperar que o DBA lhe informe sobre isso. Aqui está o objetivo principal. E acho que todos chegaremos a isso. E nós fazemos isso para que todos tenham. Portanto ZFS, porque estará disponível em todos os lugares. Obrigado à comunidade por resolver problemas e por ter uma licença de código aberto, etc.*

Saudações! Obrigado pelo relatório! Meu nome é Máximo. Nós lidamos com os mesmos problemas. Eles decidiram por conta própria. Como você compartilha recursos entre esses clones? Cada clone pode fazer suas próprias coisas a qualquer momento: um testa uma coisa, outro outra, alguém constrói um índice, alguém tem um trabalho pesado. E se você ainda pode dividir por CPU, então por IO, como você divide? Esta é a primeira pergunta.

E a segunda pergunta é sobre a dissimilaridade das arquibancadas. Digamos que eu tenha ZFS aqui e tudo legal, mas o cliente no prod não tem ZFS, mas ext4, por exemplo. Como neste caso?

As perguntas são muito boas. Mencionei um pouco esse problema com o fato de compartilharmos recursos. E a solução é esta. Imagine que você está testando no staging. Você também pode ter essa situação ao mesmo tempo em que alguém dá uma carga, outra pessoa. E como resultado, você vê métricas incompreensíveis. Mesmo o mesmo problema pode ser com prod. Quando você quer verificar algum pedido e vê que há algum problema com ele - funciona devagar, então na verdade o problema não estava no pedido, mas no fato de haver algum tipo de carregamento paralelo.

E, portanto, é importante aqui focar em qual será o plano, quais etapas daremos no plano e quantos dados levantaremos para isso. O fato de nossos discos, por exemplo, serem carregados com algo, afetará especificamente o tempo. Mas podemos estimar o quão carregada esta solicitação está pela quantidade de dados. Não é tão importante que ao mesmo tempo haja algum tipo de execução.

Eu tenho duas perguntas. Isso é muito legal. Houve casos em que os dados de produção são críticos, como números de cartão de crédito? Já existe algo pronto ou é uma tarefa separada? E a segunda pergunta - existe algo assim para o MySQL?

Sobre os dados. Faremos ofuscação até que o façamos. Mas se você implantar exatamente Joe, se não der acesso aos desenvolvedores, não haverá acesso aos dados. Por que? Porque Joe não mostra dados. Só mostra métricas, planos e pronto. Isso foi feito propositalmente, pois esse é um dos requisitos do nosso cliente. Eles queriam ser capazes de otimizar sem dar acesso a todos.

Sobre MySQL. Este sistema pode ser usado para qualquer coisa que armazene estado em disco. E como estamos fazendo o Postgres, agora estamos fazendo toda a automação do Postgres primeiro. Queremos automatizar a obtenção de dados de um backup. Estamos configurando o Postgres corretamente. Sabemos combinar os planos, etc.

Mas como o sistema é extensível, também pode ser usado para MySQL. E existem tais exemplos. O Yandex tem algo semelhante, mas não o publica em lugar nenhum. Eles o usam dentro do Yandex.Metrica. E há apenas uma história sobre o MySQL. Mas as tecnologias são as mesmas, ZFS.

Obrigado pelo relatório! Eu também tenho algumas perguntas. Você mencionou que a clonagem pode ser usada para análise, por exemplo, para criar índices adicionais lá. Você pode contar um pouco mais sobre como funciona?

E logo farei a segunda pergunta sobre a semelhança das arquibancadas, a semelhança dos planos. O plano também depende das estatísticas coletadas pelo Postgres. Como você resolve este problema?

De acordo com as análises, não há casos específicos, porque ainda não usamos, mas existe essa oportunidade. Se estamos falando de índices, imagine que uma consulta está perseguindo uma tabela com centenas de milhões de registros e uma coluna que geralmente não é indexada em prod. E queremos calcular alguns dados lá. Se essa solicitação for enviada para o prod, existe a possibilidade de que seja simples no prod, pois a solicitação será processada ali por um minuto.

Ok, vamos fazer um clone fino que não seja terrível de parar por alguns minutos. E para facilitar a leitura das análises, adicionaremos índices para as colunas nas quais estamos interessados ​​​​nos dados.

O índice será criado a cada vez?

Você pode fazer com que toquemos nos dados, façamos instantâneos, depois nos recuperaremos desse instantâneo e geraremos novas solicitações. Ou seja, você pode fazer com que crie novos clones com índices já afixados.

Quanto à questão das estatísticas, se restaurarmos a partir de um backup, se fizermos replicação, nossas estatísticas serão exatamente as mesmas. Porque nós temos toda a estrutura física dos dados, ou seja, vamos trazer os dados como estão com todas as métricas estatísticas também.

Aqui está outro problema. Se você usar uma solução em nuvem, apenas dumps lógicos estarão disponíveis lá, porque o Google, a Amazon não permitem que você faça uma cópia física. Haverá um problema.

Obrigado pelo relatório. Houve duas boas perguntas aqui sobre MySQL e compartilhamento de recursos. Mas, na verdade, tudo se resume ao fato de que este não é um tópico de um DBMS específico, mas do sistema de arquivos como um todo. E, consequentemente, as questões de compartilhamento de recursos também devem ser resolvidas a partir daí, não no final que seja Postgres, mas no sistema de arquivos, no servidor, por exemplo.

A minha pergunta é um pouco diferente. Está mais próximo do banco de dados multicamadas, onde existem várias camadas. Por exemplo, configuramos uma atualização de imagem de dez terabytes, estamos replicando. E usamos especificamente esta solução para bancos de dados. A replicação está em andamento, os dados estão sendo atualizados. São 100 funcionários trabalhando em paralelo, que estão constantemente lançando esses tiros diferentes. O que fazer? Como ter certeza de que não há conflito, que eles lançaram um e, em seguida, o sistema de arquivos mudou e essas fotos desapareceram?

Eles não irão porque é assim que o ZFS funciona. Podemos manter separadamente em um thread as alterações do sistema de arquivos que ocorrem devido à replicação. E mantenha os clones que os desenvolvedores usam em versões mais antigas dos dados. E funciona para nós, está tudo em ordem com isso.

Acontece que a atualização ocorrerá como uma camada adicional, e todas as novas fotos já irão, com base nessa camada, certo?

De camadas anteriores que eram de replicações anteriores.

As camadas anteriores vão cair, mas vão se referir à camada antiga, e vão tirar novas imagens da última camada que foi recebida na atualização?

Em geral sim.

Então como consequência teremos até um figo de camadas. E com o tempo eles precisarão ser compactados?

Sim está tudo correto. Há alguma janela. Mantemos instantâneos semanais. Depende do recurso que você tem. Se você tiver a capacidade de armazenar muitos dados, poderá armazenar instantâneos por um longo período. Eles não vão embora por conta própria. Não haverá corrupção de dados. Se os instantâneos estiverem desatualizados, como nos parece, ou seja, depende da política da empresa, podemos simplesmente excluí-los e liberar espaço.

Olá, obrigado pelo relato! Pergunta sobre Joe. Você disse que o cliente não queria dar acesso aos dados para todos. Estritamente falando, se uma pessoa tem o resultado da Análise Explicativa, ela pode espiar os dados.

É assim. Por exemplo, podemos escrever: "SELECT FROM WHERE email = to that". Ou seja, não veremos os dados em si, mas podemos ver alguns sinais indiretos. Isso deve ser entendido. Mas, por outro lado, está tudo lá. Temos uma auditoria de log, temos controle de outros colegas que também veem o que os desenvolvedores estão fazendo. E se alguém tentar fazer isso, o serviço de segurança irá até eles e trabalhará nessa questão.

Boa tarde Obrigado pelo relatório! Eu tenho uma pergunta curta. Se a empresa não usa o Slack, há alguma vinculação a ele agora ou é possível que os desenvolvedores implantem instâncias para conectar um aplicativo de teste aos bancos de dados?

Agora existe um link para o Slack, ou seja, não há outro mensageiro, mas eu realmente quero dar suporte para outros mensageiros também. O que você pode fazer? Você pode implantar o DB Lab sem Joe, ir com a ajuda da API REST ou com a ajuda da nossa plataforma e criar clones e conectar com o PSQL. Mas isso pode ser feito se você estiver pronto para dar aos seus desenvolvedores acesso aos dados, porque não haverá mais nenhuma tela.

Não preciso dessa camada, mas preciso dessa oportunidade.

Aí sim pode ser feito.

Fonte: habr.com