DBA бот Джо. Анатолий Щанслер (Postgres.ai)

Как бекенд разработчик разбира, че SQL заявка ще работи добре на „prod“? В големи или бързо развиващи се компании не всеки има достъп до „продукта“. А с достъпа не всички заявки могат да бъдат проверени безболезнено и създаването на копие на базата данни често отнема часове. За да разрешим тези проблеми, създадохме изкуствен DBA - Joe. Той вече е успешно внедрен в няколко компании и помага на повече от дузина разработчици.

Video:

Здравейте всички! Казвам се Анатолий Щанслер. Работя във фирма postgres.ai. Ние се ангажираме да ускорим процеса на разработка, като премахнем забавянията, свързани с работата на Postgres от разработчици, DBA и QA.

Имаме страхотни клиенти и днес част от доклада ще бъде посветен на казуси, с които се сблъскахме, работейки с тях. Ще говоря за това как сме им помогнали да решат доста сериозни проблеми.

Когато разработваме и извършваме сложни миграции с голямо натоварване, ние си задаваме въпроса: „Ще започне ли тази миграция?“. Използваме преглед, използваме знанията на по-опитни колеги, DBA експерти. И те могат да кажат дали ще лети или не.

Но може би би било по-добре, ако можем да го тестваме сами върху копия в пълен размер. И днес просто ще говорим за това какви подходи към тестването са сега и как може да се направи по-добре и с какви инструменти. Ще говорим също за плюсовете и минусите на подобни подходи и какво можем да коригираме тук.

Кой някога е правил индекси директно на prod или е правил промени? Доста малко. И за кого това доведе до загуба на данни или прекъсвания? Тогава познавате тази болка. Слава Богу, че има резервни копия.

Първият подход е тестване в прод. Или, когато разработчик седи на локална машина, той има тестови данни, има някакъв вид ограничен избор. И ние се разгръщаме до прод, и получаваме тази ситуация.

Боли, скъпо е. Вероятно е най-добре да не го правите.

И кой е най-добрият начин да го направите?

Нека да вземем постановката и да изберем част от продукцията там. Или в най-добрия случай, нека вземем истински продукт, всички данни. И след като го разработим локално, ще проверим допълнително за постановка.

Това ще ни позволи да премахнем някои от грешките, т.е. да попречим да бъдат на прод.

Какви са проблемите?

• Проблемът е, че споделяме тази постановка с колеги. И много често се случва да направите някаква промяна, бам - и няма данни, работата е на вятъра. Постановката беше многотерабайтова. И трябва да чакате дълго време, за да втаса отново. И решаваме да го финализираме утре. Това е, имаме развитие.
• И, разбира се, имаме много колеги, които работят там, много екипи. И трябва да се направи ръчно. И това е неудобно.

И си струва да кажем, че имаме само един опит, един изстрел, ако искаме да направим някои промени в базата данни, да докоснем данните, да променим структурата. И ако нещо се обърка, ако е имало грешка в миграцията, тогава няма да се върнем бързо.

Това е по-добре от предишния подход, но все още има голяма вероятност някаква грешка да отиде в производството.

Какво ни пречи да дадем на всеки разработчик тестов стенд, копие в пълен размер? Мисля, че е ясно какво пречи.

Кой има база данни, по-голяма от терабайт? Повече от половината стая.

И е ясно, че поддържането на машини за всеки разработчик, когато има толкова голямо производство, е много скъпо, а освен това отнема много време.

Имаме клиенти, които са разбрали, че е много важно да тестват всички промени върху копия в пълен размер, но тяхната база данни е по-малка от терабайт и няма ресурси за поддържане на тестова стенда за всеки разработчик. Следователно те трябва да изтеглят дъмповете локално на своята машина и да тестват по този начин. Отнема много време.

Дори ако го направите вътре в инфраструктурата, тогава изтеглянето на един терабайт данни на час вече е много добро. Но те използват логически дъмпове, изтеглят локално от облака. При тях скоростта е около 200 гигабайта на час. И все още отнема време, за да се върнете от логическия дъмп, да навиете индексите и т.н.

Но те използват този подход, защото им позволява да поддържат продукта надежден.

Какво можем да направим тук? Нека направим тестовите стендове евтини и да дадем на всеки разработчик собствен тестов стенд.

И това е възможно.

И при този подход, когато правим тънки клонинги за всеки разработчик, можем да го споделим на една машина. Например, ако имате 10TB база данни и искате да я дадете на 10 разработчици, не е необходимо да имате XNUMX x XNUMXTB бази данни. Имате нужда само от една машина, за да правите тънки изолирани копия за всеки разработчик, използвайки една машина. Ще ви кажа как работи малко по-късно.

Реален пример:

• DB - 4,5 терабайта.

• Можем да получим независими копия за 30 секунди.

Не е нужно да чакате тестов стенд и да зависи от това колко е голям. Можете да го получите за секунди. Това ще бъдат напълно изолирани среди, но които споделят данни помежду си.

Това е страхотно. Тук говорим за магия и паралелна вселена.

В нашия случай това работи с помощта на системата OpenZFS.

OpenZFS е файлова система за копиране при запис, която поддържа моментни снимки и клонинги веднага. Той е надежден и мащабируем. Тя е много лесна за управление. Може буквално да се разположи в два екипа.

Има и други опции:

• lvm,

• Съхранение (например Pure Storage).

Лабораторията за бази данни, за която говоря, е модулна. Може да се реализира с помощта на тези опции. Но засега сме се фокусирали върху OpenZFS, защото имаше проблеми конкретно с LVM.

Как работи? Вместо да презаписваме данните всеки път, когато ги променим, ние ги запазваме, като просто маркираме, че тези нови данни са от нов момент във времето, нова моментна снимка.

И в бъдеще, когато искаме да върнем назад или искаме да направим нов клонинг от някаква по-стара версия, ние просто казваме: "Добре, дайте ни тези блокове от данни, които са маркирани по този начин."

И този потребител ще работи с такъв набор от данни. Той постепенно ще ги промени, ще направи свои собствени снимки.

И ще разклоняваме. Всеки разработчик в нашия случай ще има възможност да има свой собствен клонинг, който редактира, а данните, които се споделят, ще се споделят между всички.

За да разположите такава система у дома, трябва да решите два проблема:

• Първият е източникът на данните, откъдето ще ги вземете. Можете да настроите репликация с производство. Вече можете да използвате резервните копия, които сте конфигурирали, надявам се. WAL-E, WAL-G или Barman. И дори ако използвате някакво облачно решение като RDS или Cloud SQL, тогава можете да използвате логически дъмпове. Но все пак ви съветваме да използвате резервни копия, защото с този подход ще запазите и физическата структура на файловете, което ще ви позволи да бъдете още по-близо до показателите, които бихте виждали в производството, за да уловите онези проблеми, които съществуват.

• Второто е мястото, където искате да хоствате Database Lab. Може да е Cloud, може да е On-premise. Тук е важно да се каже, че ZFS поддържа компресиране на данни. И го прави доста добре.

Представете си, че за всеки такъв клонинг, в зависимост от операциите, които правим с базата, ще расте някакъв вид dev. За това dev също ще се нуждае от пространство. Но поради факта, че взехме база от 4,5 терабайта, ZFS ще я компресира до 3,5 терабайта. Това може да варира в зависимост от настройките. И все още имаме място за разработчици.

Такава система може да се използва за различни случаи.

• Това са разработчици, DBA за валидиране на заявки, за оптимизация.

• Това може да се използва при тестване на QA, за да се тества конкретна миграция, преди да я пуснем в прод. И можем също така да създадем специални среди за QA с реални данни, където те могат да тестват нова функционалност. И това ще отнеме секунди вместо часове на изчакване, а може би и дни в някои други случаи, когато не се използват тънки копия.

• И още един случай. Ако компанията няма настроена система за анализ, тогава можем да изолираме тънък клонинг на продуктовата база и да го дадем на дълги заявки или специални индекси, които могат да се използват в анализите.

С този подход:

1. Ниска вероятност за грешки в "prod", защото тествахме всички промени върху данни в пълен размер.

2. Имаме култура на тестване, защото сега не е нужно да чакате с часове за собствения си щанд.

3. И няма бариера, няма чакане между тестовете. Всъщност можете да отидете и да проверите. И така ще е по-добре, като ускорим развитието.

• Ще има по-малко рефакторинг. По-малко грешки ще се окажат в прод. По-късно ще ги преработим по-малко.

• Можем да обърнем необратими промени. Това не е стандартният подход.

1. Това е от полза, защото споделяме ресурсите на тестовите стендове.

Вече добре, но какво друго може да се ускори?

Благодарение на такава система можем значително да намалим прага за влизане в такова тестване.

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

Но как да расте, ако го няма. Но какво ще стане, ако разполагате само с много малък набор от тестови данни? Тогава няма да получите истински опит.

Как да излезем от този кръг? Като първи интерфейс, удобен за разработчици от всяко ниво, избрахме бота Slack. Но може да бъде всеки друг интерфейс.

Какво ви позволява да правите? Можете да вземете конкретна заявка и да я изпратите до специален канал за базата данни. Ние автоматично ще внедрим тънък клонинг за секунди. Нека изпълним тази заявка. Ние събираме показатели и препоръки. Да покажем визуализация. И тогава този клонинг ще остане, за да може тази заявка да бъде оптимизирана по някакъв начин, да се добавят индекси и т.н.

Освен това Slack ни дава възможности за сътрудничество извън кутията. Тъй като това е само канал, можете да започнете да обсъждате тази заявка точно там в нишката за такава заявка, да пингвате вашите колеги, DBA, които са вътре в компанията.

Но има, разбира се, проблеми. Тъй като това е реалният свят и ние използваме сървър, хостващ много клонинги наведнъж, трябва да компресираме количеството памет и мощността на процесора, налични за клонингите.

Но за да бъдат тези тестове правдоподобни, трябва по някакъв начин да разрешите този проблем.

Ясно е, че важният момент са едни и същи данни. Но ние вече го имаме. И ние искаме да постигнем същата конфигурация. И ние можем да дадем такава почти идентична конфигурация.

Би било страхотно да имате същия хардуер като в производството, но може да се различава.

Нека си припомним как Postgres работи с паметта. Имаме два кеша. Един от файловата система и един собствен Postgres, т.е. споделен буферен кеш.

Важно е да се отбележи, че споделеният буферен кеш се разпределя при стартиране на Postgres в зависимост от размера, който сте посочили в конфигурацията.

А вторият кеш използва цялото налично пространство.

И когато направим няколко клонинга на една машина, се оказва, че постепенно запълваме паметта. И в добър смисъл, споделеният буферен кеш е 25% от общото количество памет, което е налично на машината.

И се оказва, че ако не променим този параметър, тогава ще можем да стартираме само 4 инстанции на една машина, тоест общо 4 от тези тънки клонинги. И това, разбира се, е лошо, защото искаме да имаме много повече от тях.

Но от друга страна, буферният кеш се използва за изпълнение на заявки за индекси, тоест планът зависи от това колко големи са нашите кешове. И ако просто вземем този параметър и го намалим, тогава нашите планове могат да се променят много.

Например, ако имаме голям кеш на prod, тогава Postgres ще предпочете да използва индекс. И ако не, тогава ще има SeqScan. И какъв би бил смисълът, ако плановете ни не съвпаднаха?

Но тук стигаме до извода, че всъщност планът в Postgres не зависи от конкретния размер, посочен в споделения буфер в плана, той зависи от efektivn_cache_size.

Effective_cache_size е прогнозното количество кеш, който е наличен за нас, т.е. сумата от буферния кеш и кеша на файловата система. Това се задава от конфигурацията. И тази памет не е разпределена.

И благодарение на този параметър можем някак да излъжем Postgres, казвайки, че всъщност имаме много налични данни, дори и да нямаме тези данни. И по този начин плановете ще съвпадат напълно с производството.

Но това може да повлияе на времето. И ние оптимизираме заявките по време, но е важно времето да зависи от много фактори:

• Зависи от натоварването, което е в момента на прод.

• Зависи от характеристиките на самата машина.

И това е индиректен параметър, но всъщност можем да оптимизираме точно по количеството данни, които тази заявка ще прочете, за да получим резултата.

И ако искате времето да бъде близко до това, което ще видим в прод, тогава трябва да вземем най-сходния хардуер и, вероятно, дори повече, така че всички клонинги да паснат. Но това е компромис, т.е. ще получите същите планове, ще видите колко данни ще прочете дадена заявка и ще можете да заключите дали тази заявка е добра (или миграция) или лоша, все още трябва да се оптимизира .

Нека да разгледаме как Joe е конкретно оптимизиран.

Нека вземем заявка от реална система. В този случай базата данни е 1 терабайт. И ние искаме да преброим броя на новите публикации, които са имали повече от 10 харесвания.

Пишем съобщение до канала, за нас е внедрен клонинг. И ще видим, че такава заявка ще завърши за 2,5 минути. Това е първото нещо, което забелязваме.

B Joe ще ви покаже автоматични препоръки въз основа на плана и показателите.

Ще видим, че заявката обработва твърде много данни, за да получи относително малък брой редове. Необходим е и някакъв вид специализиран индекс, тъй като забелязахме, че има твърде много филтрирани редове в заявката.

Нека да разгледаме по-отблизо какво се случи. Наистина виждаме, че сме прочели почти един и половина гигабайта данни от файловия кеш или дори от диска. И това не е добре, защото имаме само 142 реда.

И, изглежда, тук имаме сканиране на индекс и трябваше да се получи бързо, но тъй като филтрирахме твърде много редове (трябваше да ги преброим), заявката бавно се изпълни.

И това се случи в плана поради факта, че условията в заявката и условията в индекса частично не съвпадат.

Нека се опитаме да направим индекса по-прецизен и да видим как се променя изпълнението на заявката след това.

Създаването на индекса отне доста време, но сега проверяваме заявката и виждаме, че времето вместо 2,5 минути е само 156 милисекунди, което е достатъчно. И четем само 6 мегабайта данни.

И сега използваме сканиране само на индекс.

Друга важна история е, че искаме да представим плана по някакъв по-разбираем начин. Внедрихме визуализация с помощта на Flame Graphs.

Това е различно искане, по-интензивно. И ние изграждаме Flame Graphs според два параметъра: това е количеството данни, които определен възел е преброил в плана и времето, т.е. времето за изпълнение на възела.

Тук можем да сравним конкретни възли един с друг. И ще бъде ясно кой от тях отнема повече или по-малко, което обикновено е трудно да се направи при други методи за рендиране.

Разбира се, всеки знае expand.depesz.com. Добра характеристика на тази визуализация е, че запазваме текстовия план и също така поставяме някои основни параметри в таблица, за да можем да сортираме.

И разработчиците, които все още не са се задълбочили в тази тема, също използват expand.depesz.com, защото им е по-лесно да разберат кои показатели са важни и кои не.

Има нов подход към визуализацията - това е expand.dalibo.com. Те правят дървовидна визуализация, но е много трудно да се сравняват възлите един с друг. Тук можете да разберете структурата добре, но ако има голяма заявка, тогава ще трябва да превъртите напред и назад, но също и опция.

сътрудничество

И както казах, Slack ни дава възможност да си сътрудничим. Например, ако попаднем на сложна заявка, която не е ясна как да се оптимизира, можем да изясним този проблем с нашите колеги в нишка в Slack.

Струва ни се, че е важно да се тества върху данни в пълен размер. За да направим това, създадохме инструмента Update Database Lab, който е наличен в отворен код. Можете също да използвате бота Joe. Можете да го вземете точно сега и да го приложите у вас. Всички ръководства са налични там.

Също така е важно да се отбележи, че самото решение не е революционно, защото има Delphix, но е корпоративно решение. Напълно е затворен, много е скъп. Ние специално сме специализирани в Postgres. Това са всички продукти с отворен код. Присъедини се към нас!

Тук свършвам. Благодаря ти!

Въпроси

Здравейте! Благодаря за доклада! Много интересно, особено за мен, защото преди време реших приблизително същия проблем. И така имам редица въпроси. Надявам се да получа поне част от него.

Чудя се как изчислявате мястото за тази среда? Технологията означава, че при определени обстоятелства вашите клонинги могат да растат до максималния размер. Грубо казано, ако имате база данни от десет терабайта и 10 клонинга, тогава е лесно да симулирате ситуация, при която всеки клонинг тежи 10 уникални данни. Как изчислявате това място, тоест тази делта, за която говорихте, в която ще живеят тези клонинги?

Добър въпрос. Тук е важно да следите конкретни клонинги. И ако даден клонинг има някаква твърде голяма промяна, той започне да расте, тогава можем първо да предупредим потребителя за това или незабавно да спрем този клонинг, така че да нямаме ситуация на грешка.

Да, имам вложен въпрос. Тоест как осигурявате жизнения цикъл на тези модули? Имаме този проблем и съвсем отделна история. как става това

Има малко ttl за всеки клонинг. По принцип имаме фиксиран ttl.

Какво, ако не е тайна?

1 час, т.е. празен ход - 1 час. Ако не се използва, тогава го чукаме. Но тук няма изненада, тъй като можем да отгледаме клонинга за секунди. И ако имате нужда от него отново, моля.

Интересува ме и изборът на технологии, защото ние например използваме няколко метода паралелно по една или друга причина. Защо ZFS? Защо не използвахте LVM? Споменахте, че има проблеми с LVM. Какви бяха проблемите? Според мен най-оптималния вариант е със сторидж, като производителност.

Какъв е основният проблем на ZFS? Фактът, че трябва да работите на един и същ хост, т.е. всички екземпляри ще живеят в една и съща операционна система. А в случай на съхранение можете да свържете различно оборудване. И тясното място са само онези блокове, които са в системата за съхранение. И въпросът за избора на технологии е интересен. Защо не LVM?

По-конкретно, можем да обсъдим LVM на среща. Относно съхранението - просто е скъпо. Можем да внедрим системата ZFS навсякъде. Можете да го разположите на вашата машина. Можете просто да изтеглите хранилището и да го внедрите. ZFS е инсталиран почти навсякъде, ако говорим за Linux. Тоест получаваме много гъвкаво решение. И самата ZFS дава много от кутията. Можете да качвате колкото искате данни, да свързвате голям брой дискове, има моментни снимки. И както казах, администрирането е лесно. Тоест изглежда много приятно за използване. Тестван е, на много години е. Той има много голяма общност, която се разраства. ZFS е много надеждно решение.

Николай Самохвалов: Мога ли да коментирам допълнително? Казвам се Николай, работим заедно с Анатолий. Съгласен съм, че съхранението е страхотно. И някои от нашите клиенти имат Pure Storage и т.н.

Анатолий правилно отбеляза, че сме фокусирани върху модулността. И в бъдеще можете да внедрите един интерфейс - да направите моментна снимка, да направите клонинг, да унищожите клонинга. Всичко е лесно. И съхранението е готино, ако е така.

Но ZFS е достъпен за всички. DelPhix вече е достатъчно, те имат 300 клиента. От тях Fortune 100 има 50 клиенти, т.е. те са насочени към НАСА и т.н. Време е всички да се сдобият с тази технология. И затова имаме Core с отворен код. Имаме интерфейсна част, която не е с отворен код. Това е платформата, която ще покажем. Но искаме да е достъпно за всички. Искаме да направим революция, така че всички тестери да спрат да гадаят на лаптопи. Трябва да напишем SELECT и веднага да видим, че е бавен. Спрете да чакате DBA да ви каже за това. Ето я и основната цел. И мисля, че всички ще стигнем до това. И ние правим това нещо за всеки. Следователно ZFS, защото ще бъде достъпен навсякъде. Благодаря на общността за решаването на проблеми и за това, че имате лиценз с отворен код и т.н.*

Поздравления! Благодаря за доклада! Казвам се Максим. Справяли сме се със същите проблеми. Те решиха сами. Как споделяте ресурси между тези клонинги? Всеки клонинг може да прави свои собствени неща във всеки един момент: един тества едно нещо, друг друго, някой изгражда индекс, някой има тежка работа. И ако все още можете да разделите на CPU, след това на IO, как се разделя? Това е първият въпрос.

И вторият въпрос е за несходството на трибуните. Да кажем, че тук имам ZFS и всичко е готино, но клиента на prod няма ZFS, а ext4 примерно. Как в този случай?

Въпросите са много добри. Споменах малко този проблем с факта, че споделяме ресурси. И решението е това. Представете си, че тествате постановка. Можете също така да имате такава ситуация в същото време, че някой дава един товар, някой друг. И в резултат на това виждате неразбираеми показатели. Дори същият проблем може да бъде с prod. Когато искате да проверите някаква заявка и видите, че има някакъв проблем с нея - тя работи бавно, тогава всъщност проблемът не е бил в заявката, а в това, че има някакво паралелно натоварване.

И затова тук е важно да се съсредоточим върху това какъв ще бъде планът, какви стъпки ще предприемем в плана и колко данни ще съберем за това. Фактът, че нашите дискове, например, ще бъдат заредени с нещо, това ще се отрази конкретно на времето. Но можем да преценим колко натоварена е тази заявка по количеството данни. Не е толкова важно, че в същото време ще има някаква екзекуция.

Имам два въпроса. Това е много готино нещо. Имало ли е случаи, когато производствените данни са критични, като номера на кредитни карти? Има ли вече нещо готово или е отделна задача? И вторият въпрос - има ли нещо такова за MySQL?

Относно данните. Ще правим обфускация, докато не го направим. Но ако разположите точно Джо, ако не дадете достъп на разработчиците, тогава няма достъп до данните. Защо? Защото Джо не показва данни. Показва само показатели, планове и толкова. Това беше направено нарочно, защото това е едно от изискванията на нашия клиент. Те искаха да могат да оптимизират, без да дават достъп на всички.

Относно MySQL. Тази система може да се използва за всичко, което съхранява състояние на диск. И тъй като правим Postgres, сега първо извършваме цялата автоматизация за Postgres. Искаме да автоматизираме получаването на данни от резервно копие. Ние конфигурираме Postgres правилно. Ние знаем как да съвпадат плановете и т.н.

Но тъй като системата е разширяема, тя може да се използва и за MySQL. И такива примери има. Yandex има нещо подобно, но не го публикуват никъде. Те го използват в Yandex.Metrica. И има само една история за MySQL. Но технологиите са същите, ZFS.

Благодаря за доклада! Аз също имам няколко въпроса. Споменахте, че клонирането може да се използва за анализ, например за изграждане на допълнителни индекси там. Можете ли да кажете малко повече за това как работи?

И веднага ще задам втория въпрос за сходството на щандовете, сходството на плановете. Планът зависи и от статистическите данни, събрани от Postgres. Как решавате този проблем?

Според анализите няма конкретни случаи, защото все още не сме го използвали, но има такава възможност. Ако говорим за индекси, тогава си представете, че една заявка преследва таблица със стотици милиони записи и колона, която обикновено не е индексирана в prod. И ние искаме да изчислим някои данни там. Ако тази заявка бъде изпратена до prod, тогава има възможност тя да бъде проста на prod, защото заявката ще бъде обработена там за минута.

Добре, нека направим тънък клонинг, който не е ужасно да спре за няколко минути. И за да бъде по-удобно да четем анализите, ще добавим индекси за тези колони, в които се интересуваме от данни.

Индексът ще се създава всеки път?

Можете да направите така, че да докоснем данните, да направим моментни снимки, след което ще се възстановим от тази моментна снимка и ще задвижим нови заявки. Тоест можете да направите така, че да можете да отглеждате нови клонинги с вече поставени индекси.

Колкото до въпроса за статистиката, ако възстановим от резервно копие, ако направим репликация, тогава нашата статистика ще бъде абсолютно същата. Тъй като разполагаме с цялата физическа структура на данните, тоест ние ще представим данните такива, каквито са, и с всички статистически показатели.

Ето още един проблем. Ако използвате облачно решение, тогава там са налични само логически дъмпове, защото Google, Amazon не ви позволяват да правите физическо копие. Ще има проблем.

Благодаря за доклада. Тук имаше два добри въпроса за MySQL и споделянето на ресурси. Но всъщност всичко се свежда до факта, че това не е тема на конкретна СУБД, а на файловата система като цяло. И съответно оттам трябва да се решават и проблемите със споделянето на ресурси, не накрая, че е Postgres, а във файловата система, в сървъра, например.

Моят въпрос е малко по-различен. Тя е по-близо до многослойната база данни, където има няколко слоя. Например, настройваме актуализация на изображението от десет терабайта, репликираме. И ние специално използваме това решение за бази данни. Репликацията е в ход, данните се актуализират. Тук паралелно работят 100 служители, които постоянно пускат тези различни кадри. Какво да правя? Как да се уверя, че няма конфликт, че са стартирали такъв и след това файловата система се е променила и тези снимки са изчезнали?

Няма да отидат, защото ZFS така работи. Можем да съхраняваме отделно в една нишка промените във файловата система, които идват поради репликация. И запазете клонингите, които разработчиците използват на по-стари версии на данните. И при нас работи, всичко е наред с това.

Оказва се, че актуализацията ще се извърши като допълнителен слой и всички нови снимки вече ще вървят въз основа на този слой, нали?

От предишни слоеве, които са от предишни репликации.

Предишните слоеве ще паднат, но ще се отнасят към стария слой и ще вземат ли нови изображения от последния слой, който е получен при актуализацията?

Като цяло, да.

Тогава като следствие ще имаме до една смокиня слоеве. И след време ще трябва да се компресират?

Да всичко е точно. Има някакъв прозорец. Поддържаме седмични моментни снимки. Зависи с какъв ресурс разполагаш. Ако имате възможност да съхранявате много данни, можете да съхранявате моментни снимки за дълго време. Те няма да изчезнат сами. Няма да има повреда на данните. Ако снимките са остарели, както ни се струва, т.е. зависи от политиката в компанията, тогава можем просто да ги изтрием и да освободим място.

Здравейте, благодаря за доклада! Въпрос за Джо. Казахте, че клиентът не е искал да даде на всички достъп до данните. Строго погледнато, ако човек има резултата от Explain Analyze, тогава той може да надникне в данните.

Това е така. Например, можем да напишем: "SELECT FROM WHERE email = to that". Тоест няма да видим самите данни, но можем да видим някои косвени признаци. Това трябва да се разбере. Но от друга страна, всичко е там. Имаме лог одит, имаме контрол на други колеги, които също виждат какво правят разработчиците. И ако някой се опита да направи това, тогава службата за сигурност ще дойде при тях и ще работи по този въпрос.

Добър ден Благодаря за доклада! Имам кратък въпрос. Ако компанията не използва Slack, има ли някакво обвързване към него сега или е възможно разработчиците да разположат екземпляри, за да свържат тестово приложение към базите данни?

Сега има връзка към Slack, т.е. няма друг месинджър, но наистина искам да направя поддръжка и за други месинджъри. Какво можеш да направиш? Можете да разположите DB Lab без Joe, да отидете с помощта на REST API или с помощта на нашата платформа и да създадете клонинги и да се свържете с PSQL. Но това може да стане, ако сте готови да дадете на своите разработчици достъп до данните, защото вече няма да има екран.

Нямам нужда от този слой, но имам нужда от такава възможност.

Тогава да, може да се направи.

Източник: www.habr.com