SQLite эсвэл PostgreSQL: нэг writer хүрэлцэхгүй болох мөчид сонголт өөрчлөгдөнө

Аппликейшн ба өгөгдлийн файл нэг сервер дээр байж, бичих хүсэлтүүд богино хугацаанд ээлжээ хүлээж чадвал SQLite тохиромжтой. SQLite-ийн WAL горимын тайлбар уншилт бичилттэй зэрэг явагддаг ч нэг өгөгдлийн файлд нэг агшинд нэг л бичигч ажилладгийг тодорхойлдог. Тиймээс хэрэглэгчийн нийт тооноос илүү бичилтүүд давхцах үед хэр удаан хүлээж байгааг анхаарах хэрэгтэй.

Олон аппликейшний сервер нэг төвлөрсөн санд хандах шаардлагатай, эсвэл бичилтийг ээлжлүүлэхэд хариу өгөх хугацаа зөвшөөрсөн хэмжээнээс давж байвал PostgreSQL илүү тохирно. PostgreSQL-ийн MVCC тайлбар өгөгдлийн хувилбар ашиглан олон сессийн ажиллагааг зохицуулж, уншилт ба бичилтийн түгжээний зөрчлийг багасгадаг. Гэхдээ ижил мөрийг зэрэг өөрчлөх гүйлгээнүүд хоорондоо хүлээлт үүсгэж болно.

Нэг сервер дээр SQLite хэзээ хүрэлцэх вэ?

Дотоод хэрэгсэл, шинэ аппликейшн эсвэл нэг сервер дээр ажиллах үйлчилгээнд SQLite-ийн гол давуу тал нь SQL ажиллуулдаг код өгөгдлийн файлаа шууд нээдэг энгийн зохион байгуулалт юм. Тусдаа өгөгдлийн сангийн сервер ажиллуулах, түүнтэй холболт удирдах шаардлагагүй. Олон хүн зэрэг жагсаалт үзэж байна гэдэг нь дангаараа өөр хөдөлгүүр хэрэгтэй гэсэн үг биш; нэг файлд давхцан ирэх бичих гүйлгээ шийдвэрт илүү нөлөөлнө.

Нөхцөлт жишээ авбал, ажилтнууд ихэвчлэн бүртгэл хайж, хааяа шинэ мөр нэмдэг дотоод системд бичилтийн хүлээлт мэдэгдэхгүй өнгөрч болно. Харин гүйлгээ нээлттэй байх зуур аппликейшн удаан тооцоолол эсвэл өөр үйлчилгээний хариу хүлээвэл дараагийн бичигчийн ээлж уртасна. Өгөгдлийн файл жижиг байсан ч ийм саатал гарч болно. Ийм үед эхлээд гүйлгээний үргэлжлэх хугацааг харах нь файлын хэмжээгээр шийдэхээс ашигтай.

Сүлжээний зааг сонголтыг хэрхэн өөрчилдөг вэ?

Олон машин нэг SQLite файлыг сүлжээний файлын системээр шууд нээхээр төлөвлөсөн бол клиент–сервер өгөгдлийн сан сонгох үндэслэл бий. SQLite-ийн хэрэглээ сонгох заавар олон клиент сүлжээгээр нэг санд шууд SQL хүсэлт илгээх үед клиент–сервер хөдөлгүүр зөвлөж, сүлжээний файлын системийн саатал болон файлын түгжээний найдвартай байдлыг шалтгаан болгон тайлбарладаг. PostgreSQL-д аппликейшнүүд өгөгдлийн файлыг хуваалцан нээх бус, өгөгдлийн сангийн сервертэй холбогдоно.

Эцсийн хэрэглэгч утас эсвэл хөтчөөс API-д хандаж байгаа нь SQLite файлыг алсаас шууд нээж байна гэсэн үг биш. API доторх SQL ажиллуулдаг код болон өгөгдлийн файл нэг машин дээр байвал SQLite хэрэглэж болно. Харин үйлчилгээний хэд хэдэн сервер нэг төвлөрсөн өгөгдөлд бичих ёстой бол сервер бүрт тусдаа локал файл байрлуулах нь тэдгээрт автоматаар нэгдсэн өгөгдөл өгөхгүй. Энд шийдвэрлэх асуулт нь хэрэглэгч хаана байгаад бус, SQL ажиллуулдаг код өгөгдлөөс сүлжээгээр тусгаарлагдсан эсэхэд оршино.

Уншилт давамгай ачаалалд юу саад болдог вэ?

Унших хүсэлт олон, бичилт богино бөгөөд цөөн байвал SQLite-ийн нэг бичигчийн хязгаар шууд хүндрэл болохгүй байж болно. WAL горимд уншигч бичигч хоёр зэрэг ажиллах боломжтой. Гэхдээ удаан нээлттэй унших гүйлгээ checkpoint дуусахад саад хийж, WAL файл томроход уншилтын ажил нэмэгдэх боломжтой. Иймээс уншилт давамгай гэдгийг зөвхөн хүсэлтийн тоогоор дүгнэх нь хангалтгүй.

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

Олон бичигчтэй үед бодит босго хаана байна вэ?

PostgreSQL руу шилжих бүх үйлчилгээнд таарах хэрэглэгчийн тооны босго байхгүй. Нэг хэрэглэгч олон бичих хүсэлт илгээж болох бол олон хэрэглэгч зөвхөн уншиж болно. Тухайн үйлчилгээний босго нь оргил үед бичих гүйлгээнүүд ээлжээ хүлээсэн ч зөвшөөрсөн хариу өгөх хугацаанд багтаж, шаардлагатай нийт үйлдлийн хурдыг хадгалж чадаж байна уу гэдгээр тогтоно.

Үүнийг ялгахын тулд бодит үйлдэлтэй төстэй ачаалал дээр зэрэг бичих хүсэлтийг өсгөхөд p50, удаан хүсэлтийн хугацаа, нийт дууссан бичилт хэрхэн өөрчлөгдөхийг хэмжинэ. Хүлээлт нэмэгдэж байхад SQLite-ийн нийт хурд өсөхөө больж, үйлчилгээний хугацааны шаардлага зөрчигдвөл ижил ачааллыг PostgreSQL дээр харьцуулах үндэслэл бүрдэнэ. Үүнээс өмнө гүйлгээний дотор хийж буй шаардлагагүй ажлыг богиносгох боломжийг шалгах хэрэгтэй: удаан гүйлгээг хөдөлгүүр солих нь өөрөө богиносгохгүй.

PostgreSQL олон зэрэг бичилт боловсруулах боломжтой ч бүх бичилт бие биеэсээ хамааралгүй гэсэн үг биш. Нэг мөрийг шинэчлэх зэрэг хүсэлтүүд түгжээ хүлээнэ; аппликейшний өөрийн гүйлгээний бүтэц ч сааталд нөлөөлнө. Иймээс сонголтыг зөвхөн нийт throughput-ээр хийхэд хэрэглэгчид мэдрэгдэх удаан хүсэлтүүд далд үлдэж болзошгүй.

Benchmark-ийн тоог хэрхэн ойлгох вэ?

Нэг машин, нэг SSD дээрх давтан ажиллуулах боломжтой benchmark-д нэг холболтоор дараалсан INSERT хийхэд SQLite секундэд 23,403, PostgreSQL 7,740 үйлдэл гүйцэтгэсэн; харин PostgreSQL-ийн 16 зэрэг холболтын туршилт секундэд нийт 35,370 үйлдэлд хүрсэн. Сүүлийн хоёр тоог ижил зэрэг бичилтийн шууд харьцуулалт гэж үзэж болохгүй: SQLite-ийн дурдсан дүн нэг холболтын дараалсан бичилт, PostgreSQL-ийн өндөр дүн олон холболтын нийлбэр хурд юм.

Туршилт SQLite-ийг WAL горимд, PostgreSQL-ийг мөн тэр машин дээр суулгаж, өөр өөр драйвер болон бичилтийн баталгаажуулалтын тохиргоотой ажиллуулсан. Иймээс дүн нь тухайн орчин дахь нэг хүсэлтийн саатал ба олон холболтын нийт хурд өөр чиглэлд өөрчлөгдөж болохыг харуулна. Алсын PostgreSQL сервер хүртэлх сүлжээний саатал, олон аппликейшний серверээс зэрэг бичих ачаалал, том өгөгдөл болон нийлмэл асуулгуудыг энэ туршилт хэмжээгүй. Эдгээр дүнг өөр үйлчилгээний шилжих бэлэн босго болгох боломжгүй.

Дөрвөн нөхцөлөөр сонголтоо гаргах нь

• Нэг сервер, богино бичилт: SQL ажиллуулдаг код өгөгдлийн файлтайгаа нэг машин дээр, оргил үеийн бичилтийн хүлээлт зөвшөөрсөн хугацаанд багтаж байвал SQLite тохирно.
• Уншилт давамгай: уншигч олширсныг дангаар нь шилжих шалтгаан болгохгүй; бичилтийн хүлээлт, удаан унших гүйлгээ, WAL-ийн ажиллагааг хамт харна.
• Сүлжээтэй өгөгдлийн сан: олон аппликейшний сервер нэг төвлөрсөн санд SQL түвшинд хандах шаардлагатай бол PostgreSQL-ийн клиент–сервер зохион байгуулалт тохирно.
• Олон зэрэг бичигч: бичилтүүд ээлжээ хүлээснээр хугацааны шаардлага зөрчигдөж, ижил ачаалалд PostgreSQL шаардлагыг хангаж байвал шилжих үндэслэл бий.

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

• n8n эсвэл Make: сарын үнэ биш, алхам тоолох арга нь сонголтыг шийднэ
• n8n-ийг өөрийн серверт байрлуулах нь: нэг encryption key бүх нууцыг аварна
• AI агентыг prompt injection-оос хамгаалах нь: prompt дангаараа хүрэлцэхгүй