{"id":74953,"date":"2020-03-22T08:42:22","date_gmt":"2020-03-22T05:42:22","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/dba-gramotno-organizovyvaem-sinhronizaczii-i-importy"},"modified":"2020-03-22T08:42:22","modified_gmt":"2020-03-22T05:42:22","slug":"dba-gramotno-organizovyvaem-sinhronizaczii-i-importy","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/dba-gramotno-organizovyvaem-sinhronizaczii-i-importy","title":{"rendered":"DBA: organizamos adecuadamente sincronizaciones e importaciones","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

En el procesamiento complejo de grandes conjuntos de datos (diferentes procesos ETL<\/a><\/noindex>: importaciones, conversiones y sincronizaciones con fuentes externas) a menudo surge la necesidad de \u00abrecordar\u00bb temporalmente y procesar r\u00e1pidamente<\/b> algo voluminoso.<\/p>\n

Una tarea t\u00edpica de este tipo suele plantearse de la siguiente manera: \u00abAqu\u00ed la contabilidad ha exportado desde el banco de clientes<\/a><\/noindex> los \u00faltimos pagos recibidos, hay que cargarlos r\u00e1pidamente en el sitio y vincularlos a las cuentas\u00bb<\/i><\/p>\n

Pero cuando el volumen de esta \u00abcosa\u00bb comienza a medirse en cientos de megabytes, y el servicio debe seguir funcionando con la base de datos en modo 24\/7, aparecen muchos efectos secundarios que arruinar\u00e1n su vida.
\n\"DBA:
\nPara hacer frente a ellos en PostgreSQL (y no solo en \u00e9l), se pueden utilizar algunas funciones de optimizaci\u00f3n que permitir\u00e1n procesar todo m\u00e1s r\u00e1pido y con menos recursos.
\n<\/a><\/noindex><\/p>\n

1. \u00bfD\u00f3nde cargar?<\/h2>\n

\nPrimero, determinemos d\u00f3nde podemos volcar los datos que queremos \u00abprocesar\u00bb.<\/p>\n

1.1. Tablas temporales (TEMPORARY TABLE)<\/h3>\n

\nEn principio, para PostgreSQL, las tablas temporales son iguales a cualquier otra tabla. Por lo tanto, son incorrectos los prejuicios como \u00aball\u00ed todo se almacena solo en la memoria, y esta puede agotarse\u00bb<\/b><\/i>. Pero tambi\u00e9n hay algunas diferencias importantes.<\/p>\n

Su propio \u00abespacio de nombres\u00bb para cada conexi\u00f3n a la BD<\/h4>\n

\nSi dos conexiones intentan ejecutar simult\u00e1neamente CREATE TABLE x<\/code>, entonces alguien definitivamente obtendr\u00e1 un error de no unicidad<\/b> de los objetos de la BD.<\/p>\n

Pero si ambos intentan ejecutar CREAR TEMPORARIO<\/b> TABLA x<\/code>, entonces ambos lo har\u00e1n correctamente, y cada uno obtendr\u00e1 su propia instancia<\/b> de la tabla. Y no habr\u00e1 nada en com\u00fan entre ellas.<\/p>\n

\u00abAutodestrucci\u00f3n\u00bb al desconectarse<\/h4>\n

\nAl cerrar la conexi\u00f3n, todas las tablas temporales se eliminan autom\u00e1ticamente, por lo que no tiene sentido ejecutar manualmente DROP TABLE x<\/code> , salvo\u2026<\/p>\n

Si trabaja a trav\u00e9s de pgbouncer en modo de transacci\u00f3n<\/b>, entonces la base todav\u00eda considera que esta conexi\u00f3n sigue activa, y en \u00e9l, esta tabla temporal sigue existiendo.<\/p>\n

Por lo tanto, intentar crearla de nuevo, ya desde otra conexi\u00f3n a pgbouncer, conducir\u00e1 a un error. Pero se puede eludir esto utilizando CREAR TABLA TEMPORAL SI NO EXISTE<\/b> x<\/code>.<\/p>\n

Sin embargo, es mejor no hacerlo, porque entonces puede \u00abdescubrir repentinamente\u00bb datos que quedan de \u00abel propietario anterior\u00bb. En su lugar, es mucho mejor leer el manual y ver que al crear la tabla hay una opci\u00f3n para a\u00f1adir EN COMPROMISO ELIMINAR<\/b><\/code> \u2014 es decir, al finalizar la transacci\u00f3n, la tabla ser\u00e1 eliminada autom\u00e1ticamente.<\/p>\n

No-replicaci\u00f3n<\/h4>\n

\nDebido a que pertenece solo a una conexi\u00f3n espec\u00edfica, las tablas temporales no se replican. Sin embargo, esto elimina la necesidad de escribir dos veces los datos<\/b> en heap + WAL, por lo que INSERT\/UPDATE\/DELETE en ella es significativamente m\u00e1s r\u00e1pido.<\/p>\n

Pero dado que la temporal es, al fin y al cabo, una tabla 'casi normal', no se puede crear en la r\u00e9plica tampoco. Al menos, por ahora, aunque ya hay un parche correspondiente circulando.<\/p>\n

1.2. Tablas no registradas (UNLOGGED TABLE)<\/h3>\n

\nPero, \u00bfqu\u00e9 hacer si, por ejemplo, tiene un proceso ETL voluminoso que no se puede realizar dentro de una \u00fanica transacci\u00f3n, y usted sigue teniendo pgbouncer en modo de transacci\u00f3n<\/b>?..<\/p>\n

O si el flujo de datos es tan grande que la capacidad de un solo enlace a la base de datos no es suficiente (es decir, un proceso por CPU)?..<\/b> \u00bfO algunas de las operaciones se realizan<\/p>\n

de forma asincr\u00f3nica en diferentes conexiones?..<\/b> Aqu\u00ed solo hay una opci\u00f3n \u2014<\/p>\n

crear temporalmente una tabla no temporal . Un juego de palabras, s\u00ed. Es decir:<\/b>cre\u00f3 'sus' tablas con nombres lo m\u00e1s aleatorios posible para no cruzarse con nadie<\/p>\n