SQLite эсвэл PostgreSQL: ганц connection-ийн хурд олон writer дээр эргэнэ

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

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

Нэг холболтод SQLite яагаад хурдан байж болох вэ?

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

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

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

Benchmark-ийн давуу тал ямар нөхцөлд эргэсэн бэ?

André Casal-ийн нийтэлсэн benchmark-д нэг холболтын дараалсан INSERT-д SQLite секундэд 23 403, PostgreSQL 7 740 үйлдэл гүйцэтгэсэн; PostgreSQL-ийн тусдаа зэрэгцээ бичилтийн сорилд 4, 8, 16, 32 холболтоор секундэд харгалзан 23 290, 31 856, 35 370, 24 371 үйлдэл хэмжсэн. Энд нэг холболтын туршилтад SQLite ойролцоогоор гурав дахин илүү гарцтай байсан бол PostgreSQL-ийн олон холболтын нийт гарц өсөж, дараа нь буурсан. Сүүлийн хоёр тоо нь ижил ачааллын SQLite ба PostgreSQL-ийн шууд харьцуулалт биш.

Туршилтын хоёр тал нэг машин, нэг SSD, ижил хүснэгтийн бүтэц ашигласан. SQLite файл дээр WAL горим, synchronous=NORMAL тохиргоотой, PostgreSQL локал суулгалттай, synchronous_commit=on тохиргоотой ажилласан; ашигласан драйверууд ч өөр. Энэ ялгаа нь хадгалалтын баталгаажуулалт, холболтын зардлыг үр дүнд хамтад нь оруулж байгаа тул хүснэгтийн тоог өгөгдлийн сангийн хөдөлгүүр тус бүрийн цэвэр хурд гэж үзэж болохгүй.

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

Уншигч олшрох, бичигч олшрох хоёрын ялгаа

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

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

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

Нөхцөлт жишээ авбал, захиалгын API жагсаалт унших хүсэлт олонтой боловч шинэ захиалга богино транзакцаар хадгалдаг байж болно. Тэнд SQLite-ийн уншигч ба ганц бичигчийн зэрэг ажиллагаа хангалттай байх магадлалтай. Харин олон ажиллах процесс нэгэн зэрэг төлөв өөрчилж, бичилтийн оочер тогтмол уртсаж байвал PostgreSQL-ийн зэрэгцээ ажиллагаа илүү үнэ цэнтэй болно. Шийдэх үзүүлэлт нь холболт нээгдсэн тоо биш, яг зэрэг бичихийг оролдсон транзакцын ачаалал юм.

Олон сервер хэрэгтэй үед файлын байрлал юу өөрчилдөг вэ?

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

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

Файлтай ажиллах нь нөөцлөлтийг орлохгүй. Ялангуяа WAL идэвхтэй үед үндсэн файлтай холбоотой нэмэлт төлөв бий тул ажиллаж буй санг хуулбарлах аргыг нягтлах шаардлагатай. PostgreSQL төвлөрсөн сангийн үйлчилгээ өгдөг ч серверийг ажиллуулах, хянах өртөг нэмнэ. Хоёр талын нийт өртгийг зөвхөн нэг асуулгын миллисекундээр дүгнэхэд энэ ялгаа алга болно.

Шилжих босгыг ямар ачаалал тогтоох вэ?

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

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

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

• SQLite эсвэл PostgreSQL: нэг writer хүрэлцэхгүй болох мөчид сонголт өөрчлөгдөнө
• PostgreSQL эсвэл MySQL: benchmark-ийн ялагч workload солигдоход өөрчлөгдөнө
• Webflow эсвэл Framer: хурдан landing page өсөх CMS-ийг орлохгүй