{"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 die Anpassung der Konsistenz von Aufzeichnungen f\u00fcr jede spezifische 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>. M\u00f6chten Sie sich in diesem Bereich weiterentwickeln? Wir laden Sie ein zu unserem Tag der offenen T\u00fcr<\/a><\/noindex>, wo wir Ihnen das Programm, die Besonderheiten des Online-Formats, die Kompetenzen und die Karrierechancen, die Absolventen nach dem Studium erwarten, ausf\u00fchrlich erkl\u00e4ren.<\/em><\/p>\n

<\/p>\n

\"PostgreSQL<\/p>\n

<\/p>\n

PostgreSQL und die Anpassung der Konsistenz von Aufzeichnungen f\u00fcr jede spezifische Verbindung
\nBei Compose arbeiten wir mit vielen Datenbanken, was uns erm\u00f6glicht, deren Funktionalit\u00e4ten und Schw\u00e4chen genauer kennenzulernen. W\u00e4hrend wir beginnen, die funktionalen Eigenschaften neuer Datenbanken zu sch\u00e4tzen, denken wir manchmal daran, wie sch\u00f6n es w\u00e4re, wenn \u00e4hnliche Funktionen auch in den reiferen Tools vorhanden w\u00e4ren, mit denen wir schon lange arbeiten. Eine der neuen Funktionen, die wir uns in PostgreSQL gew\u00fcnscht hatten, war die anpassbare Konsistenz von Aufzeichnungen pro Verbindung im gesamten Cluster. Und wie sich herausstellte, haben wir sie bereits, und heute m\u00f6chten wir Ihnen Informationen dar\u00fcber geben, wie Sie diese nutzen k\u00f6nnen.<\/a><\/noindex><\/p>\n

<\/p>\n

Warum ist das f\u00fcr mich wichtig?<\/h1>\n

<\/p>\n

Das Verhalten eines Clusters h\u00e4ngt von Ihrer Anwendung ab. Nehmen wir als Beispiel eine Rechnungszahlungsanwendung. Hier ben\u00f6tigen Sie hundertprozentige Konsistenz im Cluster, was bedeutet, dass Sie synchrone Commits aktivieren m\u00fcssen, damit Ihre Datenbank wartet, bis alle \u00c4nderungen vorgenommen wurden. Wenn jedoch Ihre Anwendung ein schnell wachsendes soziales Netzwerk ist, werden Sie wahrscheinlich eine schnelle Reaktionszeit anstelle von hundertprozentiger Konsistenz bevorzugen. 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 stehen vor dem Kompromiss zwischen Datenkonsistenz und Leistung. PostgreSQL bewegt sich von der Konsistenz weg, da die Standardkonfiguration in diesem Fall vorhersehbar und ohne unerwartete \u00dcberraschungen ist. Lassen Sie uns nun die Kompromisse kennenlernen.<\/p>\n

<\/p>\n

Kompromiss 1: Leistung<\/h3>\n

<\/p>\n

Wenn ein PostgreSQL-Cluster keine Konsistenz ben\u00f6tigt, kann er durchaus asynchron betrieben werden. Die Schreiboperation erfolgt beim Cluster-Prim\u00e4rserver, und dessen Replikate erhalten nach wenigen Millisekunden die Updates. Wenn der PostgreSQL-Cluster jedoch Konsistenz ben\u00f6tigt, muss er synchron arbeiten. Die Schreiboperation wird beim Prim\u00e4rserver ausgef\u00fchrt, der die Updates an die Replikate sendet und auf eine Best\u00e4tigung wartet, dass jedes Replikat die Schreiboperation erfolgreich durchgef\u00fchrt hat, bevor eine Best\u00e4tigung an den Client gesendet wird, der die Schreiboperation initiiert hat, dass die Operation erfolgreich war. Der praktische Unterschied zwischen diesen Ans\u00e4tzen besteht darin, dass die asynchrone Methode zwei Netzwerk-Hops erfordert, w\u00e4hrend die synchrone Methode vier erfordert. <\/p>\n

<\/p>\n

Kompromiss 2: Konsistenz<\/h3>\n

<\/p>\n

Das Resultat im Falle eines Ausfalls des Leaders in diesen beiden Ans\u00e4tzen wird ebenfalls unterschiedlich sein. Wenn die Aufgaben asynchron ausgef\u00fchrt werden, sind bei einem solchen Fehler nicht alle Aufzeichnungen in den Replikaten gespeichert. Wie viel wird verloren gehen? Das h\u00e4ngt von der Anwendung selbst und der Effizienz der Replikation ab. Die Compose-Replikation verhindert, dass ein Replikat zum Leader wird, wenn die Datenmenge darin 1 MB geringer ist als beim Leader, was bedeutet, dass potenziell bis zu 1 MB an Aufzeichnungen bei asynchronem Betrieb verloren gehen kann. <\/p>\n

<\/p>\n

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

<\/p>\n

Synchrones Verhalten ist sinnvoll in einer Rechnungserstellungsanwendung, wo Konsistenz klarer Vorteil bietet, um einen Kompromiss zwischen Konsistenz und Leistung zu finden. Das Wichtigste f\u00fcr eine solche Anwendung sind g\u00fcltige Daten. Denken Sie jetzt an ein soziales Netzwerk, in dem die Hauptaufgabe darin besteht, die Aufmerksamkeit des Nutzers zu halten, indem Anfragen so schnell wie m\u00f6glich beantwortet werden. In diesem Fall hat die Leistung mit weniger Netzwerk-Hops und k\u00fcrzeren Wartezeiten auf Commits oberste Priorit\u00e4t. Doch der Kompromiss zwischen Leistung und Konsistenz ist nicht der einzige, \u00fcber den man nachdenken muss.<\/p>\n

<\/p>\n

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

<\/p>\n

Es ist entscheidend zu verstehen, wie sich ein Cluster w\u00e4hrend eines Ausfalls verh\u00e4lt. Betrachten wir die Situation, in der eine oder mehrere Replikate ausfallen. Wenn die Commits asynchron verarbeitet werden, wird der Leader weiterhin funktionieren, das hei\u00dft, er wird Daten entgegennehmen und verarbeiten, ohne auf die fehlenden Replikate zu warten. Wenn die Replikate wieder im Cluster sind, holen sie den Leader auf. Bei synchroner Replikation, wenn die Replikate nicht antworten, hat der Leader keine Wahl und wird weiterhin auf die Best\u00e4tigung des Commits warten, bis das Replikat wieder im Cluster ist und die Daten annehmen und best\u00e4tigen kann.<\/p>\n

<\/p>\n

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

<\/p>\n

Jede Anwendung ben\u00f6tigt eine spezifische Balance zwischen Konsistenz und Leistung. Es sei denn, sie ist unsere Buchhaltungsanwendung, die wir uns als vollkommen konsistent vorstellen, oder unsere fast fl\u00fcchtige Social-Media-Anwendung. In allen anderen F\u00e4llen gibt es Momente, in denen einige Operationen synchron und andere asynchron ausgef\u00fchrt werden m\u00fcssen. Sie m\u00f6chten wahrscheinlich nicht, dass das System darauf wartet, dass eine im Chat gesendete Nachricht festgeschrieben wird, aber wenn in derselben Anwendung eine Zahlung erfolgt, muss es eben warten.<\/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 auf der SQL-Ebene sowohl f\u00fcr Verbindungen als auch f\u00fcr Transaktionen zwischen den Ans\u00e4tzen wechseln kann. <\/p>\n

<\/p>\n

Die praktische Kontrolle gew\u00e4hrleisten<\/h2>\n

<\/p>\n

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

<\/p>\n

Beim Setzen des Parameters auf off<\/code> Alle synchronen Commits werden gestoppt, auch im lokalen System. Der Parameter in local definiert den synchronen Modus f\u00fcr das lokale System, jedoch erfolgen die Aufzeichnungen in den Replikaten asynchron. Remote_write<\/code> geht sogar noch weiter: Die Aufzeichnungen in den Replikaten erfolgen asynchron, aber sie werden zur\u00fcckgegeben, sobald das Replikat die Aufzeichnung akzeptiert hat, aber sie noch nicht auf die Festplatte geschrieben wurde.<\/p>\n

<\/p>\n

Wenn wir das vorhandene Spektrum an Optionen betrachten, w\u00e4hlen wir das Verhalten und ber\u00fccksichtigen dabei, dass on<\/code> \u2013 dies synchrone Aufzeichnungen sind, w\u00e4hlen wir local<\/code> f\u00fcr asynchrone Commits \u00fcber das Netzwerk, w\u00e4hrend die lokalen Commits synchron bleiben.<\/p>\n

<\/p>\n

Nun werden wir Ihnen zeigen, wie Sie dies im Handumdrehen einrichten k\u00f6nnen, aber stellen Sie sich vor, dass wir synchronous_commit<\/code> in local<\/code> f\u00fcr den Server installiert haben. Wir fragten uns, ob wir den Parameter synchronous_commit<\/code> dynamisch \u00e4ndern k\u00f6nnen, und es stellte sich heraus, dass dies nicht nur m\u00f6glich ist, sondern daf\u00fcr gibt es sogar zwei verschiedene M\u00f6glichkeiten. Die erste M\u00f6glichkeit besteht darin, Ihre Verbindungssitzung wie folgt einzustellen:<\/p>\n

<\/p>\n

SET SESSION synchronous_commit TO ON;  \n\/\/ Hier kommen Ihre Schreibvorg\u00e4nge<\/code><\/pre>\n
<\/p>\n
Alle nachfolgenden Aufzeichnungen in der Sitzung best\u00e4tigen die Schreiboperationen f\u00fcr die Replikate, bevor sie ein positives Ergebnis an den verbundenen Client zur\u00fcckgeben. Es sei denn, Sie \u00e4ndern die Einstellung synchronous_commit<\/code> wieder. Sie k\u00f6nnen den Teil SESSION weglassen.<\/code> im Team, da es die Standardbedeutung haben wird.<\/p>\n
<\/p>\n
\u0412\u0442\u043e\u0440\u043e\u0439 \u0441\u043f\u043e\u0441\u043e\u0431 \u0445\u043e\u0440\u043e\u0448, \u043a\u043e\u0433\u0434\u0430 \u0432\u044b \u043f\u0440\u043e\u0441\u0442\u043e \u0445\u043e\u0442\u0438\u0442\u0435 \u0443\u0431\u0435\u0434\u0438\u0442\u044c\u0441\u044f, \u0447\u0442\u043e \u043f\u043e\u043b\u0443\u0447\u0430\u0435\u0442\u0435 \u0441\u0438\u043d\u0445\u0440\u043e\u043d\u043d\u0443\u044e \u0440\u0435\u043f\u043b\u0438\u043a\u0430\u0446\u0438\u044e \u0434\u043b\u044f \u043e\u0434\u043d\u043e\u0439 \u0442\u0440\u0430\u043d\u0437\u0430\u043a\u0446\u0438\u0438. \u0412\u043e \u043c\u043d\u043e\u0433\u0438\u0445 \u0431\u0430\u0437\u0430\u0445 \u0434\u0430\u043d\u043d\u044b\u0445 \u043f\u043e\u043a\u043e\u043b\u0435\u043d\u0438\u044f «NoSQL» \u043f\u043e\u043d\u044f\u0442\u0438\u044f \u0442\u0440\u0430\u043d\u0437\u0430\u043a\u0446\u0438\u0439 \u043d\u0435 \u0441\u0443\u0449\u0435\u0441\u0442\u0432\u0443\u0435\u0442, \u043d\u043e \u043e\u043d\u043e \u0441\u0443\u0449\u0435\u0441\u0442\u0432\u0443\u0435\u0442 \u0432 PostgreSQL. \u0412 \u044d\u0442\u043e\u043c \u0441\u043b\u0443\u0447\u0430\u0435 \u0432\u044b \u0437\u0430\u043f\u0443\u0441\u043a\u0430\u0435\u0442\u0435 \u0442\u0440\u0430\u043d\u0437\u0430\u043a\u0446\u0438\u044e, \u0430 \u0437\u0430\u0442\u0435\u043c \u0443\u0441\u0442\u0430\u043d\u0430\u0432\u043b\u0438\u0432\u0430\u0435\u0442\u0435 synchronous_commit<\/code> in on<\/code> vor der Durchf\u00fchrung des Schreibens f\u00fcr die Transaktion. BEST\u00c4TIGEN<\/code> die Transaktion mit einem beliebigen Wert des Parameters synchronous_commit<\/code>, der zu diesem Zeitpunkt gesetzt wurde, obwohl es am besten ist, die Variable im Voraus zu definieren, um sicherzustellen, dass andere Entwickler verstehen, dass die Aufzeichnungen nicht asynchron sind.<\/p>\n
<\/p>\n
BEGIN;  \nSET LOCAL synchronous_commit TO ON;  \n\/\/ Ihre Schreibvorg\u00e4nge kommen hierhin\nCOMMIT;  <\/code><\/pre>\n
<\/p>\n
Alle Transaktionscommits werden jetzt so best\u00e4tigt, als w\u00e4ren sie in Repliken geschrieben, noch bevor die Datenbank eine positive Antwort an den verbundenen Client zur\u00fcckgibt.<\/p>\n
<\/p>\n
PostgreSQL-Konfiguration<\/h2>\n
<\/p>\n
Vorher haben wir uns ein PostgreSQL-System mit synchronous_commit<\/code>, eingestellt auf local<\/code>. Damit dies auf der Serverseite wirksam wird, m\u00fcssen Sie zwei Serverkonfigurationsparameter setzen. Ein weiterer Parameter synchronous_standby_names<\/code> wird in Kraft treten, wenn synchronous_commit<\/code> in on<\/code>. Es bestimmt, welche Replikate f\u00fcr synchronisierte Commits berechtigt sind, und wir werden es auf *<\/code>, was bedeutet, dass alle Replikate in Betrieb genommen 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
Durch das Setzen der Option synchronous_commit<\/code> auf local<\/code>, schaffen wir ein System, bei dem lokale Festplatten synchron bleiben, w\u00e4hrend 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 Entwicklungen des Governor-Projekts<\/a><\/noindex>verfolgt haben, k\u00f6nnten Ihnen einige k\u00fcrzliche \u00c4nderungen aufgefallen sein (1<\/a><\/noindex>, 2<\/a><\/noindex>), die es den Benutzern von Governor erlauben, diese Optionen zu testen und ihre Konsistenz zu steuern.<\/p>\n
<\/p>\n
Ein paar Worte mehr\u2026<\/h2>\n
<\/p>\n
Vor einer Woche h\u00e4tte ich Ihnen gesagt, dass es unm\u00f6glich sei, PostgreSQL so fein abzustimmen. Damals insistierte Kurt, ein Mitglied des Compose-Plattformenteams, dass diese M\u00f6glichkeit besteht. Er beruhigte meine Bedenken und fand in der PostgreSQL-Dokumentation 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 bestimmt, die zum Zeitpunkt des Commits aktiv ist. Daher kann es sinnvoll und n\u00fctzlich sein, f\u00fcr einige Transaktionen die Commits synchron und f\u00fcr andere asynchron durchzuf\u00fchren. Um beispielsweise eine Multistatement<\/code> Transaktion asynchron zu committen, wenn der Standardwert das Gegenteil ist, geben Sie <\/em>SET LOCAL synchronous_commit TO OFF<\/code> in der Transaktion an.<\/em><\/p>\n
<\/p>\n
Mit dieser kleinen Modifikation in der Konfigurationsdatei haben wir den Nutzern die Kontrolle \u00fcber ihre Konsistenz und Leistung gegeben.<\/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 Aufzeichnungen f\u00fcr die Konsistenzanpassung jeder spezifischen Verbindung | ProHoster","description":"Die \u00dcbersetzung des Artikels wurde speziell f\u00fcr die Studenten des Kurses 'Datenbanken' erstellt. Interessiert an einer Entwicklung in diesem Bereich? Wir laden Sie zu unserem Tag der offenen T\u00fcr ein, an dem wir ausf\u00fchrlich \u00fcber das Programm, die Besonderheiten des Online-Formats, die Kompetenzen und die Karriereperspektiven sprechen, die Absolventen nach dem Studium erwarten. PostgreSQL und die Einstellungen zur Konsistenz der Aufzeichnung f\u00fcr jede spezifische Verbindung. In Compose haben wir es mit vielen Datenbanken zu tun.","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? \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","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"},"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}]}}