{"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":"Verwenden Sie OFFSET und LIMIT nicht in paginierten Abfragen.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Die Zeiten, in denen man sich keine Gedanken \u00fcber die Optimierung der Datenbankleistung machen musste, sind vorbei. Die Zeit bleibt nicht stehen. Jeder neue Unternehmer im Technologiebereich m\u00f6chte das n\u00e4chste Facebook schaffen und dabei alle Daten sammeln, die ihm zug\u00e4nglich sind. Diese Daten sind f\u00fcr Unternehmen erforderlich, um qualitativ hochwertige Modelle zu trainieren, die helfen, Gewinne zu generieren. Unter diesen Bedingungen m\u00fcssen Programmierer APIs erstellen, die es erm\u00f6glichen, schnell und zuverl\u00e4ssig mit gro\u00dfen Datenmengen zu arbeiten.<\/p>\n

\"Verwenden<\/a><\/noindex>
\n<\/a><\/noindex>
\nWenn Sie bereits seit einiger Zeit an der Gestaltung von Server-Komponenten oder Datenbanken arbeiten, haben Sie wahrscheinlich Code geschrieben, um paginierte Anfragen auszuf\u00fchren. Zum Beispiel solchen:<\/p>\n

SELECT * FROM table_name LIMIT 10 OFFSET 40\n<\/code><\/pre>\n
\nStimmt das?<\/p>\n
Aber wenn Sie die Paginierung genau so durchgef\u00fchrt haben, muss ich leider sagen, dass Sie das bei weitem nicht am effizientesten gemacht haben.<\/p>\n
M\u00f6chten Sie mir widersprechen? Sie k\u00f6nnen<\/a><\/noindex> nicht<\/a><\/noindex> ausgeben<\/a><\/noindex> die Zeit<\/a><\/noindex>. Slack<\/a><\/noindex>, Shopify<\/a><\/noindex> und Mixmax<\/a><\/noindex> verwenden bereits Techniken, \u00fcber die ich heute sprechen m\u00f6chte.<\/p>\n
Nennen Sie mindestens einen Backend-Entwickler, der niemals genutzt hat OFFSET<\/code> und LIMIT<\/code> um Anfragen mit Seitenaufteilung durchzuf\u00fchren. In MVPs (Minimum Viable Product) und in Projekten mit kleinen Datenmengen ist dieser Ansatz durchaus praktikabel. Er funktioniert einfach.<\/p>\n
Wenn jedoch zuverl\u00e4ssige und effiziente Systeme von Grund auf erstellt werden m\u00fcssen, sollte im Voraus auf die Effizienz der Datenbankabfragen geachtet werden, die in solchen Systemen verwendet werden.<\/p>\n
Heute sprechen wir \u00fcber die Probleme, die mit den weit verbreiteten (leider) Implementierungen von Anfragen mit Seitenaufteilung verbunden sind, und dar\u00fcber, wie man eine hohe Leistung bei der Ausf\u00fchrung solcher Anfragen erreichen kann.<\/p>\n
Was ist falsch mit OFFSET und LIMIT?<\/h2>\n
\nWie bereits erw\u00e4hnt, OFFSET<\/code> und LIMIT<\/code> zeigen sich in Projekten, in denen keine gro\u00dfen Datenmengen verarbeitet werden m\u00fcssen, hervorragend.<\/p>\n
Das Problem tritt auf, wenn die Datenbank so gro\u00df wird, dass sie nicht mehr in den RAM des Servers passt. Aber w\u00e4hrend der Arbeit mit dieser Datenbank m\u00fcssen trotzdem Anfragen mit Seitenaufteilung verwendet werden.<\/p>\n
Damit dieses Problem auftritt, muss eine Situation entstehen, in der das DBMS bei der Ausf\u00fchrung jeder Anfrage mit Paging eine ineffiziente vollst\u00e4ndige Tabellenscan-Operation (Full Table Scan) durchf\u00fchrt (w\u00e4hrend gleichzeitig Daten eingef\u00fcgt oder gel\u00f6scht werden k\u00f6nnen, und veraltete Daten sind dabei 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 sequentiell liest, das hei\u00dft, die darin enthaltenen Daten \u00fcberpr\u00fcft und mit einer bestimmten Bedingung vergleicht. Es ist bekannt, dass dieser Typ des Tabellenscans der langsamste ist. Das liegt daran, dass bei seiner Ausf\u00fchrung viele Ein-\/Ausgabeoperationen beteiligt sind, die das Speichersystem des Servers beanspruchen. Die Situation wird durch die Verz\u00f6gerungen, die mit der Arbeit mit auf der Festplatte gespeicherten Daten verbunden sind, und die Tatsache, dass der Datentransfer von der Festplatte in den Speicher eine ressourcenintensive Operation ist, versch\u00e4rft.<\/p>\n
Zum Beispiel haben Sie Aufzeichnungen \u00fcber 100000000 Benutzer, und Sie f\u00fchren eine Anfrage mit der Konstruktion aus OFFSET 50000000<\/code>. Das bedeutet, dass das DBMS all diese Datens\u00e4tze laden muss (obwohl wir sie eigentlich nicht ben\u00f6tigen!), sie im Speicher ablegen und dann beispielsweise 20 Ergebnisse abrufen muss, die in LIMIT<\/code>.<\/p>\n
So k\u00f6nnte es aussehen: \u201eW\u00e4hlen Sie die Zeilen von 50000 bis 50020 aus 100000\u201c. Das hei\u00dft, das System muss zuerst 50000 Zeilen laden, um die Anfrage auszuf\u00fchren. Sehen Sie, wie viel unn\u00f6tige Arbeit es leisten muss?<\/p>\n
Wenn Sie es nicht glauben, werfen Sie einen Blick auf das Beispiel, das ich unter Verwendung der M\u00f6glichkeiten erstellt habe. db-fiddle.com<\/a><\/noindex>.\u00a0<\/p>\n
\"Verwenden
\nBeispiel auf db-fiddle.com<\/i><\/p>\n
Dort, links im Feld Schema SQL<\/code>, befindet sich der Code, der das Einf\u00fcgen von 100000 Zeilen in die Datenbank ausf\u00fchrt, w\u00e4hrend rechts im Feld Query SQL<\/code>, zwei Anfragen dargestellt sind. 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 dasselbe Problem darstellt, so:<\/p>\n
SELECT *\nFROM `docs`\nWHERE id > 85000\nLIMIT 10;\n<\/code><\/pre>\n
\nUm diese Abfragen auszuf\u00fchren, gen\u00fcgt ein Klick auf die Schaltfl\u00e4che Ausf\u00fchren<\/code> oben auf der Seite. Wenn Sie dies tun, k\u00f6nnen wir die Informationen \u00fcber die Abfragezeit vergleichen. Es stellt sich heraus, dass bei der Ausf\u00fchrung einer ineffizienten Anfrage mindestens 30-mal mehr Zeit ben\u00f6tigt wird als f\u00fcr die Ausf\u00fchrung der zweiten (von Durchlauf zu Durchlauf kann sich diese Zeit unterscheiden; beispielsweise kann das System melden, dass die Ausf\u00fchrung der ersten Anfrage 37 ms und die der zweiten 1 ms dauerte).<\/p>\n
Und wenn die Datenmenge gr\u00f6\u00dfer wird, sieht es noch schlechter aus (um dies zu \u00fcberpr\u00fcfen, werfen Sie einen Blick auf meine Nummer 00 oder<\/a><\/noindex> mit 10 Millionen Zeilen).<\/p>\n
Was wir gerade besprochen haben, sollte Ihnen ein gewisses Verst\u00e4ndnis daf\u00fcr vermitteln, wie Anfragen an Datenbanken tats\u00e4chlich verarbeitet werden.<\/p>\n
Bedenken Sie, dass je h\u00f6her der Wert ist, OFFSET<\/code> desto l\u00e4nger die Anfrage dauert.<\/p>\n
Was sollte stattdessen anstelle der Kombination OFFSET und LIMIT verwendet werden?<\/h2>\n
\nAnstelle der Kombination OFFSET<\/code> und LIMIT<\/code> sollte die folgende Konstruktion verwendet werden:<\/p>\n
SELECT * FROM table_name WHERE id > 10 LIMIT 20\n<\/code><\/pre>\n
\nDies ist die Ausf\u00fchrung der Abfrage mit paginierten Ergebnissen, basierend auf dem Cursor (cursorbasierte Paginierung).<\/p>\n
Anstatt den aktuellen OFFSET<\/code> und LIMIT<\/code> und sie bei jeder Anfrage zu \u00fcbermitteln, ist es notwendig, den zuletzt erhaltenen Prim\u00e4rschl\u00fcssel zu speichern (normalerweise ist das ID<\/code>) und LIMIT<\/code>, wodurch Anfragen entstehen, die den oben genannten \u00e4hneln.<\/p>\n
Warum? Der Grund ist, dass Sie durch die explizite Angabe der ID der zuletzt gelesenen Zeile Ihrer DBMS mitteilen, wo sie mit der Suche nach den ben\u00f6tigten Daten beginnen soll. Dank der Verwendung des Schl\u00fcssels erfolgt die Suche effizient, da das System nicht abgelenkt wird von Zeilen, die au\u00dferhalb des angegebenen Bereichs liegen.<\/p>\n
Lassen Sie uns einen Blick auf den folgenden Vergleich der Performance verschiedener Abfragen werfen. Hier ist eine ineffiziente Abfrage.<\/p>\n
\"Verwenden
\nLangsame Anfrage<\/i><\/p>\n
Und hier ist die optimierte Version dieser Abfrage.<\/p>\n
\"Verwenden
\nSchnelle Abfrage<\/i><\/p>\n
Beide Abfragen geben genau denselben Datenumfang zur\u00fcck. Doch die Ausf\u00fchrung der ersten dauert 12,80 Sekunden, w\u00e4hrend die zweite nur 0,01 Sekunde ben\u00f6tigt. F\u00fchlen Sie den Unterschied?<\/p>\n
M\u00f6gliche Probleme<\/h2>\n
\nF\u00fcr die effektive Ausf\u00fchrung der vorgeschlagenen Abfragemethode ist es notwendig, dass die Tabelle eine oder mehrere Spalten mit einzigartigen, aufeinanderfolgenden Indizes wie einer Ganzzahl-ID enth\u00e4lt. In einigen speziellen F\u00e4llen kann dies den Erfolg der Anwendung solcher Abfragen zur Beschleunigung der Datenbankoperationen bestimmen.<\/p>\n
Nat\u00fcrlich m\u00fcssen beim Konstruieren von Abfragen die Besonderheiten der Tabellenarchitektur ber\u00fccksichtigt werden, und es sollte die Mechanismen ausgew\u00e4hlt werden, die sich am besten in den gegebenen Tabellen bew\u00e4hren. Zum Beispiel, wenn Sie bei Abfragen mit gro\u00dfen Mengen verwandter Daten arbeiten m\u00fcssen, k\u00f6nnte f\u00fcr Sie interessant sein, diesem<\/a><\/noindex> Artikel.<\/p>\n
Wenn wir mit dem Problem eines fehlenden Prim\u00e4rschl\u00fcssels konfrontiert sind, zum Beispiel wenn eine Tabelle mit einer \"viele-zu-viele\"-Beziehung vorliegt, dann erfordert der traditionelle Ansatz die Anwendung OFFSET<\/code> und LIMIT<\/code>, es ist garantiert geeignet. Allerdings kann die Anwendung zu potenziell langsamen Abfragen f\u00fchren. In solchen F\u00e4llen w\u00fcrde ich empfehlen, einen Prim\u00e4rschl\u00fcssel mit automatischer Inkrementierung zu verwenden, auch wenn dieser nur zur Organisation der paginierten Abfragen ben\u00f6tigt wird.<\/p>\n
Wenn Sie an diesem Thema interessiert sind \u2014 hier ist<\/a><\/noindex>, hier ist<\/a><\/noindex> und hier ist<\/a><\/noindex> \u2014 hier sind einige n\u00fctzliche Materialien.<\/p>\n
Ergebnisse<\/h2>\n
\nDie Hauptschlussfolgerung, die wir ziehen k\u00f6nnen, ist, dass unabh\u00e4ngig von der Gr\u00f6\u00dfe der Datenbanken immer die Geschwindigkeit der Abfragen analysiert werden muss. In der heutigen Zeit ist die Skalierbarkeit der L\u00f6sungen von entscheidender Bedeutung, und wenn man von Anfang an ein System richtig plant, kann man in der Zukunft dem Entwickler viele Probleme ersparen.<\/p>\n
Wie analysieren und optimieren Sie die Abfragen in Datenbanken?<\/b><\/p>\n
\"Verwenden<\/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 die Verwendung von OFFSET und LIMIT in paginierten Abfragen | ProHoster","description":"Die Zeiten, in denen man sich keine Gedanken \u00fcber die Optimierung der Datenbankleistung machen musste, sind vorbei. Die Zeit steht nicht still. Jeder neue Unternehmer im Bereich der Hochtechnologie will das n\u00e4chste Facebook schaffen und gleichzeitig alle Daten sammeln, die er erreichen kann. Diese Daten sind f\u00fcr Unternehmen wichtig, um die Modelle besser zu trainieren, die helfen, Gewinne zu erzielen. Unter diesen Bedingungen m\u00fcssen Entwickler","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. \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","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":null,"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":"2022-10-04 04:57:05"},"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}]}}