PostgreSQL эсвэл MySQL: benchmark-ийн ялагч workload солигдоход өөрчлөгдөнө

PostgreSQL эсвэл MySQL-ийг шинэ системд сонгоход бүх ачаалалд түрүүлэх нэг сан байхгүй: холимог унших, бичих болон INSERT давамгайлбал PostgreSQL-ийг эхэлж үнэлэх үндэслэлтэй, харин мужийн уншилт давамгайлбал MySQL давуу гарч болно. ComputingForGeeks-ийн 2026 оны ижил VM дээрх sysbench хэмжилтэд PostgreSQL 17.9 ба MySQL 8.4.8 холимог ачаалалд 2,886 ба 436 TPS, зөвхөн уншихад 5,628 ба 5,400 TPS, INSERT-д 7,255 ба 2,206 TPS үзүүлж, холимог ачааллын p95 хоцролт нь 8.74 ба 90.78 мс байв. Энэ нь тухайн өгөгдөл, тохиргоо, зэрэгцээ хүсэлтийн үр дүн юм.

Харин Small Datum-ийн том серверийн бичил туршилтад PostgreSQL цэгэн хайлт болон бичилтэд, MySQL мужийн унших асуулгад илүү гарсан. Тэнд өөр төхөөрөмж, илүү том өгөгдөл, өөр тооны зэрэгцээ хэрэглэгч ашигласан учраас хоёр туршилтын TPS-ийг шууд зэрэгцүүлэх нь утгагүй. Шинэ системийн шийдвэрт өөрийн SELECT-ийн хэлбэр, унших ба бичих харьцаа, оргил үеийн хүлээлт илүү шууд хамаарна.

Ижил VM дээрх тоо юуг харуулж байна вэ?

Эхний туршилтад сангууд нэг виртуал машинд ээлжлэн ажиллаж, sysbench-ийн ижил асуулга, ижил хэмжээний өгөгдөл боловсруулсан. Хүсэлт үүсгэгч нь тухайн машиндаа байсан тул сүлжээний саатал хэмжилтэд ороогүй. Ийм зохион байгуулалт нь нэг орчны доторх ялгааг тодруулдаг ч бодит үйлчилгээний холболтын сан, холын сүлжээ, олон төрлийн SQL болон өгөгдөл өсөх үеийн зан төлөвийг бүрэн төлөөлөхгүй.

TPS нь нэг секундэд дууссан транзакц, хоцролт нь нэг хүсэлт дуусах хугацаа. p95 хоцролт гэдэг нь хүсэлтийн 95 хувь түүнээс хурдан дууссаныг илэрхийлнэ. Нэвтрэх, захиалга баталгаажуулах зэрэг хэрэглэгч хүлээдэг үйлдэлд энэ үзүүлэлт дундаж TPS-тэй адил чухал. Харин зөвхөн унших туршилтын нэг транзакц холимог туршилтынхтай адил ажил хийдэггүй тул хоёр төрлийн TPS-ийг хооронд нь хурдны шууд хэмжүүр болгох боломжгүй.

Уншилтын төрөл ба бичилтийн хувь

Холимог OLTP транзакцад SELECT, UPDATE, INSERT, DELETE нийлдэг. Мөр олохын зэрэгцээ өөрчлөлт баталгаажуулах, индекс шинэчлэх, зэрэгцээ бичилтийн зөрчлийг зохицуулах ажил орно. Зөвхөн унших туршилтад энэ ажлын ихэнх нь байхгүй учраас ижил VM-ийн хэмжилтэд хоёр сангийн зөрүү ойртсон. INSERT-ийн тусдаа үр дүн нь үйл явдлын бүртгэл их нэмдэг системд хэрэгтэй боловч олон мөрийг нэг транзакцаар бичих бодит урсгалыг заавал төлөөлөхгүй.

Нэг мөрийг түлхүүрээр авах, хугацааны интервалаар олон мөр унших, олон мөрийг нийлүүлэн тооцох нь бүгд «унших» боловч индекс ба гүйцэтгэлийн төлөвлөгөөнд өөр шаардлага тавина. Том серверийн туршилтад цэгэн хайлт PostgreSQL-д, агрегацтай болон агрегацгүй мужийн уншилт MySQL-д давуу гарсан нь энэ ялгааны жишээ. Хэрэв үйлчилгээний гол урсгал тайлангийн мужийн асуулга бол жижиг VM-ийн холимог OLTP дүнгээр тэр урсгалын ялагчийг урьдчилан тогтоож болохгүй. Харин хэрэглэгчийн үйлдэл бүр хэд хэдэн мөр өөрчилдөг бол холимог транзакцын хоцролт илүү чухал.

Зэрэгцээ хүсэлтэд MVCC хэрхэн нөлөөлөх вэ?

PostgreSQL-ийн MVCC-ийн албан тайлбараар энгийн уншилтаас үүсэх түгжээ бичилтийн түгжээтэй зөрчилдөхгүй; уншигч ба бичигч бие биеэ хүлээлгэх шаардлага багасна. Энэ нь олон хэрэглэгчтэй үед ашигтай боловч нэг мөрийг зэрэг өөрчилж буй транзакцуудын бүх зөрчлийг арилгахгүй. Урт транзакц, ижил түлхүүрт давхцсан шинэчлэлт, сонгосон тусгаарлалтын түвшин нь дараалал үүсгэж болно.

MySQL-ийн InnoDB ч хуучин мөрийн хувилбар болон undo бүртгэл ашиглан тогтвортой уншилт, буцаалтыг хэрэгжүүлдэг. Тиймээс VM-ийн TPS зөрүүг нэг сан MVCC-тэй, нөгөө нь түүнгүй гэсэн тайлбараар шийдэх аргагүй. Зэрэгцээ ачааллыг харьцуулахдаа холболтын тоо, транзакцын урт, ижил мөр рүү чиглэх бичилтийн давтамж, түгжээ хүлээсэн хугацааг хамт тэмдэглэх нь механизмыг ойлгоход тусална. Зэрэгцээ хүсэлтийн тоо нэмэгдэхэд TPS өсөөд хоцролт огцом нэмэгдвэл тухайн тохиргооны хүчин чадлын хязгаар ойртож байж болно.

JSON, тохиргоо ба шилжих өртөг

JSON хадгалдаг эсэхээс илүү доторх талбараар яаж шүүх, эрэмбэлэх, шинэчлэх нь сонголтыг өөрчилнө. PostgreSQL-ийн jsonb болон MySQL-ийн JSON дээр асуулгын илэрхийлэл, индексийн загварыг тус тусад нь боловсруулах шаардлагатай. MySQL-ийн JSON төрлийн зааварт JSON баганыг шууд индексжүүлэхийн оронд утгыг гаргасан generated column-д индекс үүсгэх, массивын хувьд олон утгат индекс хэрэглэх аргыг тайлбарладаг. Ижил баримт оруулсан ч индексгүй талбарын хайлтыг индексжүүлсэн асуулгатай харьцуулбал сангийн биш, схемийн ялгаа хэмжигдэнэ.

Тохиргоог тэнцүүлэхдээ санах ойн хэмжээ адил байх нь эхлэл төдий. Индекс, өгөгдлийн төрөл, баталгаажуулалтын журам, транзакцын тусгаарлалт, холболтын сан өөр байвал ижил SQL ч өөр зардалтай. Бодит системд драйвер, ORM, нөөцлөлт ба сэргээх дадал, багийн мэддэг ажиллагаа мөн шилжих өртөгтэй. MySQL-ээс PostgreSQL рүү нүүхэд SQL-ийн хэллэг, өгөгдлийн төрөл, stored procedure, хэрэглээний кодын таамаглал, тайлангийн асуулгыг тус бүр шалгана. Одоогийн сангийн хоцролт үйлчилгээний шаардлагад багтаж байвал ганц лабораторийн дүн шилжилтийн ажлыг дангаараа зөвтгөхгүй.

Өөрийн өгөгдлөөр sysbench-ийг давтах нь

Бэлэн OLTP тест нь харьцуулах эхлэл; шийдвэрлэх хэмжилтэд үйлчилгээний бодит хүснэгтийн хэмжээ, түлхүүрийн тархалт, түгээмэл асуулгыг оруулах хэрэгтэй. Дараах дараалал нь ялгаа хаанаас гарсныг буцааж тогтоох боломж өгнө:

1. Хоёр сангийн хувилбар, CPU, санах ой, хадгалах төхөөрөмж, өгөгдлийн хэмжээ, индекс, транзакцын тусгаарлалт, баталгаажуулалтын тохиргоог тэмдэглэ. Нэг машин ашиглавал сангуудыг ээлжлэн ажиллуул; хоёр машин ашиглавал нөөцийн нөхцөлийг ижил болго.
2. Ижил хүснэгт, ойролцоо өгөгдлийн тархалт бэлтгээд sysbench-ийн oltp_read_write, oltp_read_only, oltp_insert туршилтыг тусад нь ажиллуул. PostgreSQL-д db-driver=pgsql сонголтыг зааж, MySQL талд тохирох драйверыг хэрэглэ. Дараа нь хамгийн чухал бодит SQL-ээ тусад нь хэмж.
3. Зэрэгцээ холболтыг багаас оргил ачаалал хүртэл хэд хэдэн түвшинд өөрчил. Түвшин бүрт TPS, дундаж болон p95 хоцролт, алдаа, CPU, санах ой, дискний ачааллыг хамтад нь хадгал; нэвтрүүлэх чадвар нэмэгдэхэд хүлээлт хэрхэн өөрчлөгдөх нь сонголтын гол хэсэг.
4. Халаалтын хугацааг хэмжилтээс ялгаж, туршилтыг давт, ажиллуулах дарааллыг соль. Кэш дүүрсэн эсэх, арын ажиллагаа, өгөгдөл өөрчлөгдсөн эсэхийг тэмдэглэснээр сангийн бодит ялгааг туршилтын дарааллын нөлөөнөөс салгана.

Сонголтыг хамгийн их TPS-ээр бус, хэрэглэгчид мэдрэгдэх хоцролтын босго, шаардлагатай нэвтрүүлэх чадвар, JSON асуулгын төлөвлөгөө, ажиллагаа болон шилжилтийн зардлаар эцэслэнэ. Холимог бичилт давамгайлбал PostgreSQL-ийг, мужийн уншилт эсвэл одоо байгаа MySQL экосистем шийдвэрлэх хүчин зүйл бол MySQL-ийг өөрийн өгөгдөл дээр ижил нөхцөлөөр хэмжих нь зохистой.

Мөн уншаарай:

• SQLite эсвэл PostgreSQL: нэг writer хүрэлцэхгүй болох мөчид сонголт өөрчлөгдөнө
• Paddle эсвэл Stripe: 5% шимтгэл татварын ажлыг хамт худалдаж авна
• RAG эсвэл fine-tuning: шинэ баримтыг загварт цээжлүүлэх шаардлагагүй