{"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\/de\/blog\/administrirovanie\/ne-stoit-polzovatsya-offset-i-limit-v-zaprosah-s-razbieniem-na-straniczy","title":{"rendered":"Vermeiden Sie die Verwendung von OFFSET und LIMIT in paginierten Abfragen.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Die Zeiten, in denen man sich keine Sorgen um die Optimierung der Datenbankleistung machen musste, sind vorbei. Die Zeit steht nicht still. Jeder neue Unternehmer im Bereich der Hochtechnologie will ein weiteres Facebook schaffen und dabei alle Daten sammeln, die er erreichen kann. Diese Daten sind f\u00fcr das Gesch\u00e4ft notwendig, um qualitativ hochwertigere Modelle zu trainieren, die beim Geldverdienen helfen. Unter diesen Umst\u00e4nden m\u00fcssen Programmierer APIs erstellen, die eine schnelle und zuverl\u00e4ssige Verarbeitung von riesigen Datenmengen erm\u00f6glichen.<\/p>\n

\"Vermeiden<\/a><\/noindex>
\n<\/a><\/noindex>
\nWenn Sie sich bereits eine Weile mit dem Entwurf von Serverteilen von Anwendungen oder Datenbanken besch\u00e4ftigen, haben Sie wahrscheinlich Code geschrieben, um Abfragen mit Paging durchzuf\u00fchren. Zum Beispiel \u2014 so:<\/p>\n

SELECT * FROM table_name LIMIT 10 OFFSET 40\n<\/code><\/pre>\n
\nStimmt das?<\/p>\n
Wenn Sie das Paging genau so gemacht haben, muss ich bedauernd feststellen, dass Sie dies keineswegs auf die effektivste Weise getan haben.<\/p>\n
Wollen Sie mir widersprechen? Sie k\u00f6nnen<\/a><\/noindex> nicht<\/a><\/noindex> Zeit<\/a><\/noindex> Zeit<\/a><\/noindex>. Slack<\/a><\/noindex>, Shopify<\/a><\/noindex> und Mixmax<\/a><\/noindex> nutzt bereits die Techniken, von denen ich heute erz\u00e4hlen m\u00f6chte.<\/p>\n
Nennen Sie mir bitte einen Backend-Entwickler, der noch nie genutzt hat OFFSET<\/code> und LIMIT<\/code> um Abfragen mit Paging durchzuf\u00fchren. In MVP (Minimum Viable Product, minimal funktionsf\u00e4higes Produkt) und in Projekten, in denen kleine Datenmengen verwendet werden, ist dieser Ansatz durchaus anwendbar. Er funktioniert sozusagen \"einfach\".<\/p>\n
Aber wenn man von Grund auf zuverl\u00e4ssige und effiziente Systeme erstellen m\u00f6chte, sollte man im Voraus daf\u00fcr sorgen, dass die Abfragen an die Datenbanken, die in solchen Systemen verwendet werden, effizient ausgef\u00fchrt werden.<\/p>\n
Heute werden wir \u00fcber die Probleme sprechen, die mit den weit verbreiteten (leider ist es so) Implementierungen von Mechanismen zur Ausf\u00fchrung von Abfragen mit Paging verbunden sind, und dar\u00fcber, wie man eine hohe Leistung bei solchen Abfragen erzielen kann.<\/p>\n
Was ist falsch mit OFFSET und LIMIT?<\/h2>\n
\nWie bereits erw\u00e4hnt, OFFSET<\/code> und LIMIT<\/code> schneiden sich gut in Projekten, in denen nicht mit gro\u00dfen Datenmengen gearbeitet werden muss.<\/p>\n
Das Problem tritt auf, wenn die Datenbank so gro\u00df wird, dass sie nicht mehr in den Speicher des Servers passt. Aber dennoch m\u00fcssen bei der Arbeit mit dieser Datenbank Abfragen mit Paging verwendet werden.<\/p>\n
Um dieses Problem zu erkennen, muss eine Situation entstehen, in der das DBMS auf eine ineffiziente Operation des vollst\u00e4ndigen Tabellenscans (Full Table Scan) zur\u00fcckgreift, wenn es jede Anfrage mit Paging ausf\u00fchrt (w\u00e4hrenddessen k\u00f6nnen auch Einf\u00fcge- und L\u00f6schoperationen stattfinden, und veraltete Daten sind hierbei nicht erforderlich!).<\/p>\n
Was ist ein \u201evollst\u00e4ndiger Tabellenscan\u201c (oder \u201esequentieller Tabellenscan\u201c, Sequential Scan)? Dies ist eine Operation, bei der das DBMS jede Zeile der Tabelle nacheinander lesen, das hei\u00dft, die enthaltenen Daten, und diese auf \u00dcbereinstimmung mit einer bestimmten Bedingung \u00fcberpr\u00fcfen. Es ist bekannt, dass dieser Typ des Tabellenscans der langsamste ist. Das liegt daran, dass bei seiner Ausf\u00fchrung viele E\/A-Operationen durchgef\u00fchrt werden, die das Speichersystem des Servers einbeziehen. Die Situation wird durch Verz\u00f6gerungen, die mit der Arbeit mit Daten, die auf Festplatten gespeichert sind, verbunden sind, und durch die Tatsache, dass der Transfer von Daten von der Festplatte in den Speicher eine ressourcenintensive Operation ist, versch\u00e4rft.<\/p>\n
Zum Beispiel haben Sie Aufzeichnungen \u00fcber 100000000 Benutzer und f\u00fchren eine Anfrage mit der Konstruktion aus OFFSET 50000000<\/code>. Das bedeutet, dass das DBMS alle diese Aufzeichnungen laden muss (obwohl wir diese nicht einmal brauchen!), sie in den Speicher bringen und erst dann beispielsweise 20 Ergebnisse abrufen kann, die in LIMIT<\/code>.<\/p>\n
Nehmen wir an, das k\u00f6nnte so aussehen: \u201eW\u00e4hlen Sie Zeilen von 50000 bis 50020 aus 100000\u201c. Das hei\u00dft, um diese Anfrage auszuf\u00fchren, muss das System zuerst 50000 Zeilen laden. Sehen Sie, wie viel unn\u00f6tige Arbeit es verrichten muss?<\/p>\n
Wenn Sie es nicht glauben, schauen Sie sich das Beispiel an, das ich mit den M\u00f6glichkeiten von db-fiddle.com<\/a><\/noindex>.\u00a0<\/p>\n
\"Vermeiden
\nBeispiel auf db-fiddle.com<\/i><\/p>\n
Dort gibt es links im Feld Schema SQL<\/code>, einen Code, der 100000 Zeilen in die Datenbank einf\u00fcgt, und rechts im Feld Query SQL<\/code>, sind zwei Abfragen zu sehen. Die erste, langsame, sieht so aus:<\/p>\n
SELECT *\nFROM `docs`\nLIMIT 10 OFFSET 85000;\n<\/code><\/pre>\n
\nUnd die zweite, die eine effiziente L\u00f6sung f\u00fcr dieselbe Aufgabe darstellt, so:<\/p>\n
SELECT *\nFROM `docs`\nWHERE id > 85000\nLIMIT 10;\n<\/code><\/pre>\n
\nUm diese Abfragen auszuf\u00fchren, gen\u00fcgt es, auf die Schaltfl\u00e4che zu klicken. Ausf\u00fchren<\/code> Im oberen Teil der Seite. Wenn Sie dies tun, vergleichen wir die Daten \u00fcber die Ausf\u00fchrungszeiten der Anfragen. Es stellt sich heraus, dass die Ausf\u00fchrung einer ineffizienten Anfrage mindestens 30-mal l\u00e4nger dauert als die Ausf\u00fchrung der zweiten (von Ausf\u00fchrung zu Ausf\u00fchrung variiert diese Zeit beispielsweise, das System kann berichten, dass die Ausf\u00fchrung der ersten Anfrage 37 ms in Anspruch genommen hat, w\u00e4hrend die Ausf\u00fchrung der zweiten 1 ms dauert).<\/p>\n
Und wenn es mehr Daten gibt, wird alles noch schlimmer aussehen (um dies festzustellen, werfen Sie einen Blick auf mein Beispiel<\/a><\/noindex> mit 10 Millionen Zeilen).<\/p>\n
Das, was wir gerade besprochen haben, sollte Ihnen ein gewisses Verst\u00e4ndnis daf\u00fcr geben, wie Anfragen an Datenbanken tats\u00e4chlich verarbeitet werden.<\/p>\n
Bedenken Sie, dass je gr\u00f6\u00dfer der Wert ist, OFFSET<\/code> desto l\u00e4nger dauert die Anfrage.<\/p>\n
Was sollte man anstelle der Kombination OFFSET und LIMIT verwenden?<\/h2>\n
\nStatt einer Kombination OFFSET<\/code> und LIMIT<\/code> sollte eine Konstruktion verwendet werden, die nach folgendem Schema aufgebaut ist:<\/p>\n
SELECT * FROM table_name WHERE id > 10 LIMIT 20\n<\/code><\/pre>\n
\nDies ist die Ausf\u00fchrung einer Anfrage mit Pagination basierend auf einem Cursor (Cursor basierte Pagination).<\/p>\n
Anstatt die aktuellen OFFSET<\/code> und LIMIT<\/code> lokal zu speichern und sie mit jeder Anfrage zu \u00fcbermitteln, sollten Sie den letzten erhaltenen Prim\u00e4rschl\u00fcssel speichern (in der Regel ist dies ID<\/code>) und LIMIT<\/code>und in der Folge ergeben sich Anfragen, die der oben genannten \u00e4hneln.<\/p>\n
Warum? Der Grund ist, dass Sie durch die explizite Angabe der Identifikation der zuletzt gelesenen Zeile Ihrer DBMS mitteilen, wo sie die Suche nach den erforderlichen Daten beginnen soll. Dar\u00fcber hinaus wird die Suche durch die Verwendung des Schl\u00fcssels effizienter, das System muss sich nicht mit Zeilen befassen, die au\u00dferhalb des angegebenen Bereichs liegen.<\/p>\n
Lassen Sie uns den folgenden Vergleich der Leistung verschiedener Anfragen betrachten. Hier ist eine ineffiziente Anfrage.<\/p>\n
\"Vermeiden
\nLangsame Abfrage<\/i><\/p>\n
Und hier ist die optimierte Version dieser Anfrage.<\/p>\n
\"Vermeiden
\nSchnelle Anfrage<\/i><\/p>\n
Beide Anfragen geben exakt dasselbe Datenvolumen zur\u00fcck. Aber die erste ben\u00f6tigt 12,80 Sekunden zur Ausf\u00fchrung, w\u00e4hrend die zweite 0,01 Sekunden in Anspruch nimmt. F\u00fchlen Sie den Unterschied?<\/p>\n
M\u00f6gliche Probleme<\/h2>\n
\nUm die effektive Nutzung der vorgeschlagenen Methode zur Ausf\u00fchrung von Anfragen sicherzustellen, muss die Tabelle eine oder mehrere Spalten aufweisen, die eindeutige, fortlaufend angeordnete Indizes enthalten, wie zum Beispiel eine ganzzahlige Identifikationsnummer. In bestimmten speziellen F\u00e4llen kann dies den Erfolg der Anwendung solcher Anfragen zur Steigerung der Geschwindigkeit beim Arbeiten mit der Datenbank bestimmen.<\/p>\n
Nat\u00fcrlich ist es wichtig, beim Konstruieren von Anfragen die Besonderheiten der Tabellarchitektur zu ber\u00fccksichtigen und die Mechanismen auszuw\u00e4hlen, die sich am besten bei den vorhandenen Tabellen bew\u00e4hren. Wenn Sie beispielsweise mit gro\u00dfen Mengen verkn\u00fcpfter Daten in Anfragen arbeiten m\u00fcssen, k\u00f6nnte Ihnen das interessieren dies<\/a><\/noindex> Artikel.<\/p>\n
Wenn wir mit dem Problem eines fehlenden Prim\u00e4rschl\u00fcssels konfrontiert sind, zum Beispiel in einer Tabelle mit einer \"Viele-zu-viele\"-Beziehung, wird der traditionelle Ansatz, der die Anwendung von OFFSET<\/code> und LIMIT<\/code>, auf jeden Fall geeignet sein. Aber seine Anwendung kann zu potenziell langsamen Anfragen f\u00fchren. In solchen F\u00e4llen w\u00fcrde ich empfehlen, einen Prim\u00e4rschl\u00fcssel mit automatischer Inkrementierung zu verwenden, selbst wenn er nur zur Organisation der Ausf\u00fchrung von Anfragen mit Paginierung ben\u00f6tigt wird.<\/p>\n
Wenn Sie sich f\u00fcr dieses Thema interessieren \u2014 hier<\/a><\/noindex>, hier<\/a><\/noindex> und hier<\/a><\/noindex> \u2014 einige n\u00fctzliche Materialien.<\/p>\n
Ergebnisse<\/h2>\n
\nDie wichtigste Erkenntnis, die wir gewinnen k\u00f6nnen, besteht darin, dass es unabh\u00e4ngig von der Gr\u00f6\u00dfe der Datenbanken notwendig ist, die Geschwindigkeit der Anfragen zu analysieren. In unserer Zeit ist die Skalierbarkeit von L\u00f6sungen extrem wichtig, und wenn man zu Beginn der Arbeit an einem System alles richtig plant, kann man den Entwickler in der Zukunft von vielen Problemen befreien.<\/p>\n
Wie analysieren und optimieren Sie Anfragen an Datenbanken?<\/b><\/p>\n
\"Vermeiden<\/a><\/noindex>
\n
Quelle: 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\udd47Vermeiden Sie es, OFFSET und LIMIT in Anfragen zur Paginierung zu verwenden | ProHoster","description":"Die Zeiten, in denen man sich keine Gedanken \u00fcber die Leistung von Datenbanken machen musste, sind vorbei. Die Zeit steht nicht still.","canonical_url":"https:\/\/prohoster.info\/de\/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":"de_DE","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\/de\/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\/de\/wp-json\/wp\/v2\/posts\/91048","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/comments?post=91048"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/91048\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media\/91049"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=91048"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=91048"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=91048"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}