DBA бот Џо. Анатолиј Станслер (Postgres.ai)

Како развивачот на заднина разбира дека барањето SQL ќе работи добро на „прод“? Во големите или брзорастечките компании, не секој има пристап до „производот“. И со пристапот, не можат безболно да се проверат сите барања, а создавањето на копија од базата на податоци често трае со часови. За да ги решиме овие проблеми, создадовме вештачка DBA - Џо. Веќе е успешно имплементиран во неколку компании и им помага на повеќе од десетина програмери.

Видео:

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

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

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

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

Кој некогаш направил индекси директно на прод или направил какви било промени? Сосема малку од. И за кого ова доведе до фактот дека податоците се изгубени или имало прекини? Тогаш ја знаете оваа болка. Фала богу што има резервни копии.

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

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

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

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

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

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

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

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

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

Што нè спречува да му дадеме на секој развивач тест клупа, копија со целосна големина? Мислам дека е јасно што е на патот.

Кој има база на податоци поголема од терабајт? Повеќе од половина од собата.

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

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

Дури и ако го правите тоа внатре во инфраструктурата, тогаш преземањето на еден терабајт податоци на час е веќе многу добро. Но, тие користат логички депонии, тие преземаат локално од облакот. За нив брзината е околу 200 гигабајти на час. И сè уште е потребно време да се свртиме од логичката депонија, да се навиваат индексите итн.

Но, тие го користат овој пристап затоа што им овозможува да го задржат продот сигурен.

Што можеме да правиме овде? Ајде да ги направиме тест клупите евтини и да му дадеме на секој развивач своја сопствена тест клупа.

И ова е можно.

И во овој пристап, кога правиме тенки клонови за секој развивач, можеме да го споделиме на една машина. На пример, ако имате база на податоци од 10 ТБ и сакате да ја дадете на 10 програмери, не треба да имате бази на податоци од XNUMX x XNUMX ТБ. Потребна ви е само една машина за да направите тенки изолирани копии за секој развивач што користи една машина. Ќе ви кажам како функционира малку подоцна.

Вистински пример:

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

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

Не треба да чекате за тест штанд и да зависите од тоа колку е голема. Можете да го добиете за неколку секунди. Тоа ќе бидат целосно изолирани средини, но кои споделуваат податоци меѓу себе.

Ова е супер. Овде зборуваме за магија и паралелен универзум.

Во нашиот случај, ова функционира со користење на системот OpenZFS.

OpenZFS е датотечен систем за копирање-на-пишување кој поддржува снимки и клонови надвор од кутијата. Тој е сигурен и скалабилен. Таа е многу лесна за управување. Буквално може да се распореди во два тима.

Постојат и други опции:

• лвм,

• Складирање (на пример, Чисто складирање).

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

Како работи? Наместо да ги препишуваме податоците секогаш кога ги менуваме, ние ги зачувуваме со едноставно означување дека овие нови податоци се од нова временска точка, нова снимка.

И во иднина, кога сакаме да се вратиме назад или сакаме да направиме нов клон од некоја постара верзија, само велиме: „Во ред, дајте ни ги овие блокови на податоци што се вака означени“.

И овој корисник ќе работи со таков збир на податоци. Постепено ќе ги менува, ќе прави свои снимки.

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

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

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

• Вториот е местото каде што сакате да ја хостирате Лабораторијата за бази на податоци. Може да биде Cloud, може да биде On-premise. Овде е важно да се каже дека ZFS поддржува компресија на податоци. И тоа го прави доста добро.

Замислете дека за секој таков клон, во зависност од операциите што ги правиме со базата, ќе расте некој вид на dev. За ова, на dev ќе му треба и простор. Но, поради фактот што зедовме база од 4,5 терабајти, ZFS ќе ја компресира на 3,5 терабајти. Ова може да варира во зависност од поставките. И ние сè уште имаме простор за dev.

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

• Тоа се програмери, DBA за валидација на барањето, за оптимизација.

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

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

Со овој пристап:

1. Мала веројатност за грешки на „прод“, бидејќи ги тестиравме сите промени на податоци со целосна големина.

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

3. И нема бариера, нема чекање помеѓу тестовите. Вие всушност можете да отидете и да проверите. И така ќе биде подобро додека го забрзуваме развојот.

• Ќе има помалку рефакторирање. Помалку грешки ќе завршат во прод. Подоцна ќе ги рефакторираме помалку.

• Можеме да ги смениме неповратните промени. Ова не е стандарден пристап.

1. Ова е корисно бидејќи ги споделуваме ресурсите на тест клупите.

Веќе добро, но што друго би можело да се забрза?

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

Сега постои маѓепсан круг, кога развивачот, за да добие пристап до вистински податоци со целосна големина, мора да стане експерт. Мора да му се верува со таков пристап.

Но, како да растете ако го нема. Но, што ако имате на располагање само многу мал сет на податоци од тестот? Тогаш нема да добиете вистинско искуство.

Како да излезете од овој круг? Како прв интерфејс, погоден за програмери од кое било ниво, го избравме ботот Slack. Но, тоа може да биде кој било друг интерфејс.

Што ви дозволува да направите? Можете да преземете одредено барање и да го испратите на посебен канал за базата на податоци. Автоматски ќе распоредиме тенок клон за неколку секунди. Ајде да го извршиме ова барање. Ние собираме метрика и препораки. Ајде да покажеме визуелизација. И тогаш овој клон ќе остане така што ова барање може некако да се оптимизира, да додава индекси итн.

И, исто така, Slack ни дава можности за соработка надвор од кутијата. Бидејќи ова е само канал, можете да започнете да разговарате за ова барање токму таму во темата за такво барање, пинг на вашите колеги, DBA кои се во компанијата.

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

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

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

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

Да се ​​потсетиме како Postgres работи со меморијата. Имаме две кешови. Еден од датотечниот систем и еден мајчин Postgres, т.е. Заеднички бафер кеш.

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

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

И кога правиме неколку клонови на една машина, излегува дека постепено ја пополнуваме меморијата. И на добар начин, Shared Buffer Cache е 25% од вкупната количина на меморија што е достапна на машината.

И излегува дека ако не го промениме овој параметар, тогаш ќе можеме да извршиме само 4 примери на една машина, односно вкупно 4 од овие тенки клонови. И ова, се разбира, е лошо, бидејќи сакаме да имаме многу повеќе од нив.

Но, од друга страна, Buffer Cache се користи за извршување на барања за индекси, односно, планот зависи од тоа колку се големи нашите кешови. И ако само го земеме овој параметар и го намалиме, тогаш нашите планови можат многу да се променат.

На пример, ако имаме голем кеш на прод, тогаш Postgres ќе претпочита да користи индекс. А ако не, тогаш ќе има SeqScan. И која би била поентата доколку нашите планови не се поклопат?

Но, тука доаѓаме до заклучок дека всушност планот во Postgres не зависи од специфичната големина наведена во Shared Buffer во планот, тоа зависи од effect_cache_size.

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

И поради овој параметар, можеме да го измамиме Postgres, велејќи дека всушност имаме многу достапни податоци, дури и ако ги немаме овие податоци. И така, плановите целосно ќе се поклопат со производството.

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

• Тоа зависи од товарот што моментално е на прод.

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

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

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

Ајде да погледнеме како Џо е конкретно оптимизиран.

Ајде да земеме барање од реален систем. Во овој случај, базата на податоци е 1 терабајт. И сакаме да го броиме бројот на свежи објави кои имаа повеќе од 10 лајкови.

Пишуваме порака до каналот, распореден е клон за нас. И ќе видиме дека таквото барање ќе заврши за 2,5 минути. Ова е првото нешто што го забележуваме.

Б Џо ќе ви покаже автоматски препораки врз основа на планот и метриката.

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

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

И, се чини, имаме скенирање на индекс овде и требаше брзо да работиме, но бидејќи филтриравме премногу линии (моравме да ги броиме), барањето полека успеа.

И ова се случи во планот поради фактот што условите во барањето и условите во индексот делумно не се совпаѓаат.

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

Создавањето на индексот траеше доста долго, но сега го проверуваме барањето и гледаме дека времето наместо 2,5 минути е само 156 милисекунди, што е доволно добро. И читаме само 6 мегабајти податоци.

И сега користиме само скенирање индекси.

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

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

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

Се разбира, секој знае објасни.depesz.com. Добра карактеристика на оваа визуелизација е тоа што го зачувуваме текстуалниот план и исто така ставаме некои основни параметри во табела за да можеме да сортираме.

А програмерите кои сè уште не навлегле во оваа тема, исто така, користат објаснување.depesz.com, бидејќи им е полесно да сфатат кои метрики се важни, а кои не се.

Има нов пристап за визуелизација - ова е објаснување.dalibo.com. Тие прават визуелизација на дрво, но многу е тешко да се споредат јазлите едни со други. Овде можете добро да ја разберете структурата, меѓутоа, ако има големо барање, тогаш ќе треба да скролувате напред-назад, но и опција.

соработка

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

Ни се чини дека е важно да се тестираат на податоци со целосна големина. За да го направите ова, ја направивме алатката Update Database Lab, која е достапна во отворен код. Можете да го користите и ботот Џо. Можете да го земете токму сега и да го спроведете кај вас. Сите водичи се достапни таму.

Исто така, важно е да се напомене дека самото решение не е револуционерно, бидејќи постои 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, бидејќи ќе биде достапен насекаде. Благодарност до заедницата за решавање на проблемите и за поседување лиценца со отворен код, итн.*

Поздрав! Ви благодариме за извештајот! Јас се викам Максим. Ние се занимававме со истите прашања. Сами одлучија. Како ги споделувате ресурсите помеѓу овие клонови? Секој клон може да го направи своето во секој момент: еден тестира едно, друго друго, некој гради индекс, некој има тешка работа. И ако сеуште можеш да делиш по процесор, тогаш по IO, како се делиш? Ова е првото прашање.

А второто прашање е за различноста на трибините. Да речеме дека имам ZFS овде и се е кул, но клиентот на prod нема ZFS, туку ext4, на пример. Како во овој случај?

Прашањата се многу добри. Малку го спомнав овој проблем со тоа што делиме ресурси. А решението е ова. Замислете дека тестирате на постановка. Може да имате и таква ситуација во исто време некој да дава еден товар, некој друг. И како резултат на тоа, гледате неразбирливи метрики. Дури и истиот проблем може да биде и кај прод. Кога сакате да проверите некое барање и гледате дека има некаков проблем со него - работи бавно, тогаш всушност проблемот не бил во барањето, туку во тоа што има некаков паралелен товар.

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

Имам две прашања. Ова е многу кул работа. Дали имало случаи кога податоците за производството се критични, како што се броевите на кредитни картички? Дали веќе има нешто подготвено или тоа е посебна задача? И второто прашање - има ли вакво нешто за MySQL?

За податоците. Ќе правиме заматување додека не го направиме тоа. Но, ако го распоредите токму Џо, ако не им дадете пристап на програмерите, тогаш нема пристап до податоците. Зошто? Затоа што Џо не покажува податоци. Покажува само метрика, планови и тоа е тоа. Ова е направено намерно, бидејќи тоа е едно од барањата на нашиот клиент. Сакаа да можат да се оптимизираат без да им дадат пристап на сите.

За MySQL. Овој систем може да се користи за сè што ја зачувува состојбата на дискот. И бидејќи правиме Postgres, сега прво ја правиме целата автоматизација за Postgres. Сакаме да го автоматизираме добивањето податоци од резервна копија. Правилно го конфигурираме Postgres. Знаеме како да направиме плановите да одговараат, итн.

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

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

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

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

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

Индексот ќе се креира секој пат?

Можете да го направите така што ќе ги допреме податоците, ќе правиме снимки, а потоа ќе се опоравиме од оваа слика и ќе испратиме нови барања. Тоа е, можете да го направите така што ќе можете да подигнете нови клонови со веќе поставени индекси.

Што се однесува до прашањето за статистиката, ако обновиме од резервна копија, ако правиме репликација, тогаш нашата статистика ќе биде сосема иста. Бидејќи ја имаме целата структура на физички податоци, односно ќе ги донесеме податоците како што се и со сите статистички метрики.

Еве уште еден проблем. Ако користите облак решение, тогаш таму се достапни само логички депонии, бидејќи Google, Amazon не ви дозволуваат да земете физичка копија. Ќе има проблем.

Ви благодариме за извештајот. Имаше две добри прашања овде за MySQL и споделување ресурси. Но, всушност, сè се сведува на фактот дека ова не е тема на специфичен DBMS, туку на датотечниот систем како целина. И, соодветно, од таму треба да се решат и прашањата за споделување ресурси, не на крајот дека тоа е Postgres, туку во датотечниот систем, на пример во серверот.

Моето прашање е малку поинакво. Поблиску е до повеќеслојната база на податоци, каде што има неколку слоеви. На пример, поставивме ажурирање на сликата од десет терабајти, реплицираме. И ние конкретно го користиме ова решение за бази на податоци. Репликацијата е во тек, податоците се ажурираат. Паралелно работат 100 вработени, кои постојано ги лансираат овие различни кадри. Што да се прави? Како да се уверите дека нема конфликт, дека тие лансирале еден, а потоа се сменил датотечен систем и сите овие слики отишле?

Нема да одат затоа што така функционира ЗФС. Можеме да ги чуваме одделно во една нишка промените на датотечниот систем кои доаѓаат поради репликација. И чувајте ги клоновите што ги користат програмерите на постарите верзии на податоците. И кај нас функционира, се е во ред со ова.

Излегува дека ажурирањето ќе се одвива како дополнителен слој, и сите нови слики ќе одат веќе, врз основа на овој слој, нели?

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

Претходните слоеви ќе паднат, но ќе се однесуваат на стариот слој и дали ќе направат нови слики од последниот слој што е примен во ажурирањето?

Во принцип, да.

Потоа како последица ќе имаме до смоква слоеви. И со текот на времето ќе треба да се компресираат?

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

Здраво, благодарам за извештајот! Прашање за Џо. Рековте дека клиентот не сака да им даде на сите пристап до податоците. Строго кажано, ако некое лице го има резултатот од Explain Analyze, тогаш може да ги погледне податоците.

Тоа е така. На пример, можеме да напишеме: „SELECT FROM WHERE е-пошта = до тоа“. Односно, нема да ги видиме самите податоци, но можеме да видиме некои индиректни знаци. Ова мора да се разбере. Но, од друга страна, сето тоа е таму. Имаме ревизија на дневници, имаме контрола врз другите колеги кои исто така гледаат што прават програмерите. И ако некој се обиде да го направи ова, тогаш службата за безбедност ќе дојде кај нив и ќе работи на ова прашање.

Добар ден Ви благодариме за извештајот! Имам кратко прашање. Ако компанијата не користи Slack, дали има некакво обврзување за него сега или дали е можно програмерите да распоредат примероци за да поврзат тест апликација со базите на податоци?

Сега има врска до Slack, т.е. нема друг месинџер, но навистина сакам да направам поддршка и за други месинџери. Што можеш да направиш? Можете да распоредите DB Lab без Џо, да одите со помош на REST API или со помош на нашата платформа и да креирате клонови и да се поврзете со PSQL. Но, ова може да се направи ако сте подготвени да им дадете на вашите програмери пристап до податоците, бидејќи веќе нема да има никаков екран.

Не ми треба овој слој, но ми треба таква можност.

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

Извор: www.habr.com