{"id":39169,"date":"2019-10-31T22:28:14","date_gmt":"2019-10-31T19:28:14","guid":{"rendered":"https:\/\/prohoster.info\/blog\/postgresql-i-nastrojki-soglasovannosti-zapisi-dlya-kazhdogo-konkretnogo-soedineniya\/"},"modified":"2019-10-31T22:28:14","modified_gmt":"2019-10-31T19:28:14","slug":"postgresql-i-nastrojki-soglasovannosti-zapisi-dlya-kazhdogo-konkretnogo-soedineniya","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/postgresql-i-nastrojki-soglasovannosti-zapisi-dlya-kazhdogo-konkretnogo-soedineniya","title":{"rendered":"PostgreSQL und Einstellungen zur Konsistenz von Aufzeichnungen f\u00fcr jede einzelne Verbindung.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Die \u00dcbersetzung des Artikels wurde speziell f\u00fcr die Studierenden des Kurses erstellt \u201eDatenbanken\u201c<\/a><\/noindex>. Interessiert an einer Weiterentwicklung in diesem Bereich? Wir laden Sie ein zu Tag der offenen T\u00fcr<\/a><\/noindex>, an dem wir ausf\u00fchrlich \u00fcber das Programm, die Besonderheiten des Online-Formats, die Kompetenzen und die Karrierem\u00f6glichkeiten sprechen, die Absolventen nach dem Studium erwarten.<\/em><\/p>\n

<\/p>\n

\"PostgreSQL<\/p>\n

<\/p>\n

PostgreSQL und Einstellungen zur Konsistenz von Aufzeichnungen f\u00fcr jede einzelne Verbindung.
\nIn Compose haben wir es mit vielen Datenbanken zu tun, was uns die M\u00f6glichkeit gibt, ihre Funktionalit\u00e4t und Schw\u00e4chen n\u00e4her kennenzulernen. W\u00e4hrend wir beginnen, die funktionalen Merkmale neuer Datenbanken zu sch\u00e4tzen, denken wir manchmal, dass es gut w\u00e4re, wenn solche Funktionen auch in \u00e4lteren Werkzeugen vorhanden w\u00e4ren, mit denen wir schon lange arbeiten. Eine der neuen Funktionen, die wir in PostgreSQL sehen wollten, war die anpassbare Schreibkonsistenz pro Verbindung im gesamten Cluster. Und wie sich herausstellte, haben wir sie bereits, und heute wollen wir Ihnen Informationen dar\u00fcber geben, wie Sie sie nutzen k\u00f6nnen.<\/a><\/noindex><\/p>\n

<\/p>\n

Warum brauche ich das?<\/h1>\n

<\/p>\n

Das Verhalten eines Clusters h\u00e4ngt von Ihrer Anwendung ab. Nehmen wir beispielsweise eine Anwendung zur Rechnungszahlung. Sie ben\u00f6tigen eine hundertprozentige Konsistenz im Cluster, daher m\u00fcssen Sie synchrone Commits aktivieren, damit Ihre Datenbank auf alle \u00c4nderungen wartet. Wenn Ihre Anwendung jedoch ein schnell wachsendes soziales Netzwerk ist, ziehen Sie sicherlich eine schnelle Reaktionszeit der hundertprozentigen Konsistenz vor. Um dies zu erreichen, k\u00f6nnen Sie in Ihrem Cluster asynchrone Commits verwenden.<\/p>\n

<\/p>\n

Lernen Sie den Kompromiss kennen<\/h2>\n

<\/p>\n

Sie m\u00fcssen einen Kompromiss zwischen Datenkonsistenz und Leistung eingehen. PostgreSQL tendiert zur Konsistenz, da die Standardkonfiguration in diesem Fall vorhersehbar ist und keine unerwarteten \u00dcberraschungen mit sich bringt. Lassen Sie uns nun die Kompromisse kennenlernen.<\/p>\n

<\/p>\n

Kompromiss 1: Leistung<\/h3>\n

<\/p>\n

Wenn der PostgreSQL-Cluster keine Konsistenz ben\u00f6tigt, kann er durchaus asynchron arbeiten. Die Aufzeichnung erfolgt auf dem Cluster-Leiter, und seine Replikate erhalten nach wenigen Millisekunden die Aktualisierungen. Wenn der PostgreSQL-Cluster Konsistenz ben\u00f6tigt, muss er synchron arbeiten. Die Aufzeichnung wird beim Cluster-Leiter durchgef\u00fchrt, der die Aktualisierung an die Replikate sendet und die Best\u00e4tigung abwartet, dass jede Replik die Aufzeichnung durchgef\u00fchrt hat, bevor sie die Best\u00e4tigung an den Client sendet, der die Aufzeichnung initiiert hat, dass diese erfolgreich war. Der praktische Unterschied zwischen diesen Ans\u00e4tzen besteht darin, dass die asynchrone Methode zwei Netzwerk-Hops erfordert, w\u00e4hrend die synchrone vier erfordert. <\/p>\n

<\/p>\n

Kompromiss 2: Konsistenz<\/h3>\n

<\/p>\n

Das Ergebnis im Falle eines Ausfalls des Leiters in diesen beiden Ans\u00e4tzen wird ebenfalls unterschiedlich sein. Wenn die Arbeit asynchron ausgef\u00fchrt wird, werden bei einem solchen Fehler nicht alle Aufzeichnungen von den Replikaten erfasst. Wie viel geht verloren? Das h\u00e4ngt von der Anwendung selbst und der Effizienz der Replikation ab. Mit der Compose-Replikation wird ein Replikat daran gehindert, Leiter zu werden, wenn die Menge an Informationen darin 1 MB kleiner ist als die des Leiters, was bedeutet, dass beim asynchronen Betrieb potenziell bis zu 1 MB an Aufzeichnungen verloren gehen kann. <\/p>\n

<\/p>\n

Im synchronen Modus geschieht dies nicht. Wenn der Leiter ausf\u00e4llt, werden alle Replikate aktualisiert, da jede Aufzeichnung, die auf dem Leiter best\u00e4tigt wurde, auch in den Replikaten best\u00e4tigt werden muss. Das ist die Konsistenz. <\/p>\n

<\/p>\n

Das synchrone Verhalten macht Sinn in Anwendungen zur Zahlung von Rechnungen, wo Konsistenz einen klaren Vorteil bei der Suche nach einem Kompromiss zwischen Konsistenz und Leistung bietet. Das Wichtigste f\u00fcr eine solche Anwendung sind g\u00fcltige Daten. Denken Sie nun an ein soziales Netzwerk, in dem die Hauptaufgabe darin besteht, die Aufmerksamkeit der Benutzer zu halten, indem Anfragen so schnell wie m\u00f6glich beantwortet werden. In diesem Fall hat die Leistung mit weniger Netzwerk-Hops und k\u00fcrzerer Wartezeit auf Best\u00e4tigungen Priorit\u00e4t. Der Kompromiss zwischen Leistung und Konsistenz ist jedoch nicht der einzige, \u00fcber den man nachdenken muss.<\/p>\n

<\/p>\n

Kompromiss 3: Ausf\u00e4lle<\/h3>\n

<\/p>\n

Es ist sehr wichtig zu verstehen, wie sich ein Cluster w\u00e4hrend eines Fehlers verh\u00e4lt. Lassen Sie uns die Situation betrachten, in der eine oder mehrere Repliken ausfallen. Wenn die Commits asynchron verarbeitet werden, wird der Leader weiterhin funktionieren, d.h. er wird Aufzeichnungen empfangen und bearbeiten, ohne auf fehlende Repliken zu warten. Wenn die Repliken zur\u00fcck ins Cluster kommen, holen sie den Leader ein. Bei synchroner Replikation, wenn Repliken nicht antworten, hat der Leader keine Wahl und wird weiterhin auf die Best\u00e4tigung des Commits warten, bis die Replik ins Cluster zur\u00fcckkehrt und die Aufzeichnung annehmen und best\u00e4tigen kann.<\/p>\n

<\/p>\n

Eine Verbindung pro Transaktion?<\/h2>\n

<\/p>\n

Jede Anwendung ben\u00f6tigt eine spezielle Kombination aus Konsistenz und Leistung. Es sei denn, es handelt sich um unsere Rechnungsanwendung, die wir uns als vollst\u00e4ndig konsistent vorstellen, oder um unsere fast fl\u00fcchtige Social-Media-Anwendung. In allen anderen F\u00e4llen gibt es Momente, in denen einige Operationen synchron und andere asynchron sein m\u00fcssen. Sie m\u00f6chten vielleicht nicht, dass das System wartet, bis eine Nachricht im Chat committet wurde, aber wenn in derselben Anwendung eine Zahlung durchgef\u00fchrt wird, wird man warten m\u00fcssen.<\/p>\n

<\/p>\n

All diese Entscheidungen trifft nat\u00fcrlich der Anwendungsentwickler. Die richtigen Entscheidungen dar\u00fcber, wann welcher Ansatz angewendet werden soll, helfen, das Beste aus dem Cluster herauszuholen. Es ist wichtig, dass der Entwickler zwischen ihnen auf SQL-Ebene f\u00fcr Verbindungen und f\u00fcr Transaktionen wechseln kann. <\/p>\n

<\/p>\n

Praktische Sicherstellung der Kontrolle<\/h2>\n

<\/p>\n

Standardm\u00e4\u00dfig sorgt PostgreSQL f\u00fcr Konsistenz. Dies wird durch den Serverparameter synchronous_commit<\/code>kontrolliert. Standardm\u00e4\u00dfig ist er auf on<\/code>eingestellt, hat jedoch drei andere Optionen: local<\/code>, remote_write<\/code> oder off<\/code>.<\/p>\n

<\/p>\n

Wenn der Parameter auf eingestellt ist, werden alle synchronen Commits gestoppt, selbst im lokalen System. Der Parameter in local definiert den synchronen Modus f\u00fcr das lokale System, die Aufzeichnungen in Repliken erfolgen jedoch asynchron. off<\/code> Remote_write geht noch weiter: Aufzeichnungen in Repliken erfolgen asynchron, aber es wird zur\u00fcckgegeben, wenn die Replik die Aufzeichnung angenommen hat, diese jedoch nicht auf die Festplatte geschrieben hat.<\/code> Wenn wir den verf\u00fcgbaren Bereich an Optionen betrachten, w\u00e4hlen wir das Verhalten und, da wir uns bewusst sind, dass<\/p>\n

<\/p>\n

es sich um synchrone Aufzeichnungen handelt, w\u00e4hlen wir on<\/code> f\u00fcr asynchrone Commits \u00fcber das Netzwerk, w\u00e4hrend wir die lokalen Commits synchron lassen. local<\/code> f\u00fcr asynchrone Commits \u00fcber das Netzwerk und lassen dabei lokale Commits synchron.<\/p>\n

<\/p>\n

Jetzt zeigen wir Ihnen, wie Sie dies im Handumdrehen einstellen k\u00f6nnen, aber stellen Sie sich vor, dass wir es f\u00fcr den Server installiert haben. synchronous_commit<\/code> in local<\/code> Wir haben uns gefragt, ob man den Parameter synchronous_commit<\/code> zur Laufzeit \u00e4ndern kann, und es stellte sich heraus, dass es nicht nur m\u00f6glich ist, daf\u00fcr gibt es sogar zwei Methoden. Die erste besteht darin, die Sitzung Ihrer Verbindung wie folgt einzustellen:<\/p>\n

<\/p>\n

SET SESSION synchronous_commit TO ON;  \n\/\/ Ihre Schreibvorg\u00e4nge kommen hierhin<\/code><\/pre>\n
<\/p>\n
Alle nachfolgenden Schreibvorg\u00e4nge in der Sitzung best\u00e4tigen die Schreiboperationen f\u00fcr die Replikate, bevor sie das positive Ergebnis an den verbundenen Client zur\u00fcckgeben. Es sei denn, Sie \u00e4ndern die Einstellung synchronous_commit<\/code> wieder. Sie k\u00f6nnen den Teil SESSION<\/code> im Befehl weglassen, da er den Standardwert haben wird.<\/p>\n
<\/p>\n
Die zweite Methode eignet sich gut, wenn Sie sicherstellen m\u00f6chten, dass Sie eine synchrone Replikation f\u00fcr eine Transaktion erhalten. In vielen NoSQL-Datenbanken gibt es das Konzept der Transaktionen nicht, aber in PostgreSQL ist es vorhanden. In diesem Fall starten Sie eine Transaktion und setzen dann synchronous_commit<\/code> in on<\/code> vor der Ausf\u00fchrung des Schreibvorgangs f\u00fcr die Transaktion ein. COMMIT<\/code> wird die Transaktion festschreiben, indem es jeden Wert des Parameters verwendet, der zu diesem Zeitpunkt gesetzt war, obwohl es am besten ist, die Variable im Voraus zu setzen, damit andere Entwickler verstehen, dass die Aufzeichnungen nicht asynchron sind. synchronous_commit<\/code>BEGIN;  \nSET LOCAL synchronous_commit TO ON;  \n\/\/ Ihre Schreibvorg\u00e4nge kommen hierhin\nCOMMIT;<\/p>\n
<\/p>\n
Alle Commit-Transaktionen werden jetzt best\u00e4tigt, wie in Replikate geschrieben, bevor die Datenbank eine positive Antwort an den verbundenen Client zur\u00fcckgibt.  <\/code><\/pre>\n
<\/p>\n
PostgreSQL konfigurieren<\/p>\n
<\/p>\n
Vorher haben wir uns ein System von PostgreSQL mit<\/h2>\n
<\/p>\n
Wir haben uns ein PostgreSQL-System mit synchronous_commit<\/code>, das in local<\/code>, vorgestellt. Damit dies auf der Serverseite real ist, m\u00fcssen Sie zwei Konfigurationsparameter des Servers festlegen. Ein weiterer Parameter synchronous_standby_names<\/code> wird wirksam, wenn synchronous_commit<\/code> in on<\/code>. Er definiert, welche Replikate das Recht auf synchrone Commits haben, und wir werden ihn auf *<\/code>setzen, was bedeutet, dass alle Replikate aktiviert werden. Diese Werte werden normalerweise in der Konfigurationsdatei<\/a><\/noindex> durch Hinzuf\u00fcgen von: <\/p>\n
<\/p>\n
synchronous_commit = local  \nsynchronous_standby_names='*'<\/code><\/pre>\n
<\/p>\n
Indem wir den Parameter synchronous_commit<\/code> auf den Wert local<\/code>setzen, schaffen wir ein System, in dem lokale Festplatten synchron bleiben, w\u00e4hrend die Commits von Netzwerkreplikaten standardm\u00e4\u00dfig asynchron sind. Es sei denn, wir entscheiden uns, diese Commits synchron zu gestalten, wie oben gezeigt.<\/p>\n
<\/p>\n
Wenn Sie die Entwicklung des Projekt Governor verfolgt haben.<\/a><\/noindex>, Sie haben m\u00f6glicherweise einige k\u00fcrzliche \u00c4nderungen bemerkt (1<\/a><\/noindex>, 2<\/a><\/noindex>), die es den Benutzern von Governor erm\u00f6glichen, diese Einstellungen zu testen und ihre Konsistenz zu steuern.<\/p>\n
<\/p>\n
Noch ein paar Worte\u2026<\/h2>\n
<\/p>\n
Vor einer Woche h\u00e4tte ich Ihnen gesagt, dass es unm\u00f6glich ist, PostgreSQL so fein abzustimmen. Genau dann bestand Kurt, ein Mitglied des Compose-Plattformteams, darauf, dass es diese M\u00f6glichkeit gibt. Er bes\u00e4nftigte meine Bedenken und fand in der Dokumentation von PostgreSQL Folgendes<\/a><\/noindex>:<\/p>\n
<\/p>\n
\"PostgreSQL<\/p>\n
<\/p>\n
Dieser Parameter kann jederzeit ge\u00e4ndert werden. Das Verhalten f\u00fcr jede Transaktion wird durch die Einstellung definiert, die zum Zeitpunkt des Commits aktiv ist. Daher ist es m\u00f6glich und n\u00fctzlich, dass einige Transaktionen synchronen Commits durchf\u00fchren, w\u00e4hrend andere asynchron sind. Um beispielsweise eine multistatement<\/code> Transaktion dazu zu bringen, Commits asynchron durchzuf\u00fchren, wenn der Standardwert entgegengesetzt ist, setzen Sie bitte <\/em>SET LOCAL synchronous_commit TO OFF<\/code> in der Transaktion.<\/em><\/p>\n
<\/p>\n
Mit dieser kleinen Modifikation in der Konfigurationsdatei haben wir den Benutzern die M\u00f6glichkeit gegeben, ihre Konsistenz und Leistung zu steuern.<\/p>\n
Quelle: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
\u041f\u0435\u0440\u0435\u0432\u043e\u0434 \u0441\u0442\u0430\u0442\u044c\u0438 \u043f\u043e\u0434\u0433\u043e\u0442\u043e\u0432\u043b\u0435\u043d \u0441\u043f\u0435\u0446\u0438\u0430\u043b\u044c\u043d\u043e \u0434\u043b\u044f \u0441\u0442\u0443\u0434\u0435\u043d\u0442\u043e\u0432 \u043a\u0443\u0440\u0441\u0430 \u00ab\u0411\u0430\u0437\u044b \u0414\u0430\u043d\u043d\u044b\u0445\u00bb. \u0418\u043d\u0442\u0435\u0440\u0435\u0441\u043d\u043e \u0440\u0430\u0437\u0432\u0438\u0432\u0430\u0442\u044c\u0441\u044f \u0432 \u0434\u0430\u043d\u043d\u043e\u043c \u043d\u0430\u043f\u0440\u0430\u0432\u043b\u0435\u043d\u0438\u0438? \u041f\u0440\u0438\u0433\u043b\u0430\u0448\u0430\u0435\u043c \u0432\u0430\u0441 \u043d\u0430 \u0414\u0435\u043d\u044c \u041e\u0442\u043a\u0440\u044b\u0442\u044b\u0445 \u0414\u0432\u0435\u0440\u0435\u0439, \u0433\u0434\u0435 \u043c\u044b \u043f\u043e\u0434\u0440\u043e\u0431\u043d\u043e \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u044b\u0432\u0430\u0435\u043c \u043e \u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u0435, \u043e\u0441\u043e\u0431\u0435\u043d\u043d\u043e\u0441\u0442\u044f\u0445 \u043e\u043d\u043b\u0430\u0439\u043d-\u0444\u043e\u0440\u043c\u0430\u0442\u0430, \u043a\u043e\u043c\u043f\u0435\u0442\u0435\u043d\u0446\u0438\u044f\u0445 \u0438 \u043a\u0430\u0440\u044c\u0435\u0440\u043d\u044b\u0445 \u043f\u0435\u0440\u0441\u043f\u0435\u043a\u0442\u0438\u0432\u0430\u0445, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0436\u0434\u0443\u0442 \u0432\u044b\u043f\u0443\u0441\u043a\u043d\u0438\u043a\u043e\u0432 \u043f\u043e\u0441\u043b\u0435 \u043e\u0431\u0443\u0447\u0435\u043d\u0438\u044f. PostgreSQL \u0438 \u043d\u0430\u0441\u0442\u0440\u043e\u0439\u043a\u0438 \u0441\u043e\u0433\u043b\u0430\u0441\u043e\u0432\u0430\u043d\u043d\u043e\u0441\u0442\u0438 \u0437\u0430\u043f\u0438\u0441\u0438 \u0434\u043b\u044f \u043a\u0430\u0436\u0434\u043e\u0433\u043e \u043a\u043e\u043d\u043a\u0440\u0435\u0442\u043d\u043e\u0433\u043e \u0441\u043e\u0435\u0434\u0438\u043d\u0435\u043d\u0438\u044f \u041d\u0430\u043c \u0432 Compose \u043f\u0440\u0438\u0445\u043e\u0434\u0438\u0442\u0441\u044f \u0438\u043c\u0435\u0442\u044c \u0434\u0435\u043b\u043e \u0441\u043e \u043c\u043d\u043e\u0433\u0438\u043c\u0438 \u0431\u0430\u0437\u0430\u043c\u0438 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":29395,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-39169","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\udd47PostgreSQL und Einstellungen zur Konsistenz der Aufzeichnung f\u00fcr jede spezifische Verbindung | ProHoster","description":"Die \u00dcbersetzung des Artikels wurde speziell f\u00fcr die Studenten des Kurses \u00abDatenbanken\u00bb angefertigt. Interessiert daran, sich in diesem Bereich weiterzuentwickeln?","canonical_url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/postgresql-i-nastrojki-soglasovannosti-zapisi-dlya-kazhdogo-konkretnogo-soedineniya","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\udd47PostgreSQL \u0438 \u043d\u0430\u0441\u0442\u0440\u043e\u0439\u043a\u0438 \u0441\u043e\u0433\u043b\u0430\u0441\u043e\u0432\u0430\u043d\u043d\u043e\u0441\u0442\u0438 \u0437\u0430\u043f\u0438\u0441\u0438 \u0434\u043b\u044f \u043a\u0430\u0436\u0434\u043e\u0433\u043e \u043a\u043e\u043d\u043a\u0440\u0435\u0442\u043d\u043e\u0433\u043e \u0441\u043e\u0435\u0434\u0438\u043d\u0435\u043d\u0438\u044f | ProHoster","og:description":"\u041f\u0435\u0440\u0435\u0432\u043e\u0434 \u0441\u0442\u0430\u0442\u044c\u0438 \u043f\u043e\u0434\u0433\u043e\u0442\u043e\u0432\u043b\u0435\u043d \u0441\u043f\u0435\u0446\u0438\u0430\u043b\u044c\u043d\u043e \u0434\u043b\u044f \u0441\u0442\u0443\u0434\u0435\u043d\u0442\u043e\u0432 \u043a\u0443\u0440\u0441\u0430 \u00ab\u0411\u0430\u0437\u044b \u0414\u0430\u043d\u043d\u044b\u0445\u00bb. \u0418\u043d\u0442\u0435\u0440\u0435\u0441\u043d\u043e \u0440\u0430\u0437\u0432\u0438\u0432\u0430\u0442\u044c\u0441\u044f \u0432 \u0434\u0430\u043d\u043d\u043e\u043c \u043d\u0430\u043f\u0440\u0430\u0432\u043b\u0435\u043d\u0438\u0438?","og:url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/postgresql-i-nastrojki-soglasovannosti-zapisi-dlya-kazhdogo-konkretnogo-soedineniya","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":"2019-10-31T19:28:14+00:00","article:modified_time":"2019-10-31T19:28:14+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"39169","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":"2026-01-24 01:05:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 00:54:44","updated":"2026-01-24 01:05:19","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\/39169","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=39169"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/39169\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media\/29395"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=39169"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=39169"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=39169"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}