{"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\/it\/blog\/administrirovanie\/postgresql-i-nastrojki-soglasovannosti-zapisi-dlya-kazhdogo-konkretnogo-soedineniya","title":{"rendered":"PostgreSQL e impostazioni di coerenza della scrittura per ogni connessione specifica","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

La traduzione dell'articolo \u00e8 stata preparata appositamente per gli studenti del corso \u00abDatabase\u00bb<\/a><\/noindex>. Sei interessato a svilupparti in questo campo? Ti invitiamo a Giornata Port Open<\/a><\/noindex>, dove parleremo in dettaglio del programma, delle caratteristiche del formato online, delle competenze e delle prospettive di carriera che attendono i laureati dopo il corso.<\/em><\/p>\n

<\/p>\n

\"PostgreSQL<\/p>\n

<\/p>\n

PostgreSQL e impostazioni di coerenza della scrittura per ogni connessione specifica
\nNoi di Compose gestiamo molti database, e questo ci permette di scoprire meglio le loro funzionalit\u00e0 e i loro limiti. Mentre impariamo ad apprezzare le caratteristiche funzionali dei nuovi database, a volte ci scappa di pensare a quanto sarebbe bello se tali funzionalit\u00e0 fossero presenti anche in strumenti pi\u00f9 maturi con cui lavoriamo da tempo. Una delle nuove caratteristiche che avremmo voluto vedere in PostgreSQL era la coerenza scritta personalizzabile per connessione all'interno dell'intero cluster. E, come si \u00e8 scoperto, ce l'abbiamo gi\u00e0, e oggi vogliamo condividere con voi informazioni su come potete utilizzarla.<\/a><\/noindex><\/p>\n

<\/p>\n

Perch\u00e9 dovrei interessarmene?<\/h1>\n

<\/p>\n

Il modo in cui deve comportarsi un cluster dipende dalla tua applicazione. Prendiamo, ad esempio, un'app per il pagamento delle bollette. Avrai bisogno di una coerenza al 100% nel cluster, quindi dovrai attivare i commit sincroni affinch\u00e9 il tuo database attenda l'applicazione di tutte le modifiche. Tuttavia, se la tua applicazione \u00e8 un social network in rapida evoluzione, probabilmente preferirai una risposta rapida alla coerenza al 100%. Per raggiungere questo obiettivo, puoi utilizzare nel tuo cluster commit asincroni.<\/p>\n

<\/p>\n

Incontriamo il compromesso<\/h2>\n

<\/p>\n

Dovrai scendere a compromessi tra la coerenza dei dati e le prestazioni. PostgreSQL si allontana dalla coerenza, poich\u00e9 la configurazione predefinita in questo caso risulta prevedibile e priva di sorprese inaspettate. E ora cominciamo a esaminare i compromessi.<\/p>\n

<\/p>\n

Compromesso 1: Prestazioni<\/h3>\n

<\/p>\n

Se un cluster PostgreSQL non richiede coerenza, pu\u00f2 funzionare in modo asincrono. Le scritture vengono effettuate sul leader del cluster, e le sue repliche riceveranno gli aggiornamenti dopo alcuni millisecondi. Quando il cluster PostgreSQL richiede coerenza, deve funzionare in modo sincrono. La scrittura sar\u00e0 effettuata sul leader del cluster, che invier\u00e0 aggiornamenti alle repliche e attender\u00e0 conferma che ciascuna di esse abbia eseguito la scrittura, prima di inviare una conferma al cliente che ha iniziato la scrittura, informandolo che \u00e8 stata completata con successo. La differenza pratica tra questi approcci \u00e8 che il metodo asincrono richiede due salti di rete, mentre quello sincrono ne richiede quattro. <\/p>\n

<\/p>\n

Compromesso 2: Coerenza<\/h3>\n

<\/p>\n

Il risultato in caso di guasto del leader in questi due approcci sar\u00e0 diverso. Se il lavoro viene eseguito in modo asincrono, quando si verifica un errore del genere, non tutte le registrazioni saranno registrate dalle repliche. Quanto andr\u00e0 perso? Dipende dall'applicazione stessa e dall'efficacia della replica. La replica di Compose impedir\u00e0 a una replica di diventare leader se la quantit\u00e0 di informazioni in essa \u00e8 inferiore di 1 MB rispetto al leader, il che significa che potrebbero potenzialmente andare perse fino a 1 MB di registrazioni durante il funzionamento asincrono. <\/p>\n

<\/p>\n

In modalit\u00e0 sincrona questo non accade. Se il leader fallisce, tutte le repliche vengono aggiornate, poich\u00e9 ogni registrazione confermata sul leader deve essere confermata nelle repliche. Ecco la coerenza. <\/p>\n

<\/p>\n

Il comportamento sincrono \u00e8 utile in un'applicazione per il pagamento delle fatture, dove la coerenza \u00e8 decisamente vantaggiosa per trovare un compromesso tra coerenza e prestazioni. Il dato pi\u00f9 importante per tale applicazione \u00e8 la validit\u00e0 dei dati. Ora pensate ai social network, dove l'obiettivo principale \u00e8 mantenere l'attenzione degli utenti rispondendo alle loro richieste nel modo pi\u00f9 rapido possibile. In questo caso, le prestazioni con un numero ridotto di salti nella rete e tempi di attesa minori per i commit hanno la priorit\u00e0. Tuttavia, il compromesso tra prestazioni e coerenza non \u00e8 l'unico a cui prestare attenzione.<\/p>\n

<\/p>\n

Compromesso 3: Guasti<\/h3>\n

<\/p>\n

\u00c8 molto importante comprendere come si comporta un cluster durante un guasto. Consideriamo la situazione in cui una o pi\u00f9 repliche falliscono. Quando i commit vengono elaborati in modo asincrono, il leader continuer\u00e0 a funzionare, ovvero accetter\u00e0 e elaborer\u00e0 le registrazioni senza attendere le repliche mancanti. Quando le repliche tornano nel cluster, raggiungono il leader. Con la replica sincrona, se le repliche non rispondono, il leader non avr\u00e0 scelta e continuer\u00e0 ad attendere la conferma del commit finch\u00e9 la replica non ritorna nel cluster e non pu\u00f2 accettare e confermare la registrazione.<\/p>\n

<\/p>\n

Una connessione per transazione?<\/h2>\n

<\/p>\n

Ogni applicazione necessita di un particolare tipo di combinazione tra coerenza e prestazioni. A meno che non si tratti dell'applicazione per il pagamento delle fatture, che immaginiamo essere completamente coerente, o della nostra quasi eterea applicazione per i social network. In tutti gli altri casi, ci saranno momenti in cui alcune operazioni devono essere sincrone e altre asincrone. Potresti non voler che il sistema attenda il completamento del messaggio inviato in chat, ma se in quella stessa applicazione avviene un pagamento, dovr\u00e0 attendere.<\/p>\n

<\/p>\n

Tutte queste decisioni, naturalmente, spettano allo sviluppatore dell'applicazione. Le scelte corrette su quando applicare un approccio piuttosto che un altro possono aiutare a massimizzare il cluster. \u00c8 fondamentale che lo sviluppatore possa passare tra di essi a livello di SQL per le connessioni e per le transazioni. <\/p>\n

<\/p>\n

Assicurare il controllo nella pratica<\/h2>\n

<\/p>\n

Per impostazione predefinita, PostgreSQL garantisce coerenza. Questo \u00e8 controllato dal parametro del server synchronous_commit<\/code>. Di default, \u00e8 impostato su on<\/code>, ma ha altre tre opzioni: local<\/code>, remote_write<\/code> o off<\/code>.<\/p>\n

<\/p>\n

Impostando il parametro su off<\/code> si fermano tutti gli impegni sincronizzati, anche nel sistema locale. Il parametro in local definisce la modalit\u00e0 sincronizzata per il sistema locale, ma le scritture nelle repliche avvengono in modo asincrono. Remote_write<\/code> va ancora oltre: le scritture nelle repliche vengono eseguite in modo asincrono, ma vengono restituite quando la replica ha accettato la scrittura, ma non l'ha registrata su disco.<\/p>\n

<\/p>\n

Considerando l'ampia gamma di opzioni disponibili, scegliamo il comportamento e, ricordando che on<\/code> \u2013 si tratta di scritture sincronizzate, scegliamo local<\/code> per gli impegni asincroni sulla rete, mantenendo le scritture locali sincronizzate.<\/p>\n

<\/p>\n

Ora, vi racconteremo come configurarlo in un attimo, ma immaginate di aver impostato synchronous_commit<\/code> in local<\/code> per il server. Ci siamo chiesti se fosse possibile modificare il parametro synchronous_commit<\/code> al volo, ed \u00e8 emerso che non solo \u00e8 possibile, ma ci sono ben due modi per farlo. Il primo \u00e8 impostare la sessione della vostra connessione nel modo seguente:<\/p>\n

<\/p>\n

SET SESSION synchronous_commit TO ON;  \n\/\/ I vostri scritti vanno qui<\/code><\/pre>\n
<\/p>\n
Tutte le scritture successive nella sessione confermeranno le operazioni di scrittura per le repliche, prima di restituire un risultato positivo al client connesso. A meno che, ovviamente, non si modifichi nuovamente l'impostazione synchronous_commit<\/code> di nuovo. Si pu\u00f2 omettere la parte SESSION<\/code> nel team, poich\u00e9 sar\u00e0 nel valore predefinito.<\/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> prima di eseguire la scrittura per la transazione. COMMIT<\/code> registrer\u00e0 la transazione utilizzando qualunque valore del parametro synchronous_commit<\/code>, che \u00e8 stato impostato in quel momento, anche se \u00e8 meglio impostare la variabile in anticipo per garantire che altri sviluppatori comprendano che le scritture non sono asincrone.<\/p>\n
<\/p>\n
BEGIN;  \nSET LOCAL synchronous_commit TO ON;  \n\/\/ Le tue scritture qui\nCOMMIT;  <\/code><\/pre>\n
<\/p>\n
Tutti i commit delle transazioni ora saranno confermati, come scritti nelle repliche prima che il database restituisca una risposta positiva al client connesso.<\/p>\n
<\/p>\n
Configurazione di PostgreSQL<\/h2>\n
<\/p>\n
Prima di questo, immaginavamo un sistema PostgreSQL con synchronous_commit<\/code>, impostato su local<\/code>. Per rendere ci\u00f2 reale dal lato del server, sar\u00e0 necessario impostare due parametri di configurazione del server. Un altro parametro synchronous_standby_names<\/code> entrer\u00e0 in gioco quando synchronous_commit<\/code> sar\u00e0 in on<\/code>. Definisce quali repliche hanno il diritto di eseguire commit sincroni, e lo imposteremo a *<\/code>, che significa attivare tutte le repliche. Questi valori vengono generalmente configurati nel file di configurazione<\/a><\/noindex> aggiungendo: <\/p>\n
<\/p>\n
synchronous_commit = local  \nsynchronous_standby_names='*'<\/code><\/pre>\n
<\/p>\n
Impostando il parametro synchronous_commit<\/code> su local<\/code>, creiamo un sistema in cui i dischi locali rimangono sincronici, ma i commit delle repliche di rete sono di default asincroni, a meno che non decidiamo di rendere questi commit sincroni, come mostrato sopra.<\/p>\n
<\/p>\n
Se hai seguito lo sviluppo del progetto Governor<\/a><\/noindex>, avrai notato alcuni cambiamenti recenti (1<\/a><\/noindex>, 2<\/a><\/noindex>) che hanno permesso agli utenti di Governor di testare queste impostazioni e monitorare la loro coerenza.<\/p>\n
<\/p>\n
Un paio di parole\u2026<\/h2>\n
<\/p>\n
Letteralmente una settimana fa, ti avrei detto che non era possibile ottimizzare PostgreSQL in modo cos\u00ec dettagliato. Proprio allora Kurt, un membro del team della piattaforma Compose, ha insistito sul fatto che esisteva tale possibilit\u00e0. Ha messo a tacere le mie obiezioni e ha trovato nella documentazione di PostgreSQL quanto segue<\/a><\/noindex>:<\/p>\n
<\/p>\n
\"PostgreSQL<\/p>\n
<\/p>\n
Questa impostazione pu\u00f2 essere modificata in qualsiasi momento. Il comportamento di una transazione \u00e8 determinato dalla configurazione attiva al momento del commit. Pertanto, \u00e8 possibile e utile che per alcune transazioni i commit avvengano in modo sincrono, mentre per altre in modo asincrono. Ad esempio, per consentire a una multistatement<\/code> transazione di effettuare commit in modo asincrono, quando il valore predefinito \u00e8 opposto, impostare <\/em>SET LOCAL synchronous_commit TO OFF<\/code> nella transazione.<\/em><\/p>\n
<\/p>\n
Con questa piccola modifica nel file di configurazione, abbiamo dato agli utenti la possibilit\u00e0 di controllare la loro coerenza e prestazioni.<\/p>\n
Fonte: 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 e configurazioni di coerenza della scrittura per ogni singola connessione | ProHoster","description":"La traduzione dell'articolo \u00e8 stata preparata appositamente per gli studenti del corso \"Basi di Dati\". Sei interessato a svilupparti in questo ambito? Ti invitiamo alla Giornata Porte Aperte, in cui presentiamo dettagliatamente il programma, le caratteristiche del formato online, le competenze e le prospettive di carriera che attendono i laureati dopo la formazione. PostgreSQL e configurazioni di coerenza della scrittura per ogni singola connessione Ci troviamo a dover gestire molte basi in Compose.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/postgresql-i-nastrojki-soglasovannosti-zapisi-dlya-kazhdogo-konkretnogo-soedineniya","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","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\/it\/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\/it\/wp-json\/wp\/v2\/posts\/39169","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=39169"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/39169\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/29395"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=39169"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=39169"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=39169"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}