DBA bot Joe. Anatoly Stansler (Postgres.ai)

Como entende un desenvolvedor de backend que unha consulta SQL funcionará ben nun "prod"? Nas empresas grandes ou en rápido crecemento, non todos teñen acceso ao "produto". E co acceso, non todas as solicitudes se poden comprobar sen dor, e a creación dunha copia da base de datos adoita levar horas. Para resolver estes problemas, creamos un DBA artificial - Joe. Xa se implantou con éxito en varias empresas e axuda a máis dunha ducia de desenvolvedores.

Vídeo:

Ola a todos! Chámome Anatoly Stansler. Traballo para unha empresa postgres.ai. Comprometémonos a acelerar o proceso de desenvolvemento eliminando os atrasos asociados ao traballo de Postgres dos desenvolvedores, DBA e QA.

Temos grandes clientes e hoxe parte do informe dedicarase aos casos que coñecemos mentres traballamos con eles. Vou falar de como lles axudamos a resolver problemas bastante serios.

Cando estamos desenvolvendo e realizando migracións complexas de alta carga, facémonos a pregunta: "Esta migración despegará?". Usamos a revisión, usamos o coñecemento de colegas máis experimentados, expertos en DBA. E poden dicir se voará ou non.

Pero quizais sería mellor que puidésemos probalo nós mesmos en copias a tamaño completo. E hoxe só falaremos de cales son os enfoques das probas agora e de como se pode facer mellor e con que ferramentas. Tamén falaremos dos pros e contras deste tipo de enfoques e do que podemos solucionar aquí.

Quen fixo índices directamente en prod ou fixo algún cambio? Un pouco de. E para quen levou isto a que se perderan datos ou houbese tempo de inactividade? Entón sabes esta dor. Grazas a Deus hai copias de seguridade.

O primeiro enfoque é probar en prod. Ou, cando un desenvolvedor está sentado nunha máquina local, ten datos de proba, hai algún tipo de selección limitada. E lanzamos para impulsar, e conseguimos esta situación.

Doe, é caro. Probablemente sexa mellor non facelo.

E cal é a mellor forma de facelo?

Tomemos a posta en escena e seleccionemos algunha parte do produto alí. Ou, no mellor dos casos, tomemos un auténtico prod, todos os datos. E despois de que o desenvolvamos localmente, comprobaremos ademais a posta en escena.

Isto permitiranos eliminar algúns dos erros, é dicir, evitar que estean en produción.

Cales son os problemas?

• O problema é que compartimos esta posta en escena cos compañeiros. E moitas veces ocorre que fas algún tipo de cambio, bam - e non hai datos, o traballo está polo sumidoiro. A posta en escena foi de varios terabytes. E hai que esperar moito para que volva a subir. E decidimos finalizalo mañá. Iso é todo, temos un desenvolvemento.
• E, por suposto, temos moitos compañeiros traballando alí, moitos equipos. E hai que facelo manualmente. E isto é un inconveniente.

E vale a pena dicir que só temos un intento, un tiro, se queremos facer algúns cambios na base de datos, tocar os datos, cambiar a estrutura. E se algo saíu mal, se houbo un erro na migración, non regresaremos rapidamente.

Este é mellor que o enfoque anterior, pero aínda hai unha alta probabilidade de que algún tipo de erro vaia á produción.

Que nos impide dar a cada programador un banco de probas, unha copia a tamaño completo? Creo que está claro o que se interpón.

Quen ten unha base de datos máis grande que un terabyte? Máis da metade da habitación.

E está claro que manter máquinas para cada desenvolvedor, cando hai unha produción tan grande, é moi caro e, ademais, leva moito tempo.

Temos clientes que se decataron de que é moi importante probar todos os cambios en copias a tamaño completo, pero a súa base de datos é inferior a un terabyte e non hai recursos para manter un banco de probas para cada desenvolvedor. Polo tanto, teñen que descargar os vertedoiros localmente na súa máquina e probalos deste xeito. Leva moito tempo.

Aínda que o fagas dentro da infraestrutura, descargar un terabyte de datos por hora xa é moi bo. Pero usan volcados lóxicos, descargan localmente da nube. Para eles, a velocidade é duns 200 gigabytes por hora. E aínda leva tempo dar a volta ao vertedoiro lóxico, enrolar os índices, etc.

Pero usan este enfoque porque lles permite manter o produto fiable.

Que podemos facer aquí? Imos facer que os bancos de probas sexan baratos e proporcionemos a cada programador o seu propio banco de probas.

E isto é posible.

E neste enfoque, cando facemos clons finos para cada desenvolvedor, podemos compartilo nunha máquina. Por exemplo, se tes unha base de datos de 10 TB e queres darlla a 10 desenvolvedores, non necesitas ter bases de datos de XNUMX x XNUMX TB. Só necesitas unha máquina para facer copias finas illadas para cada desenvolvedor usando unha máquina. Xa vos contarei como funciona un pouco máis tarde.

Exemplo real:

• DB - 4,5 terabytes.

• Podemos conseguir copias independentes en 30 segundos.

Non tes que esperar a un banco de probas e dependes do grande que sexa. Podes obtelo en segundos. Serán contornas completamente illadas, pero que comparten datos entre si.

Isto é xenial. Aquí estamos a falar de maxia e dun universo paralelo.

No noso caso, isto funciona usando o sistema OpenZFS.

OpenZFS é un sistema de ficheiros de copia en escritura que admite instantáneas e clons fóra da caixa. É fiable e escalable. Ela é moi fácil de xestionar. Pódese, literalmente, despregarse en dous equipos.

Hai outras opcións:

• lvm,

• Almacenamento (por exemplo, Pure Storage).

O Database Lab do que falo é modular. Pódese implementar usando estas opcións. Pero polo de agora, centrámonos en OpenZFS, porque houbo problemas específicamente con LVM.

Cómo funciona? En lugar de sobrescribir os datos cada vez que os cambiamos, gardámolos simplemente marcando que estes novos datos son dun novo punto no tempo, unha nova instantánea.

E no futuro, cando queremos retroceder ou queremos facer un novo clon desde algunha versión máis antiga, só dicimos: "OK, dános estes bloques de datos que están marcados así".

E este usuario traballará con tal conxunto de datos. Vainos cambiando aos poucos, facendo as súas propias instantáneas.

E ramificaremos. Cada desenvolvedor no noso caso terá a oportunidade de ter o seu propio clon que edite, e os datos que se compartan compartiranse entre todos.

Para implementar un sistema deste tipo na casa, cómpre resolver dous problemas:

• O primeiro é a fonte dos datos, de onde os tomará. Podes configurar a replicación coa produción. Xa podes usar as copias de seguridade que configuraches, espero. WAL-E, WAL-G ou Barman. E aínda que esteas a usar algún tipo de solución de nube como RDS ou Cloud SQL, podes usar volcados lóxicos. Pero aínda así aconsellamos que uses copias de seguridade, porque con este enfoque tamén conservarás a estrutura física dos ficheiros, o que che permitirá estar aínda máis preto das métricas que verías en produción para detectar aqueles problemas que existen.

• O segundo é onde queres aloxar o Laboratorio de bases de datos. Podería ser Cloud, podería ser On-premise. É importante dicir aquí que ZFS admite a compresión de datos. E faino bastante ben.

Imaxina que para cada clon deste tipo, dependendo das operacións que fagamos coa base, crecerá algún tipo de dev. Para iso, o dev tamén necesitará espazo. Pero debido ao feito de que tomamos unha base de 4,5 terabytes, ZFS comprimirao a 3,5 terabytes. Isto pode variar dependendo da configuración. E aínda temos espazo para dev.

Este sistema pódese utilizar para diferentes casos.

• Estes son desenvolvedores, DBA para validación de consultas, para optimización.

• Pódese usar nas probas de control de calidade para probar unha migración en particular antes de implementala para producir. E tamén podemos crear ambientes especiais para o control de calidade con datos reais, onde poidan probar novas funcionalidades. E levará segundos en lugar de horas de espera, e quizais días nalgúns outros casos nos que non se utilicen copias finas.

• E outro caso. Se a empresa non ten un sistema de análise configurado, podemos illar un clon fino da base de produtos e darlle consultas longas ou índices especiais que se poden usar en análises.

Con este enfoque:

1. Baixa probabilidade de erros no "prod", porque probamos todos os cambios en datos de tamaño completo.

2. Temos unha cultura de probas, porque agora non tes que esperar horas para o teu propio stand.

3. E non hai barreira, nin espera entre probas. Podes ir e comprobar. E será mellor deste xeito a medida que aceleremos o desenvolvemento.

• Haberá menos refactorización. Menos erros acabarán en prod. Refacturarémolos menos despois.

• Podemos reverter os cambios irreversibles. Este non é o enfoque estándar.

1. Isto é beneficioso porque compartimos os recursos dos bancos de probas.

Xa está ben, pero que máis se podería acelerar?

Grazas a este sistema, podemos reducir moito o limiar para entrar en tales probas.

Agora hai un círculo vicioso, cando un desenvolvedor, para acceder a datos reais de tamaño completo, debe converterse nun experto. Débese confiar en ese acceso.

Pero como crecer se non está alí. Pero e se só tes un conxunto moi pequeno de datos de proba dispoñible para ti? Entón non terás ningunha experiencia real.

Como saír deste círculo? Como primeira interface, conveniente para desenvolvedores de calquera nivel, escollemos o bot Slack. Pero pode ser calquera outra interface.

Que che permite facer? Podes realizar unha consulta específica e enviala a unha canle especial para a base de datos. Implementaremos automaticamente un clon fino en segundos. Imos executar esta solicitude. Recollemos métricas e recomendacións. Imos mostrar unha visualización. E entón este clon permanecerá para que esta consulta poida optimizarse dalgún xeito, engadir índices, etc.

E tamén Slack ofrécenos oportunidades de colaboración fóra da caixa. Dado que esta é só unha canle, podes comezar a discutir esta solicitude alí mesmo no fío para dita solicitude, facer ping aos teus colegas, DBA que están dentro da empresa.

Pero hai, por suposto, problemas. Debido a que este é o mundo real e estamos a usar un servidor que alberga moitos clons á vez, temos que comprimir a cantidade de memoria e potencia da CPU dispoñibles para os clons.

Pero para que estas probas sexan plausibles, cómpre resolver este problema dalgún xeito.

Está claro que o importante son os mesmos datos. Pero xa o temos. E queremos conseguir a mesma configuración. E podemos dar unha configuración case idéntica.

Sería xenial ter o mesmo hardware que en produción, pero pode ser diferente.

Lembremos como funciona Postgres coa memoria. Temos dous cachés. Un do sistema de ficheiros e outro nativo de Postgres, é dicir, caché de búfer compartido.

É importante ter en conta que a caché do búfer compartido atribúese cando se inicia Postgres, dependendo do tamaño que especifique na configuración.

E a segunda caché usa todo o espazo dispoñible.

E cando facemos varios clons nunha máquina, resulta que pouco a pouco imos enchendo a memoria. E, en boa forma, a caché do búfer compartido é o 25% da cantidade total de memoria dispoñible na máquina.

E resulta que se non cambiamos este parámetro, só poderemos executar 4 instancias nunha máquina, é dicir, 4 de todos eses clons finos. E isto, por suposto, é malo, porque queremos ter moito máis deles.

Pero, por outra banda, Buffer Cache utilízase para executar consultas de índices, é dicir, o plan depende do tamaño dos nosos cachés. E se tomamos este parámetro e o reducimos, os nosos plans poden cambiar moito.

Por exemplo, se temos unha caché grande en prod, entón Postgres preferirá usar un índice. E se non, entón haberá SeqScan. E que sentido tería se os nosos plans non coincidisen?

Pero aquí chegamos á conclusión de que, de feito, o plan en Postgres non depende do tamaño específico especificado no búfer compartido do plan, depende do effective_cache_size.

Effective_cache_size é a cantidade estimada de caché que temos dispoñible, é dicir, a suma da caché do buffer e do sistema de ficheiros. Isto é establecido pola configuración. E esta memoria non está asignada.

E debido a este parámetro, podemos enganar a Postgres, dicindo que en realidade temos moitos datos dispoñibles, aínda que non teñamos estes datos. E así, os plans coincidirán completamente coa produción.

Pero isto pode afectar o tempo. E optimizamos as consultas segundo o tempo, pero é importante que o tempo dependa de moitos factores:

• Depende da carga que estea actualmente no produto.

• Depende das características da propia máquina.

E este é un parámetro indirecto, pero de feito podemos optimizar exactamente pola cantidade de datos que lerá esta consulta para obter o resultado.

E se queres que o momento se aproxime ao que veremos en prod, entón necesitamos tomar o hardware máis semellante e, posiblemente, aínda máis para que todos os clons encaixan. Pero isto é un compromiso, é dicir, obterás os mesmos plans, verás cantos datos lerá unha determinada consulta e poderás concluír se esta consulta é boa (ou migración) ou mala, aínda debe optimizarse. .

Vexamos como Joe está especialmente optimizado.

Tomemos unha solicitude dun sistema real. Neste caso, a base de datos é de 1 terabyte. E queremos contar o número de publicacións novas que tiveron máis de 10 Gústame.

Estamos escribindo unha mensaxe á canle, despregouse un clon para nós. E veremos que tal solicitude completarase en 2,5 minutos. Isto é o primeiro que notamos.

B Joe amosarache recomendacións automáticas baseadas no plan e as métricas.

Veremos que a consulta procesa demasiados datos para obter un número relativamente pequeno de filas. E é necesario algún tipo de índice especializado, xa que observamos que hai demasiadas filas filtradas na consulta.

Vexamos máis de cerca o que pasou. De feito, vemos que lemos case un gigabyte e medio de datos da caché de ficheiros ou mesmo do disco. E isto non é bo, porque só temos 142 liñas.

E, ao parecer, temos unha exploración de índice aquí e debería ter funcionado rapidamente, pero como filtramos demasiadas liñas (tivemos que contalas), a solicitude funcionou lentamente.

E isto ocorreu no plan debido ao feito de que as condicións da consulta e as condicións do índice non coinciden parcialmente.

Imos tentar facer o índice máis preciso e ver como cambia a execución da consulta despois diso.

A creación do índice levou bastante tempo, pero agora comprobamos a consulta e vemos que o tempo en lugar de 2,5 minutos é de só 156 milisegundos, o que é o suficientemente bo. E só lemos 6 megabytes de datos.

E agora usamos o escaneo de índice só.

Outra historia importante é que queremos presentar o plan dun xeito máis comprensible. Implementamos a visualización mediante Flame Graphs.

Esta é unha petición diferente, máis intensa. E construímos Flame Graphs segundo dous parámetros: esta é a cantidade de datos que un determinado nodo contou no plan e no tempo, é dicir, o tempo de execución do nodo.

Aquí podemos comparar nodos específicos entre si. E quedará claro cal deles leva máis ou menos, o que normalmente é difícil de facer noutros métodos de renderizado.

Por suposto, todo o mundo coñece explica.depesz.com. Unha boa característica desta visualización é que gardamos o plan de texto e tamén poñemos algúns parámetros básicos nunha táboa para poder ordenar.

E os desenvolvedores que aínda non afondaron neste tema tamén usan explic.depesz.com, porque é máis fácil descubrir que métricas son importantes e cales non.

Hai un novo enfoque para a visualización: isto é explic.dalibo.com. Fan unha visualización en árbore, pero é moi difícil comparar os nós entre si. Aquí podes comprender ben a estrutura, non obstante, se hai unha solicitude grande, terás que desprazarte cara atrás e cara atrás, pero tamén unha opción.

colaboración

E, como dixen, Slack dános a oportunidade de colaborar. Por exemplo, se atopamos unha consulta complexa que non ten claro como optimizar, podemos aclarar este problema cos nosos compañeiros nun fío de conversa en Slack.

Parécenos que é importante probar con datos de tamaño completo. Para iso, fixemos a ferramenta Update Database Lab, que está dispoñible en código aberto. Tamén podes usar o bot Joe. Podes levala agora mesmo e implementala no teu lugar. Todas as guías están dispoñibles alí.

Tamén é importante ter en conta que a solución en si non é revolucionaria, porque existe Delphix, pero é unha solución empresarial. Está totalmente pechado, é moi caro. Estamos especialmente especializados en Postgres. Estes son todos produtos de código aberto. Únete a nós!

Aquí é onde remato. Grazas!

preguntas

Ola! Grazas polo informe! Moi interesante, sobre todo para min, porque resolvín o mesmo problema hai tempo. E por iso teño unha serie de preguntas. Espero conseguir polo menos unha parte.

Pregúntome como calculas o lugar para este ambiente? A tecnoloxía significa que, en determinadas circunstancias, os teus clons poden crecer ata o máximo tamaño. En liñas xerais, se tes unha base de datos de dez terabytes e 10 clons, é fácil simular unha situación na que cada clon pesa 10 datos únicos. Como calculas este lugar, é dicir, ese delta do que falaches, no que vivirán estes clons?

Boa pregunta. É importante facer un seguimento de clons específicos aquí. E se un clon ten un cambio demasiado grande, comeza a crecer, entón podemos primeiro emitir un aviso ao usuario sobre iso ou deter este clon inmediatamente para que non teñamos unha situación de fallo.

Si, teño unha pregunta aniñada. É dicir, como se garante o ciclo de vida destes módulos? Temos este problema e unha historia por separado. Como ocorre isto?

Hai algún ttl para cada clon. Basicamente, temos un ttl fixo.

Que, se non un segredo?

1 hora, é dicir, inactivo - 1 hora. Se non se usa, pegámolo. Pero non hai ningunha sorpresa aquí, xa que podemos aumentar o clon en segundos. E se o necesitas de novo, por favor.

Tamén me interesa a elección das tecnoloxías, porque, por exemplo, utilizamos varios métodos en paralelo por unha ou outra razón. Por que ZFS? Por que non usaches LVM? Mencionaches que houbo problemas con LVM. Cales foron os problemas? Na miña opinión, a opción máis óptima é co almacenamento, en canto ao rendemento.

Cal é o principal problema con ZFS? O feito de que tes que executar no mesmo host, é dicir, todas as instancias vivirán no mesmo sistema operativo. E no caso do almacenamento, pódese conectar diferentes equipos. E o pescozo de botella son só aqueles bloques que están no sistema de almacenamento. E a cuestión da elección das tecnoloxías é interesante. Por que non LVM?

En concreto, podemos falar de LVM na reunión. Sobre o almacenamento: é caro. Podemos implementar o sistema ZFS en calquera lugar. Podes implementalo na túa máquina. Podes simplemente descargar o repositorio e implementalo. ZFS está instalado case en todas partes se estamos a falar de Linux. É dicir, obtemos unha solución moi flexible. E fóra da caixa, ZFS dá moito. Podes cargar tantos datos como queiras, conectar un gran número de discos, hai instantáneas. E, como dixen, é doado de administrar. É dicir, parece moi agradable de usar. Está probado, ten moitos anos. Ten unha comunidade moi grande que está en crecemento. ZFS é unha solución moi fiable.

Nikolai Samokhvalov: Podo comentar máis? Chámome Nikolay, traballamos xunto con Anatoly. Estou de acordo en que o almacenamento é xenial. E algúns dos nosos clientes teñen Pure Storage, etc.

Anatoly observou correctamente que estamos enfocados na modularidade. E no futuro, pode implementar unha interface: facer unha instantánea, facer un clon, destruír o clon. É todo doado. E o almacenamento é xenial, se o é.

Pero ZFS está dispoñible para todos. DelPhix xa é suficiente, teñen 300 clientes. Deles, Fortune 100 ten 50 clientes, é dicir, están dirixidos á NASA, etc. É hora de que todos se fagan con esta tecnoloxía. E por iso temos un Core de código aberto. Temos unha parte da interface que non é de código aberto. Esta é a plataforma que mostraremos. Pero queremos que sexa accesible para todos. Queremos facer unha revolución para que todos os probadores deixen de adiviñar nos portátiles. Temos que escribir SELECT e inmediatamente ver que vai lento. Deixa de esperar a que o DBA che conte. Aquí está o obxectivo principal. E creo que todos chegaremos a isto. E facemos isto para que todos o teñan. Polo tanto, ZFS, porque estará dispoñible en todas partes. Grazas á comunidade por resolver problemas e por ter unha licenza de código aberto, etc.*

Saúdos! Grazas polo informe! Chámome Maxim. Nós tratamos os mesmos problemas. Decidiron pola súa conta. Como compartes recursos entre estes clons? Cada clon pode facer o seu propio en calquera momento: un proba unha cousa, outra outra, alguén constrúe un índice, alguén ten un traballo pesado. E se aínda podes dividir por CPU, entón por IO, como divides? Esta é a primeira pregunta.

E a segunda cuestión é sobre a disemellanza das bancadas. Digamos que teño ZFS aquí e todo está xenial, pero o cliente en prod non ten ZFS, senón ext4, por exemplo. Como neste caso?

As preguntas son moi boas. Mencionei un pouco este problema co feito de que compartimos recursos. E a solución é esta. Imaxina que estás probando na posta en escena. Tamén podes ter unha situación así ao mesmo tempo que alguén dá unha carga, outra persoa. E como resultado, ves métricas que son incomprensibles. Incluso o mesmo problema pode ser con prod. Cando queres comprobar algunha solicitude e ves que hai algún problema con ela, funciona lentamente, entón o problema non estaba na solicitude, senón no feito de que hai algún tipo de carga paralela.

E polo tanto, é importante aquí centrarnos en cal será o plan, que pasos daremos no plan e cantos datos recolleremos para iso. O feito de que os nosos discos, por exemplo, se carguen con algo, afectará especificamente ao tempo. Pero podemos estimar o que está cargada esta solicitude pola cantidade de datos. Non é tan importante que ao mesmo tempo haxa algún tipo de execución.

Teño dúas preguntas. Isto é cousas moi chulas. Houbo casos nos que os datos de produción son críticos, como os números de tarxeta de crédito? Xa hai algo preparado ou é unha tarefa aparte? E a segunda pregunta: hai algo así para MySQL?

Sobre os datos. Faremos ofuscación ata que o fagamos. Pero se implementas exactamente Joe, se non dás acceso aos desenvolvedores, entón non hai acceso aos datos. Por que? Porque Joe non mostra datos. Só mostra métricas, plans e xa está. Isto fíxose a propósito, porque este é un dos requisitos do noso cliente. Querían poder optimizar sen dar acceso a todos.

Acerca de MySQL. Este sistema pódese usar para calquera cousa que almacene o estado no disco. E xa que estamos facendo Postgres, agora estamos facendo toda a automatización de Postgres primeiro. Queremos automatizar a obtención de datos dunha copia de seguridade. Estamos configurando Postgres correctamente. Sabemos facer coincidir plans, etc.

Pero como o sistema é extensible, tamén se pode usar para MySQL. E hai exemplos deste tipo. Yandex ten algo semellante, pero non o publican en ningures. Utilízano dentro de Yandex.Metrica. E só hai unha historia sobre MySQL. Pero as tecnoloxías son as mesmas, ZFS.

Grazas polo informe! Tamén teño un par de preguntas. Mencionaches que a clonación pode usarse para realizar análises, por exemplo, para construír alí índices adicionais. Podes contar un pouco máis sobre como funciona?

E farei inmediatamente a segunda pregunta sobre a semellanza das bancadas, a semellanza dos planos. O plan tamén depende das estatísticas recollidas por Postgres. Como solucionas este problema?

Segundo as analíticas, non hai casos concretos, porque aínda non o utilizamos, pero existe esa oportunidade. Se estamos a falar de índices, imaxina que unha consulta persegue unha táboa con centos de millóns de rexistros e unha columna que normalmente non está indexada en prod. E queremos calcular algúns datos alí. Se esta solicitude se envía a prod, existe a posibilidade de que sexa sinxela en prod, porque a solicitude procesarase alí durante un minuto.

Ok, imos facer un clon fino que non é terrible parar durante uns minutos. E para que sexa máis cómodo a lectura das analíticas, engadiremos índices para aquelas columnas nas que nos interesen os datos.

O índice crearase cada vez?

Podes facelo para que toquemos os datos, fagamos instantáneas, despois recuperaremos esta instantánea e impulsaremos novas solicitudes. É dicir, podes facelo para que poidas crear novos clons con índices xa fixados.

En canto á pregunta sobre as estatísticas, se restauramos desde unha copia de seguridade, se facemos a replicación, entón as nosas estatísticas serán exactamente as mesmas. Porque temos toda a estrutura física de datos, é dicir, tamén traeremos os datos tal e como están con todas as métricas estatísticas.

Aquí hai outro problema. Se usas unha solución na nube, só están dispoñibles os volcados lóxicos, porque Google, Amazon non che permiten facer unha copia física. Haberá un problema.

Grazas polo informe. Había dúas boas preguntas aquí sobre MySQL e compartir recursos. Pero, de feito, todo se reduce ao feito de que este non é un tema de DBMS específico, senón do sistema de ficheiros no seu conxunto. E, en consecuencia, os problemas de compartir recursos tamén deberían resolverse a partir de aí, non ao final de que é Postgres, senón no sistema de ficheiros, no servidor, por exemplo.

A miña pregunta é un pouco diferente. Está máis preto da base de datos de varias capas, onde hai varias capas. Por exemplo, configuramos unha actualización de imaxe de dez terabytes, estamos a replicar. E usamos esta solución específicamente para bases de datos. A replicación está en curso, os datos estanse actualizando. Aquí traballan en paralelo 100 empregados, que están constantemente a lanzar estas diferentes tomas. Que facer? Como asegurarse de que non hai ningún conflito, de que lanzaron un e despois cambiou o sistema de ficheiros e que todas estas imaxes saíron?

Non irán porque así funciona ZFS. Podemos manter por separado nun fío os cambios no sistema de ficheiros que se producen debido á replicación. E mantén os clons que usan os desenvolvedores en versións antigas dos datos. E funciona para nós, todo está en orde con isto.

Acontece que a actualización terá lugar como unha capa adicional, e todas as novas imaxes xa irán, baseándose nesta capa, non?

De capas anteriores que eran de réplicas anteriores.

As capas anteriores caerán, pero referiranse á capa antiga e tomarán novas imaxes da última capa que se recibiu na actualización?

En xeral, si.

Logo como consecuencia teremos ata un figo de capas. E co tempo terán que ser comprimidos?

Si todo é correcto. Hai algunha fiestra. Mantemos instantáneas semanais. Depende do recurso que teñas. Se tes a capacidade de almacenar moitos datos, podes almacenar instantáneas durante moito tempo. Non irán por si sós. Non haberá corrupción de datos. Se as instantáneas están desactualizadas, como nos parece, é dicir, depende da política da empresa, entón podemos simplemente eliminalas e liberar espazo.

Ola, grazas polo informe! Pregunta sobre Joe. Vostede dixo que o cliente non quería dar acceso a todos os datos. En rigor, se unha persoa ten o resultado de Explicar Analizar, entón pode mirar os datos.

É así. Por exemplo, podemos escribir: "SELECT FROM WHERE correo electrónico = a ese". É dicir, non veremos os datos en si, pero podemos ver algúns sinais indirectos. Isto hai que entendelo. Pero, por outra banda, está todo aí. Temos unha auditoría de rexistro, temos o control doutros compañeiros que tamén ven o que están a facer os desenvolvedores. E se alguén intenta facelo, o servizo de seguridade acudirá a eles e traballará neste problema.

Boas tardes Grazas polo informe! Teño unha pequena pregunta. Se a empresa non usa Slack, hai algunha vinculación agora ou é posible que os desenvolvedores despreguen instancias para conectar unha aplicación de proba ás bases de datos?

Agora hai unha ligazón a Slack, é dicir, non hai outro mensaxeiro, pero tamén quero facer soporte para outros mensaxeiros. Que podes facer? Podes implementar DB Lab sen Joe, ir coa axuda da API REST ou coa axuda da nosa plataforma e crear clons e conectarte con PSQL. Pero isto pódese facer se estás preparado para dar acceso aos datos aos teus desenvolvedores, porque xa non haberá pantalla.

Non necesito esta capa, pero necesito esa oportunidade.

Entón si, pódese facer.

Fonte: www.habr.com