{"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\/ro\/blog\/administrirovanie\/ne-stoit-polzovatsya-offset-i-limit-v-zaprosah-s-razbieniem-na-straniczy","title":{"rendered":"Nu este recomandat s\u0103 folosi\u021bi OFFSET \u0219i LIMIT \u00een interog\u0103ri cu paginare","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Au trecut zilele \u00een care nu trebuia s\u0103-\u021bi fac\u0103 griji cu privire la optimizarea performan\u021bei bazelor de date. Timpul nu st\u0103 pe loc. Fiecare antreprenor din domeniul tehnologiilor avansate vrea s\u0103 creeze urm\u0103torul Facebook, str\u0103duindu-se \u00een acela\u0219i timp s\u0103 colecteze toate datele la care poate avea acces. Aceste date sunt necesare afacerii pentru a \u00eembun\u0103t\u0103\u021bi \u00eenv\u0103\u021barea modelului, care ajut\u0103 la generarea de venituri. \u00cen aceste condi\u021bii, programatorii trebuie s\u0103 creeze API-uri care s\u0103 permit\u0103 lucrul rapid \u0219i fiabil cu volume enorme de informa\u021bie.<\/p>\n

\"Nu<\/a><\/noindex>
\n<\/a><\/noindex>
\nDac\u0103 ai lucrat deja de ceva timp la proiectarea p\u0103r\u021bilor de server ale aplica\u021biilor sau bazelor de date, ai scris probabil cod pentru a face cereri cu paginare. De exemplu \u2014 a\u0219a:<\/p>\n

SELECT * FROM table_name LIMIT 10 OFFSET 40\n<\/code><\/pre>\n
\nA\u0219a e?<\/p>\n
Dar dac\u0103 ai efectuat paginarea exact a\u0219a, regret s\u0103 spun c\u0103 ai f\u0103cut-o departe de cel mai eficient mod.<\/p>\n
Vrei s\u0103 m\u0103 contrazici? Po\u021bi<\/a><\/noindex> nu<\/a><\/noindex> pierde<\/a><\/noindex> timp<\/a><\/noindex>. Slack<\/a><\/noindex>, Shopify<\/a><\/noindex> \u0219i Mixmax<\/a><\/noindex> folose\u0219te deja tehnicile despre care vreau s\u0103 vorbesc ast\u0103zi.<\/p>\n
Numi\u021bi m\u0103car un dezvoltator de backend care nu a folosit OFFSET<\/code> \u0219i LIMIT<\/code> pentru a face cereri cu paginare. \u00cen MVP (Minimum Viable Product, produs minimal viabil) \u0219i \u00een proiectele care folosesc volume mici de date, aceast\u0103 abordare este destul de aplicabil\u0103. Este, a\u0219adar, \"pur \u0219i simplu func\u021bioneaz\u0103\".<\/p>\n
Dar dac\u0103 trebuie s\u0103 creezi de la zero sisteme fiabile \u0219i eficiente, trebuie s\u0103 te ocupi din timp de eficien\u021ba execu\u021biei cererilor c\u0103tre bazele de date utilizate \u00een aceste sisteme.<\/p>\n
Ast\u0103zi vom discuta despre problemele care sunt asociate cu implement\u0103rile pe scar\u0103 larg\u0103 (din p\u0103cate a\u0219a este) ale mecanismelor de execu\u021bie a cererilor cu paginare, \u0219i despre cum s\u0103 ob\u021binem o performan\u021b\u0103 \u00eenalt\u0103 \u00een execu\u021bia unor astfel de cereri.<\/p>\n
Ce este \u00een neregul\u0103 cu OFFSET \u0219i LIMIT?<\/h2>\n
\nA\u0219a cum am men\u021bionat, OFFSET<\/code> \u0219i LIMIT<\/code> se comport\u0103 excelent \u00een proiectele \u00een care nu trebuie s\u0103 lucrezi cu volume mari de date.<\/p>\n
Problema apare atunci c\u00e2nd baza de date cre\u0219te la dimensiuni at\u00e2t de mari \u00eenc\u00e2t nu mai poate fi stocat\u0103 \u00een memoria serverului. Dar \u00een acela\u0219i timp, trebuie s\u0103 folose\u0219ti cereri cu paginare pentru a lucra cu aceast\u0103 baz\u0103 de date.<\/p>\n
Pentru ca aceast\u0103 problem\u0103 s\u0103 apar\u0103, trebuie s\u0103 existe o situa\u021bie \u00een care SGBD-ul s\u0103 recurg\u0103 la o opera\u021biune ineficient\u0103 de scanare complet\u0103 a tabelului (Full Table Scan) la executarea fiec\u0103rei interog\u0103ri cu paginare (\u00een acela\u0219i timp, pot avea loc opera\u021biuni de inserare \u0219i \u0219tergere a datelor, iar datele \u00eenvechite nu ne intereseaz\u0103!).<\/p>\n
Ce este \u201escanarea complet\u0103 a tabelului\u201d (sau \u201evizualizarea secven\u021bial\u0103 a tabelului\u201d, Sequential Scan)? Aceasta este o opera\u021biune \u00een timpul c\u0103reia SGBD-ul cite\u0219te secven\u021bial fiecare linie din tabel, adic\u0103 datele con\u021binute \u00een acesta, \u0219i le verific\u0103 pentru a se conforma unei condi\u021bii date. Este bine cunoscut faptul c\u0103 acest tip de scanare a tabelului este cel mai lent. Motivul este c\u0103, \u00een timpul execut\u0103rii sale, au loc multe opera\u021biuni de intrare\/ie\u0219ire, implic\u00e2nd subsistemul de disc al serverului. Situa\u021bia este agravat\u0103 de \u00eent\u00e2rzierile asociate cu lucrul cu datele stocate pe discuri \u0219i de faptul c\u0103 transferul de date de pe disc \u00een memorie este o opera\u021biune consumatoare de resurse.<\/p>\n
De exemplu, ave\u021bi \u00eenregistr\u0103ri despre 100000000 de utilizatori \u0219i executa\u021bi o interogare cu structura OFFSET 50000000<\/code>. Aceasta \u00eenseamn\u0103 c\u0103 SGBD-ul va trebui s\u0103 \u00eencarce toate aceste \u00eenregistr\u0103ri (iar acestea nu ne sunt necesare!), s\u0103 le plaseze \u00een memorie \u0219i abia apoi s\u0103 ia, s\u0103 zicem, 20 de rezultate, despre care este raportat \u00een LIMIT<\/code>.<\/p>\n
S\u0103 spunem c\u0103 ar putea ar\u0103ta astfel: \u201eselecta\u021bi liniile de la 50000 la 50020 din 100000\u201d. Asta \u00eenseamn\u0103 c\u0103, pentru a executa interogarea, sistemul va trebui mai \u00eent\u00e2i s\u0103 \u00eencarce 50000 de linii. Vede\u021bi c\u00e2t de mult\u0103 munc\u0103 inutil\u0103 trebuie s\u0103 efectueze?<\/p>\n
Dac\u0103 nu crede\u021bi \u2014 arunca\u021bi o privire la exemplul pe care l-am creat, folosind facilit\u0103\u021bile db-fiddle.com<\/a><\/noindex>.\u00a0<\/p>\n
\"Nu
\nExemplu pe db-fiddle.com<\/i><\/p>\n
Acolo, \u00een st\u00e2nga, \u00een c\u00e2mpul Schema SQL<\/code>, exist\u0103 un cod care execut\u0103 inser\u021bia \u00een baza de date a 100000 de linii, iar \u00een dreapta, \u00een c\u00e2mpul Query SQL<\/code>, sunt prezentate dou\u0103 interog\u0103ri. Prima, lent\u0103, arat\u0103 astfel:<\/p>\n
SELECT *\nFROM `docs`\nLIMIT 10 OFFSET 85000;\n<\/code><\/pre>\n
\nIar a doua, care reprezint\u0103 o solu\u021bie eficient\u0103 pentru aceea\u0219i problem\u0103, astfel:<\/p>\n
SELECT *\nFROM `docs`\nWHERE id > 85000\nLIMIT 10;\n<\/code><\/pre>\n
\nPentru a executa aceste interog\u0103ri, este suficient s\u0103 ap\u0103sa\u021bi butonul Run<\/code> \u00een partea de sus a paginii. Dup\u0103 ce am f\u0103cut asta, vom compara informa\u021biile despre timpul de execu\u021bie al interog\u0103rilor. Se dovede\u0219te c\u0103 executarea unei interog\u0103ri ineficiente dureaz\u0103, cel pu\u021bin, de 30 de ori mai mult dec\u00e2t execu\u021bia celei de-a doua (de la o rulare la alta, acest timp variaz\u0103, de exemplu, sistemul poate raporta c\u0103 execu\u021bia primei interog\u0103ri a durat 37 ms, iar a celei de-a doua \u2014 1 ms).<\/p>\n
\u0218i dac\u0103 vor fi mai multe date, atunci totul va ar\u0103ta \u0219i mai r\u0103u (pentru a verifica acest lucru, arunca\u021bi o privire la comentariul meu exemplu<\/a><\/noindex> cu 10 milioane de r\u00e2nduri).<\/p>\n
Ceea ce am discutat tocmai acum ar trebui s\u0103 v\u0103 ofere o \u00een\u021belegere mai bun\u0103 a modului \u00een care, de fapt, sunt procesate interog\u0103rile c\u0103tre bazele de date.<\/p>\n
Re\u021bine\u021bi c\u0103 cu c\u00e2t valoarea este mai mare OFFSET<\/code> cu at\u00e2t interogarea va dura mai mult.<\/p>\n
Ce ar trebui s\u0103 folosi\u021bi \u00een locul combina\u021biei OFFSET \u0219i LIMIT?<\/h2>\n
\n\u00cen locul combina\u021biei OFFSET<\/code> \u0219i LIMIT<\/code> ar trebui s\u0103 folosi\u021bi o structur\u0103 construit\u0103 dup\u0103 urm\u0103toarea schem\u0103:<\/p>\n
SELECT * FROM table_name WHERE id > 10 LIMIT 20\n<\/code><\/pre>\n
\nAceasta este executarea unei interog\u0103ri cu paginare pe baza cursorului (Cursor based pagination).<\/p>\n
\u00cen loc s\u0103 p\u0103stra\u021bi local curentele OFFSET<\/code> \u0219i LIMIT<\/code> \u0219i s\u0103 le transmite\u021bi cu fiecare interogare, ar trebui s\u0103 p\u0103stra\u021bi ultima cheie primar\u0103 ob\u021binut\u0103 (de obicei, aceasta este ID<\/code>) \u0219i LIMIT<\/code>, ca urmare, vor rezulta interog\u0103ri asem\u0103n\u0103toare cu cea de mai sus.<\/p>\n
De ce? Este vorba despre faptul c\u0103, specific\u00e2nd \u00een mod explicit identificatorul ultimei linii citite, \u00eei spune\u021bi SGBD-ului dumneavoastr\u0103 de unde s\u0103 \u00eenceap\u0103 c\u0103utarea datelor necesare. \u00cen plus, c\u0103utarea, datorit\u0103 utiliz\u0103rii cheii, se va desf\u0103\u0219ura eficient, sistemul nu va trebui s\u0103 se distrag\u0103 cu r\u00e2ndurile aflate dincolo de intervalul specificat.<\/p>\n
S\u0103 arunc\u0103m o privire asupra urm\u0103toarei compara\u021bii a performan\u021bei diferitelor interog\u0103ri. Iat\u0103 o interogare ineficient\u0103.<\/p>\n
\"Nu
\nCerere lent\u0103<\/i><\/p>\n
Iat\u0103 \u00eens\u0103 \u2014 versiunea optimizat\u0103 a acestei interog\u0103ri.<\/p>\n
\"Nu
\nInterogare rapid\u0103<\/i><\/p>\n
Ambele interog\u0103ri returneaz\u0103 exact acela\u0219i volum de date. Dar execu\u021bia primei dureaz\u0103 12,80 secunde, iar a celei de-a doua \u2014 0,01 secund\u0103. Sim\u021bi\u021bi diferen\u021ba?<\/p>\n
Posibile probleme<\/h2>\n
\nPentru a asigura o func\u021bionare eficient\u0103 a metodei propuse de executare a interog\u0103rilor, este necesar s\u0103 existe \u00een tabel o coloan\u0103 (sau coloane) care s\u0103 con\u021bin\u0103 indici unici, aranja\u021bi secven\u021bial, cum ar fi un identificator \u00eentreg. \u00cen anumite situa\u021bii specifice, acest lucru poate determina succesul aplic\u0103rii unor astfel de interog\u0103ri pentru a \u00eembun\u0103t\u0103\u021bi viteza de lucru cu baza de date.<\/p>\n
Desigur, atunci c\u00e2nd construim interog\u0103ri, trebuie s\u0103 \u021binem cont de caracteristicile arhitecturii tabelelor \u0219i s\u0103 alegem mecanismele care performeaz\u0103 cel mai bine pe tabelele existente. De exemplu, dac\u0103 trebuie s\u0103 lucr\u0103m cu cantit\u0103\u021bi mari de date corelate \u00een interog\u0103ri, s-ar putea s\u0103 v\u0103 intereseze aceasta<\/a><\/noindex> articolul.<\/p>\n
Dac\u0103 ne confrunt\u0103m cu problema absen\u021bei unei chei primare, de exemplu, dac\u0103 exist\u0103 un tabel cu o rela\u021bie \"mul\u021bi-la-mul\u021bi\", abordarea tradi\u021bional\u0103, care preconizeaz\u0103 utilizarea OFFSET<\/code> \u0219i LIMIT<\/code>, ne va fi garantat potrivit\u0103. Dar aplicarea sa poate conduce la executarea unor interog\u0103ri poten\u021bial lente. \u00cen astfel de cazuri, a\u0219 recomanda utilizarea unei chei primare cu auto-incrementare, chiar dac\u0103 aceasta este necesar\u0103 doar pentru organizarea interog\u0103rilor cu paginare.<\/p>\n
Dac\u0103 sunte\u021bi interesat de acest subiect \u2014 iat\u0103<\/a><\/noindex>, iat\u0103<\/a><\/noindex> \u0219i iat\u0103<\/a><\/noindex> \u2014 c\u00e2teva materiale utile.<\/p>\n
Concluzii<\/h2>\n
\nConcluzia principal\u0103 pe care o putem face este c\u0103, indiferent de dimensiunile bazelor de date despre care discut\u0103m, este necesar s\u0103 analiz\u0103m viteza de execu\u021bie a interog\u0103rilor. \u00cen vremurile noastre, scalabilitatea solu\u021biilor este extrem de important\u0103, iar dac\u0103 proiect\u0103m totul corect de la \u00eenceputul lucrului la un sistem, acest lucru poate scuti dezvoltatorul de numeroase probleme \u00een viitor.<\/p>\n
Cum analiza\u021bi \u0219i optimiza\u021bi interog\u0103rile c\u0103tre bazele de date?<\/b><\/p>\n
\"Nu<\/a><\/noindex>
\n
Sursa: 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\udd47Nu folosi\u021bi OFFSET \u0219i LIMIT \u00een interog\u0103ri cu paginare | ProHoster","description":"Au trecut acele zile c\u00e2nd nu era necesar s\u0103 te \u00eengrijorezi cu privire la optimizarea performan\u021bei bazelor de date. Timpul nu st\u0103 pe loc.","canonical_url":"https:\/\/prohoster.info\/ro\/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":"ro_RO","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\/ro\/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\/ro\/wp-json\/wp\/v2\/posts\/91048","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/comments?post=91048"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts\/91048\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/media\/91049"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/media?parent=91048"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/categories?post=91048"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/tags?post=91048"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}