, a última versión da "mellor base de datos relacional de código aberto do mundo", sairá nun par de semanas (se todo vai segundo o previsto). Isto segue o calendario habitual de lanzar unha nova versión cunha tonelada de novas funcións unha vez ao ano e, francamente, iso é impresionante. É por iso que me convertín nun membro activo da comunidade PostgreSQL.
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 . Este tipo de índice está optimizado para sistemas de almacenamento.
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 e ocupa espazo extra no disco e reduce o rendemento da recuperación e actualización de datos. Por "inchar" refírome a manter ineficazmente a estrutura do índice. Isto pode -ou non- estar relacionado coas tuplas de lixo que elimina (Grazas a Peter Gaghan pola información))). A inflación do índice é especialmente perceptible nas cargas de traballo nas que o índice está cambiando activamente.
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 () - utilizará o disco e procesará as solicitudes de forma moito máis eficiente. Canto máis espazo no disco, máis espazo ten a base de datos para crecer sen actualizar a infraestrutura.
Algunhas estratexias de actualización requiren reconstruír os índices da árbore B para aproveitar estes beneficios (p. ex. non reconstruirá os índices automaticamente). Nas versións anteriores de PostgreSQL, a reconstrución de índices grandes en táboas producía un tempo de inactividade significativo porque non se podían facer cambios mentres tanto. Pero PostgreSQL 12 ten outra característica interesante: agora podes reconstruír índices en paralelo co comando para evitar completamente o tempo de inactividade.
Hai outras melloras na infraestrutura de indexación en PostgreSQL 12. Outra cousa onde había algo de maxia - , tamén coñecido como WAL (rexistro de escritura anticipada). Un rexistro de escritura anticipada rexistra cada transacción en PostgreSQL en caso de falla e replicación. As aplicacións úsano para arquivar e . Por suposto, o rexistro de escritura anticipada escríbese no disco, o que pode afectar o rendemento.
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 11 volveuse moito máis doado de usar. En PostgreSQL 12 pode cambiar a escala das seccións.
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 - por certo, esta é unha boa forma e aquí tedes un exemplo — as táboas particionadas en PostgreSQL 12 tamén se fixeron máis eficientes. Con COPY xa todo era rápido, pero en PostgreSQL 12 voa absolutamente.
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 (tamén coñecido como CTE, tamén coñecido como CON consultas), non podía esperar para escribir un artigo sobre . Esta é unha desas características que acelerarán a aplicación. A menos que, por suposto, use CTE.
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 A compilación JIT está activada por defecto. Primeiro de todo, recibes apoio para algunhas operacións internas e, en segundo lugar, as consultas con expresións (o exemplo máis sinxelo é x + y) en listas de selección (que tes despois de SELECT), agregados, expresións con cláusulas WHERE e outras poden usar JIT para mellorar o rendemento.
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