Na miña opinión, a diferenza das versións anteriores, PostgreSQL 12 non contén unha ou dúas funcións revolucionarias (como a partición ou o paralelismo de consultas). Unha vez chanceei dicindo que a principal característica de PostgreSQL 12 é unha maior estabilidade. Non é iso o que necesitas cando xestionas os datos críticos da túa empresa?
Pero PostgreSQL 12 non se queda aí: con novas funcións e melloras, as aplicacións funcionarán mellor, e todo o que tes que facer é actualizar!
(Ben, quizais reconstruír os índices, pero nesta versión non é tan asustado como estamos afeitos).
Será xenial actualizar PostgreSQL e gozar de inmediato de melloras significativas sen problemas innecesarios. Hai uns anos, revisei unha actualización de PostgreSQL 9.4 a PostgreSQL 10 e vin como a aplicación se acelerou grazas ao paralelismo de consultas mellorado en PostgreSQL 10. E, o máis importante, case non se me requiriu case nada (solo establecer un parámetro de configuración). max_parallel_workers
).
De acordo, é conveniente cando as aplicacións funcionen mellor inmediatamente despois dunha actualización. E tratamos moito de agradar aos usuarios, porque PostgreSQL ten cada vez máis.
Entón, como pode facerche feliz unha simple actualización a PostgreSQL 12? Xa cho contarei.
Principais melloras na indexación
Sen indexación, unha base de datos non irá lonxe. De que outra forma podes atopar información rapidamente? Chámase o sistema de indexación fundamental de PostgreSQL
Simplemente usamos o operador CREATE INDEX ON some_table (some_column)
, e PostgreSQL fai moito traballo para manter o índice actualizado mentres constantemente inserimos, actualizamos e eliminamos valores. Todo funciona por si só, coma por arte de arte.
Pero os índices PostgreSQL teñen un problema: eles
PostgreSQL 12 mellora moito o rendemento dos índices B-tree e experimentos con benchmarks como TPC-C demostraron que agora se emprega un 40% menos de espazo de media. Agora dedicamos menos tempo non só a manter os índices da árbore B (é dicir, ás operacións de escritura), senón tamén a recuperar datos, porque os índices son moito máis pequenos.
Aplicacións que actualizan activamente as súas táboas, normalmente aplicacións OLTP (
Algunhas estratexias de actualización requiren reconstruír os índices da árbore B para aproveitar estes beneficios (p. ex.
Hai outras melloras na infraestrutura de indexación en PostgreSQL 12. Outra cousa onde había algo de maxia -
PostgreSQL 12 reduciu a sobrecarga dos rexistros WAL que son creados polos índices GiST, GIN e SP-GiST durante a construción do índice. Isto proporciona varios beneficios tanxibles: os rexistros WAL ocupan menos espazo no disco e os datos repítense máis rápido, como durante a recuperación ante desastres ou a recuperación puntual. Se usas estes índices nas túas aplicacións (por exemplo, as aplicacións xeoespaciais baseadas en PostGIS usan moito o índice GiST), esta é outra característica que mellorará significativamente a experiencia sen ningún esforzo da túa parte.
Partición: máis grande, mellor, máis rápido
PostgreSQL 10 introducido
En PostgreSQL 12, o rendemento do sistema de partición foi significativamente mellor, especialmente se hai miles de particións na táboa. Por exemplo, se unha consulta afecta só a algunhas particións dunha táboa con miles delas, executarase moito máis rápido. O rendemento non só se mellora para este tipo de consultas. Tamén notarás o máis rápido que son as operacións de INSERT nas táboas con varias particións.
Gravación de datos utilizando
Grazas a estas vantaxes, PostgreSQL permítelle almacenar conxuntos de datos aínda máis grandes e facelos máis fáciles de recuperar. E ningún esforzo pola túa parte. Se a aplicación ten moitas particións, como gravar datos de series temporais, unha simple actualización mellorará significativamente o seu rendemento.
Aínda que esta non é exactamente unha mellora de "actualizar e gozar", PostgreSQL 12 permítelle crear chaves estranxeiras que fan referencia a táboas particionadas, o que fai que a partición sexa un pracer traballar.
CON consultas só melloraron moito
Cando
Moitas veces penso que aos novatos en SQL lles encanta usar CTE; se os escribes dun xeito determinado, realmente parece que estás escribindo un programa imperativo. Persoalmente, gustoume reescribir estas consultas para moverme sen CTE e aumentar a produtividade. Agora todo é diferente.
PostgreSQL 12 permítelle integrar un tipo específico de CTE sen efectos secundarios (SELECT
), que só se usa unha vez preto do final da solicitude. Se fixera un seguimento das consultas CTE que reescribín, a maioría delas entrarían nesta categoría. Isto axuda aos desenvolvedores a escribir código claro que agora tamén se executa rapidamente.
Ademais, PostgreSQL 12 optimiza a propia execución de SQL, sen que teñas que facer nada. E aínda que probablemente non necesite optimizar tales consultas agora, é xenial que PostgreSQL siga traballando na optimización de consultas.
Just-in-Time (JIT): agora predeterminado
En sistemas PostgreSQL 12 con soporte
Dado que JIT está activado por defecto en PostgreSQL 12, o rendemento mellorará por si só, pero recomendo probar a aplicación en PostgreSQL 11, que introduciu JIT, para medir o rendemento das consultas e ver se precisas axustar algo.
Que pasa co resto das novas funcións de PostgreSQL 12?
PostgreSQL 12 ten un montón de novas funcións interesantes, desde a capacidade de examinar datos JSON usando expresións de ruta SQL/JSON estándar ata a autenticación multifactor cun parámetro clientcert=verify-full
, creou columnas e moito máis. Suficiente para unha publicación separada.
Do mesmo xeito que PostgreSQL 10, PostgreSQL 12 mellorará o rendemento xeral inmediatamente despois da actualización. Ti, por suposto, podes ter o teu propio camiño: proba a aplicación en condicións similares no sistema de produción antes de activar melloras, como fixen con PostgreSQL 10. Aínda que PostgreSQL 12 xa é máis estable do que esperaba, non sexas preguiceiro na proba. aplicacións a fondo, antes de publicalas en produción.
Fonte: www.habr.com