Postgres թաքուն չէ։ Թաքունը ձեր պահոցն է։ POSETTE 2026-ի խոսքի ամփոփում

Բենչմարկի նախապատրաստում

POSETTE 2026-ում Սեյ Սրիրամպուրը ներկայացրել է „Postgres Isn't Slow. Your Storage Is“ հեշտագիրը, որտեղ քննարկվել է, թե ինչպես է պահոցության աշխատանքը ազդում PostgreSQL-ի վրա մեծացնելով ժամանակ։ Նախադրծophage գնահատվել էին հինգ հաճախ խնդիրներ՝ թեթև ինգեստ, անհամարոտ կարդալու լատենտ 播放, ավտովակուումի ժամանակաչափ, թեթև checkpoint-եր և լոգիկական ռեպլիկացիայի ժամանակադրություն։ Այս խնդիրները հաճախ ունեն մեկը և նույն արմատը պահոցության սխալումներում, երբ աշխատող բազմությունը գերազանցում է հասանելի հիշքը։

Պահոցը որպես փոփոխականը առանձնացնելու համար, բենչմարկում օգտագործվել էին հինգ ին'identical PostgreSQL կլաստերներ՝ չորս instance-store NVMe-ზე և չորս բազային gp3 EBS-ზე, 3000 IOPS-ով։ Յուրաքանչյուր կլաստեր աշխատում էր m6id.4xlarge ınstances-ով 16 vCPU-ով, 64 GiB RAM-ով և 16 GiB shared_buffers-ով։ Աշխատային բեռը օգտագործում էր 482 GiB pgbench_accounts heap-ը, որը պարունակում էր 3,3 միլիարդ տողեր, և հինգ րոպե izved կատարում էր բարձր զուգահեռ random-UPDATE բեռը 64 кліենտով և 16 worker thread-ով։

Արդյունքները ինչը ցույց տուին

Բենչմարկը NVMe կլաստերների համար միջին 16 030 TPS ցույց տվեց, EBS-ում՝ 1 734 TPS, իսկ 9,24-ժեր տարբերություն։ Ցանցի միջին լատենտ 36,9 ms-ից 4,0 ms-ին նվազեց։ Տեխնիկական օպերացիաների համար NVMe-ն 10 GB bloat-ում VACUUM-ը 366 վայրկյանովarkers, EBS-ում՝ 964 վայրկյանով, իսկ 10 GB լոգիկական ռեպլիկացման backlog-ը 139 վայրկյանով ավարտվեց 238-ի տեղը։

Լատենտի վերլուծությունը ցույց տվեց, որ էջերի կարդալը EBS-ում մոտ 19 ms համադրվում էր, NVMe-ում՝ 0,3 ms, WAL fsync-ին 11 ms ավելացավ 1,5 ms-ի փոխարեն, իսկ lock-ի և scheduler-ի overhead-ը 5 ms կազմեց 0,2 ms-ի փոխարեն։ CPU-ի աշխատանքը երկու դեպքերում մոտավոր իրն էր, մոտ 2 ms։ pg_stat_activity-ի snapshot-ը ցույց տվեց, որ EBS-ի 64 backend-ից 29-ը սպասում էր IO:DataFileRead-ին, NVMe-ում՝ հինգ։ 240-վայրկյան պրոֆիլավորման պատուհաններում NVMe հոստը այնուհետև 2 253 CPU-վայրկյան հավաքեց, EBS հոստը՝ միայն 251, ինչը նշանակում է, որ EBS պրոցեսները ավելի շատ ժամանակ են տرفية CPU-ի դուրս, պահոցի mah.:

NVMe-ზე հիմնված Postgres պրոդակշնում

Այս խոսքում ներկայացված պրոդակշն արխիտեկտուրան մեկնաբանում է instance-store NVMe-ի տիր հիվանդությունները երեք պահանջներով։ Կատարեք տվյալների բազայի ռեպլիկացիան, որպեսզի սերվիսը կարողանա vượtել node-ի կորուստը, պահեք բեկապները և վերականգնման տվյալները առանձին մեքենաների դուրս, և պլանավորեք յուրաքանչյուր instance type-ի համար հասանելի NVMe-ի հիման վրա։

Առաջին պատթերն է quorum-ան մտածած սինքրոն ռեպլիկացիան երկու standby կանդիդատներով, կոնֆիգուրացիա՝ օրինակ՝ ANY 1 (standby1, standby2), ինչը գործարքին թույլ է տալիս commit դառնա այնուհետև, երբ որևէ standby-ն ధաստատում է WAL-ը։ Դատաբազայի node-ների դուրս էլ գտնվող գործիքները, ինչպիսիք են WAL-G-ը, կարող են կատարել ֆիզիկական base backup-եր և անընդհատ WAL արխիվավորումը, նպատակ RPO վայրկյաններում։ Խոսքում հղում են տրվում Instacart-ի և Datadog-ի հանրային օրինակներին, որոնք նկարագրեցին PostgreSQL-ի աշխատանքը լոկալ NVMe-ով latency-sensitive բեռների համար։

Աղբյուրները: clickhouse.com