, "Дүйнөдөгү эң мыкты ачык булак реляциялык маалымат базасынын" акыркы версиясы бир-эки жумадан кийин чыгат (эгер баары планга ылайык болсо). Бул жылына бир жолу бир нече тонна жаңы функциялар менен жаңы версияны чыгаруунун кадимки графигине ылайык келет жана ачык айтканда, бул таасирдүү. Ошондуктан мен PostgreSQL коомчулугунун активдүү мүчөсү болуп калдым.
Менин оюмча, мурунку релиздерден айырмаланып, PostgreSQL 12 бир же эки революциялык өзгөчөлүктү камтыбайт (бөлүштүрүү же суроо параллелизм сыяктуу). Мен бир жолу тамашалап айткам, PostgreSQL 12нин негизги өзгөчөлүгү - көбүрөөк туруктуулук. Бул сиздин бизнесиңиздин маанилүү маалыматтарын башкарууда сизге керек эмеспи?
Бирок PostgreSQL 12 муну менен эле токтоп калбайт: жаңы функциялар жана өркүндөтүүлөр менен тиркемелер жакшыраак иштейт, жана сизге керек болгон нерсе - жаңыртуу!
(Жакшы, балким, индекстерди кайра түзөсүз, бирок бул чыгарылышта биз көнгөндөй коркунучтуу эмес.)
PostgreSQLди жаңыртуу жана керексиз ызы-чуу жок олуттуу жакшыртуулардан ырахат алуу сонун болот. Бир нече жыл мурун мен PostgreSQL 9.4тен PostgreSQL 10го жаңыртууну карап чыктым жана PostgreSQL 10догу жакшыртылган сурамдардын параллелизминин аркасында тиркеме кантип ылдамдагандыгын көрдүм. Эң негизгиси менден дээрлик эч нерсе талап кылынган жок (конфигурация параметрин коюп эле коюңуз) max_parallel_workers).
Макул, тиркемелер жаңыртылгандан кийин дароо жакшы иштегенде ыңгайлуу. Жана биз колдонуучуларды кубантуу үчүн абдан аракет кылабыз, анткени PostgreSQLде алардын саны барган сайын көбөйүүдө.
Кантип PostgreSQL 12ге жөнөкөй жаңыртуу сизди бактылуу кыла алат? Мен азыр айтам.
Негизги индекстөө жакшыртуулар
Индекссиз, маалымат базасы алыска барбайт. Башка кантип маалыматты тез таба аласыз? PostgreSQL негизги индекстөө системасы деп аталат . Индекстин бул түрү сактоо тутумдары үчүн оптималдаштырылган.
Биз жөн гана операторду колдонобуз CREATE INDEX ON some_table (some_column), жана PostgreSQL индексти жаңыртып туруу үчүн көп иштерди аткарат, ал эми биз ар дайым маанилерди киргизип, жаңыртып жана жок кылабыз. Баары өзүнөн-өзү иштейт, сыйкырдуу сыяктуу.
Бирок PostgreSQL индекстеринде бир көйгөй бар - алар жана кошумча диск мейкиндигин ээлеп, маалыматтарды издөө жана жаңыртуу ишин азайтат. «Шипиш» демекчи, индекс структурасын эффективдүү эмес кармап туруу. Бул - же жок болушу мүмкүн - ал жок кылган таштанды түтүкчөлөрү менен байланыштуу болушу мүмкүн (маалымат үчүн Питер Гаганга рахмат))). Индекс жигердүү өзгөрүп жаткан жумуш жүктөмдөрүндө өзгөчө байкалат.
PostgreSQL 12 B-дарагы индекстеринин иштешин бир топ жакшыртат жана TPC-C сыяктуу эталондор менен эксперименттер азыр орто эсеп менен 40% га азыраак орун колдонуларын көрсөттү. Эми биз B-дарактын индекстерин сактоого гана эмес (башкача айтканда, жазуу операцияларына), ошондой эле маалыматтарды алууга да азыраак убакыт короттук, анткени индекстер кыйла азыраак.
Таблицаларын активдүү жаңыртуучу тиркемелер - адатта OLTP тиркемелери () - дискти колдонот жана суроо-талаптарды алда канча эффективдүү иштетет. Дисктеги мейкиндик канчалык көп болсо, инфраструктураны жаңыртпастан маалымат базасы ошончолук көбүрөөк мейкиндикке ээ.
Кээ бир жаңылоо стратегиялары бул артыкчылыктардан пайдалануу үчүн B-дарактын индекстерин кайра курууну талап кылат (мис. индекстерди автоматтык түрдө калыбына келтирбейт). PostgreSQLдин мурунку версияларында таблицаларда чоң индекстерди кайра куруу олуттуу иштебей калууга алып келген, анткени бул аралыкта өзгөртүүлөрдү киргизүү мүмкүн эмес. Бирок PostgreSQL 12 дагы бир сонун өзгөчөлүккө ээ: эми сиз буйрук менен параллелдүү индекстерди калыбына келтире аласыз толугу менен токтоп калуудан качуу үчүн.
PostgreSQL 12де индекстөө инфраструктурасында башка жакшыртуулар бар. кандайдыр бир сыйкыр бар болгон дагы бир нерсе - , aka WAL (алдыга жазуу журналы). Алдын ала жазуу журналы PostgreSQLдеги ар бир транзакцияны ката жана репликациялоодо жазат. Тиркемелер аны архивдөө жана . Албетте, алдын ала жазуу журналы дискке жазылат, бул иштөөгө таасир этиши мүмкүн.
PostgreSQL 12 индексти куруу учурунда GiST, GIN жана SP-GiST индекстери тарабынан түзүлгөн WAL жазууларынын кошумча чыгымын азайтты. Бул бир нече олуттуу пайдаларды берет: WAL жазуулары дискте азыраак орун ээлейт жана маалыматтар кырсыктан калыбына келтирүү же өз убагында калыбына келтирүү сыяктуу тезирээк ойнотулат. Эгер сиз тиркемелериңизде мындай индекстерди колдонсоңуз (мисалы, PostGIS негизиндеги геомейкиндиктик тиркемелер GiST индексин көп колдонушат), бул дагы бир өзгөчөлүк, ал сиз тараптан эч кандай күч-аракет жумшабастан тажрыйбаны жакшыртат.
Бөлүү - чоңураак, жакшыраак, тезирээк
PostgreSQL 10 киргизилген . PostgreSQL 11де аны колдонуу оңой болуп калды. PostgreSQL 12де бөлүмдөрдүн масштабын өзгөртө аласыз.
PostgreSQL 12де бөлүү тутумунун иштеши кыйла жакшырды, айрыкча таблицада миңдеген бөлүктөр бар болсо. Мисалы, эгер суроо миңдеген таблицадагы бир нече бөлүмгө гана таасир этсе, анда ал бир топ тезирээк аткарылат. Иштин майнаптуулугу суроонун бул түрлөрү үчүн эле жакшыртылган эмес. Ошондой эле бир нече бөлүмдөрү бар таблицаларда INSERT операциялары канчалык ылдамыраак экенин байкайсыз.
Колдонуу менен маалыматтарды жаздыруу - Баса, бул эң сонун жол жана бул жерде бир мисал — PostgreSQL 12де бөлүнгөн таблицалар да натыйжалуураак болуп калды. COPY менен баары тез болчу, бирок PostgreSQL 12де ал такыр учат.
Бул артыкчылыктардын аркасында PostgreSQL сизге дагы чоңураак маалымат топтомдорун сактоого жана аларды алууну жеңилдетет. Жана сиз тараптан эч кандай аракет жок. Эгерде тиркемеде убакыт сериясынын маалыматтарын жазуу сыяктуу көптөгөн бөлүмдөр болсо, жөнөкөй жаңыртуу анын иштешин кыйла жакшыртат.
Бул так "жаңыртуу жана ырахат алуу" жакшыруусу болбосо да, PostgreSQL 12 бөлүү менен иштөө ырахаттуу кылып, бөлүнгөн таблицаларга шилтеме берген чет өлкөлүк ачкычтарды түзүүгө мүмкүндүк берет.
WITH суроолор бир топ жакшырды
качан (aka CTE, ака WITH суроо), мен жөнүндө макала жазууга чыдай албадым . Бул колдонмону тездеткен өзгөчөлүктөрдүн бири. Албетте, сиз CTE колдонбосоңуз.
Мен көбүнчө SQLге жаңы келгендер CTEлерди колдонгонду жакшы көрөм, эгер сиз аларды кандайдыр бир жол менен жазсаңыз, сиз чындап эле императивдик программа жазып жаткандай сезилет. Жеке мен бул суроолорду кайра жазууну жактырчумун жок CTE жана өндүрүмдүүлүгүн жогорулатуу. Азыр баары башкача.
PostgreSQL 12 сизге терс таасирлери жок CTEнин белгилүү бир түрүн киргизүүгө мүмкүндүк берет (SELECT), сурамдын аягына жакын бир жолу гана колдонулат. Эгерде мен кайра жазган CTE сурамдарына көз салып турсам, алардын көбү ушул категорияга кирмек. Бул иштеп чыгуучуларга так код жазууга жардам берет, ал азыр да тез иштейт.
Мындан тышкары, PostgreSQL 12 эч нерсе кылбастан, SQL аткарылышын оптималдаштырат. Мен азыр мындай сурамдарды оптималдаштыруунун кереги жок болсо да, PostgreSQL суроону оптималдаштыруу боюнча ишин улантып жатканы абдан жакшы.
Just-in-Time (JIT) - азыр демейки
Колдоо менен PostgreSQL 12 системаларында JIT компиляциясы демейки боюнча иштетилген. Биринчиден, сиз колдоо аласыз кээ бир ички операциялар үчүн, экинчиден, тандалма тизмелердеги туюнтмалар (эң жөнөкөй мисал x + y) менен сурамдар (таңдалгандан кийин бар), агрегаттар, WHERE пункттары бар туюнтмалар жана башкалар ишти жакшыртуу үчүн JITти колдоно алышат.
PostgreSQL 12де JIT демейки боюнча иштетилгендиктен, өндүрүмдүүлүк өзүнөн-өзү жакшырат, бирок мен суроонун натыйжалуулугун өлчөө жана кандайдыр бир нерсени тууралоо керекпи же жокпу, билүү үчүн JITти киргизген PostgreSQL 11де тиркемени сынап көрүүнү сунуштайм.
PostgreSQL 12деги калган жаңы функциялар жөнүндө эмне айтууга болот?
PostgreSQL 12 стандарттуу SQL/JSON маршруттук туюнтмаларын колдонуу менен JSON маалыматтарын изилдөө мүмкүнчүлүгүнөн баштап параметр менен көп факторлуу аутентификацияга чейин көптөгөн сонун жаңы функцияларга ээ. clientcert=verify-full, түзүлгөн мамычалар жана башкалар. Өзүнчө билдирүү үчүн жетиштүү.
PostgreSQL 10 сыяктуу эле, PostgreSQL 12 жаңыртылгандан кийин дароо эле жалпы натыйжалуулукту жакшыртат. Сиз, албетте, өзүңүздүн жолуңузга ээ боло аласыз - мен PostgreSQL 10 менен кылгандай, жакшыртууларды киргизүүдөн мурун, өндүрүш тутумунда окшош шарттарда тиркемени сынап көрүңүз. PostgreSQL 12 мен күткөндөн туруктуураак болсо дагы, тестирлөөдө жалкоо болбоңуз. колдонмолорду кылдаттык менен, аларды өндүрүшкө чыгарардан мурун.
Source: www.habr.com