{"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\/et\/blog\/administrirovanie\/ne-stoit-polzovatsya-offset-i-limit-v-zaprosah-s-razbieniem-na-straniczy","title":{"rendered":"\u00c4rge kasutage k\u00fcsitlustes OFFSET ja LIMIT lehek\u00fclgede jagamise korral","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Aeg on m\u00f6\u00f6das, kus ei pidanud muretsema andmebaaside j\u00f5udluse optimeerimise \u00fcle. Aeg ei seisa paigal. Iga uus tehnoloogiatehnoloogia \u00e4rimees soovib luua j\u00e4rgmist Facebooki, p\u00fc\u00fcdes samal ajal koguda k\u00f5iki andmeid, millele nad ligi p\u00e4\u00e4sevad. Need andmed on ettev\u00f5ttele vajalikud kvaliteetsemate mudelite \u00f5petamiseks, mis aitavad kasumit teenida. Sellistes tingimustes peavad arendajad looma selliseid API-sid, mis v\u00f5imaldavad kiiresti ja usaldusv\u00e4\u00e4rselt t\u00f6\u00f6tada hiiglaslike andmemahtudega.<\/p>\n

\"\u00c4rge<\/a><\/noindex>
\n<\/a><\/noindex>
\nKui olete juba m\u00f5nda aega tegelenud rakenduste serveriplokkide v\u00f5i andmebaaside projekteerimisega, olete t\u00f5en\u00e4oliselt kirjutanud koodi lehek\u00fcljep\u00f5histe p\u00e4ringute t\u00e4itmiseks. N\u00e4iteks selline:<\/p>\n

SELECT * FROM table_name LIMIT 10 OFFSET 40\n<\/code><\/pre>\n
\nKas t\u00f5esti?<\/p>\n
Kuid kui te tegite lehek\u00fcljep\u00f5hise jagamise just nii, siis pean kurbusega m\u00e4rkima, et tegite seda kaugel mitte k\u00f5ige t\u00f5husamal viisil.<\/p>\n
Kas soovite mul vastu vaielda? Saate<\/a><\/noindex> ei<\/a><\/noindex> kulutama<\/a><\/noindex> aega<\/a><\/noindex>. Slack<\/a><\/noindex>, Shopify<\/a><\/noindex> ja Mixmax<\/a><\/noindex> juba kasutavad tehnikaid, millest ma t\u00e4na r\u00e4\u00e4kida tahan.<\/p>\n
Nimetage v\u00e4hemalt \u00fcks taustaarendaja, kes pole kunagi kasutanud CHECKSUM_AGG<\/code> ja LIMIT<\/code> lehek\u00fcljep\u00f5histe p\u00e4ringute t\u00e4itmiseks. MVP (Minimum Viable Product, minimaalne eluj\u00f5uline toode) ja projektides, kus kasutatakse v\u00e4ikseid andmemahte, on see l\u00e4henemine t\u00e4iesti rakendatav. See, nii \u00f6elda, \"lihtsalt t\u00f6\u00f6tab\".<\/p>\n
Kuid kui on vaja nullist luua usaldusv\u00e4\u00e4rseid ja t\u00f5husaid s\u00fcsteeme, tuleb eelnevalt hoolitseda andmebaaside p\u00e4ringute t\u00f5hususe eest, mida sellistes s\u00fcsteemides kasutatakse.<\/p>\n
T\u00e4na r\u00e4\u00e4gime probleemidest, mis on seotud laialdaselt kasutatavate (kahjuks) lehek\u00fcljep\u00f5histe p\u00e4ringumehanismidega, ja kuidas saavutada k\u00f5rget j\u00f5udlust selliste p\u00e4ringute t\u00e4itmisel.<\/p>\n
Mis on valesti OFFSETi ja LIMITiga?<\/h2>\n
\nKuidas juba mainitud, CHECKSUM_AGG<\/code> ja LIMIT<\/code> n\u00e4itavad end v\u00e4ga h\u00e4sti projektides, kus ei ole vaja t\u00f6\u00f6tada suurte andmemahutega.<\/p>\n
Probleem tekib siis, kui andmebaas kasvab nii suureks, et see ei mahu enam serveri m\u00e4llu. Kuid samal ajal tuleb sellise andmebaasiga t\u00f6\u00f6tamisel kasutada lehek\u00fcljep\u00f5hiseid p\u00e4ringuid.<\/p>\n
Probleemi ilmenemiseks peab olema olukord, kus andmebaas kasutab iga p\u00e4ringu t\u00e4itmiseks ebaefektiivset t\u00e4ielikku tabeli skaneerimist (Full Table Scan) lehek\u00fcljed jagades (samal ajal v\u00f5ivad toimuda andmete sisestamis- ja kustutamisoperatsioonid ning me ei vaja aegunud andmeid!).<\/p>\n
Mis on \"t\u00e4ielik tabeli skaneerimine\" (v\u00f5i \"j\u00e4rjestikune tabeli vaatamine\", Sequential Scan)? See on operatsioon, mille k\u00e4igus andmebaas loeb j\u00e4rjestikku iga tabeli rida, st sisaldatud andmeid, ja kontrollib neid antud tingimusele vastavuse suhtes. On teada, et see t\u00fc\u00fcp tabeli skaneerimist on aeglasem. Selle p\u00f5hjuseks on see, et selle t\u00e4itmise k\u00e4igus toimub palju sisend-\/v\u00e4ljundoperatsioone, mis h\u00f5lmavad serveri kettas\u00fcsteemi. Seisundit halvendavad viivitused, mis kaasnevad kettal hoitud andmete t\u00f6\u00f6tlemisega, ja see, et andmete edastamine kettalt m\u00e4llu on ressursimahukas operatsioon.<\/p>\n
N\u00e4iteks, teil on kirjed 100000000 kasutajast ja teete p\u00e4ringu koos konstruktsiooniga OFFSET 50000000<\/code>. See t\u00e4hendab, et andmebaas peab laadima k\u00f5ik need kirjed (ja need ei ole meile isegi vajalikud!), pannakse need m\u00e4llu ja seej\u00e4rel, oletame, v\u00f5tab 20 tulemust, millest on teavitatud LIMIT<\/code>.<\/p>\n
\u00d6eldes, et see v\u00f5iks v\u00e4lja n\u00e4ha nii: \"valige read 50000 kuni 50020 100000-st\". See t\u00e4hendab, et s\u00fcsteem peab p\u00e4ringu t\u00e4itmiseks esmalt laadima 50000 rida. N\u00e4ete, kui palju tarbetut t\u00f6\u00f6d tal tuleb teha?<\/p>\n
Kui ei usu \u2014 vaadake n\u00e4idet, mille ma l\u00f5in, kasutades v\u00f5imalusi db-fiddle.com<\/a><\/noindex>.\u00a0<\/p>\n
\"\u00c4rge
\nN\u00e4idis db-fiddle.com-is<\/i><\/p>\n
Seal, vasakul, valdkonnas Schema SQL<\/code>, on kood, mis sisestab andmebaasi 100000 rida, ja paremal, valdkonnas Query SQL<\/code>, on n\u00e4idatud kaks p\u00e4ringut. Esimene, aeglane, n\u00e4eb v\u00e4lja nii:<\/p>\n
SELECT *\nFROM `docs`\nLIMIT 10 OFFSET 85000;\n<\/code><\/pre>\n
\nJa teine, mis on sama probleemi efektiivne lahendus, on nii:<\/p>\n
SELECT *\nFROM `docs`\nWHERE id > 85000\nLIMIT 10;\n<\/code><\/pre>\n
\nNende p\u00e4ringute t\u00e4itmiseks piisab, kui vajutada nuppu K\u00e4ita<\/code> lehe \u00fclaosas. Kui te seda teete, saame v\u00f5rrelda p\u00e4ringute t\u00e4itmise aega. Selgub, et ebaefektiivse p\u00e4ringu t\u00e4itmiseks kulub v\u00e4hemalt 30 korda rohkem aega kui teise (k\u00e4ivituse vahel v\u00f5ib see aeg varieeruda, n\u00e4iteks s\u00fcsteem v\u00f5ib teatada, et esimese p\u00e4ringu t\u00e4itmine kestis 37 ms, samas kui teise oma - 1 ms).<\/p>\n
Ja kui andmeid on rohkem, siis n\u00e4eb see veel hullem v\u00e4lja (selle kinnitamiseks vaadake minu n\u00e4ide<\/a><\/noindex> 10 miljoni reaga).<\/p>\n
See, millest me just r\u00e4\u00e4kisime, peaks andma teile arusaamise, kuidas p\u00e4ringud tegelikult andmebaasidesse j\u00f5uavad.<\/p>\n
Pidage meeles, et mida suurem on v\u00e4\u00e4rtus CHECKSUM_AGG<\/code> seda kauem p\u00e4ring kestab.<\/p>\n
Mida peaks kasutama OFFSET-i ja LIMIT-i kombinatsiooni asemel?<\/h2>\n
\nOFFSET-i ja LIMIT-i kombinatsiooni asemel CHECKSUM_AGG<\/code> ja LIMIT<\/code> on parem kasutada konstruktsiooni j\u00e4rgmisel viisil:<\/p>\n
SELECT * FROM table_name WHERE id > 10 LIMIT 20\n<\/code><\/pre>\n
\nSee on p\u00e4ringu t\u00e4itmine, mis p\u00f5hineb lehejaotusel (Cursor based pagination).<\/p>\n
Ahnem kusagil kohapeal hoida praeguseid CHECKSUM_AGG<\/code> ja LIMIT<\/code> ja edastada neid iga p\u00e4ringuga, peaksite hoidma viimasena saadud peav\u00f5tit (tavaliselt on see ID<\/code>) ja LIMIT<\/code>, mis viib selleni, et p\u00e4ringud sarnanevad eespool toodud n\u00e4iteks.<\/p>\n
Miks? Asi on selles, et kui te n\u00e4itate selges\u00f5naliselt viidatud viimase ridade identifikaatorit, anname oma andmebaasihaldus s\u00fcsteemile teada, kust alustada vajalike andmete otsimist. Ja see otsing, kasutades v\u00f5tit, toimub t\u00f5husalt, s\u00fcsteem ei pea k\u00f5rvalistele ridadele t\u00e4helepanu p\u00f6\u00f6rama, mis j\u00e4\u00e4vad m\u00e4\u00e4ratud vahemikust v\u00e4lja.<\/p>\n
Vaadakem j\u00e4rgmisi erinevate p\u00e4ringute j\u00f5udluse v\u00f5rdlusi. Siin on ebaefektiivne p\u00e4ring.<\/p>\n
\"\u00c4rge
\nAeglane p\u00e4ring<\/i><\/p>\n
Aga siin on selle p\u00e4ringu optimeeritud versioon.<\/p>\n
\"\u00c4rge
\nKiire p\u00e4ring<\/i><\/p>\n
M\u00f5lemad p\u00e4ringud tagastavad t\u00e4pselt sama hulga andmeid. Kuid esimese t\u00e4itmine kestab 12,80 sekundit, samas kui teisel vaid 0,01 sekundit. Kas m\u00e4rkate vahet?<\/p>\n
V\u00f5imalikud probleemid<\/h2>\n
\nEttepaneku meetodi t\u00f5husaks toimimiseks peab tabelis olema veerg (v\u00f5i veerud), mis sisaldavad ainulaadseid, j\u00e4rjestikuseid indekse, n\u00e4iteks t\u00e4isarvulist identifikaatorit. M\u00f5nedes spetsiifilistes olukordades v\u00f5ib see m\u00e4\u00e4rata taoliste p\u00e4ringute kasutamise edu andmebaasi t\u00f6\u00f6 kiirusel.<\/p>\n
Muidugi tuleb p\u00e4ringute koostamisel arvesse v\u00f5tta tabelite arhitektuuri erip\u00e4ra ja valida need mehhanismid, mis toovad parima tulemuse olemasolevates tabelites. N\u00e4iteks, kui peate t\u00f6\u00f6tama suurte seotud andmahulkadega p\u00e4ringutes, v\u00f5ib teile huvi pakkuda see<\/a><\/noindex> artikkel.<\/p>\n
Kui seisame silmitsi esmase v\u00f5tme puudumise probleemiga, n\u00e4iteks kui tabelis on \"palju-palju\" suhe, siis traditsiooniline l\u00e4henemine, mis h\u00f5lmab CHECKSUM_AGG<\/code> ja LIMIT<\/code>, sobib meile kindlasti. Kuid selle rakendamine v\u00f5ib viia potentsiaalselt aeglaste p\u00e4ringute t\u00e4itmiseni. Niisugustes olukordades soovitaksin kasutada automaatse suurenemisega esmase v\u00f5tit, isegi kui see on vajalik ainult p\u00e4ringute lehek\u00fcntede kaupa t\u00e4itmiseks.<\/p>\n
Kui see teema teid huvitab \u2014 siin on<\/a><\/noindex>, siin on<\/a><\/noindex> ja siin on<\/a><\/noindex> \u2014 m\u00f5ned kasulikud materjalid.<\/p>\n
Summary<\/h2>\n
\nPeamine j\u00e4reldus, mille v\u00f5ime teha, on see, et olenemata andmebaaside suurusest, tuleb alati anal\u00fc\u00fcsida p\u00e4ringute t\u00e4itmise kiirus. T\u00e4nap\u00e4eval on lahenduste skaleeritavus \u00fclioluline, ning kui juba s\u00fcsteemi t\u00f6\u00f6planeerimise alguses on k\u00f5ik \u00f5igesti projekteeritud, v\u00f5ib see edaspidi aidata arendajal kokku puutuda paljude probleemidega.<\/p>\n
Kuidas te anal\u00fc\u00fcsite ja optimeerite andmebaaside p\u00e4ringuid?<\/b><\/p>\n
\"\u00c4rge<\/a><\/noindex>
\n
Allikas: 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\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\udd47 \u00c4rge kasutage OFFSET ja LIMIT p\u00e4ringutes lehek\u00fcntede kaupa | ProHoster","description":"Need p\u00e4evad, mil ei pidanud andmebaaside j\u00f5udluse optimeerimise p\u00e4rast muretsema, on m\u00f6\u00f6das. Aeg ei seisa paigal.","canonical_url":"https:\/\/prohoster.info\/et\/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":"et_EE","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\/et\/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\/et\/wp-json\/wp\/v2\/posts\/91048","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/comments?post=91048"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts\/91048\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/media\/91049"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/media?parent=91048"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/categories?post=91048"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/tags?post=91048"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}