{"id":91048,"date":"2020-08-08T01:42:02","date_gmt":"2020-08-07T23:42:02","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/ne-stoit-polzovatsya-offset-i-limit-v-zaprosah-s-razbieniem-na-straniczy"},"modified":"2020-08-08T01:42:02","modified_gmt":"2020-08-07T23:42:02","slug":"ne-stoit-polzovatsya-offset-i-limit-v-zaprosah-s-razbieniem-na-straniczy","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sv\/blog\/administrirovanie\/ne-stoit-polzovatsya-offset-i-limit-v-zaprosah-s-razbieniem-na-straniczy","title":{"rendered":"Det \u00e4r inte bra att anv\u00e4nda OFFSET och LIMIT i f\u00f6rfr\u00e5gningar med sidindelning","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

De dagar d\u00e5 man inte beh\u00f6vde oroa sig f\u00f6r databasens prestanda \u00e4r f\u00f6rbi. Tiden st\u00e5r inte still. Varje ny teknologientrepren\u00f6r vill skapa n\u00e4sta Facebook och samla in all data de kan f\u00e5 tag p\u00e5. Denna data beh\u00f6vs f\u00f6r att f\u00f6retag ska kunna tr\u00e4na modeller av h\u00f6gre kvalitet som hj\u00e4lper dem att tj\u00e4na pengar. Under dessa f\u00f6rh\u00e5llanden m\u00e5ste programmerare skapa API:er som g\u00f6r det m\u00f6jligt att snabbt och p\u00e5litligt arbeta med enorma datam\u00e4ngder.<\/p>\n

\"Det<\/a><\/noindex>
\n<\/a><\/noindex>
\nOm du har arbetat med att designa serverdelar av applikationer eller databaser under en tid har du f\u00f6rmodligen skrivit kod f\u00f6r att utf\u00f6ra paginering i dina fr\u00e5gor. Till exempel s\u00e5 h\u00e4r:<\/p>\n

SELECT * FROM table_name LIMIT 10 OFFSET 40\n<\/code><\/pre>\n
\n\u00c4r det s\u00e5?<\/p>\n
Men om du har utf\u00f6rt paginering p\u00e5 detta s\u00e4tt s\u00e5 m\u00e5ste jag tyv\u00e4rr p\u00e5peka att du inte har gjort det p\u00e5 det mest effektiva s\u00e4ttet.<\/p>\n
Vill du inv\u00e4nda mot mig? Du kan<\/a><\/noindex> inte<\/a><\/noindex> sl\u00f6sa<\/a><\/noindex> tid<\/a><\/noindex>. Slack<\/a><\/noindex>, Shopify<\/a><\/noindex> och Mixmax<\/a><\/noindex> anv\u00e4nder redan de metoder som jag vill ber\u00e4tta om idag.<\/p>\n
N\u00e4mn en enda backendutvecklare som aldrig har anv\u00e4nt OFFSET<\/code> och LIMIT<\/code> f\u00f6r att utf\u00f6ra paginerade fr\u00e5gor. I ett MVP (Minimum Viable Product, minimi livskraftig produkt) eller i projekt d\u00e4r sm\u00e5 datam\u00e4ngder anv\u00e4nds \u00e4r detta tillv\u00e4gag\u00e5ngss\u00e4tt fullt till\u00e4mpbart. Det 'bara fungerar', s\u00e5 att s\u00e4ga.<\/p>\n
Men om man beh\u00f6ver skapa p\u00e5litliga och effektiva system fr\u00e5n grunden, b\u00f6r man se till att man i f\u00f6rv\u00e4g tar h\u00e4nsyn till effektiviteten i fr\u00e5gor mot databaser som anv\u00e4nds i s\u00e5dana system.<\/p>\n
Idag ska vi diskutera problem relaterade till de allm\u00e4nt anv\u00e4nda (tyv\u00e4rr) implementeringarna av pagineringsmekanismer och hur man kan uppn\u00e5 h\u00f6g prestanda vid utf\u00f6randet av s\u00e5dana fr\u00e5gor.<\/p>\n
Vad \u00e4r fel med OFFSET och LIMIT?<\/h2>\n
\nSom tidigare n\u00e4mnts OFFSET<\/code> och LIMIT<\/code> presterar utm\u00e4rkt i projekt d\u00e4r man inte beh\u00f6ver arbeta med stora datam\u00e4ngder.<\/p>\n
Problemet uppst\u00e5r n\u00e4r databasen v\u00e4xer till en storlek som g\u00f6r att den inte l\u00e4ngre f\u00e5r plats i serverns minne. Men under arbetet med denna databas m\u00e5ste man anv\u00e4nda paginerade fr\u00e5gor.<\/p>\n
F\u00f6r att detta problem ska framtr\u00e4da kr\u00e4vs det en situation d\u00e4r databashanteraren (DBMS) anv\u00e4nder en ineffektiv fullst\u00e4ndig tabellskanning (Full Table Scan) f\u00f6r att utf\u00f6ra varje fr\u00e5ga med paginering (under tiden kan det ske operationer f\u00f6r att infoga och ta bort data, och f\u00f6r\u00e5ldrad data \u00e4r inte relevant f\u00f6r oss!).<\/p>\n
Vad \u00e4r \"fullst\u00e4ndig tabellskanning\" (eller \"sekventiell tabellgenomg\u00e5ng\", Sequential Scan)? Det \u00e4r en operation d\u00e4r DBMS sekventiellt l\u00e4ser varje rad i tabellen, det vill s\u00e4ga de data som finns i den, och kontrollerar dem mot ett specificerat villkor. Det \u00e4r v\u00e4lk\u00e4nt att denna typ av tabellgenomg\u00e5ng \u00e4r den l\u00e5ngsammaste. Problemet \u00e4r att det vid denna operation f\u00f6rekommer m\u00e5nga in-\/utdataoperationer som belastar serverns diskunderh\u00e5ll. Situationer f\u00f6rv\u00e4rras av f\u00f6rseningar kopplade till arbetet med data lagrade p\u00e5 diskar, och det faktum att \u00f6verf\u00f6ring av data fr\u00e5n disk till minne \u00e4r en resurskr\u00e4vande operation.<\/p>\n
Till exempel, om du har poster om 100000000 anv\u00e4ndare och du utf\u00f6r en fr\u00e5ga med konstruktionen OFFSET 50000000<\/code>. Detta betyder att DBMS m\u00e5ste ladda alla dessa poster (och vi beh\u00f6ver dem inte ens!), placera dem i minnet, och f\u00f6rst d\u00e4refter h\u00e4mta, s\u00e4g, 20 resultat som anges i LIMIT<\/code>.<\/p>\n
L\u00e5t oss s\u00e4ga att det kan se ut s\u00e5 h\u00e4r: \u00abv\u00e4lj rader fr\u00e5n 50000 till 50020 av 100000\u00bb. Det vill s\u00e4ga, f\u00f6r att utf\u00f6ra fr\u00e5gan m\u00e5ste systemet f\u00f6rst ladda 50000 rader. F\u00f6rst\u00e5r du hur mycket on\u00f6digt arbete det m\u00e5ste utf\u00f6ra?<\/p>\n
Om du inte tror mig - ta en titt p\u00e5 exemplet som jag skapade med hj\u00e4lp av db-fiddle.com<\/a><\/noindex>.\u00a0<\/p>\n
\"Det
\nExempel p\u00e5 db-fiddle.com<\/i><\/p>\n
D\u00e4r, till v\u00e4nster, i f\u00e4ltet Schema SQL<\/code>, finns det kod som infogar 100000 rader i databasen, och till h\u00f6ger, i f\u00e4ltet Query SQL<\/code>, visas tv\u00e5 fr\u00e5gor. Den f\u00f6rsta, som \u00e4r l\u00e5ngsam, ser ut s\u00e5 h\u00e4r:<\/p>\n
SELECT *\nFROM `docs`\nLIMIT 10 OFFSET 85000;\n<\/code><\/pre>\n
\nOch den andra, som \u00e4r en effektiv l\u00f6sning p\u00e5 samma problem, ser ut s\u00e5 h\u00e4r:<\/p>\n
SELECT *\nFROM `docs`\nWHERE id > 85000\nLIMIT 10;\n<\/code><\/pre>\n
\nF\u00f6r att utf\u00f6ra dessa fr\u00e5gor r\u00e4cker det att trycka p\u00e5 knappen Run<\/code> i den \u00f6vre delen av sidan. Genom att g\u00f6ra detta kan vi j\u00e4mf\u00f6ra information om svarstider. Det visar sig att det tar minst 30 g\u00e5nger l\u00e4ngre tid att utf\u00f6ra en ineffektiv f\u00f6rfr\u00e5gan \u00e4n en andra (fr\u00e5n k\u00f6rning till k\u00f6rning varierar denna tid, till exempel kan systemet rapportera att den f\u00f6rsta f\u00f6rfr\u00e5gningen tog 37 ms, medan den andra tog 1 ms).<\/p>\n
Och om datam\u00e4ngden \u00f6kar, kommer allt att se \u00e4nnu v\u00e4rre ut (f\u00f6r att \u00f6vertyga dig \u2014 kolla p\u00e5 min exempel<\/a><\/noindex> med 10 miljoner rader).<\/p>\n
Det vi just diskuterade b\u00f6r ge dig en viss f\u00f6rst\u00e5else f\u00f6r hur fr\u00e5gor till databaser faktiskt behandlas.<\/p>\n
T\u00e4nk p\u00e5 att ju h\u00f6gre v\u00e4rde OFFSET<\/code> \u2014 desto l\u00e4ngre tid tar det att k\u00f6ra f\u00f6rfr\u00e5gan.<\/p>\n
Vad b\u00f6r man anv\u00e4nda ist\u00e4llet f\u00f6r kombinationen OFFSET och LIMIT?<\/h2>\n
\nIst\u00e4llet f\u00f6r kombinationen OFFSET<\/code> och LIMIT<\/code> b\u00f6r man anv\u00e4nda en konstruktion som \u00e4r uppbyggd enligt f\u00f6ljande schema:<\/p>\n
SELECT * FROM table_name WHERE id > 10 LIMIT 20\n<\/code><\/pre>\n
\nDetta \u00e4r en f\u00f6rfr\u00e5gan med sidindelning, baserad p\u00e5 en kursorn (Cursor based pagination).<\/p>\n
Ist\u00e4llet f\u00f6r att lokalt lagra aktuella OFFSET<\/code> och LIMIT<\/code> och skicka dem med varje f\u00f6rfr\u00e5gan, b\u00f6r man lagra den senaste erh\u00e5llna prim\u00e4ra nyckeln (vanligtvis \u00e4r det ID<\/code>) och LIMIT<\/code>, vilket resulterar i f\u00f6rfr\u00e5gningar som liknar den ovanst\u00e5ende.<\/p>\n
Varf\u00f6r? Faktum \u00e4r att genom att tydligt ange identifieraren f\u00f6r den sista l\u00e4sta raden, informerar du din DBMS om var den ska b\u00f6rja s\u00f6ka efter de n\u00f6dv\u00e4ndiga uppgifterna. Dessutom kommer s\u00f6kningen, tack vare anv\u00e4ndningen av nyckeln, att ske effektivt, och systemet beh\u00f6ver inte avbryta f\u00f6r att titta p\u00e5 rader utanf\u00f6r det angivna intervallet.<\/p>\n
L\u00e5t oss titta p\u00e5 f\u00f6ljande j\u00e4mf\u00f6relse av prestandan f\u00f6r olika f\u00f6rfr\u00e5gningar. H\u00e4r \u00e4r en ineffektiv f\u00f6rfr\u00e5gan.<\/p>\n
\"Det
\nL\u00e5ngsam f\u00f6rfr\u00e5gan<\/i><\/p>\n
Och h\u00e4r \u00e4r en optimerad version av denna f\u00f6rfr\u00e5gan.<\/p>\n
\"Det
\nEn snabb f\u00f6rfr\u00e5gan<\/i><\/p>\n
B\u00e5da f\u00f6rfr\u00e5gningarna returnerar exakt samma m\u00e4ngd data. Men den f\u00f6rsta tar 12,80 sekunder att k\u00f6ra, medan den andra tar 0,01 sekund. K\u00e4nner du skillnaden?<\/p>\n
M\u00f6jliga problem<\/h2>\n
\nF\u00f6r att s\u00e4kerst\u00e4lla att den f\u00f6reslagna metoden f\u00f6r att utf\u00f6ra f\u00f6rfr\u00e5gningar fungerar effektivt, m\u00e5ste tabellen inneh\u00e5lla en eller flera kolumner med unika, sekventiellt ordnade index, som en heltalsidentifierare. I vissa specifika fall kan detta avg\u00f6ra framg\u00e5ngen f\u00f6r anv\u00e4ndningen av s\u00e5dana f\u00f6rfr\u00e5gningar f\u00f6r att \u00f6ka hastigheten p\u00e5 databasanv\u00e4ndningen.<\/p>\n
Naturligtvis m\u00e5ste man ta h\u00e4nsyn till tabellernas arkitektur n\u00e4r man konstruerar f\u00f6rfr\u00e5gningar och v\u00e4lja de mekanismer som b\u00e4st presterar med de aktuella tabellerna. Till exempel, om man beh\u00f6ver arbeta med stora m\u00e4ngder relaterade data i f\u00f6rfr\u00e5gningar, kan det vara intressant f\u00f6r dig. detta<\/a><\/noindex> artikel.<\/p>\n
Om vi har problemet med avsaknad av en prim\u00e4rnyckel, till exempel om det finns en tabell med en 'm\u00e5nga-till-m\u00e5nga'-relation, s\u00e5 \u00e4r den traditionella metoden som f\u00f6ruts\u00e4tter anv\u00e4ndning av OFFSET<\/code> och LIMIT<\/code>, vi garanterat kommer att kunna till\u00e4mpa. Men dess anv\u00e4ndning kan leda till att potentiellt l\u00e5ngsamma f\u00f6rfr\u00e5gningar utf\u00f6rs. I s\u00e5dana fall skulle jag rekommendera att anv\u00e4nda en prim\u00e4rnyckel med autoinkrement, \u00e4ven om den endast beh\u00f6vs f\u00f6r att organisera f\u00f6rfr\u00e5gningar med paginering.<\/p>\n
Om du \u00e4r intresserad av detta \u00e4mne \u2014 h\u00e4r<\/a><\/noindex>, h\u00e4r<\/a><\/noindex> och h\u00e4r<\/a><\/noindex> \u2014 h\u00e4r \u00e4r n\u00e5gra anv\u00e4ndbara resurser.<\/p>\n
Sammanfattning<\/h2>\n
\nDet huvudsakliga slutsatsen vi kan dra \u00e4r att oavsett storleken p\u00e5 databaserna m\u00e5ste f\u00f6rfr\u00e5gningarnas hastighet alltid analyseras. I v\u00e5r tid \u00e4r skalbarhet av l\u00f6sningar extremt viktigt, och om man redan fr\u00e5n b\u00f6rjan av arbetet med ett system designar allt korrekt, kan detta i framtiden spara utvecklaren fr\u00e5n m\u00e5nga problem.<\/p>\n
Hur analyserar och optimerar du f\u00f6rfr\u00e5gningar mot databaser?<\/b><\/p>\n
\"Det<\/a><\/noindex>
\n
K\u00e4lla: habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
\u041f\u0440\u043e\u0448\u043b\u0438 \u0442\u0435 \u0434\u043d\u0438, \u043a\u043e\u0433\u0434\u0430 \u043d\u0435 \u043d\u0430\u0434\u043e \u0431\u044b\u043b\u043e \u0431\u0435\u0441\u043f\u043e\u043a\u043e\u0438\u0442\u044c\u0441\u044f \u043e\u0431 \u043e\u043f\u0442\u0438\u043c\u0438\u0437\u0430\u0446\u0438\u0438 \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u0438 \u0431\u0430\u0437 \u0434\u0430\u043d\u043d\u044b\u0445. \u0412\u0440\u0435\u043c\u044f \u043d\u0435 \u0441\u0442\u043e\u0438\u0442 \u043d\u0430 \u043c\u0435\u0441\u0442\u0435. \u041a\u0430\u0436\u0434\u044b\u0439 \u043d\u043e\u0432\u044b\u0439 \u0431\u0438\u0437\u043d\u0435\u0441\u043c\u0435\u043d \u0438\u0437 \u0441\u0444\u0435\u0440\u044b \u0432\u044b\u0441\u043e\u043a\u0438\u0445 \u0442\u0435\u0445\u043d\u043e\u043b\u043e\u0433\u0438\u0439 \u0445\u043e\u0447\u0435\u0442 \u0441\u043e\u0437\u0434\u0430\u0442\u044c \u043e\u0447\u0435\u0440\u0435\u0434\u043d\u043e\u0439 Facebook, \u0441\u0442\u0440\u0435\u043c\u044f\u0441\u044c \u043f\u0440\u0438 \u044d\u0442\u043e\u043c \u0441\u043e\u0431\u0438\u0440\u0430\u0442\u044c \u0432\u0441\u0435 \u0434\u0430\u043d\u043d\u044b\u0435, \u0434\u043e \u043a\u043e\u0442\u043e\u0440\u044b\u0445 \u043c\u043e\u0436\u0435\u0442 \u0434\u043e\u0442\u044f\u043d\u0443\u0442\u044c\u0441\u044f. \u042d\u0442\u0438 \u0434\u0430\u043d\u043d\u044b\u0435 \u043d\u0443\u0436\u043d\u044b \u0431\u0438\u0437\u043d\u0435\u0441\u0443 \u0434\u043b\u044f \u0431\u043e\u043b\u0435\u0435 \u043a\u0430\u0447\u0435\u0441\u0442\u0432\u0435\u043d\u043d\u043e\u0433\u043e \u043e\u0431\u0443\u0447\u0435\u043d\u0438\u044f \u043c\u043e\u0434\u0435\u043b\u0435\u0439, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u043f\u043e\u043c\u043e\u0433\u0430\u044e\u0442 \u0437\u0430\u0440\u0430\u0431\u0430\u0442\u044b\u0432\u0430\u0442\u044c. \u0412 \u0442\u0430\u043a\u0438\u0445 \u0443\u0441\u043b\u043e\u0432\u0438\u044f\u0445 \u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u0438\u0441\u0442\u0430\u043c […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":91049,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-91048","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Anv\u00e4nd inte OFFSET och LIMIT i f\u00f6rfr\u00e5gningar med paginering | ProHoster","description":"De dagar d\u00e5 man inte beh\u00f6vde oroa sig f\u00f6r att optimera databaskapaciteten \u00e4r f\u00f6rbi. Tiden st\u00e5r inte still.","canonical_url":"https:\/\/prohoster.info\/sv\/blog\/administrirovanie\/ne-stoit-polzovatsya-offset-i-limit-v-zaprosah-s-razbieniem-na-straniczy","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"sv_SE","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041d\u0435 \u0441\u0442\u043e\u0438\u0442 \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u044c\u0441\u044f OFFSET \u0438 LIMIT \u0432 \u0437\u0430\u043f\u0440\u043e\u0441\u0430\u0445 \u0441 \u0440\u0430\u0437\u0431\u0438\u0435\u043d\u0438\u0435\u043c \u043d\u0430 \u0441\u0442\u0440\u0430\u043d\u0438\u0446\u044b | ProHoster","og:description":"\u041f\u0440\u043e\u0448\u043b\u0438 \u0442\u0435 \u0434\u043d\u0438, \u043a\u043e\u0433\u0434\u0430 \u043d\u0435 \u043d\u0430\u0434\u043e \u0431\u044b\u043b\u043e \u0431\u0435\u0441\u043f\u043e\u043a\u043e\u0438\u0442\u044c\u0441\u044f \u043e\u0431 \u043e\u043f\u0442\u0438\u043c\u0438\u0437\u0430\u0446\u0438\u0438 \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u0438 \u0431\u0430\u0437 \u0434\u0430\u043d\u043d\u044b\u0445. \u0412\u0440\u0435\u043c\u044f \u043d\u0435 \u0441\u0442\u043e\u0438\u0442 \u043d\u0430 \u043c\u0435\u0441\u0442\u0435.","og:url":"https:\/\/prohoster.info\/sv\/blog\/administrirovanie\/ne-stoit-polzovatsya-offset-i-limit-v-zaprosah-s-razbieniem-na-straniczy","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-08-07T23:42:02+00:00","article:modified_time":"2020-08-07T23:42:02+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"91048","title":null,"description":null,"keywords":null,"keyphrases":{"focus":[],"additional":[]},"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 12:35:24","updated":"2026-08-11 12:50:11","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/posts\/91048","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/comments?post=91048"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/posts\/91048\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/media\/91049"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/media?parent=91048"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/categories?post=91048"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/tags?post=91048"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}