Сага про кластері. Все, що ви хотіли знати про горизонтальне масштабування в Postgres'е



Олег Бартунов (@zen), Олександр Коротков(@smagen), Федір Сігаєв
Ілля Космодемьянский: Зараз буде найбільш животрепетна тема PostgreSQL. Всі роки, що ми займаємося консалтингом, перше, що запитують люди: «Як зробити мультимастер-реплікацію, як домогтися чарівництва?». Багато професійних чарівників будуть розповідати про те, як це зараз добре і здорово реалізовано в PostgreSQL — хлопці з Postgres Professional в рамках цієї доповіді розкажуть про кластер все. Назва відповідна — «Сага» — щось епічне і монументальна. Зараз хлопці з Postgres Professional почнуть свою сагу, і це буде цікаво і добре.

Отже, Олег Бартунов, Олександр Коротков і Федір Сігаєв.

Олег Бартунов: Ілля сказав, що ми будемо розповідати про те, як у нас Postgres'e все добре з кластером, але насправді ми розповімо про те, що зараз відбувається в Postgres-співтоваристві з цією темою. Насправді тема неоднозначна, і ми постараємося показати, чому це все не так важко, і які перспективи нас чекають.

Спочатку хочу представитися — ми троє є провідними розробниками від Росії в Postgres ком'юніті.



Все, що ми зробили в Postgres, ми постаралися перерахувати в цій маленькій табличці (на слайді), напевно, ви знаєте ці наші роботи.

Ми вирішили спочатку зробити деяку сценку і показати, наскільки це важко і яка це біль — працювати з розподіленими речами. Перший слайд у нас називається «Розподілені нещастя».




Федір Сігаєв: Продовжу я.

Коли говорять про кластері, як правило, або це люди, які добре розуміють, про що це, і тоді відразу заглиблюємося в деталі: «як у вас те і се реалізовано, а як єдиний комміт, а як у вас між нодами взаємодія, а як відновлення?», або це люди, які приходять і кажуть, що кластер — це «ми поставимо кілька тачок одна під інший, всі вони будуть працювати і нам буде щастя».

Я хотів показати в сценці, що це не так просто, і будь-кластер вимагає деяких рішень. Спочатку я попрошу вийти Івана Панченка і Колю Шаплова — ми їх призначимо серверами. Сервер А і сервер Б. Ми будемо діяти в надії, що вони чесні сервера, тобто чесні бази даних. Сашу я попрошу бути клієнтом. Клієнтом не в сенсі того, хто прийшов у банк і розлучився з грошима, а в тому сенсі, що це якийсь додаток, що обслуговує зовнішніх клієнтів нашого банку. Безпосередньо тих клієнтів ми мати на увазі не будемо. Власне, клієнт — це наш додаток.

Ось наше додаток починає транзакцію і роздає по команді begin. Після цього товариш клієнт відходить від баз даних, тисне їм руки і каже, що їм потрібно робити в якійсь абстрактній манері: «тут що-то поміняй, тут встав, тут видали, абсолютно не принципово».

Тепер, як всі люблять говорити, двофазний комміт вирішує наші проблеми. Клієнт роздає їм по команді prepare (підготуватися). Що насправді робить база даних? Вона виконує всі тригера, вона перевіряє constraint і т. д. Після цього, якщо ці команди пройшли, то база даних обіцяє, що отримати пройде завжди, тобто що б не трапилося, навіть при втраті живлення.

Ось, у нас клієнт видає один комміт, йде до однієї бази даних. Ваня у нас закоммитил. А ось під час другої Саша йде-йде, і тут вимикається світло — всі падають втрьох. Впали. Світло включили. Вони піднімаються, а комміт не прийшов. Клієнт взагалі ні сном ні духом, тому що у нього все пройшло. База даних імені Вані Панченко прочитала свої WAL-логи, прочитала про те, що закоммитила, вона знаходиться у щасливому стані — я все зробила. База даних, що подається Колій, сервер Б, читає свій WAL-лог, знаходить те, що там написано «prepared to commit», а після чого зависає з питанням — коміта-то не було. Що їй робити? А їй піти абсолютно нікуди. Клієнт про це нічого не знає, Ваня теж — у нього отримати свій є. Питання: що робити, як з такої ситуації виплутуватися?



Одна база даних успішно закоммитила, друга висить у питанні. Виходів не так багато. Викликаємо DBA або когось ще, наприклад, системного адміністратора. Той намагається зрозуміти по логам, що сталося, що в одній базі закоммичено, а в іншій — ні. В цей час, якщо ви не боїтеся втратити гроші, то ваш кластер працює з неконсистентными даними, або ви геть зупиняєте сервіс, говорите, що у нас йдуть технічні роботи, ми з'ясовуємо, хто кому скільки винен.

Або ж ви вводите в роботу арбітра. Клієнт буде ходити до арбітра, а не до наших баз даних, саме арбітр буде роздавати завдання, писати собі в лог те, що ми в стані «prepared to commit», або «ми виконали це». Після цього роздасть коміти і запише собі в лог те, що перша база комміт записала, а друга — ні. Далі ми прокинемося, прочитаємо логи і нещасному Колі скажімо: «коммить те, що у тебе знайшлося».

Біда тут така, що писати цей арбітр з нуля — теж дуже і дуже непросте завдання. І все одно у вас є момент, коли ви базі сказали комміт, а собі в лог записати не встигли. Так що, це одна з проблем. Одна з багатьох проблем, з якими стикається будь-кластерний рішення, яке хоче бути/здаватися надійним.

Для наступної сценки уявімо собі банк, у якого є 2 рахунки, на кожному рахунку у нас по 1000 кредиток. Один рахунок у нас у Вані, один — у Колі. Клієнт 1 (Саша) опитує суму рахунків. Що він бачить? Він бачить 1000 кредиток, 1000 кредиток, в сумі — 2000 кредиток. Далі Саша починає транзакцію — він одній базі віддає «-500 кредиток», другий «+500 кредиток». І після чого запитує: «а що у вас є у сумі?». В сумі є: у Вані він бачить результат 1500, а в Колі 500 кредиток відібрали у нього 500. Все добре. Клієнт 1 знову бачить 2000.

Далі Саша починає це справа коммитить. Коммитить він починає з Колі. У цей момент прокидається клієнт №2 (дівчина з залу) і йде з питанням: «а покажіть, скільки у вас грошей». Транзакція у Вані ще не закоммичена, і що бачить перший клієнт? Він бачить 1000. А у Колі вже комміт настав — у нього вже 500. Що в результаті бачить нещасний другий клієнт? Що гроші кудись поділися. Він бачить в сумі 1500!

Це і є проблеми неконсистентності — ви не можете одночасно закоммитить в дві різні бази даних. Тобто вам завжди треба з цим якось боротися. Локі виставляти, причому поза баз даних, або забороняти доступ до баз даних. Ось, інсценізований нещастя прямо в особах, з якими проблемами можна зіткнутися.

Олег Бартунов: Висновок з цього уявлення у тому, що ви не можете мати цілісний read з двофазним комітом, тобто навіть читання не може бути цілісним.

Федір Сігаєв: Тут ми навіть не дуже приваблювали двофазний комміт, тобто двофазний комміт ускладнює ситуацію з біганиною, але насправді ви все одно залишаєте «дірку», під час якої у вас одна база вже комміт прийняла, а друга — ні. Тому у вас завжди буде той момент, коли у вас стан двох баз неконсистентно.

Олег Бартунов: Після того, як ми показали вам, що не все так просто, ми перейдемо до деяких політичних ігор.

Чому політичні ігри? Це умовна назва. Postgres розробляється спільнотою, а в співтоваристві у нас як би демократія, і для того, щоб домогтися якогось одного рішення доводиться застосовувати дуже багато всяких рухів тіла, розмов і т. д. Все це я називаю політичними іграми.

До недавніх часів ми взагалі про це не думали. А буквально 2-3 роки тому виникла така ситуація в open source, т. к. open source стає домінуючою моделлю розробки програмного забезпечення. На цьому графіку можна побачити світові тенденції:



Ми бачимо, що open source'ві бази даних ростуть, а власні бази даних — падають.

Просто моделі рішення. Ось, gartner's Magic Quadrant показує: ліворуч — за минулий рік, а справа — це нинішній рік.



Ми бачимо, що Postgres в особі EnterpriseDB і Fujitsu вже вийшов в лідери баз даних. Це досить чудова подія, що вперше ще в 2014 році open source'ва база даних увійшла в список лідерів баз даних. Тобто ринок загострюється.



Видно, що 70% баз даних будуть вже з відкритим кодом в 2018 році. Це передбачення, в це можна вірити й не вірити, але існує тенденція, що зараз люди з більшою охотою починають використовувати бази даних. І лідером баз даних з відкритим кодом є Postgres. Є ще MySQL — це теж дуже хороша база даних, але Postgres є серйозною базою даних, яка знаходиться зараз на дуже хорошому зльоті. І це відчувається у нас в ком'юніті, тому що всі клієнти, до яких ми приходимо, починають задавати питання, починають вимагати якихось фіч від Postgres.



Цей слайд я стырил з презентації EnterpriseDB, на ньому видно етапи розвитку Postgres. Вони позначили: зараз йде етап Enterprise'а. Зверніть увагу на фічі, які там написано, що вони називають Enterprise'ом. Все б добре, але ми не бачимо там слово «кластер». Тобто це насправді, дійсно так. У нас до цих пір в ком'юніті не було думки, що потрібно кластерний рішення.



Якщо ви подивіться на наш Todo (я спеціально зробив скріншот) — у нас там є кластер, але це не той кластер. Це команда cluster. Тобто навіть в нашому Todo немає ні слова про те, що потрібно робити горизонтальний кластер і т. д.

Це все було зроблено не випадково. З одного боку співтовариство консервативно, з іншого боку — ринок нас ще не підпер.

Зараз вже, особливо в Росії, Postgres розглядається як кандидат на дуже великі проекти, і поняття кластер стало must have.



Подивіться на сторінку форков Postgres'а. Бачите, скільки форков. І це не все.

Красненькими кружечками я позначив ті форки, в яких кластер є фичей. Ми бачимо, що практично всі форки, які з'явилися від Postgres'а, з'явилися тільки тому, що не вистачало кластера. І, зрештою, спільнота почала думати про те, що дійсно кластер повинен бути в нашому Todo, що ми повинні щось робити.



Це вже не перший раз так відбувається. Старожили Postgres, старі користувачі, пам'ятають розмови про реплікації. Колись у Postgres не було реплікації, і говорилося про те, що реплікація і не потрібна в ядрі, реплікація повинна бути стороннім продуктом. І так було до тих пір, поки знову ж користувачі, співтовариство не збагнув раптом, що воно повинно бути в ядрі. І воно у нас з'явилося і тепер реплікація є хорошим, нормальним інструментом, якими всі користуються. Також була історія з портом на windows — скільки ми хотіли, скільки у нас було сил, ми отбрикивалісь від порту на windows, але врешті-решт його зробили.

Федір Сігаєв: Але ми отбрыкались, зробили не ми.

Олег Бартунов: В результаті зараз настала та сама революційна ситуація, коли низи хочуть, верхи не зважилися. Причому, цікава ситуація — ми організували компанію, ми розмовляємо з нашими кастомерами, і говоримо: «ми робимо кластер». The 2ndQuadrant говорить те ж: «ми робимо кластер». EnterpriseDB каже: «ми теж робимо кластер». Однак, все кастомеры, як один, кажуть: «нас не цікавить ваш roadmap, нас цікавить roadmap спільноти», тобто потрібно щоб в співтоваристві був цей кластер, і щоб спільнота працювало.

На слайді я коротко навів рішення, Сашко розповість.

Олександр Коротков:

  • Напевно, багато хто чули, є Postgres XL XC. XL — це був форк від Postgres XC. XC зараз перейшов в X2, це окремий форк, який реалізує шардінг і репліковані таблиці, він досягає глобальної консистанси допомогою окремого сервісу, який там називається GTM — Global Transaction Manager. Його зараз розвивають 2ndQuadrant, МТТ і Huawei. Huawei, крім цього, має ще й свій пропріетарний форк MPPDB, це форк від XC.
Олег Бартунов: Хочу сказати, що це бази даних, у яких вже є живі користувачі, тобто багато банків в Китаї використовують ці XC.

Олександр Коротков: Незважаючи на те, що там були баги з консистанси, Китай настільки сміливий, що готовий на цьому запускати банки.

  • Є pg_shard — це open source розширення до Postgres, яке надає базову функціональність шардингу. Знову ж таки, там немає ніякого менеджера транзакцій, немає розподіленої консистанси, але для якихось вебовских завдань його можна використовувати.
  • Є Citus DB — це поки проприетарная база, яка компанія Citus Data обіцяє ось-ось відкрити. Там є функції багатший, тобто більш складні запити. Там можна якийсь лаб організувати, але знову ж таки для OLTP розподілена консистанси ніяка не гарантується.
  • FDW — це поки що такий підхід, який EnterpriseDB намагається зробити для Postgres, тобто основну майстер-гілку його додати. Ідея в тому, щоб використовувати вже існуючий механізм Foreign data wrappers, тобто звернення до якогось зовнішнього джерела даних для того, щоб зробити шардінг. У 9.6. вже закоммитили патч, який дозволяє через існуюче у Postgres'e спадкування зробити партицирование. Точно так само, якщо робити спадкування foreign таблиць, зовнішніх таблиць, можна зробити якийсь досить простий шардінг. Але, знову ж таки, виникає багато питань до того, наскільки оптимізатор може оптимізувати такі розподілені запити.
Зараз EnterpriseDB працює над патчами, щоб можна було робити Aggregate Pushdown, тобто щоб не все витягати з шардов, а потім агрегати вважати, а щоб можна було агрегати порахувати на самих шардах. Точно так само Join pushdown… І такий досить довгий roadmap, який не до кінця, може бути, повний і не зрозуміло, коли ми отримаємо повноцінний розподілений оптимайзер. Тим не менш, плюс цього підходу в тому, що ми покращуємо FDW, і це само по собі добре.

  • Greenplum — це комерційний форк від компанії Pivotal, який зовсім недавно був зарелизен в open source, 3 дні тому.
Олег Бартунов: Ви можете на GitHub скачати Greenplum, скомпілювати, поставити, і вас вже буде та сама масивна паралельна база даних, на якій довгий час працював eBay, яка працює зараз в Тінькофф Банку і т. д. тобто модель open source розвитку тут відкрито ипоказывает свої переваги.

Федір Сігаєв: Тільки майте на увазі — це OLAP бази даних, а не OLTP, тобто якщо вам що-небудь масово проаналізувати в Postgres, то це можна помацати Greenplum або pg_shard, але заводити туди гроші в надії, що будуть надійно перераховуватися, краще не треба.

Олександр Коротков: І ось наш проект, який ми почали — це Distributed Transaction Manager для Postgres майстра. Про нього ми розповімо трохи докладніше окремо.

Олег Бартунов: Це такі живі активні проекти, які є, у яких є свої кастомеры, вони розвиваються. І ми бачимо, що є ресурси, а рішення ком'юніті немає.

На минулому PGCon'е ми підняли це питання і домовилися про те, що все-таки влаштуємо велику зустріч, так званий кластер саміт, де будемо вирішувати цю проблему, що будемо з цим робити, як жити?



2 дні тому ми прилетіли з цієї наради. Зустрілися ми у Відні і обговорили нагальні проблеми кластера, тобто підняли питання, чи буде у ком'юніті кластерний рішення в Todo або не буде.



Вирішили, що ситуація назріла настільки, що це треба позначити в нашому Todo. При цьому треба продовжувати розвивати кластерні рішення, тому що, як ми вже показували, кластерні рішення — це дуже складні речі, і ми не можемо заздалегідь сказати, що завтра або через 2 роки це рішення переможе, тому рішення повинні розвиватися. При цьому вони повинні розвиватися так, щоб, скажімо, отримати нашої компанії не заблокував дорогу іншим рішенням — це дуже важливо. Вирішили — peace and love.

З'явилася ідея зробити інфраструктуру Postgres так, щоб кластерні рішення могли розвиватися як розширення, що сильно полегшить розвиток. Ми розповіли про наш менеджер розподілених транзакцій, людям ця ідея здалася цікавою, і ми будемо протискати це справа 9.6, тобто 9.6 ми постараємося, щоб розподілені транзакції вже були в Postgres'e, і будь-який бажаючий міг робити кластер, принаймні? на рівні програми.



Я додав у слайд, який я взяв у EnterpriseDB, 31-е жовтня 2015 року. Я назвав цей період як горизонтальне масштабування (шардінг), і ми написали список завдань, які нам потрібно буде вирішувати. Тобто це те, що ми зараз просуваємо в ком'юніті, щоб ком'юніті перейматися цим.

Олександр Коротков: Цілі зрозумілі, і ми хочемо scalability як на читання, так і на запис, крім цього, щоб була high valability. Досягти цього можна, наприклад, за допомогою redundancy, тобто один і той же шард тримається не в одній копії, а у двох копіях.

І за завданнями тут розбили, тут найбільші. Зрозуміло, що насправді їх ще більше. Завдання, якою ми зайнялися — це управління розподіленими транзакціями. Той, де зараз перетинається багато різних інтересів — це планувальник і виконавець розподілених запитів, тобто FDW — це один підхід до розподілених запитів, pg_shard — інший підхід, Postgres XL XC — вже третій підхід. І може бути ще 4-ий, 5-ий і т. д. Але ми сподіваємося, що рано чи пізно в цьому напрямку ми теж до якогось єдиного знаменника прийдемо.

Олег Бартунов: Тут на конференції є Брюс Момжан, він є відповідальним людиною, який повинен Todo вписати пункт про кластерности, і тоді у нас все піде, тому що треба об'єднувати зусилля.



Це картинка означає, що багато інгредієнтів, з них можна багато чого приготувати, але не факт, що вийде.



Олександр Коротков: У таблиці ми спробували зробити таку матрицю, вписали сюди кластерні рішення, причому як ті, які зараз існують і розвиваються, так і ті, які коли-то в історії були і вже не підтримуються.

Федір Сігаєв: Ми взяли найбільш популярні. Олег спочатку показував, що ця матриця ще більше, ми могли б зробити попіксельне графіком, але з неї буде зовсім нічого не зрозуміло.

Олег Бартунов: Можна довго розглядати цю таблиця, з нею можна сперечатися, вона показує те, що ідеального рішення немає. Наприклад, XC/XL/X2 виглядає найбільш привабливо, у неї найбільше плюсиков. У FDW і pg_shard теж досить багато плюсиков, але чогось не вистачає, зокрема їм не вистачає цілісності даних.

Коли почалася вся ця бійка, кожна компанія заявила про те, що «ми робимо рішення, наші рішення хороші» і т. д. адже Ми теж взяли XL і почали з ним гратися, вирішили робити свій кластер, але потім ми зрозуміли, що XL не дуже готовий для того, щоб використовувати його в продакшені, і ми вирішили не вплутуватися в загальну бійку, а сконцентруватися на тому загальному технологічному елементі, який потрібний всім. Тобто всім кластерним рішень потрібен менеджер розподілених транзакцій.

Тому ми і вибрали цей напрямок і реалізували його. Зараз ми розповімо, що це таке і чому це важливо, і що воно дає кластерним рішень.



Олександр Коротков: Що ми, взагалі, хочемо від менеджера розподілених транзакцій? Зрозуміло, що ми хочемо, щоб отримати з нашої розподіленій системі був атомарним. Атомарний означає, що, по-перше, він або атомарно скрізь пройшов, або скрізь відкотився. По-друге, ми хочемо його атомарної видимості, тобто це означає, що якщо ви робите запит на читання до декількох баз (те, що ми в 2-ій сценці показували), то кожен окремий комміт ми повинні бачити скрізь, або скрізь не бачити. Не повинно бути такого, що ми на одному сервері побачили, що гроші вже перевелися, а на іншому сервері побачили, що вони не перевелися, і в результаті у нас сума не сходиться.

Для такої проблеми є різні рішення, по своїм властивостям жодне з них не є ідеальним. Детальніше про це розповім в наступних слайдах, але з'явилася ідея, що ми хочемо деякої pluggable API для менеджера транзакцій. Тобто у нас є в Postgres'е менеджер, який дозволяє виконувати локальні транзакції — це одна реалізація, потім до неї ще додамо декілька реалізацій менеджерів розподілених транзакцій. Поки що ми можемо виділити три штуки, можливо, потім, у нас з'являться ще якісь ідеї, може бути навіть краще, ніж ті, які ми зараз бачимо.



Ми взяли і виділили API, який потрібен, щоб реалізувати такий менеджер розподілених транзакцій. Це просто деякий набір функцій, які в Postgres до цього були зашиті, і ми виділяємо їх в окрему so'шку, в окрему бібліотеку, яку можна підмінити.

Олег Бартунов: В цілому, ми просто йдемо по шляху pluggable. У нас є планер pluggable, executer pluggable, ми можемо робити типи даних, індекси, а тепер зробили так, щоб Transaction Manager теж був pluggable.

Федір Сігаєв: Для тих, хто не знає, executer в Postgres цілком pluggable, тобто можна використовувати абсолютно свій executer, точно так само як планер.



У нас запитують: чому саме ці сім функцій, а не інші сім функцій на попередньому слайді? Відповідь така: тому що ми спробували три різних за природою менеджера і з'ясували, що цих семи функцій достатньо для того, щоб винести Transaction Manager з Postgres в окремий процес.

Олександр Коротков: Сім тому що ми хотіли б шість, але не вийшло шість, а вісім не потрібно.



Це було до патча, тобто якщо всі ці виклики йшли безпосередньо, були зашиті в сам Postgres.



А далі ми це виділили в окремий компонент, який називається Transaction Manager.



Далі.



Це про те, які в нас бувають різновиди способів управління розподіленими транзакціями, які у них є переваги і недоліки.

  • Перший підхід — Snapshot sharing — це підхід, який зараз використовується в Postgres XC, XL. Ідея в тому, що у нас є деякий центральний арбітр, через який проходять всі коміти, і він же роздає всім снепшоты. Завдяки цьому забезпечується те, що кожен снепшот отриманий від цього центрального арбітра, і означає, що якийсь комміт ми покажемо як видимий, тільки коли він пройде на всіх вузлах. Які у нього є переваги? Те, що для використання такого підходу нам не потрібно використовувати двох фазний комміт. Але мінусом є те, що ми не можемо використовувати при цьому локальні транзакції, відповідно, кожна транзакція повинна центрально координуватися — це є недоліком, оверхед у нас є, весь час треба ходити в мережу і т. д.
  • Наступний підхід він на основі Timestamp. Тут ідея в тому, що для того, щоб позначити сшепшот, використовувати Timestamp. Це може бути не зовсім реальний Timestamp, це може бути якесь синтетичне час, для якого виконані певні гарантії, зокрема, нам, наприклад, треба забезпечити, щоб час ніколи не йшло назад. У класичному MTP це не можливо, воно іноді стрибає назад. Так, він взяв, зв'язався з сервером, зрозумів, що він перегнав, і тому себе. З нашої точки зору завжди повинна іти вперед. У цього підходу основна перевага у тому, що він може працювати без центрального арбітра, в ньому можливі локальні транзакції, і для того, щоб виконати якісь транзакції, достатньо задіяти тільки ті вузли, які вона безпосередньо зачіпає, ніякі більше вузли не треба задіяти. Мінусом є те, що для нього потрібно використовувати two-phase commit, який дає пристойний оверхед, але над зменшенням оверхеда, над якимсь полегшеним двофазним комітом для цього підходу ми теж працюємо.
  • Є ще один підхід — це инкрементальные снепшоты. Ідея в тому, що у нас є окремо локальні транзакції і глобальні транзакції. І глобальні транзакції повинні координуватися через якийсь центральний арбітр, а локальні транзакції можуть проходити локально. Тут, як би, все здорово, але насправді в цьому підході є ще багато трейдофф'ів всередині нього, тому що може статися так, що ви не завжди можете локальну транзакцію перетворити в глобальну, т. к. там вийде так званий крос феномен, або ж вам доведеться пожертвувати продуктивністю глобальних транзакцій. Зараз заглиблюватися в це не будемо, є окрема хороша наукова стаття, де розглянуто всі різні варіанти приготування інкрементальних снепшотов.


Така архітектура — це перший підхід, який ми називаємо DTM. У нас є кілька инстансов Postgres, на яких безпосередньо зберігаються дані, координатор, який виконує транзакції і арбітр, який зберігає статуси транзакцій, видає снепшоты. При цьому для того, щоб цей арбітр не був єдиною точкою відмови, ми його також дублюємо, робимо слейвы і в разі збою, ми перемикаємо арбітр на слейв.



Ось як це може працювати: у нас координатор тримає два конекту до двох серверів. З одного з них він починає розподілену транзакцію, а іншому говорить приєднатися до цієї розподіленої транзакції. Далі виконує якісь дії, а потім виконує на обох вузлах комміт.



При цьому ці обидва вузла працюють з dtmd — з демоном для підтримки розподілених транзакцій. Та нода, з якої почалася розподілена транзакція отримує begin, у відповідь їй призначається id'шник цій транзакції, снепшот. Потім наступна нода приєднується до цієї транзакції, дає команду join, теж отримує снепшот. Global xmin потрібно підтримувати для того, щоб вакуум міг розподілено тільки потрібні речі чистити.



В кінці обом цим нодам посилаємо команду, клієнт говорить комміт, вони в свою чергу на dtmd посилають теж комміт. Якщо dtmd бачить, що від кожної з мод, які брали участь у цій транзакції, прийшов комміт, тоді він їм обом повертає ОК. Якщо хоча б одна з них сказала йому roadback, то він повертає всім з них помилку.



flow — це те, що я пояснив, тільки у вигляді схеми.



Інший варіант — це, коли на Timestamp, тут ніякого центрального арбітра ні, тут все покладається на инстансы Postgres'а й на координатор.





Тут приблизно те ж саме, але особливість у тому, що доводиться робити фактично двофазний комміт. Ми сподіваємося, що ми зможемо зробити його потім полегшеним.



Це з приводу зв'язку з арбітром. Якщо на кожен чих, тобто на кожне отримання снепшота нам окремий TCP-пакет посилати до арбітра — це виходить дуже довго, тому є спеціальний демон, робимо sockhub, який відповідно групує звернення до арбітра і пачками їх пересилає і отримує відповіді.







Тут деякі приклади, які ми використовували для бенчмарків.



Класичний банківський приклад, коли ми з одного рахунку знімаємо, на інший переводимо — власне наша друга сценка. Аналогічно у нас був другий потік, який в нашій виставі виконувала дівчина, з якого ми вважали суму і перевіряли сходиться вона чи ні.

Олег Бартунов: Тут у прикладі ми використовували pg_shard. pg_shard ви можете завантажити, скачати патч, і у вас буде транзакционность.



Олександр Коротков: Ми брали і застосовували свій підхід до розподілених транзакцій до вже наявних рішень, у яких підтримки розподілених транзакцій немає, — це pg_shard і FDW.



Ось результати.

  • Синенька — це те, як ми зробили без менеджера розподілених транзакцій. Тобто тут швидкість за рахунок відсутності консистентности між нодами.
  • Червона — це, коли все робить клієнтське додаток.
  • Зелена — це pg_shard.
  • Жовта — FDW.
Відповідно, ми знайшли, що впираємося в швидкість взаємодії з арбітром. Певна оптимізація вже зроблена, потім далі продовжуємо робити. До всього цього у нас є підхід з Timestamp, який в плані масштабності дуже перспективний, тому що в ньому немає єдиної точки, куди всі ходять за снепшотами.

Олег Бартунов: Ви тут не турбуйтеся, що нижче, ніж синенька — ви ніколи не можете бути швидше, ніж синенька, потрібно платити. Тут важливо, що вона масштабується, що три ноди швидше, ніж одна, і при цьому у вас дотримуються і consistency і high valability. Я сам спочатку засмучувався.



Ми зробили мультимастер.

Олександр Коротков: У нас є певне обмежене число друкарських потоків, які реплікують свої операції запису між усіма серверами, і є читають потоки. Можна бачити, що читання масштабується лінійно, як і очікувалося. У випадку, коли у нас мультимастер, ми можемо читати з будь-якого сервера.



Roadmap у нас наступний — зробити патч, який називається XTM — розширювана менеджер транзакцій для 9.6., потім поекспериментувати з різними іншими підходами до реалізації розподіленого менеджера транзакцій, у тому числі, і підхід на Timestamp довести до розуму, продовжити нашу роботу по інтеграції з різними рішеннями.

Ми показали, хто зараз вже може виграти від нашої роботи з менеджеру розподілених транзакцій:



По-перше, це pg_shard і FDW — вони фактично можуть отримати собі властивості ACID завдяки нашому менеджерові розподілених транзакцій. А форки XC/XL/X2 вони можуть просто отримати собі менший праця для синхронізацій з майстром, тому що менеджер розподілених транзакцій вже буде у майстер-гілці і, відповідно, вони можуть менше праці прикладати, не синхронізувати свій GTM.

Олег Бартунов: Закінчуючи, ми дякуємо вам за увагу і говоримо, що чекаємо майбутнього. Ми сподіваємося, що ком'юніті вставить це все в Todo… Досвід показує, що Postgres, звичайно, розгойдується, але потім все робить дуже якісно.

Контакти
zen
smagen
Блог компанії Postgres Professional

Ця доповідь — розшифровка одного з кращих виступів на конференції розробників високонавантажених систем HighLoad++. Зараз ми активно готуємо конференцію 2016 року — у цьому році HighLoad++ пройде в Сколково, 7 і 8 листопада.

Найбільш активний і самий великий трек HighLoad++? Це PostgreSQL! В цьому році нас розкрутили на окремий трек, привозять своїх західних доповідачів, загалом, відриваються по повній.

Також деякі з цих матеріалів використовуються нами в навчальному онлайн-курс по розробці високонавантажених систем HighLoad.Guide — це ланцюжок спеціально підібраних листів, статей, матеріалів, відео. Вже зараз у нашому підручнику понад 30 унікальних матеріалів. Підключайтеся!
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.