Python Pagination af Postgres

introduktion

denne artikel er en tutorial om Python Pagination af Postgres data. Af mange grunde kan du begrænse retur af recordsets til små bidder i modsætning til at returnere store recordsets, der kan være dyre både med hensyn til båndbredde, RAM og tid på serveren samt økonomi for brugeren. Vores metode:

  • hvad og hvorfor? Hvad er Python pagination? Hvorfor ønsker vi at paginere vores Postgres-data med Python og under hvilke omstændigheder?
  • hvordan? Hvordan paginerer vi Postgraduate resultater med Python? Hvad er de hurtigste og nemmeste måder at gøre dette på for mindre datasæt, og hvad er de mere robuste og effektive måder til store databaser og/eller situationer, hvor server-eller klientressourcer er begrænsede og nøjagtighed er altafgørende?

forudsætninger

  • kvm: forståelse af det grundlæggende ved at skrive kvm til Postgres. Vi bruger dBeaver på grund af sin lethed og antallet af funktioner.
  • vælg: vi gør liberal brug af kommandoen “Vælg” i denne artikel for at forespørge en Postgres-database med en Python-applikation.
  • Tutorial om navngivningskonventioner, der viser, hvorfor du måske vil præfikse dine variabler, kolonnenavne, tabelnavne osv. som du ser gjort i denne artikel. For eksempel at navngive “tvariable” med præfikset “t” for at definere det som et “tekst” (streng) objekt og “tbl_” før tabelnavne for klart at skelne disse objekter som tabeller. Vejledningen går også lidt dybere og taler om, hvordan man navngiver variabler baseret på et hierarkisystem.

Opret en Postgres-tabel, der skal pagineres

lad os sige, at vi opretter et forum eller content management system (CMS) i Python og Postgres, og vi vil have en tabel til lagring af forumindlæg.

1
2
3
4
5
6
7
8
9
10
Opret tabel offentlig.page_contents (
id serial NOT NULL,
id_session int4 NULL DEFAULT 0,
id_author int4 NULL DEFAULT 0,
t_title VARCHAR(256) NULL,
t_contents tekst NULL,
D_CREATED DATE NULL DEFAULT nu(),
CONSTRAINT page_contents_pkey PRIMARY KEY (id)
);
Opret Unik indeksside_contents_id_id på offentlig.page_contents ved hjælp af btree (id);

nu hvor vi har en postgraduate tabel, fylder vi den med data, så vi har noget at teste med:

1
2
3
4
5
6
7
8
9
10
11
indsæt i
page_contents
(
id_author
, t_title
)
vælg
tilfældig()*100::heltal + 1 som id_author
, array_to_string(array(vælg substr(‘ABCDEFGHIJKLMNOPKRSTUVSTUVE0123456789’,((tilfældig()*(36-1)+1)::heltal),1) fra generate_series(1,32)),”) som t_title;
fra
generate_Series(1,10000);

oversigt: vi indsætter 10000 poster i vores” page_contents ” tabel. For hver post udfylder vi feltet “id_author” med et tilfældigt tal mellem 1 og 100 inklusive disse to tal. Vi udfylder også feltet “t_title” med en tilfældig streng på 32 tegn fra alfabetet.

Bemærk: Hvis du har brug for et større datasæt, skal du blot øge “10000”, du ser ovenfor, til et større antal.

analyse

  • indsæt: brugt postgraduate ‘ s “random” – funktion til at generere et tilfældigt tal mellem 0 og 99, cast det som et heltal (“::”1″, så resultatet er mellem (inklusive) 1 og 100 og er af tilstrækkelig datatype til at placere i kolonnen” id_author”.
  • array_to_string: vi vælger tilfældigt bogstaver 32 gange (“generate_series(1,32)”) fra en 36 tegn lang streng fra A til Å og 0 til 9 for at opbygge en streng, der indsættes i feltet “t_title”.
  • generate_Series(1,10000): dette fortæller Postgres-motoren at generere 10,000 rækker i tabellen.

nu hvor vi har et stort datasæt at arbejde med, lad os se på to forskellige metoder til at hente data fra denne tabel ved hjælp af Python.

Python pagination af Postgres hurtig og beskidt metode

den mindst effektive, men mest ofte anvendte er normalt et objekt eller bibliotek, der-nedenunder – bruger “limit – offset” pagination. I situationer, hvor din database er lille eller mellemstor, skal dette fungere fint med få ulemper, hvis nogen. Senere, når vi bruger en mere robust metode, vil vi tale om forskellene.

for det første fordelene ved enhver metode til paginering:

  • den første side af dine data indlæses hurtigere. For brugerens opfattelse af, hvor hurtig din app er, er dette uvurderligt!
  • hurtigere visninger af store datasæt.
  • potentiale for indkapsling af forretningslogik (afhænger af, hvordan du gør det).
  • klienten modtager mindre data ad gangen, hvilket kan være super nyttigt, hvis ikke et krav i visse miljøer.

dernæst inkluderer de metoder, vi bruger, total, limit, offset og skip.

lad os nu se på nogle kode:

1
2
3
4
5
6
7
8
9
10
11
12
13
page_current = 3
records_per_page = 10
offset = (page_current – 1) * records_per_page
s = “”
s += ” SELECT *”
s += “FROM page_contents”
s += “ORDER BY id”
s += “LIMIT” + records_per_page
s += “offset” + offset
# resulterende “limit” del af forespørgslen: “limit 10”
# resulterende “offset” del af forespørgslen: “OFFSET 20”

analyse

  • page_current: til testformål opsætter vi vores nuværende side til at være 3.
  • records_per_page: vi vil kun returnere 10 poster pr.
  • offset: dette er parameteren, der fortæller Postgres, hvor langt man skal “hoppe” i tabellen. I det væsentlige, ” spring over disse mange poster.”
  • s: opretter en forespørgselsstreng, der skal sendes til postgreskl til udførelse.

det største problem med ovennævnte “limit offset” – metode til paginering er, at “under omslagene” Postgres tilføjer det samlede antal poster, tæller sider baseret på dette nummer og scanner indekset for at tælle hvor mange rækker. Med de første par sider er disse omkostninger muligvis ikke tydelige. Men med større recordsets og endda mellemstore, jo højere du øger “page_current”, vil de langsommere ting få. Heldigvis er der mange måder, vi kan gøre paginering af Postgres-data.

en bedre metode: seek and keyset pagination

en løsning, der lindrer nogle af de ulemper, der er forbundet med at bruge ovenstående metode, er at videregive det unikke ID for den sidste post på den forrige side.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
ID_page_previous = 200
page_current = 3
records_per_page = 10
# limit_optional_offset ikke længere nødvendigt!
limit_optional_offset = (page_current – 1) * records_per_page
s = “”
s += “fra page_contents”
s += ” hvor id>”& id_page_previous
s += “Bestil efter id”
s += “limit” + records_per_page
# s + = “offset” + offset
# resulterende “limit” del af forespørgslen: “limit 10”

Bemærk, Med denne metode har vi ikke længere brug for OFFSET-kommandoen. Ved at tilføje” hvor ” – klausulen for at fortælle Postgraduate at udelade alle tidligere poster, så det ved, hvor man skal begynde at vise poster, fortsætter vi med at bruge LIMIT til at kommandere, hvor mange poster der skal returneres.

selvom der helt sikkert er mere effektive metoder til at paginere et Postgres-bord, høster ovenstående metode massive fordele i hastighed og effektivitet. En meget vigtig overvejelse er: “id” skal indekseres.

konklusion

i denne tutorial lærte vi to metoder til brug af Python til paginering af Postgres-data. Vi begyndte med at oprette en postgraduate tabel, derefter tilføjet 10.000 poster til tabellen, så vi havde noget at basere test på, og så sammenlignede vi to metoder til paginering i Python, og endelig analyserede vi fordele og ulemper ved begge metoder. Under denne proces brugte vi Postgraduate ‘ s “Tilfældige” Funktion, Python-strengsammenkædning til opbygning af KVM til at sende til Postgres og variabel oprettelse.

Skriv et svar

Din e-mailadresse vil ikke blive publiceret.