Algún día nun futuro distante, a eliminación automática de datos innecesarios será unha das tarefas importantes dun DBMS [1]. Mentres tanto, nós mesmos debemos encargarnos de eliminar ou mover os datos innecesarios a sistemas de almacenamento menos custosos. Digamos que decides eliminar varios millóns de filas. Unha tarefa bastante sinxela, especialmente se se coñece a condición e hai un índice axeitado. "DELETE FROM table1 WHERE col1 = :value" - que podería ser máis sinxelo, non?
Vídeo:
-
Estou no comité do programa Highload desde o primeiro ano, é dicir, desde 2007.
-
E estou con Postgres desde 2005. Utilizouno en moitos proxectos.
-
O grupo tamén está con RuPostges desde 2007.
-
Chegamos a máis de 2100 participantes en Meetup. Este é o segundo lugar do mundo despois de Nova York, tras superar a San Francisco hai tempo.
-
Levo varios anos vivindo en California. Traballo principalmente con empresas estadounidenses, incluídas as grandes. Son usuarios activos de Postgres. E alí xorden todo tipo de cousas interesantes.
- Esta é a miña empresa. Estamos no negocio de automatizar tarefas que eliminan as desaceleracións do desenvolvemento.
Se fas algo, ás veces hai algúns fallos en Postgres. Digamos que cómpre esperar ata que o administrador che proporcione un banco de probas ou ata que o DBA che responda. E atopamos estes colos de botella no proceso de desenvolvemento, probas e administración e tentamos eliminalos mediante a automatización e novos enfoques.
Recentemente estiven en VLDB en Los Ángeles. Esta é a maior conferencia de base de datos. E houbo un informe de que no futuro os DBMS non só almacenarán, senón que tamén eliminarán automaticamente os datos. Este é un tema novo.
Cada vez hai máis datos no mundo. Os zetabytes son 1 de petabytes. E agora xa se calcula que temos máis de 000 zettabytes de datos almacenados no mundo. E cada vez son máis.
E que facer con el? Está claro que hai que borralo. Aquí tedes unha ligazón a este interesante informe. Pero ata agora isto non se implementou no DBMS.
Os que saben contar cartos queren dúas cousas. Queren que o eliminemos, polo que tecnicamente temos que poder facelo.
O que vou contar a continuación é unha situación abstracta que inclúe unha morea de situacións reais, é dicir, unha certa recompilación do que realmente me pasou a min e ás bases de datos circundantes moitas veces, moitos anos. Os rastrillos están en todas partes e todos os pisan todo o tempo.
Digamos que temos unha ou varias bases que van medrando. E algúns dos rexistros son un lixo obvio. Por exemplo, o usuario comezou a facer algo alí, pero non terminou. E despois dun tempo sabemos que esta obra inacabada xa non se pode gardar. É dicir, gustaríanos limpar algunhas cousas lixo para aforrar espazo, mellorar o rendemento, etc.
En xeral, a tarefa é automatizar a eliminación de cousas específicas, liñas específicas nunha táboa.
E temos unha petición da que falaremos hoxe, é dicir, da retirada do lixo.
Pedímoslle a un programador experimentado que o fixese. Tomou esta solicitude, comprobouno el mesmo: todo funciona. Probeino na posta en escena: todo está ben. Estendeo - todo funciona. Unha vez ao día realizamos isto: todo está ben.
A base de datos está crecendo e medrando. O DELETE diario comeza a funcionar un pouco máis lento.
Entón decatámonos de que agora somos unha empresa de mercadotecnia e o tráfico será varias veces maior, polo que decidimos deter temporalmente as cousas innecesarias. E esquecémonos de devolvelo.
Uns meses despois acordáronse. E ese programador abandonou ou estaba ocupado con outra cousa, asignáronlle outro para que o devolvese.
Comprobou no desenvolvemento, na posta en escena: todo está ben. Por suposto, aínda debes limpar o acumulado. El comprobou, todo funciona.
Que pasa despois? Entón todo se nos desmorona. Baixa tanto que nalgún momento cae todo. Todo o mundo está en shock, ninguén entende o que está a pasar. E entón resulta que este DELETE foi o problema.
Algo saíu mal? Aquí tes unha lista de cousas que poden saír mal. Cal deles é o máis importante?
-
Por exemplo, non houbo revisión, é dicir, o experto DBA non mirou. Cun ollo experimentado, atoparía inmediatamente o problema e, ademais, ten acceso a prod, onde se acumularon varios millóns de liñas.
-
Quizais comprobaron algo mal.
-
Quizais o hardware estea desactualizado e necesites actualizar esta base de datos.
-
Ou algo está mal coa propia base de datos e necesitamos pasar de Postgres a MySQL.
-
Ou quizais hai algo mal na operación.
-
Quizais hai algúns erros na organización do traballo e necesites despedir a alguén e contratar mellores persoas?
Non houbo comprobación de DBA. Se houbese un DBA, vería estes millóns de liñas e aínda sen ningún experimento diría: "Non fan iso". Digamos que se este código estaba en GitLab, GitHub e houbese un proceso de revisión do código e non existise tal cousa que sen a aprobación do DBA esta operación tivese lugar en prod, entón obviamente o DBA diría: "Non podes facelo. ”
E diría que terás problemas co IO do disco e que todos os procesos se volverán tolos, pode haber bloqueos e tamén bloquearás o baleiro automático durante uns minutos, polo que isto non é bo.
O segundo erro é que comprobaron no lugar equivocado. Vimos despois do feito de que se acumularon moitos datos de lixo en prod, pero o desenvolvedor non tiña datos acumulados nesta base de datos e ninguén creou realmente este lixo na posta en escena. En consecuencia, houbo 1 liñas, que se completaron rapidamente.
Entendemos que as nosas probas son débiles, é dicir, o proceso que se constrúe non colle problemas. Non se realizou un experimento de DB adecuado.
Un experimento ideal debería realizarse preferentemente no mesmo equipo. Non sempre é posible facelo no mesmo hardware, pero é moi importante que sexa unha copia a tamaño completo da base de datos. Isto é o que levo predicando dende hai varios anos. E hai un ano que falei disto, podes velo todo en YouTube.
Quizais o noso equipo sexa malo? Se miras, a latencia saltou. Vimos que a reciclaxe era 100%. Por suposto, se estas fosen unidades NVMe modernas, probablemente sería moito máis fácil para nós. E quizais non nos deitaríamos por iso.
Se tes nubes, a actualización é sinxela. Lanzamos novas réplicas en hardware novo. Cambio. E todo está ben. Moi doado.
É posible tocar discos máis pequenos dalgún xeito? E aquí, coa axuda de DBA, mergullámonos nun determinado tema chamado axuste do punto de control. Resulta que non levamos a cabo a sintonización do punto de control.
Que é un punto de control? Isto está dispoñible en calquera DBMS. Cando os datos da túa memoria cambian, non se escriben inmediatamente nos discos. A información de que os datos cambiaron primeiro escríbese no rexistro de reenvío, no rexistro de escritura anticipada. E nalgún momento, o DBMS decide que é hora de botar as páxinas reais ao disco, de xeito que se temos un fallo, podemos facer menos REDO. É como un xoguete. Se nos matan, comezaremos o xogo dende o último punto de control. E todos os DBMS implementan isto.
A configuración de Postgres está atrasada. Están deseñados para volumes de datos e operacións de entre 10 e 15 anos. E o punto de control non é unha excepción.
Esta información é do noso informe con comprobación de Postgres, é dicir, comprobación automática de saúde. E aquí tes unha base de datos de varios terabytes. E está claro que os postos de control son obrigados en case o 90% dos casos.
Qué significa? Hai dúas opcións alí. O punto de control pode ocorrer no tempo de espera, por exemplo, en 10 minutos. Ou pode ocorrer cando se encheron bastantes datos.
E por defecto, max_wal_saze está configurado en 1 gigabyte. De feito, isto ocorre en Postgres despois de 300-400 megabytes. Cambiaches moitos datos e tes un punto de control.
E se ninguén o axustou, pero o servizo creceu e a empresa gaña moito diñeiro, ten moitas transaccións, entón o punto de control ocorre unha vez por minuto, ás veces unha vez cada 30 segundos, e ás veces incluso se superpoñen. . Isto é moi malo.
E temos que asegurarnos de que veña con menos frecuencia. É dicir, podemos aumentar max_wal_size. E atacará con menos frecuencia.
Pero desenvolvemos toda unha metodoloxía sobre como facelo de forma máis correcta, é dicir, como tomar decisións sobre a elección de opcións, claramente baseadas en datos específicos.
En consecuencia, realizamos dúas series de experimentos de base de datos.
Primeira serie: cambiamos max_wal_size. E levamos a cabo unha operación masiva. Primeiro facémolo coa configuración predeterminada de 1 gigabyte. E facemos unha eliminación masiva de moitos millóns de liñas.
Podes ver o difícil que nos é. Vemos que o disco IO é moi malo. A ver canto WAL xeramos, porque isto é moi importante. A ver cantas veces pasou o control. E vemos que non é bo.
A continuación aumentamos max_wal_size. Repetimos. Aumentar, repetir. E tantas veces. En principio, 10 puntos son bos, onde 1, 2, 4, 8 gigabytes. E observamos o comportamento dun sistema específico. Está claro que o equipo aquí debería ser como un produto. Debería ter os mesmos discos, a mesma cantidade de memoria e a mesma configuración de Postgres.
E deste xeito intercambiaremos o noso sistema, e sabemos como se comportará o DBMS en caso dunha mala masa DELETE, como será o punto de control.
Checkpoint en ruso significa puntos de control.
Exemplo: ELIMINA varios millóns de filas por índice, as filas están "esparcidas" por páxinas.
Aquí tes un exemplo. Esta é unha base. E coa configuración predeterminada de 1 gigabyte para max_wal_size, está moi claro que os nosos discos para gravar van ao estante. Esta imaxe é un síntoma típico dun paciente moi enfermo, é dicir, sentíase moi mal. E só houbo unha operación, aquí só había DELETE de varios millóns de liñas.
Se se permite tal operación en prod, simplemente caeremos, porque está claro que un DELETE nos mata no estante.
Ademais, onde hai 16 gigabytes, podes ver que os dentes xa comezaron a aparecer. Os dentes xa están mellores, é dicir, estamos a petar no teito, pero non tan mal. Alí apareceu un pouco de liberdade. Á dereita está a gravación. E o número de operacións é o segundo gráfico. E está claro que xa respiramos un pouco máis tranquilos con 16 gigabytes.
E onde son visibles 64 gigabytes, foi completamente mellor. Xa os dentes son claramente visibles, hai máis oportunidades de sobrevivir a outras operacións e facer algo co disco.
Por que isto?
Afondareime un pouco nos detalles, pero este tema de como levar a cabo a sintonización do punto de control pode dar lugar a un informe completo, polo que non entrarei en demasiados detalles, pero esbozarei un pouco cales son as dificultades que hai.
Se o punto de verificación ocorre con demasiada frecuencia e non actualizamos as nosas filas secuencialmente, senón que as atopamos por índice, o que é bo, porque non eliminamos toda a táboa, pode ocorrer que primeiro toquemos a primeira páxina, despois a milésima, e despois volveu ao primeiro . E se entre estas visitas á primeira páxina o punto de control xa o gardou no disco, entón gardarao de novo, porque o ensuciamos unha segunda vez.
E forzaremos o punto de control a salvalo moitas veces. Como se houbese operacións redundantes para iso.
Pero iso non é todo. En Postgres, as páxinas pesan 8 kilobytes e en Linux 4 kilobytes. E hai unha configuración full_page_writes. Está activado por defecto. E isto é correcto, porque se a desactivamos corre o perigo de que se hai un fallo só se garde a metade da páxina.
O comportamento da entrada no WAL do rexistro de reenvío é tal que cando temos un punto de control e cambiamos unha páxina por primeira vez, toda a páxina, é dicir, os 8 kilobytes, acaba no rexistro de reenvío, aínda que só cambiou unha liña que pesa 100 bytes . E vémonos obrigados a anotar toda a páxina.
Nos cambios posteriores só haberá unha tupla específica, pero por primeira vez anotamos todo.
E, en consecuencia, se o punto de control volve ocorrer, entón temos que comezar todo desde cero de novo e abarrotar toda a páxina. Con puntos de control frecuentes, cando percorremos as mesmas páxinas, full_page_writes = on será maior do que podería ser, é dicir, xeramos máis WAL. Envíase máis ás réplicas, ao arquivo, ao disco.
E, en consecuencia, temos dous despedimentos.
Se aumentamos max_wal_size, resulta que facilitamos o traballo tanto do punto de control como do escritor wal. E iso é xenial.
Imos instalar un terabyte e vivir con el. Que ten de malo? Isto é malo, porque en caso de falla levantaremos horas, porque o control era hai moito tempo e xa mudou moito. E hai que facer REDO por todo isto. E así estamos facendo unha segunda serie de experimentos.
Facemos a operación e vemos cando o punto de control está preto de completarse, facemos un kill -9 Postgres adrede.
E despois diso, comezamos de novo, e vemos canto tempo tardará en subir neste equipo, é dicir, canto REDO fará nesta mala situación.
Notarei dúas veces que a situación é mala. En primeiro lugar, caemos xusto antes do final do control, así que temos moito que perder. E en segundo lugar, tivemos unha operación masiva. E se os puntos de control tivesen un tempo de espera, o máis probable é que se xerase menos WAL desde o último punto de control. É dicir, este é un perdedor dúas veces.
Medimos esta situación para diferentes tamaños max_wal_size e entendemos que se max_wal_size é de 64 gigabytes, na situación do dobre peor, aumentaremos durante 10 minutos. E pensamos se isto nos convén ou non. Este é un problema empresarial. Debemos mostrar esta imaxe aos responsables das decisións empresariais e preguntarnos: “Cal é o tempo máximo que podemos esperar en caso de problema? Podemos deitarnos nunha situación peor durante 3-5 minutos?" E ti tomas unha decisión.
E aquí hai un punto interesante. Temos un par de reportaxes sobre Patroni na conferencia. E quizais o estés usando. Este é o fallo automático para Postgres. GitLab e Data Egret falaron sobre isto.
E se tes unha falla automática que ocorrerá en 30 segundos, quizais poidamos deitarnos 10 minutos? Porque a estas alturas cambiaremos á réplica, e todo estará ben. Este é un tema controvertido. Non sei unha resposta clara. Só creo que este tema non é só sobre a recuperación ante desastres.
Se temos unha longa recuperación dun fracaso, entón estaremos incómodos noutras moitas situacións. Por exemplo, nos mesmos experimentos, cando facemos algo e ás veces temos que esperar 10 minutos.
Aínda non iría demasiado lonxe, aínda que teñamos falla automática. Como regra xeral, valores como 64, 100 gigabytes son bos valores. Ás veces incluso paga a pena escoller menos. En xeral, esta é unha ciencia sutil.
Para iterar, por exemplo, max_wal_size = 1, 8, cómpre repetir a operación en masa moitas veces. Fixéchelo. E queres facelo de novo na mesma base, pero xa o eliminaches todo. Que facer?
Máis tarde falarei sobre a nosa solución e o que facemos para iterar en tales situacións. E este é o enfoque máis correcto.
Pero neste caso tivemos sorte. Se, como di aquí "BEGIN, DELETE, ROLLBACK", entón podemos repetir DELETE. É dicir, se o cancelamos nós mesmos, entón podemos repetilo. E fisicamente os teus datos estarán alí. Nin sequera che incha. Podes repetir sobre este tipo de DELETE.
Este DELETE con ROLLBACK é ideal para o axuste de puntos de control, aínda que non teñas un laboratorio de base de datos correctamente implantado.
Fixemos un cartel cunha columna "i". Postgres ten columnas de servizo. Son invisibles a non ser que o solicite expresamente. Estes son: ctid, xmid, xmax.
Ctid é o enderezo físico. Páxina cero, a primeira tupla da páxina.
Pódese ver que despois de ROOLBACK a tupla quedou no mesmo lugar. É dicir, podemos tentalo de novo, comportarase igual. Isto é o principal.
Xmax é o momento da morte da tupla. Introdúcese, pero Postgres sabe que esta transacción foi revertida, polo que non importa se é 0 ou unha transacción retrotraída. Isto suxire que DELETE pódese usar para iterar e probar operacións masivas do comportamento do sistema. Podes facer laboratorios de bases de datos para os pobres.
Trátase de programadores. Sobre DBA tamén, sempre regañan aos programadores por isto: "Por que estás facendo operacións tan longas e difíciles?" Este é un tema perpendicular completamente diferente. Antes había administración, pero agora haberá desenvolvemento.
Obviamente non o dividimos en partes. Está claro. É imposible romper un DELETE deste tipo por un montón de millóns de liñas en partes. Levará 20 minutos facelo, e todo quedará deitado. Pero, por desgraza, incluso os desenvolvedores experimentados cometen erros, mesmo en empresas moi grandes.
Por que é importante romper?
-
Se vemos que o disco é duro, imos diminuír a velocidade. E se estamos rotos, entón podemos engadir pausas, podemos ralentizar o estrangulamento.
-
E non bloquearemos outros por moito tempo. Nalgúns casos, non importa, se estás eliminando o lixo real no que ninguén está a traballar, é probable que non bloquees ninguén, excepto o traballo do baleiro automático porque esperará a que se complete a transacción. Pero se eliminas algo que outra persoa poida solicitar, bloquearase e producirase algún tipo de reacción en cadea. Deben evitarse transaccións longas en sitios web e aplicacións móbiles.
Isto é interesante. Moitas veces vexo que os desenvolvedores preguntan: "Que tamaño de paquete debo escoller?"
Está claro que canto maior sexa o tamaño do lote, menor será a sobrecarga da transacción, é dicir, unha sobrecarga adicional da transacción. Pero ao mesmo tempo, o tempo para esta transacción aumenta.
Teño unha regra moi sinxela: tomar o máximo posible, pero non exceder a execución por segundo.
Por que un segundo? A explicación é moi sinxela e comprensible para todos, incluso para persoas non técnicas. Vemos a reacción. Imos tomar 50 milisegundos. Se algo cambiou, o noso ollo reaccionará. Se é menos, é máis difícil. Se algo responde despois de 100 milisegundos, por exemplo, fai clic co rato e respondeu despois de 100 milisegundos, xa sentes este lixeiro atraso. Un segundo xa se percibe como un freo.
En consecuencia, se dividimos as nosas operacións masivas en ráfagas de 10 segundos, corremos o risco de bloquear a alguén. E funcionará durante uns segundos, e a xente xa o notará. Por iso prefiro non facelo máis dun segundo. Pero, ao mesmo tempo, non o desglose demasiado, porque a sobrecarga da transacción notarase. Será máis pesado para a base e poden xurdir outros problemas.
Seleccionamos o tamaño do paquete. En cada caso podemos facelo de forma diferente. Pódese automatizar. E estamos convencidos da eficacia de procesar un paquete. É dicir, facemos BORRAR un paquete ou ACTUALIZAR.
Por certo, todo o que che digo non é só sobre BORRAR. Como adiviñaches, estas son operacións masivas sobre datos.
E vemos que o plan é excelente. Podes ver o escaneo de índice, aínda mellor o escaneo só de índice. E temos unha pequena cantidade de datos implicados. E todo funciona en menos dun segundo. Super.
E aínda temos que asegurarnos de que non haxa degradación. Acontece que os primeiros lotes son rapidamente resoltos, e despois todo empeora e empeora. O proceso é tal que cómpre probar moito. Isto é exactamente para o que se necesitan os laboratorios de bases de datos.
E aínda temos que preparar algo para que nos permita controlar isto correctamente na produción. Por exemplo, podemos escribir a hora no rexistro, podemos escribir onde estamos agora e quen agora borramos. E isto permitiranos comprender máis adiante o que está a suceder. E se algo sae mal, atopa rapidamente o problema.
Se necesitamos comprobar a eficiencia das consultas e necesitamos repetir moitas veces, entón existe un bot compañeiro. Xa está listo. É usado por decenas de desenvolvedores todos os días. E pode proporcionar unha enorme base de datos de terabytes a petición en 30 segundos, a súa propia copia. E podes eliminar algo alí e dicir RESET e eliminalo de novo. Podes experimentar con el deste xeito. Vexo futuro nesta cousa. E xa o estamos facendo.
Cales son as estratexias de partición? Vexo 3 estratexias de partición diferentes que usan os desenvolvedores no paquete.
O primeiro é moi sinxelo. Temos un DNI numérico. E imos dividilo en diferentes intervalos e traballar con iso. A desvantaxe está clara. No primeiro segmento, podemos ter 100 liñas de lixo real, no segundo 5 liñas ou nada, ou as 1 liñas resultarán ser lixo. Traballo moi irregular, pero fácil de romper. Colleron a máxima identificación e esnaquizárono. Este é un enfoque inxenuo.
A segunda estratexia é un enfoque equilibrado. Úsase en Gitlab. Collemos e escaneamos a mesa. Atopamos os límites dos paquetes de identificación para que cada paquete contiña exactamente 10 rexistros. E meteronme nunha especie de cola. E procesamos máis. Podes facelo en varios fíos.
Na primeira estratexia, por certo, tamén podes facelo en varios fíos. Non é difícil.
Pero hai un enfoque máis fresco e óptimo. Esta é a terceira estratexia. E cando sexa posible, é mellor elixilo. Facemos isto en base a un índice especial. Neste caso, o máis probable é que sexa un índice baseado no noso estado de lixo e identificación. Incluiremos o ID para que sexa un único escaneo de índice para que non vaiamos ao montón.
Normalmente, a exploración de índice só é máis rápida que a exploración de índice.
E atopamos rapidamente os nosos ID que queremos eliminar. Seleccionamos BATCH_SIZE con antelación. E non só os recibimos, recibímolos dun xeito especial e inmediatamente os arranxamos. Pero pechámolas de tal xeito que, se xa están bloqueadas, non as pechamos, senón que seguimos e tomamos as seguintes. Isto é para o salto de actualización bloqueado. Esta súper función de Postgres permítenos traballar en varios fíos se queremos. Posiblemente nun fío. E despois está CTE: esta é unha solicitude. E temos a eliminación real no segundo andar deste CTE - returning *. Podes devolver a identificación, pero é mellor *, se tes poucos datos en cada liña.
Por que necesitamos isto? Necesitamos isto para informar. Agora borramos moitas liñas de feito. E os nosos límites por ID ou created_at son así. Podes facer min, max. Pódese facer outra cousa. Hai moitas cousas que podes meter aquí. E isto é moi cómodo para o seguimento.
Hai unha nota máis sobre o índice. Se decidimos que necesitamos un índice especial para esta tarefa en particular, entón debemos asegurarnos de que non estrague as actualizacións só de tuplas. É dicir, Postgres ten tales estatísticas. Isto pódese ver en pg_stat_user_tables para a túa táboa. Podes ver se se utilizan actualizacións quentes ou non.
Hai situacións nas que o teu novo índice pode simplemente cortalos. E todas as outras actualizacións que xa estean en execución diminuirán. Non só porque apareceu o índice (cada índice ralentiza un pouco as actualizacións, pero só un pouco), senón que aquí aínda desordenará as cousas. E é imposible facer unha optimización especial para esta táboa. Isto ocorre ás veces. Esta é unha sutileza que poucas persoas lembran. E é fácil pisar este anciño. Ás veces ocorre que cómpre atopar un enfoque desde o outro lado e aínda prescindir deste novo índice, ou facer outro índice ou facer outra cousa, por exemplo, pode usar o segundo método.
Pero esta é a estratexia máis óptima, como dividilo en lotes e disparar en lotes cunha solicitude, eliminar un pouco á vez, etc.
Transaccións longas -
Aspiración automática bloqueada
Problema de bloqueo
O erro número 5 é un gran. Nikolay de Okmeter falou sobre o seguimento de Postgres. Desafortunadamente, o seguimento perfecto de Postgres non existe. Algúns están máis preto, outros están máis lonxe. Okmeter está o suficientemente preto como para ser perfecto, pero falta moito e hai que engadir. Debes estar preparado para isto.
Por exemplo, é mellor controlar as tuplas mortas. Se tes moitas cousas mortas na túa mesa, algo está mal. É mellor reaccionar agora, se non pode haber degradación alí, e podemos deitarnos. Ocorre.
Se hai un IO grande, entón está claro que isto non é bo.
Transaccións longas tamén. Non se deben permitir transaccións longas en OLTP. E aquí tes unha ligazón ao fragmento, que che permite levar este fragmento e facer xa un seguimento de transaccións longas.
Por que as transaccións longas son malas? Porque todos os bloqueos só se liberarán ao final. E encerramos a todos. Ademais, bloqueamos o baleiro automático para todas as mesas. Isto non é bo en absoluto. Aínda que teñas activado o modo de espera en quente na réplica, isto aínda é malo. En xeral, é mellor evitar transaccións longas en calquera lugar.
Se temos moitas táboas que non se aspiran, entón necesitamos ter unha alerta. Tal situación é posible aquí. Podemos afectar indirectamente ao funcionamento do baleiro automático. Este é un fragmento de Avito, que mellorei un pouco. E resultou ser unha ferramenta interesante para ver o que temos co baleiro automático. Por exemplo, hai algunhas mesas esperando alí e non esperarán a súa quenda. Tamén hai que poñelo en vixilancia e ter unha alerta.
E emite bloques. Bosque de árbores de bloqueo. Gústame tomar algo de alguén e melloralo. Aquí tomei un CTE recursivo interesante de Data Egret, que mostra un bosque de árbores bloqueadas. Isto é bo para o diagnóstico. E o seguimento tamén se pode construír sobre a súa base. Pero isto debe facerse con coidado. Debes facer un pequeno statement_timeout por ti mesmo. E lock_timeout é desexable.
Ás veces, todos estes erros ocorren xuntos.
Na miña opinión, o erro máis importante aquí é o de organización. É organizativo, porque a tecnoloxía non funciona. Este é o número 2: comprobaron no lugar equivocado.
Non verificamos alí porque non tiñamos un clon de produción que fose fácil de comprobar. É posible que o programador non teña acceso á produción.
E comprobamos no lugar equivocado. Se o comprobaran alí, nós mesmos o veriamos. O desenvolvedor podería ver todo isto aínda sen un DBA, se o comprobou nun bo ambiente, onde haxa a mesma cantidade de datos e unha disposición idéntica. El tería visto toda esta degradación e teríase avergoñado.
Máis información sobre o baleiro do coche. Despois de facer unha limpeza masiva de varios millóns de liñas, aínda temos que facer un REPACK. Isto é especialmente importante para os índices. Sentiránse mal despois de que limpamos todo alí.
E se queres recuperar o traballo diario de desnudar, suxeriríao facelo con máis frecuencia, pero máis pequeno. Pode ser unha vez cada minuto ou aínda máis a miúdo un pouco. E hai que vixiar dúas cousas: que esta cousa non teña erros e que non se quede atrás. O truco que mostrei permitirache resolver isto.
O que facemos é código aberto. Isto está publicado en GitLab. E facémolo para que a xente poida comprobar incluso sen un DBA. Facemos un laboratorio de base de datos, é dicir, chamamos ao compoñente base no que Joe está a traballar actualmente. E podes coller unha copia da produción. Agora hai unha implementación de Joe para slack, podes dicir alí: "explica tal ou tal solicitude" e obtén inmediatamente o resultado da túa copia da base de datos. Incluso podes facer DELETE alí, e ninguén se decatará.
Digamos que tes 10 terabytes, estamos facendo un laboratorio de bases de datos tamén de 10 terabytes. E 10 desenvolvedores poden traballar simultaneamente con bases de datos simultáneas de 10 terabytes. Cada un pode facer o que queira. Pode eliminar, soltar, etc. Isto é fantástico. Disto falaremos mañá.
Isto chámase thin provisioning. Este é un aprovisionamento sutil. Este é algún tipo de fantasía que elimina moito os atrasos no desenvolvemento e probas e fai que o mundo sexa un lugar mellor neste sentido. É dicir, só permite evitar problemas coas operacións masivas.
Exemplo: base de datos de 5 terabytes, obtendo unha copia en menos de 30 segundos. E nin sequera depende do tamaño, é dicir, non importa cantos terabytes.
Hoxe podes ir e cavar nas nosas ferramentas. Podes rexistrarte e ver o que hai. Podes instalar este bot por ti mesmo. É gratuíto. Escribe.
preguntas
Moitas veces en situacións reais resulta que os datos que deberían permanecer na táboa son moito menores que os que hai que borrar. É dicir, en tal situación, moitas veces é máis fácil implementar este enfoque, cando é máis fácil crear un novo obxecto, copiar alí só os datos necesarios e transcribir a táboa antiga. Está claro que necesitas un enfoque de software para este momento mentres estás cambiando. Como é este enfoque?
Este é un enfoque moi bo e unha tarefa moi boa. É moi parecido ao que fai pg_repack, é moi parecido ao que tes que facer cando identificaches a xente que o fixo 4 bytes. Moitos marcos fixeron isto hai varios anos, e as placas acaban de crecer e deben converterse en 8 bytes.
Esta tarefa é bastante difícil. Fixémolo. E hai que ter moito coidado. Hai peches, etc. Pero está feito. É dicir, o enfoque estándar é usar pg_repack. Vostede anuncia tal sinal. E antes de comezar a enchelo con datos de instantáneas, tamén declaras unha táboa que rastrexa todos os cambios. Hai un truco que pode nin sequera rastrexar algúns cambios. Hai sutilezas. E despois cambias, aplicando os cambios. Haberá unha pequena pausa cando encerramos a todos, pero en xeral isto estase facendo.
Se miras pg_repack en GitHub, entón cando houbo unha tarefa para converter o ID de int 4 a int 8, entón houbo unha idea de usar o propio pg_repack. Isto tamén é posible, pero este é un método un pouco de hacker, pero tamén funcionará para iso. Podes intervir no disparador que usa pg_repack e dicir alí: "Non necesitamos estes datos", é dicir, transferimos só o que necesitamos. E entón só cambia e xa está.
Con este enfoque, tamén obtemos unha segunda copia da táboa, na que os datos xa están indexados e dispostos de xeito moi sinxelo con índices fermosos.
Inchar non, este é un bo enfoque. Pero sei que hai intentos de desenvolver a automatización para iso, é dicir, facer unha solución universal. Podo presentarche esta automatización. Está escrito en Python, cousas boas.
Son un pouco do mundo MySQL, así que vin para escoitar. E usamos este enfoque.
Pero é só se temos o 90%. Se temos un 5%, entón non é moi bo usalo.
Grazas polo informe! Se non hai recursos para facer unha copia completa de prod, hai algún algoritmo ou fórmula para calcular a carga ou o tamaño?
Boa pregunta. Ata agora somos capaces de atopar bases de datos de varios terabytes. Aínda que o hardware alí non sexa o mesmo, por exemplo, menos memoria, menos procesador e os discos non sexan exactamente iguais, seguimos facendo. Se non hai absolutamente ningún lugar, entón tes que pensar niso. Déixame pensar niso ata mañá, viñeches, falaremos, esta é unha boa pregunta.
Grazas polo informe! Primeiro comezaches a falar de que hai un Postgres xenial, que ten tales ou tales limitacións, pero que se está a desenvolver. E todo isto é unha muleta en xeral. Non contradí todo isto o propio desenvolvemento de Postgres, no que aparecerá algún tipo de deferente DELETE ou outra cousa que debería manter a un nivel baixo o que aquí intentamos tapar con algún dos nosos estraños medios?
Se en SQL dixemos eliminar ou actualizar moitos rexistros nunha transacción, entón como pode distribuír Postgres? Estamos fisicamente limitados nas operacións. Aínda estaremos facendo isto durante moito tempo. E pecharemos neste momento, etc.
Fixeron o mesmo cos índices.
Podo asumir que a mesma sintonización do punto de control podería ser automatizada. Algún día isto pode ocorrer. Pero entón realmente non entendo a pregunta.
A pregunta é: hai un vector de desenvolvemento que vai alí mesmo, e vaia paralelo ao teu aquí? Eses. Aínda non o pensan?
Falei dos principios que se poden usar agora. Hai outro bot , con isto podes facer un axuste automatizado de puntos de control. Pasará isto algunha vez en Postgres? Non sei, isto aínda non se está a discutir. Aínda estamos lonxe disto. Pero hai científicos que fan novos sistemas. E métennos nos índices automáticos. Hai desenvolvementos. Por exemplo, podes ver a sintonización automática. Selecciona os parámetros automaticamente. Pero aínda non fará a sintonización do punto de control por ti. É dicir, seleccionará o rendemento, o búfer de shell, etc.
E para a sintonización do punto de control podes facer o seguinte: se tes mil clusters e diferentes pezas de hardware, diferentes máquinas virtuais na nube, podes usar o noso bot facer automatización. E max_wal_size seleccionarase automaticamente segundo a túa configuración de destino. Pero ata agora isto non está nin preto de estar no núcleo, por desgraza.
Boas tardes Falaches dos perigos das transaccións longas. Dixeches que o baleiro automático está bloqueado en caso de eliminación. Como máis nos prexudica isto? Porque falamos máis de liberar espazo e poder utilizalo. Que máis temos que perder?
Pode que o baleiro automático non sexa o maior problema aquí. E o feito de que unha transacción longa poida bloquear outras transaccións é unha posibilidade máis perigosa. Ela pode atoparse ou non. Se se coñeceu, as cousas poderían estar moi mal. E co baleiro automático tamén é un problema. Hai dous problemas con transaccións longas en OLTP: bloqueos e baleiro automático. E se tes activada a retroalimentación de espera en quente na réplica, o bloqueo automático de baleiro tamén chegará ao mestre, chegará desde a réplica. Pero polo menos alí non haberá peches. E aquí haberá peches. Estamos a falar de cambios de datos, polo que os bloqueos son un punto importante aquí. E se isto continúa durante moito, moito tempo, entón bloquearanse máis e máis transaccións. Poden atrapar a outros. E aparecen árbores de peche. Ofrecín unha ligazón ao fragmento. E este problema rapidamente faise máis perceptible que o problema co baleiro automático, que só pode acumularse.
Grazas polo informe! Comezaches o teu informe dicindo que probaches incorrectamente. Continuamos coa nosa idea de que necesitamos levar o mesmo equipo, coa base exactamente igual. Digamos que demos unha base ao desenvolvedor. E cumpriu coa petición. E parece que lle vai ben. Pero non comproba en directo, senón en directo, por exemplo, a nosa carga é do 60-70%. E aínda que usemos esta afinación, non resulta moi ben
É importante ter un experto no teu equipo e empregar expertos en DBA que poidan predecir o que ocorrerá baixo a carga de fondo real. Cando simplemente conducimos polos nosos cambios puros, vemos a imaxe. Pero un enfoque máis avanzado foi cando volvemos facer o mesmo, pero cunha carga de produción simulada. Isto é totalmente xenial. Aínda temos que crecer ata este punto. É maduro. Miramos puramente o que temos e tamén miramos se temos recursos suficientes. Esa é unha boa pregunta.
Cando xa estamos facendo unha selección de lixo e temos, por exemplo, unha bandeira eliminada
Isto é o que fai autovacuum automaticamente en Postgres.
Ah, fai iso?
Autovacuum é o colector de lixo.
Grazas!
Grazas polo informe! Existe unha opción para deseñar inmediatamente unha base de datos con partición para que todo o lixo sexa eliminado da táboa principal nalgún lugar do lado?
Por suposto que ten.
¿Podemos protexernos se temos bloqueado unha mesa que non se debe usar?
Por suposto que ten. Pero esta é unha pregunta de galiña e ovo. Se todos sabemos o que pasará no futuro, entón, por suposto, faremos todo xenial. Pero o negocio está cambiando, aparecen novas columnas e novas solicitudes. E entón - vaia, queremos borralo. Pero esta é unha situación ideal; ocorre na vida, pero non sempre. Pero en xeral é unha boa idea. Só trunca e xa está.
Fonte: www.habr.com