Estrategias para reducir el tamaño de la base de datos en PostgreSQL: un enfoque basado en el uso

Los modelos de precios de bases de datos son difíciles. Como desarrollador que busca una base de datos administrada, uno de los aspectos más molestos (y aún más cruciales) del proceso de búsqueda implica evaluar no solo el precio inicial de la solución para el tamaño de su base de datos, sino también cómo funciona el precio y qué tan bien escalará. . Además de los matices al evaluar el precio de la base de datos (por ejemplo, "¿Cuánto aumenta la factura a medida que crecen mis datos?", "¿Me cobran por escrituras o lecturas?" y "¿Tengo que pagar más por las copias de seguridad?"). ), los desarrolladores tienden a pasar por alto un aspecto: la forma en que se estructura el modelo de precios de una base de datos influirá en la forma en que administra sus datos y evalúa el tamaño de su base de datos Postgres. Diferentes modelos de precios requieren diferentes enfoques para ejecutar PostgreSQL. Por ejemplo, si está encerrado en un disco grande, es posible que no dé prioridad a la reducción del tamaño de su base de datos. Si se le cobra por datos leídos, puede pensar dos veces antes de ejecutar ciertas consultas, y si se le cobra por entrada de datos, puede tener cuidado con la frecuencia y el volumen de los datos recién ingeridos. Cada elemento de precio influye sutilmente en las estrategias y comportamientos que terminará adoptando, impulsándolo hacia una forma particular de administrar e interactuar con su base de datos para garantizar tanto la rentabilidad como el rendimiento óptimo. , con excelentes comentarios de los clientes. En esta publicación de blog, exploraremos las ventajas operativas que hemos observado en nuestros clientes desde la transición a este modelo, junto con tácticas sobre cómo administrar de manera óptima su almacenamiento PostgreSQL en un modelo basado en el uso. En Timescale, hicimos la transición a un modelo de almacenamiento basado en el uso hace unos meses. Los modelos de almacenamiento basados en el uso se están volviendo cada vez más populares en el mundo de las bases de datos: ¿quién quiere pagar por el espacio en disco que no utiliza? Aún así, un modelo basado en el uso no está exento de consecuencias y es necesario considerar algunas de las mejores prácticas para navegarlo de manera efectiva. Resumen rápido de los modelos de almacenamiento de PostgreSQL Para establecer un terreno común para nuestra discusión sobre la administración del tamaño de su base de datos en un modelo basado en el uso, comencemos cubriendo rápidamente cómo funcionan los precios en nuestra plataforma PostgreSQL ( ) y cómo se compara con otros productos PostgreSQL administrados, como Amazon RDS para PostgreSQL y Amazon Aurora. Escala de tiempo Desde ayer (💥), ofrecemos dos tipos de servicios de bases de datos en la plataforma Timescale: , donde los desarrolladores pueden crear bases de datos PostgreSQL con computación dinámica para ahorrar dinero sin sacrificar el rendimiento. Servicios dinámicos de PostgreSQL Servicios Time Series, donde los desarrolladores pueden crear bases de datos PostgreSQL mejoradas con rendimiento y escalabilidad adicionales a través de hipertablas, compresión de columnas, y almacenamiento por niveles. agregados continuos Centrémonos en cómo valoramos el almacenamiento en nuestra plataforma. Ambos servicios vienen con un modelo de almacenamiento basado en el uso, lo que significa lo siguiente: A los desarrolladores se les cobra por el volumen que utilizan, sin letra pequeña: sin tamaño mínimo de base de datos ni pasos mínimos de escalado. Si, al final del mes, has usado 128 GB, eso es lo que se te facturará. Puede comenzar con 1 GB y aumentar hasta TB. No hay cargos basados en datos escritos, transferencias de datos o consultas realizadas. No es necesario asignar almacenamiento al crear una base de datos o escalar. No es necesario reducir el tamaño de los discos manualmente. Para aclarar esto, expongamos las diferencias entre este modelo, Amazon RDS PostgreSQL y Amazon Aurora: En resumen, aquí están las tres conclusiones principales de nuestra comparación: Tanto Timescale como Aurora cobran por el tamaño real de su base de datos. Por el contrario, RDS PostgreSQL cobra por el almacenamiento aprovisionado. No se pueden reducir los volúmenes en RDS. Timescale no cobra por los datos escritos, las transferencias de datos ni las operaciones de consulta. Tanto RDS como Aurora cobran por transferencia de datos, almacenamiento de respaldo adicional y es posible que usted incurra en algunos cargos de E/S adicionales, según el tipo de almacenamiento que elija. Timescale no tiene pasos mínimos de escalamiento, mientras que Aurora escala en incrementos de 10 GB después de comenzar con 10 GB. Como puede ver, el modelo de Timescale está más cerca de , con la diferencia de que Timescale carece de pasos de escalamiento y cargos adicionales por cosas como la transferencia de datos. Por el contrario, RDS es una buena representación del modelo basado en la asignación, incluso si tradicionalmente se encuentran en los proveedores de bases de datos que operan con este modelo. Aurora I/O optimizada RDS carece de "niveles de almacenamiento" Cómo los precios basados en el uso mejoran la gestión del almacenamiento de PostgreSQL Como presentamos anteriormente, diferentes modelos de precios implican diferentes experiencias de bases de datos. Cuando hicimos la transición de un modelo basado en la asignación a uno basado en el uso, nuestros clientes nos dijeron que vieron mejoras inmediatas en tres áreas operativas: No necesitaban aprovisionar almacenamiento por adelantado al iniciar una base de datos, lo que generó menos errores de aprovisionamiento excesivo y, por lo tanto, menores facturas de almacenamiento. No tuvieron que pensar en el almacenamiento mientras ampliaban. Podrían reducir su escala; por ejemplo, si eliminaban datos, dejaban de pagar por ellos. Los modelos basados en el uso eliminan el problema del sobreaprovisionamiento de almacenamiento En los modelos tradicionales basados en asignación, los desarrolladores a menudo se encuentran prediciendo sus necesidades de almacenamiento, lo que, muy a menudo, conduce a un aprovisionamiento excesivo de almacenamiento. Observamos esto en toda nuestra flota cuando Timescale operaba en un modelo basado en el uso: la mayoría de nuestros clientes no estaban usando su capacidad total de disco, lo que significa que esencialmente estaban pagando por el espacio de almacenamiento que aún no estaban usando. Los modelos basados en el uso eliminan este juego de adivinanzas (y las consecuencias de conjeturas erróneas). No necesita pensar en el almacenamiento mientras amplía “El almacenamiento basado en el uso de Timescale significa que ya no tengo que pensar en el tamaño del disco. ¡Nuestro costo de almacenamiento se redujo en un 30% y no tuve que hacer nada!" Adán McCrea, (Cliente de escala de tiempo) escala de judo En los modelos basados en el uso, el almacenamiento escala sin problemas a medida que crece su base de datos. Una de las principales fuentes de estrés en los modelos tradicionales basados en la asignación es el peligro de quedarse sin espacio en disco, lo que puede provocar numerosos problemas que van desde tiempo de inactividad de las aplicaciones y pérdida de transacciones hasta corrupción de datos en el peor de los casos. Con los modelos basados en el uso, los desarrolladores ya no tienen que monitorear atentamente su almacenamiento para evitar chocar contra un muro de almacenamiento. Al mismo tiempo, no tienen que preocuparse por pasos pesados de escalado automático o saltos de nivel. Puede reducir la escala (dejar de pagar por los datos que eliminó) Por último, pero no menos importante, los modelos basados en el uso le permiten "reducir la escala". Si elimina datos (o logra reducir considerablemente el tamaño de su base de datos), comenzará a pagar menos por almacenamiento, lo que parece justo. Como veremos en la siguiente sección, Timescale tiene algunas características para ayudar a los clientes a reducir el tamaño de su base de datos PostgreSQL. La adopción de un modelo basado en el uso permitió a nuestros clientes obtener ahorros inmediatos al reducir el uso del disco, lo que los incentivó a mantener su base de datos optimizada. Cómo navegar eficazmente por un modelo basado en el uso: consejos para reducir el tamaño de su base de datos Postgres Los beneficios que acabamos de mencionar mejoran significativamente la experiencia del desarrollador al trabajar con almacenamiento, razón por la cual los modelos basados en el uso se están volviendo muy populares. Pero la fijación de precios basada en el uso tiene una consecuencia obvia (aunque profunda): obliga a los desarrolladores a adoptar buenas prácticas de datos para reducir el tamaño de su base de datos PostgreSQL tanto como sea posible. Cuando sabe que sus costos de almacenamiento están directamente relacionados con el tamaño del disco que realmente está utilizando, existe un nuevo incentivo para ser más juicioso con el almacenamiento de datos. Si está operando en un modelo de almacenamiento basado en el uso, es su responsabilidad asegurarse de almacenar los datos de manera eficiente. En cierto modo, esto puede considerarse un “inconveniente” de los modelos basados en el uso y requiere algo de trabajo, pero en realidad es una bendición disfrazada. En los modelos tradicionales basados en la asignación, la higiene de los datos puede pasarse un poco por alto porque los costos son fijos: si está encerrado en un disco de 500 GB en RDS y su base de datos es de 200 GB, no parece tener un gran incentivo para hacer que el uso del almacenamiento sea eficiente. Pero aquí está la cuestión: las buenas prácticas en materia de datos no se refieren sólo a ahorrar dinero. Para escalar una base de datos PostgreSQL, es fundamental mantenerla optimizada. Al adoptar buenas prácticas de gestión de datos de PostgreSQL, no sólo verá un mejor rendimiento sino que su vida como administrador de bases de datos será mucho más fácil. Con esto en mente, repasemos algunas prácticas que lo ayudarán a navegar por un modelo de almacenamiento basado en el uso de la manera más efectiva posible, reduciendo el tamaño de su base de datos PostgreSQL de manera sistemática. En el caso particular de Timescale, tenemos algunas características particularmente útiles, que también cubriremos. Reduzca la hinchazón en su base de datos PostgreSQL Lo primero que se debe hacer en un modelo basado en el uso es prestar atención a los aspectos específicos de cómo funciona el almacenamiento PostgreSQL, es decir, se debe reducir la sobrecarga de forma regular. Esto le ayudará no sólo con el tamaño de su base de datos sino también con sus requisitos de E/S. Le indicaremos algunos conceptos básicos en esta sección, , y también hemos escrito . pero este hilo de HN tiene buenos consejos. una publicación de blog sobre la hinchazón de tablas en PostgreSQL Un enfoque proactivo para optimizar el almacenamiento de PostgreSQL comienza vigilando de cerca las tuplas muertas. Las tuplas muertas, si no se controlan, pueden acumularse y generar gastos generales de almacenamiento innecesarios. La extensión puede ser un gran aliado para comprender cómo las tablas administran estas tuplas. Monitorear tuplas muertas. pgstattuple() Para combatir eficazmente la hinchazón de la mesa, es posible que desee configurar el vacío automático para que se ejecute con más frecuencia. En lugar de ajustar globalmente la configuración de autovacuum en postgresql.conf, es más preciso ajustar estas configuraciones por tabla. Esto responde al hecho de que diferentes tablas pueden tener diferentes tendencias para acumular tuplas muertas. También es crucial monitorear las transacciones de larga duración que podrían obstaculizar las operaciones de autovacuum. Aspire con frecuencia. Mientras que el autovacuum y el vacío solucionan tuplas muertas, recuperar páginas no utilizadas exige un enfoque diferente. Aunque VACUUM FULL se puede utilizar para este propósito, tiene la limitación inherente de bloquear toda la mesa. puede ayudarte con esto. Recupere páginas no utilizadas. Pg_repack Haga algunos ajustes en PostgreSQL Reducir sistemáticamente el tamaño de su base de datos PostgreSQL está estrechamente relacionado con poder escalar su base de datos PostgreSQL de manera efectiva, es decir, mantener las cosas rápidas y ágiles mientras agrega más y más datos. Vigilar (y tal vez ajustar) algunos parámetros clave de PostgreSQL puede resultar útil. . Aquí hay algunos aspectos que debes considerar: Este artículo revisa los parámetros de rendimiento más importantes. : controla la memoria utilizada para el caché de páginas de PostgreSQL y normalmente se establece en el 25 % de la RAM total del sistema. shared_buffers : establece la memoria asignada por operación dentro de una consulta. En Timescale, la configuración recomendada es . work_mem (25 % of RAM) / max_connections : establece el número máximo de conexiones simultáneas permitidas a la base de datos. Los agrupadores de conexiones pueden ayudar a gestionar muchas conexiones de corta duración. max_connections : determina el número máximo de procesos de trabajo que PostgreSQL puede iniciar. Si usa Timescale, la fórmula para establecer este parámetro es: . max_worker_processes max_worker_processes = 3 + timescaledb.max_background_workers + max_parallel_workers : especifica el número máximo de trabajadores que admiten consultas paralelas. El valor predeterminado es establecer esto igual al número de CPU disponibles. max_parallel_workers : determina el número máximo de procesos de autovacuum simultáneos. En Timescale, está configurado en 10 de forma predeterminada. autovacuum_max_workers Practique la higiene de indexación La optimización periódica de los índices ayudará a mantener la eficiencia de PostgreSQL, especialmente a medida que la base de datos escala. Si bien los índices pueden ayudarle a mejorar el rendimiento de las consultas cuando se usan con prudencia, un exceso de índices puede crear problemas en implementaciones grandes de PostgreSQL. La consecuencia más obvia de una indexación excesiva es un mayor consumo de almacenamiento, ya que cada índice necesita un almacenamiento separado, que crece proporcionalmente con el tamaño de las tablas. Esta sobrecarga puede volverse más significativa cuando las tablas están particionadas, como en las hipertablas de Timescale. Los índices innecesarios también pueden ser contraproducentes a la hora de mejorar sus operaciones de escritura, ya que cada nueva entrada o modificación de datos implica actualizaciones de índice simultáneas, lo que genera más operaciones de E/S y una posible sobrecarga de la tabla. Monitorear sus índices lo ayudará a identificar cuáles ya no se usan, manteniendo todo ágil. Una forma de hacerlo es mediante : pg_stat_user_indexes -- Retrieve indexes that might not be used or are infrequently used SELECT schemaname, relname AS table_name, indexrelname AS index_name, idx_scan AS times_used FROM pg_stat_user_indexes WHERE idx_scan = 0 OR idx_scan < some_low_threshold -- replace 'some_low_threshold' with a value that makes sense for your context ORDER BY idx_scan ASC, schemaname, relname; Si un índice tiene un valor de 0 en la columna idx_scan, significa que no se ha utilizado desde la última vez que se restablecieron las estadísticas, lo que significa que podría ser candidato para optimización. Al establecer un umbral bajo para , también puede identificar índices utilizados con poca frecuencia. idx_scan Reduzca sus tablas grandes mediante la compresión de escala de tiempo Una de las características destacadas de Timescale es su soporte nativo para la compresión de columnas, que puede reducir drásticamente el espacio en disco utilizado por tablas grandes sin comprometer el rendimiento de las consultas. La compresión mejora el rendimiento de muchas consultas. La compresión de Timescale funciona convirtiendo datos regulares basados en filas en un formato de columnas más compacto. Este proceso es particularmente eficaz para datos de series temporales, donde muchas columnas pueden contener valores repetitivos; Podemos lograr tasas de compresión impresionantes (+90%) aplicando diferentes algoritmos de compresión dependiendo de cada tipo de datos. Esto significa que sus mesas grandes se pueden reducir hasta 10 veces. En Timescale, la compresión se habilita tabla por tabla a través de una política de compresión basada en el tiempo. Por ejemplo, este código permite la compresión en una hipertabla particular y comprime automáticamente datos de más de dos semanas: -- Enable compression on the hypertable ALTER TABLE your_hypertable SET ( timescaledb.compress, timescaledb.compress_segmentby = 'some_column' ); -- Set a compression policy to compress data older than two weeks SELECT add_compression_policy('your_hypertable', INTERVAL '2 weeks'); Para obtener más información sobre la compresión, . consulte nuestra documentación Configure una estrategia de gestión de datos: traslade los datos antiguos a un almacenamiento más económico y elimine los datos que ya no necesita Las tácticas anteriores son muy útiles para reducir el tamaño de su base de datos, pero hay otra vía que puede aprovechar en Timescale para escalar su almacenamiento de manera efectiva: el almacenamiento por niveles. Al crear una política de niveles simple, puede mover datos más antiguos a los que se accede menos a una capa de almacenamiento de objetos sin fondo: -- This policy moves all data older than one month to object storage SELECT add_tiering_policy('example', INTERVAL '1 month); Este almacén de objetos tiene las siguientes características: Tiene un precio más bajo que nuestro almacenamiento de alto rendimiento, lo que le permite almacenar muchos TB de datos por mucho menos. Es infinito, lo que significa que puedes almacenar tantos datos como quieras. Esta arquitectura de almacenamiento por niveles está arraigada en el backend de Timescale. El almacenamiento de objetos no es un “depósito” separado de su base de datos; más bien, es una parte integral de ella. Las consultas accederán de forma transparente a ambas capas de almacenamiento sin necesidad de que usted realice ninguna acción; puede seguir usando SQL estándar sobre el mismo esquema. Una vez establecida su política de niveles, ¡no hay nada más que considerar! Recomendamos mover los datos a la capa de almacenamiento de bajo costo una vez que su aplicación no acceda a ellos con frecuencia, ya que hay un costo de rendimiento (el almacén de objetos no es tan rápido como nuestro almacenamiento normal). Pero puede seguir ejecutando cómodamente consultas ad hoc sobre estos datos (por ejemplo, consultas que no son críticas para la experiencia de usuario de sus clientes y para las cuales el máximo rendimiento no es esencial). Nota del editor: pronto compartiremos noticias interesantes sobre el almacenamiento por niveles. 🎉 ¡Estén atentos! Además de ofrecer esta capa de almacenamiento de bajo costo, Timescale facilita la configuración de políticas de retención de datos para eliminar datos que ya no necesita: -- Set a data retention policy to drop data older than 10 months SELECT add_retention_policy('your_hypertable', INTERVAL '10 months'); Puede combinar políticas de retención de datos como la anterior con agregados continuos para reducir la muestra de su conjunto de datos de manera efectiva; por ejemplo, reducir la granularidad de un segundo a un minuto, eliminar los valores de un segundo pero mantener los agregados de un minuto. . Lea esta publicación de blog para ver un ejemplo de cómo hacer esto y administrar datos a largo plazo de manera proactiva. Modelos basados en el uso y el paradigma de gestión de datos Si bien los modelos basados en el uso pueden parecer nada más que un cambio de precios en la superficie, provocan un cambio de paradigma en cómo los desarrolladores piensan sobre el tamaño de su base de datos y cómo perciben y manejan los datos. Los modelos basados en el uso promueven una cultura de mejora continua, donde el enfoque pasa de la mera gestión del almacenamiento al estado y la eficiencia de la base de datos. Esto requiere algo de disciplina al principio, pero una vez que cambie su forma de pensar y aprenda algunas técnicas, estará en el mejor lugar para escalar su base de datos PostgreSQL de manera eficiente y efectiva. Timescale tiene herramientas valiosas para ayudarle a reducir sistemáticamente el tamaño de su base de datos PostgreSQL, como políticas de compresión, almacenamiento por niveles y retención de datos. Esto le permite escalar eficazmente sus bases de datos PostgreSQL en un modelo basado en el uso. . Para experimentarlo usted mismo, regístrese en Timescale; puede usarlo gratis durante los primeros 30 días - Escrito por . Carlota Sota También publicado aquí.

Estrategias para reducir el tamaño de la base de datos en PostgreSQL: un enfoque basado en el uso

About Author

COMENTARIOS

ETIQUETAS

ESTE ARTÍCULO FUE PRESENTADO EN

Related Stories

Navegando por las aguas: desarrollo de aplicaciones RAG de nivel de producción con lagos de datos

Crecimiento de las criptomonedas: creación de perfiles de usuarios eficaces

¿Quieres ganar un concurso de redacción de HackerNoon? Esto es lo que recomiendan los ganadores del concurso #crypto-api

Liberando el poder de la IA. Una revisión sistemática de técnicas de vanguardia: resumen e introducción

Navegando por las aguas: desarrollo de aplicaciones RAG de nivel de producción con lagos de datos

Crecimiento de las criptomonedas: creación de perfiles de usuarios eficaces

¿Quieres ganar un concurso de redacción de HackerNoon? Esto es lo que recomiendan los ganadores del concurso #crypto-api

Liberando el poder de la IA. Una revisión sistemática de técnicas de vanguardia: resumen e introducción

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps