, "Дэлхийн хамгийн шилдэг нээлттэй эх сурвалжийн харилцааны мэдээллийн сан"-ын хамгийн сүүлийн хувилбар нь хэдхэн долоо хоногийн дараа гарах болно (хэрэв бүх зүйл төлөвлөгөөний дагуу байвал). Энэ нь жилд нэг удаа олон тонн шинэ боломж бүхий шинэ хувилбар гаргах ердийн хуваарийг дагаж мөрддөг бөгөөд үнэнийг хэлэхэд энэ нь гайхалтай юм. Тийм ч учраас би 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 индексүүд нэг асуудалтай байдаг - тэд мөн дискний нэмэлт зай эзэлдэг ба өгөгдөл хайх, шинэчлэх гүйцэтгэлийг бууруулдаг. "Bloat" гэж би индексийн бүтцийг үр дүнгүй байлгахыг хэлж байна. Энэ нь устгадаг хог хаягдалтай холбоотой эсвэл үгүй ч байж болно (мэдээлэл өгсөн Питер Гаганд баярлалаа))). Индекс идэвхтэй өөрчлөгдөж байгаа ажлын ачаалалд индексийн хавдах нь ялангуяа мэдэгдэхүйц юм.
PostgreSQL 12 нь B-tree индексүүдийн гүйцэтгэлийг ихээхэн сайжруулдаг бөгөөд TPC-C зэрэг жишиг үзүүлэлтүүдтэй хийсэн туршилтууд нь одоо дунджаар 40% бага зай ашиглаж байгааг харуулсан. Одоо бид зөвхөн B-tree индексийг хадгалахад (өөрөөр хэлбэл бичих үйлдлүүд) төдийгүй өгөгдлийг сэргээхэд бага цаг зарцуулдаг, учир нь индексүүд нь хамаагүй бага байдаг.
Хүснэгтээ идэвхтэй шинэчилдэг програмууд - ихэвчлэн 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 асуултууд илүү сайжирсан
Хэзээ (CTE, WITH query гэх мэт) тухай нийтлэл бичихийг тэсэн ядан хүлээж байлаа . Энэ нь програмыг хурдасгах боломжуудын нэг юм. Мэдээжийн хэрэг та CTE-г ашиглахгүй бол.
SQL-д шинээр орсон хүмүүс CTE-г ашиглах дуртай байдгийг би олонтаа олж хардаг; хэрвээ та тэдгээрийг тодорхой байдлаар бичвэл зайлшгүй шаардлагатай програм бичиж байгаа юм шиг санагддаг. Би хувьдаа эдгээр асуултуудыг тойрон гарахын тулд дахин бичих дуртай байсан ямар ч CTE болон бүтээмжийг нэмэгдүүлэх. Одоо бүх зүйл өөр болсон.
PostgreSQL 12 нь танд тодорхой төрлийн CTE-г гаж нөлөөгүйгээр оруулах боломжийг олгодог.SELECT), хүсэлтийн төгсгөлд зөвхөн нэг удаа ашиглагддаг. Хэрэв би дахин бичсэн CTE асуулгыг хянаж байвал ихэнх нь энэ ангилалд багтах болно. Энэ нь хөгжүүлэгчдэд ойлгомжтой код бичихэд тусалдаг бөгөөд одоо бас хурдан ажилладаг.
Түүнээс гадна PostgreSQL 12 нь танд юу ч хийхгүйгээр SQL-ийн гүйцэтгэлийг өөрөө оновчтой болгодог. Хэдийгээр би одоо ийм асуулга оновчтой болгох шаардлагагүй ч PostgreSQL асуулгын оновчлол дээр үргэлжлүүлэн ажиллаж байгаа нь гайхалтай юм.
Яг цаг хугацаанд нь (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 нь миний бодож байснаас илүү тогтвортой байсан ч туршилт хийхдээ залхуу байж болохгүй. програмуудыг үйлдвэрлэлд гаргахаас өмнө сайтар .
Эх сурвалж: www.habr.com