{"id":79039,"date":"2020-04-23T19:43:26","date_gmt":"2020-04-23T17:43:26","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/ekonomim-kopeechku-na-bolshih-obemah-v-postgresql"},"modified":"2020-04-23T19:43:26","modified_gmt":"2020-04-23T17:43:26","slug":"ekonomim-kopeechku-na-bolshih-obemah-v-postgresql","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/ekonomim-kopeechku-na-bolshih-obemah-v-postgresql","title":{"rendered":"Ahorra unos centavos en grandes vol\u00famenes en PostgreSQL","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Continuando con el tema de registrar grandes flujos de datos, planteado en el art\u00edculo anterior sobre particionamiento<\/a><\/noindex>, en este exploraremos las maneras en que se puede reducir el tama\u00f1o 'f\u00edsico' del almacenamiento<\/b> en PostgreSQL y su impacto en el rendimiento del servidor.<\/p>\n

Vamos a hablar sobre configuraciones de TOAST y alineaci\u00f3n de datos<\/b>. 'En promedio', estas alternativas permiten ahorrar no demasiado recursos, pero s\u00ed \u2014 sin modificar el c\u00f3digo de la aplicaci\u00f3n.<\/p>\n

\"Ahorra
\nSin embargo, nuestra experiencia result\u00f3 ser bastante productiva en este sentido, dado que el almacenamiento de casi cualquier monitoreo por su naturaleza es en su mayor parte append-only<\/b> en t\u00e9rminos de datos registrados. Y si te interesa c\u00f3mo se puede ense\u00f1ar a la base a escribir en disco en lugar de 200MB\/s<\/b> la mitad \u2014 te invito a seguir leyendo.
\n<\/a><\/noindex><\/p>\n

Peque\u00f1os secretos de grandes datos<\/h2>\n

\nPor el perfil de trabajo de nuestro servicio<\/a><\/noindex>, recibe regularmente desde los logs paquetes de texto<\/b>.<\/p>\n

Y dado que el complejo SBIS<\/a><\/noindex>, cuyas bases de datos monitoreamos, es un producto multicomponente con estructuras de datos complejas, las consultas para lograr la m\u00e1xima performance<\/b> resultan bastante 'de m\u00faltiples vol\u00famenes' con una l\u00f3gica algor\u00edtmica compleja<\/a><\/noindex>. As\u00ed que el tama\u00f1o de cada instancia individual de consulta o plan de ejecuci\u00f3n resultado en el log que recibimos resulta ser 'en promedio' bastante grande.<\/p>\n

Veamos la estructura de una de las tablas en las que escribimos datos 'crudos' \u2014 es decir, justo el texto original del registro del log:<\/p>\n

CREATE TABLE rawdata_orig(\n  pack -- PK\n    uuid NOT NULL\n, recno -- PK\n    smallint NOT NULL\n, dt -- clave de secci\u00f3n\n    date\n, data -- lo m\u00e1s importante\n    text\n, PRIMARY KEY(pack, recno)\n);<\/code><\/pre>\n
\nUna tabla t\u00edpica (ya particionada, por supuesto, as\u00ed que esto es un template de secci\u00f3n), donde lo m\u00e1s importante es el texto. A veces, bastante voluminoso.<\/p>\n
Recordemos que el tama\u00f1o 'f\u00edsico' de un registro en PG no puede ocupar m\u00e1s de una p\u00e1gina de datos, pero el tama\u00f1o 'l\u00f3gico' es otra historia. Para insertar un valor voluminoso en un campo (varchar\/text\/bytea) se utiliza la tecnolog\u00eda TOAST<\/a><\/noindex>:<\/p>\n
PostgreSQL utiliza un tama\u00f1o de p\u00e1gina fijo (generalmente 8 KB), y no permite que los tuplas ocupen varias p\u00e1ginas. Por lo tanto, no es posible almacenar directamente valores de campo muy grandes. Para superar esta limitaci\u00f3n, los valores de campo grandes se comprimen y\/o se dividen en varias filas f\u00edsicas. Esto ocurre de manera imperceptible para el usuario y afecta de forma m\u00ednima la mayor parte del c\u00f3digo del servidor. Este m\u00e9todo se conoce como TOAST \u2026<\/p><\/blockquote>\n
\nDe hecho, para cada tabla con campos \"potencialmente grandes\" se crea autom\u00e1ticamente una tabla complementaria con \"segmentaci\u00f3n\"<\/a><\/noindex> de cada registro \"grande\" en segmentos de 2KB:<\/p>\n
TOAST(\n  chunk_id\n    integer\n, chunk_seq\n    integer\n, chunk_data\n    bytea\n, PRIMARY KEY(chunk_id, chunk_seq)\n);<\/code><\/pre>\n
\nEs decir, si tenemos que grabar una fila con un valor \"grande\" data<\/code>, la grabaci\u00f3n real ocurrir\u00e1 no solo en la tabla principal y su clave primaria, sino tambi\u00e9n en TOAST y su clave primaria.<\/b>.<\/p>\n
Reduciendo el impacto de TOAST<\/h4>\n
\nPero la mayor\u00eda de nuestros registros no son tan grandes, deber\u00edan caber en 8KB.<\/b> \u00bfC\u00f3mo podemos ahorrar en esto?<\/p>\n
Aqu\u00ed entra en juego el atributo STORAGE<\/code><\/a><\/noindex> de la columna de la tabla:<\/p>\n
\n