PgQue sjell radhë ngjarjesh vetëm-shtuese në bazën e të dhënave me burim të hapur
Shumë instanca prodhimi të bazës së të dhënave me burim të hapur vuajnë nga tabela që marrin miliona përditësime në ditë, duke shkaktuar autovacuum qindra herë në ditë dhe fryrje të rëndë tabelash. Kjo çon në performancë të dobët, probleme konkurence dhe një bazë të dhënash që bëhet e vështirë për t'u menaxhuar. Në një postim blogu të 28 shtatorit 2026 për Percona, autori Jobin Augustine shpjegon se si mjeti me burim të hapur PgQue mund t'i zgjidhë pikërisht këto probleme duke zëvendësuar ndjekjen e statusit me përditësime të shpeshta me një regjistër ngjarjesh vetëm-shtues.
PgQue është një version i modernizuar i PgQ, një kornizë radhësh e krijuar fillimisht nga Marko Kreen si pjesë e Skytools. Edhe pse kryesisht i harruar për më shumë se 20 vjet, anëtarët e komunitetit si Alexander Kukushkin e sollën përsëri në vëmendje përmes bisedave në konferenca si 'Radhët e bazës së të dhënave me burim të hapur të bëra siç duhet me PgQ' në POSETTE 2026. Nikolay Samokhvalov më vonë rifreskoi kodin si PgQue, duke përmirësuar dokumentacionin dhe duke e bërë më të lehtë për t'u vendosur. Në mënyrë thelbësore, PgQue nuk kërkon instalimin e ndonjë zgjerimi binar.
Implementimet tradicionale të radhëve në bazën e të dhënave me burim të hapur shpesh përdorin veçori SQL si FOR UPDATE SKIP LOCKED, por kjo çon në fryrje masive tabelash dhe pengesa konkurence. PgQue merr një qasje të ndryshme: ruan ngjarjet në një tabelë të ndarë vetëm-shtuese dhe përdor snapshot-et e bazës së të dhënave me burim të hapur për të identifikuar se cilat transaksione përfunduan midis dy pikave në kohë. Konsumatorët ndjekin pozicionin e tyre me një kursor, kështu që asnjë rresht ngjarjeje nuk përditësohet kurrë në vend. Kjo eliminon plotësisht fryrjen dhe kostot e përditësimit, dhe lejon konsumatorë të shumtë të lexojnë të njëjtin regjistër ngjarjesh në mënyrë të pavarur.
Pavarësisht emrit, PgQue nuk është një radhë në kuptimin e zakonshëm sepse ngjarjet nuk fshihen kurrë kur konsumohen. Në vend të kësaj, një konfirmim thjesht avancon kursorin e atij konsumatori. Modeli është një regjistër i përbashkët vetëm-shtues, më afër një teme Kafka dhe veçanërisht i ngjashëm me modelin e abonimit të Pulsar. Çdo konsumator mban pozicionin e vet mbi të njëjtat ngjarje, të cilat ruhen vetëm një herë. Megjithatë, PgQue nuk ka ndarjet e Kafka-s, kështu që nuk ofron renditje sipas çelësit, dhe kursori i tij tregon një tick (një copë kohe) në vend të një offset-i specifik mesazhi. Një konsumator kryen commit përmes një numri tick-u, jo përmes një ID ngjarjeje. Rikuperimi i hapësirës funksionon duke rrotulluar dhe shkurtuar tabelat e vjetra, por vetëm pasi konsumatori më i ngadalshëm ka kaluar përtej tyre. Dritarja e garantuar e rikthimit është një periudhë rrotullimi, e cila është 2 orë si parazgjedhje; një konsumator i bllokuar bllokon rikuperimin në vend që të shkaktojë humbje të dhënash. PgQue gjithashtu ofron semantikë radhe që Kafka ia lë aplikacionit: ridorëzim për konsumator (një ngjarje e dështuar ri-shtohet si një kopje private e dukshme vetëm për atë konsumator), një radhë letrash të vdekura të integruar, dhe konsumatorë bashkëpunues që lejojnë punëtorë të shumtë të ndajnë një kursor të vetëm logjik. Veçoria e konsumatorit bashkëpunues është shënuar si eksperimentale sipas postimit të blogut.
Ngjarjet grupohen në tufa, gjë që zvogëlon udhëtimet e rrjetit sepse një kërkesë e vetme fetch mund të kthejë ngjarje të shumta. Pas përpunimit të një tufe, konsumatori dërgon një konfirmim dhe treguesi avancon në tufën tjetër. Në mënyrë të rëndësishme, konfirmimi është për tufë, jo për mesazh, kështu që nëse një mesazh në një tufë dështon, ai mesazh duhet të konfirmohet negativisht përpara se tufa të konfirmohet. Kufijtë e tufës përcaktohen nga një ticker që ekzekutohet në një interval të planifikuar, siç është çdo 100 milisekonda (parazgjedhja) ose çdo pjesëtues i saktë i 1000 ms. Ticker-i aktivizohet një herë në sekondë nga një zgjerim planifikues i ngjashëm me cron për bazën e të dhënave, dhe brenda asaj sekonde prodhon tick-e në shpejtësinë e konfiguruar. Pas çdo tick-u, ticker-i lëshon një ngjarje LISTEN/NOTIFY, duke lejuar konsumatorët të presin për njoftime në vend që të bëjnë polling. Në radhët me aktivitet të ulët, ku janë grumbulluar më pak se 500 ngjarje që nga tick-u i fundit, ticker-i mund të kufizohet; përdoruesit mund të detyrojnë manualisht një tick me pgque.force_next_tick().
PgQue ofron role të veçanta sigurie për prodhuesit dhe konsumatorët: pgque_writer dhe pgque_reader, plus një rol administrativ pgque_admin. API-të kryesore përfshijnë send(), send_batch(), subscribe(), unsubscribe(), receive(), ack(), dhe nack(). Një grup funksionesh për radhën e letrave të vdekura (dlq_inspect(), dlq_replay(), dlq_replay_all(), dlq_purge(), event_dead()) zhvendos mesazhet e dështuara në mënyrë të përsëritur në një zonë të veçantë. Prodhuesit idempotentë mbështeten përmes send_idem() dhe maint_idem(), të cilat heqin dublikatat e publikimeve sipas çelësit në mënyrë që prodhuesit që riprovojnë të mos publikojnë dy herë. Funksionet e menaxhimit përfshijnë start(), stop(), status(), version(), set_tick_period_ms(), dhe uninstall(). Funksionet e vëzhgueshmërisë si queue_stats(), consumer_stats(), queue_health(), otel_metrics(), stuck_consumers(), throughput(), dhe error_rate() ofrojnë statistika, vlerësim shëndeti, zbulim të konsumatorëve të bllokuar dhe një pamje metrikash të pajtueshme me OpenTelemetry. Dorëzimi i vonuar është i mundur me send_at() dhe funksionet e lidhura të mirëmbajtjes.
Për të përdorur PgQue, një aplikacion mund të thërrasë API-të e tij të papërpunuara SQL ose të përdorë biblioteka zyrtare klienti. Sipas postimit të blogut, bibliotekat ekzistojnë për Python, Go, TypeScript dhe Ruby nën direktorinë 'client' të depos. Për testim nga ndërfaqja e linjës së komandës së bazës së të dhënave, një prodhues mund të publikojë një ngjarje në një radhë me një ngarkesë JSONB. Një konsumator thërret pgque.receive() për të marrë deri në një numër të caktuar ngjarjesh. Funksioni receive kthen kolona duke përfshirë msg_id, batch_id, type, payload, retry_count dhe created_at. Tufat boshe nuk kanë nevojë për konfirmim; marrja e tyre automatikisht përfundon tufën dhe avancon kursorin. Tufat jo boshe duhet të konfirmohen me ack(), përndryshe thirrjet pasuese kthejnë të njëjtën tufë të pakonfirmuar. Cikli standard është: merr një tufë, përpuno mesazhet nëse ka, konfirmo tufën dhe përsërit. Një skenar shembull në blog tregon se si të zbrazen ngjarjet derisa konsumatori të arrijë tick-un më të fundit.
Jobin Augustine vëren se zhurma rreth 'Thjesht përdor bazën e të dhënave me burim të hapur' po rritet ndërsa dizajnuesit e sistemeve duan të zvogëlojnë kompleksitetin nga komponentët e jashtëm si Kafka. Ai i referohet postimit të fundit të Chandan Shukla 'Baza e të Dhënave me Burim të Hapur si Motor Workflow: Ndërtimi i Punëve të Besueshme Afatgjata të AI pa Kafka' si një shembull i këtij trendi. PgQue ofron një kornizë të gatshme që shmang nevojën për të rishpikur logjikën e radhëve të bazuara në snapshot. Për ekipet që ekzekutojnë bazën e të dhënave me burim të hapur në prodhim, adoptimi i modeleve si PgQue mund të zvogëlojë fryrjen e bazës së të dhënave dhe të përmirësojë shkallëzimin. Një mjedis cloud i menaxhuar si bazat e të dhënave të menaxhuara të AEU Data mund të ndihmojë më tej duke ofruar kopje rezervë të automatizuara, monitorim dhe disponueshmëri të lartë, duke lejuar ekipet të përqendrohen në logjikën e aplikacionit në vend të mirëmbajtjes së infrastrukturës.