SQLite или PostgreSQL: један уписивач побеђује — док не стигне гужва

Изаберите SQLite када апликација користи локалну датотеку базе, а кратки уписи не стварају приметан ред чекања. За заједничку базу у коју више инстанци апликације активно пише, PostgreSQL је прикладнији избор. Документација SQLite о изолацији утврђује пресудно ограничење: у исту базу у датом тренутку пише само један уписивач, иако више веза може бити отворено.

Један уписивач није исто што и спора апликација. Ако су трансакције кратке и не преклапају се много, уграђена база избегава комуникацију са засебним серверским процесом. Када уписи из веб захтева, позадинских послова и увоза података почну да се преклапају, за избор постају важнији чекање и потребно време одговора него брзина једног SQL исказа.

Шта показује тест са једном везом

У репродуктивном тесту Андреа Касала SQLite је при секвенцијалним уписима са једном везом достигао 23.403 операције у секунди, а PostgreSQL 7.740; медијана латенције била је 0,023 ms према 0,096 ms; у одвојеном тесту конкурентних уписа PostgreSQL је са 16 веза достигао 35.370 операција у секунди. Први резултат говори о појединачним локалним уписима, а други о протоку засебне серверске конфигурације под конкурентним оптерећењем.

Обе базе су у тесту радиле на истом рачунару и SSD-у. SQLite је користио датотеку, WAL режим и synchronous=NORMAL, док је PostgreSQL радио као локално инсталиран сервер са synchronous_commit=on; разликовали су се и управљачки програми. Тест није обухватио мрежни пут до удаљеног сервера, нити је мерио више SQLite уписивача који чекају исту датотеку. Зато већи PostgreSQL проток у одвојеном сценарију није измерена тачка на којој би свака SQLite апликација морала да промени базу.

Шта се дешава када уписи стигну заједно

Више процеса на истом домаћину може да отвори исту SQLite базу, али њихове трансакције уписа добијају ред. WAL дозвољава читаоцима да наставе да читају свој снимак података док упис траје; други уписивач ипак мора да сачека. Ако трансакција обухвати спор посао ван самог SQL исказа, она дуже задржава право уписа и повећава чекање наредних захтева.

Документација PostgreSQL о MVCC-у описује верзије података захваљујући којима обична читања не блокирају уписе, нити уписи блокирају читања. Сервер може да обрађује конкурентне трансакције, али сукоб око истог реда или експлицитно закључавање и даље могу да произведу чекање. Предност је у томе што уписи у различите делове базе не морају сви да прођу кроз право једног SQLite уписивача.

Број регистрованих корисника слабо описује ово оптерећење. Апликација са много читалаца и повременим кратким уписима може добро да ради на SQLite-у. Мања апликација може да осети застој ако позадински посао држи трансакцију отвореном док истовремени веб захтеви чекају упис. Зато је корисније посматрати колико се уписи преклапају и колико дуго трају него број налога или величину датотеке.

Где је мерљива граница

Граница је тренутак када чекање на упис квари потребно време одговора при стварном вршном оптерећењу. За тај закључак треба раздвојити време проведено у реду од времена извршавања трансакције и пратити колико често апликација наилази на заузету базу. Ако ред расте и после скраћивања трансакција и разумног груписања уписа, ограничење једног уписивача постаје разлог за серверску базу. Сам број отворених веза није довољан показатељ.

Условни рачун показује зашто трајање држања права уписа мења исход: ако свака трансакција заузима уписивача 20 ms, непрекидно заузет уписивач теоријски може да заврши највише 50 таквих трансакција у секунди, пре осталих трошкова. То није измерен праг за SQLite. Другачије трансакције, груписање више измена у једну трансакцију и другачија опрема мењају резултат. Одлуку зато треба везати за сопствени ред чекања и захтевано време одговора, а поређење са PostgreSQL-ом извести под истим пословним оптерећењем.

Резервне копије и реплике решавају различите проблеме

SQLite поједностављује распоређивање једне локалне инстанце, али активну базу треба копирати доследним поступком. SQLite Online Backup API прави снимак активне базе и може да копира садржај у корацима, тако да извор не мора бити закључан током целог поступка. Резервна копија служи за враћање података; сама по себи не даје другу инстанцу која непрекидно прати промене и преузима рад.

За секундарни сервер који прати примарни, PostgreSQL има документован пут преко преноса WAL записа и стриминг репликације. Упутство за резервне PostgreSQL сервере наводи да је стриминг репликација подразумевано асинхрона: при отказу примарног сервера могу се изгубити потврђене измене које још нису стигле на резервни. Синхрони режим може да смањи тај ризик, али упис тада чека потврду резервног сервера. Репликација зато у избор уноси и надзор кашњења, опоравак и цену жељене трајности.

Избор према архитектури апликације

• За локалну апликацију или више процеса на истом домаћину, SQLite је разуман почетни избор ако су уписи кратки, чекање прихватљиво и доследна резервна копија покрива потребе за опоравком. Више процеса и даље дели једног уписивача у исту датотеку.
• Ако више инстанци апликације треба да користи заједничку базу као серверску услугу, или конкурентни уписи већ продужавају одговоре, PostgreSQL боље одговара том моделу. И код њега треба ограничити непотребно дуге трансакције и проверити сукобе око истих редова.
• Ако је услов реплика за читање или брзо преузимање рада после отказа, серверска репликација је засебан критеријум чак и када тренутни број уписа није велики. Треба одредити колико кашњење реплике и колики ризик губитка последњих измена производ може да прихвати.
• Ако одлука зависи од сложених спајања табела, проширења или правила приступа подацима, упоредите потребне функције и планове својих упита. Наведени тест мери једноставне уписе и мешавину читања по кључу и уписа; његов резултат не бира базу уместо функционалних захтева.

Прочитајте и:

• PostgreSQL или MySQL: бржи benchmark не доноси одлуку без истог нивоа изолације
• AI детектор није доказ: један проценат грешке може да оптужи човека
• Како ограничити AI агента пре него што prompt injection стигне до алата