DBA-бот Joe. Анатолий Станслер (Postgres.ai)

Как backend разработчик разбира се, как SQL заявка ќе работи добро на "прод"? Во големи или брзо растечки компании, пристапот до "прод" не е достапен за сите. И дури со пристап не можат сите барања да се проверат безболно, а создавањето копија на БД често одзема часови. За да ги решиме овие проблеми, создадовме вештачки DBA — Joe. Тој веќе успешно е имплементиран во неколку компании и помага на неколку десетици развиватели.

Видео:

Здраво на сите! Јас сум Анатолиј Станслер. Работам во компанијата Postgres.ai. Ние се занимаваме со забрзување на процесот на развој, отстранувајќи доцнења поврзани со работата на Postgres, за развивачите, DBA и QA.

Имаме одлични клиенти и денес дел од презентацијата ќе биде посветена на случаите што сме ги сретнале во работата со нив. Ќе зборувам за тоа како им помогнавме да решат прилично сериозни проблеми.

Кога водиме развој и правиме сложени миграции, си го поставуваме прашањето: "Ќе успее ли оваа миграција?". Користиме преглед, користиме знаења од поискусни колеги, DBA експерти. И тие можат да кажат – ќе успее или не.

Но, можеби ќе беше подобро ако можевме самите да го тестираме ова на целосни копии. И денес токму ќе разговараме за тоа кои се моменталните пристапи за тестирање и како тоа може да се подобри и со какви алатки. Како и за плусите и минусите на таквите пристапи и што можемe да поправиме тука.

Кој некогаш направил индекси или направил некои промени директно на прод? Доста многу. А кај кого тоа довело до губење на податоци или достани? Тогаш ти е позната оваа болка. Слава Богу, имаме резервни копии.

Првиот пристап – е тестирањето на прод. Или, кога развивачот седи на локалната машина, има тест податоци, има некоја ограничена селекција. И ние запознаваме на прод, и добиваме ваква ситуација.

Ова е болно, скапо. Веројатно, подобро е да не се прави така.

А како подобро да се направи?

Ајде да земеме staging и да издвоиме дел од прод. Или во најдобар случај, да земеме вистински прод, сите податоци. И по локалниот развој, дополнително ќе проверуваме и на staging.

Ова ќе ни дозволи да отстраниме дел од грешките, т.е. да не дозволиме на прод.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• БД – 4,5 терабайта.

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

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

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

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

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

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

• LVM,

• СХД (например, Pure Storage).

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

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

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

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

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

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

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

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

Представете си, че всеки такъв клон, в зависимост от операциите, които извършваме с базата, ще натрупва някакво dev. За това dev също ще трябва място. Но благодарение на това, че взехме база от 4.5 терабайта, ZFS ще я компресира до 3.5 терабайта. В зависимост от настройките това може да варира. И за dev ще остане още място.

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

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

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

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

С такъв подход:

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

2. Съществува култура на тестване, тъй като сега не трябва да чакате часове за вашия собствен стенд.

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

• По-малко рефакториране. По-малко бъгове попадат в продукция. Ние ще ги рефакториране по-малко след това.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Когато създаваме няколко клона на една машина, постепенно запълваме паметта. Според оптималните настройки, Shared Buffer Cache трябва да е 25% от общия обем памет, който е достъпен на машината.

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

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

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

Но тук стигаме до заключението, че планът в Postgres не зависи от конкретния зададен размер на Shared Buffer, а зависи от effective_cache_size.

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

Чрез този параметър можем да 'измамим' Postgres, казвайки, че наистина имаме достъп до много данни, дори ако нямаме. Така плановете ще съвпадат напълно с продукцията.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

И сега използваме index only scan.

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

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

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

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

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

Има нов подход към визуализацията – explain.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 клиенти, т.е. те целят NASA и т.н. Време е тази технология да е достъпна за всички. Затова имаме open source Core. Имаме част от интерфейса, която не е open source. Това е платформа, която ще покажем. Но искаме да бъде достъпна за всеки. Искаме да направим революция, за да спрат всички тестери да гадаят на лаптопите си. Трябва да пишем SELECT и веднага да виждаме, че е бавен. Достатъчно е да чакаме, докато DBA ни разкаже за това. Това е основната цел. И мисля, че ще я постигнем всички. И тази система я правим, за да я имат всички. Затова ZFS, защото ще е достъпен навсякъде. Благодаря на общността за решаването на проблемите и за това, че там е open source лицензия и т.н.*

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

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

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

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

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

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

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

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

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

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

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

ОК, нека направим тънък клон, който не е страшно да спрем за няколко минути. И за да е по-удобно да анализираме данните, ще добавим индекси за онези колони, които ни интересуват.

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

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

Относно въпроса за статистиката, ако се възстановяваме от резервно копие, ако правим репликация, статистиката ще бъде точно такава. Защото напълно всички физически структури на данните, тоест, данните с всички статистически метрики ще бъдат включени.

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

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

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

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

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

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

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

Общо казано, да.

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

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

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

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

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

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

Не ми е необходима тази отделна част, а искам такава възможност.

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

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