Преводот на статијата е подготвен специјално за студентите на курсот "База на податоци". Дали сте заинтересирани да се развивате во оваа насока? Ве покануваме да Отворен ден, каде што детално зборуваме за програмата, карактеристиките на онлајн форматот, компетенциите и изгледите за кариера што ги чекаат дипломираните студенти по обуката.

PostgreSQL и поставки за конзистентност на пишување специфични за конекцијата
Во Compose се занимаваме со многу бази на податоци, што ни дава можност повеќе да се запознаеме со нивната функционалност и недостатоци. Како што учиме да ги сакаме карактеристиките на новите бази на податоци, понекогаш почнуваме да размислуваме колку би било убаво доколку слични карактеристики беа присутни во позрелите алатки со кои работиме долго време. Една од новите функции што сакав да ја видам во PostgreSQL беше конфигурабилна конзистентност на пишување по врска низ целиот кластер. И како што се испостави, ние веќе го имаме, а денес сакаме да споделиме со вас информации за тоа како можете да го користите.

Зошто ми треба?

Како треба да се однесува кластерот зависи од вашата апликација. Земете, на пример, апликација за плаќање сметки. Ќе ви треба XNUMX% конзистентност низ кластерот, така што ќе треба да овозможите синхрони обврзувања така што вашата база на податоци чека да се направат сите промени. Меѓутоа, ако вашата апликација е брзорастечка социјална мрежа, тогаш веројатно ќе претпочитате брз одговор над XNUMX% конзистентност. За да го постигнете ова, можете да користите асинхрони обврзници во вашиот кластер.

Запознајте компромис

Мора да направите компромиси помеѓу конзистентноста на податоците и перформансите. PostgreSQL се оддалечува од конзистентноста бидејќи стандардната конфигурација тогаш е предвидлива и без неочекувани изненадувања. Сега да ги погледнеме компромисите.

Tradeoff 1: Performance

Ако кластерот PostgreSQL не бара конзистентност, може да работи асинхроно. Пишувањето е направено до лидерот на кластерот, а ажурирањата ќе бидат испратени до неговите реплики неколку милисекунди подоцна. Кога кластерот PostgreSQL бара конзистентност, тој мора да работи синхроно. Пишувањето ќе биде направено до водачот на кластерот, кој ќе испрати ажурирање до репликите и ќе чека потврда дека секој напишал пред да испрати потврда до клиентот што го иницирал пишувањето дека е успешно. Практичната разлика помеѓу овие пристапи е во тоа што за асинхрониот метод се потребни два мрежни скокови, додека за синхрониот метод се потребни четири.

Замена 2: Конзистентност

Резултатот во случај на неуспех на лидерот во овие два пристапа исто така ќе биде различен. Ако работата се изведува асинхроно, тогаш ако се појави таква грешка, нема да бидат извршени сите записи од репликите. Колку ќе се изгуби? Зависи од самата апликација и ефикасноста на репликацијата. Составете репликација ќе спречи репликата да стане лидер ако количината на информации во неа е за 1 MB помала отколку во лидерот, односно, до 1 MB записи потенцијално може да се изгубат при асинхрона операција.

Ова не се случува во синхрониот режим. Ако лидерот не успее, сите реплики се ажурираат, бидејќи секое пишување потврдено на лидерот мора да биде потврдено на репликите. Ова е конзистентност.

Синхроното однесување има смисла во апликација за наплата каде што конзистентноста има јасна предност во компромисот помеѓу конзистентноста и перформансите. Најважно за ваква апликација се валидни податоци. Сега размислете за социјална мрежа во која главната задача е да го задржите вниманието на корисникот со тоа што ќе одговорите на барањата што е можно побрзо. Во овој случај, приоритет ќе биде изведбата со помалку мрежни скокови и помалку чекање за обврски. Сепак, компромисот помеѓу перформансите и конзистентноста не е единствениот за кој треба да размислите.

Размена 3: Несреќи

Многу е важно да се разбере како кластерот се однесува за време на неуспех. Размислете за ситуација кога една или повеќе реплики не успеваат. Кога заложбите се обработуваат асинхроно, лидерот ќе продолжи да функционира, односно да прифаќа и обработува записи, без да чека реплики што недостасуваат. Кога репликите се враќаат во кластерот, тие се стигнуваат со лидерот. Со синхрона репликација, ако репликите не реагираат, тогаш лидерот нема да има избор и ќе продолжи да чека за потврда за извршување додека репликата не се врати во кластерот и не може да го прифати и изврши запишувањето.

Една врска по трансакција?

Секоја апликација има потреба од различен тип на комбинација на конзистентност и перформанси. Освен, се разбира, ако не е нашата апликација за плаќање сметки, за која замислуваме дека е целосно конзистентна, или нашата речиси ефемерна апликација за социјално вмрежување. Во сите други случаи, ќе има моменти кога некои операции мора да бидат синхрони, а некои мора да бидат асинхрони. Можеби не сакате системот да чека додека не се изврши пораката испратена до разговорот, но ако плаќањето се обработи во истата апликација, тогаш ќе мора да почекате.

Сите овие одлуки, се разбира, ги донесува развивачот на апликацијата. Донесувањето правилни одлуки за тоа кога да го користите секој пристап ќе ви помогне да го извлечете максимумот од вашиот кластер. Важно е развивачот да може да се префрла меѓу нив на ниво на SQL за врски и за трансакции.

Обезбедување контрола во пракса

Стандардно, PostgreSQL обезбедува конзистентност. Ова е контролирано од параметарот на серверот synchronous_commit. Стандардно е во позиција on, но има три други опции: local, remote_write или off.

При поставување на параметарот на off сите синхрони обврзувања се стопирани, дури и на локалниот систем. Локалниот параметар го одредува синхрониот режим за локалниот систем, но запишувањето во репликите се врши асинхроно. Remote_write оди уште подалеку: запишувањата во репликите се прават асинхроно, но се враќаат кога репликата го прифатила запишувањето, но не ја напишала на дискот.

Со оглед на расположливиот опсег на опции, избираме однесување и, имајќи го предвид тоа on – тоа се синхрони снимки, ние ќе избереме local за асинхрони обврзувања преку мрежата, додека локалните обврзувања оставаат синхрони.

Сега, ќе ви кажеме како да го поставите ова за момент, но замислете дека го поставивме synchronous_commit в local за серверот. Се прашувавме дали е можно да се смени параметарот synchronous_commit во лет, и се покажа дека не само што е можно, има дури два начини да го направите ова. Првиот е да ја поставите сесијата на вашата врска на следниов начин:

SET SESSION synchronous_commit TO ON;  
// Your writes go here

Сите последователни запишувања во сесијата ќе ги потврдат пишувањата на репликите пред да се вратат позитивен резултат на поврзаниот клиент. Освен, се разбира, ако не ја смените поставката synchronous_commit повторно. Можете да испуштите дел SESSION во командата бидејќи ќе биде во стандардната вредност.

Вториот метод е добар кога само сакате да бидете сигурни дека добивате синхрона репликација за една трансакција. Во многу бази на податоци за генерирање NoSQL концептот на трансакции не постои, но постои во PostgreSQL. Во овој случај започнувате трансакција и потоа поставувате synchronous_commit в on пред да се изврши уписот за трансакцијата. COMMIT ќе ја изврши трансакцијата користејќи која било вредност на параметарот synchronous_commit, што беше поставено во тоа време, иако најдобро е да ја поставите променливата однапред за да бидете сигурни дека другите програмери разбираат дека пишувањата не се асинхрони.

BEGIN;  
SET LOCAL synchronous_commit TO ON;  
// Your writes go here
COMMIT;  

Сите обврзувања на трансакции сега ќе бидат потврдени како напишани на репликите пред базата на податоци да врати позитивен одговор на поврзаниот клиент.

Поставување PostgreSQL

Пред ова, замисливме систем PostgreSQL со synchronous_commit, инсталиран во local. За да го направите ова реално на страната на серверот, ќе треба да поставите две опции за конфигурација на серверот. Уште еден параметар synchronous_standby_names ќе си дојде на свое кога synchronous_commit ќе биде во on. Тој одредува кои реплики се подобни за синхрони обврски, и ние ќе го поставиме на *, што ќе значи дека се вклучени сите реплики. Овие вредности обично се конфигурираат во конфигурациска датотека со додавање:

synchronous_commit = local  
synchronous_standby_names='*'

Со поставување на параметарот synchronous_commit во значење local, создаваме систем каде локалните дискови остануваат синхрони, но мрежните реплики се стандардно асинхрони. Освен, се разбира, ако не одлучиме да ги направиме овие обврски синхрони, како што е прикажано погоре.

Ако сте го следеле развојот Проект за гувернер, можеби сте забележале некои неодамнешни промени (1, 2), што им овозможи на корисниците на Гувернер да ги тестираат овие параметри и да ја следат нивната конзистентност.

Уште неколку зборови...

Пред само една недела, би ви кажал дека е невозможно толку фино да се прилагоди PostgreSQL. Тогаш Курт, член на тимот на платформата Compose, инсистираше на тоа дека постои таква можност. Тој ги смири моите приговори и најде во документацијата PostgreSQL следното:

Оваа поставка може да се смени во секое време. Однесувањето за која било трансакција се определува со поставката важечка во моментот на извршување. Затоа, можно е и корисно за некои трансакции да се извршуваат синхроно, а за други асинхроно. На пример, да се присили еден multistatement трансакцијата за правење обврзува асинхроно кога стандардната вредност на параметарот е спротивна, се поставува SET LOCAL synchronous_commit TO OFF во трансакција.

Со оваа мала модификација на конфигурациската датотека, на корисниците им дадовме контрола врз нивната конзистентност и перформанси.

Извор: www.habr.com