ДБА бот Јое. Анатолиј Станслер (Постгрес.аи)

Како позадински програмер разуме да ће СКЛ упит добро функционисати на „производу“? У великим или брзо растућим компанијама, немају сви приступ „производу“. А са приступом, сви захтеви се не могу безболно проверити, а прављење копије базе података често траје сатима. Да бисмо решили ове проблеме, креирали смо вештачки ДБА - Јое. Већ је успешно имплементиран у неколико компанија и помаже више десетина програмера.

Видео:

Здраво свима! Моје име је Анатолиј Станслер. Радим за компанију постгрес.аи. Посвећени смо убрзавању процеса развоја уклањањем кашњења повезаних са радом Постгреса од програмера, ДБА-а и КА-а.

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

Када развијамо и радимо сложене миграције са великим оптерећењем, постављамо себи питање: „Да ли ће ова миграција кренути?“. Користимо преглед, користимо знање искуснијих колега, ДБА стручњака. И они могу да кажу да ли ће летети или не.

Али можда би било боље да то сами тестирамо на копијама у пуној величини. А данас ћемо само причати о томе који су приступи тестирању сада и како се то може учинити боље и са којим алатима. Такође ћемо говорити о предностима и недостацима таквих приступа, и шта можемо да поправимо овде.

Ко је икада направио индексе директно на прод или направио било какве измене? Сасвим мало. А за кога је то довело до тога да су подаци изгубљени или је дошло до застоја? Онда знаш овај бол. Хвала Богу да постоје резервне копије.

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

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

И који је најбољи начин да се то уради?

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

Ово ће нам омогућити да уклонимо неке од грешака, односно спречимо да буду на прод.

који су проблеми?

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

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

Ово је боље од претходног приступа, али и даље постоји велика вероватноћа да ће нека врста грешке отићи у производњу.

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

Ко има базу података већу од терабајта? Више од половине собе.

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

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

Чак и ако то радите унутар инфраструктуре, преузимање једног терабајта података на сат је већ врло добро. Али они користе логичке думпове, преузимају локално из облака. За њих је брзина око 200 гигабајта на сат. И још треба времена да се окренеш од логичке депоније, намоташ индексе итд.

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

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

И ово је могуће.

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

Прави пример:

• ДБ - 4,5 терабајта.

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

Не морате да чекате на пробни штанд и зависите од тога колико је велико. Можете га добити за неколико секунди. Биће то потпуно изолована окружења, али која међусобно деле податке.

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

У нашем случају, ово функционише користећи ОпенЗФС систем.

ОпенЗФС је систем датотека за копирање-уписивање који подржава брзе снимке и клонове. Поуздан је и скалабилан. Њом се веома лако управља. Може се буквално распоредити у два тима.

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

• ЛВМ,

• Складиштење (на пример, Пуре Стораге).

Лабораторија за базе података о којој говорим је модуларна. Може се имплементирати помоћу ових опција. Али за сада смо се фокусирали на ОпенЗФС, јер је било проблема посебно са ЛВМ-ом.

Како то ради? Уместо да преписујемо податке сваки пут када их променимо, ми их чувамо једноставним означавањем да су ти нови подаци из нове тачке у времену, нови снимак.

И у будућности, када желимо да се вратимо или желимо да направимо нови клон од неке старије верзије, само кажемо: „У реду, дајте нам ове блокове података који су овако означени“.

И овај корисник ће радити са таквим скупом података. Он ће их постепено мењати, правити сопствене снимке.

И гранаћемо се. Сваки програмер у нашем случају ће имати прилику да има свој клон који уређује, а подаци који се деле биће подељени између свих.

Да бисте применили такав систем код куће, морате решити два проблема:

• Први је извор података, одакле ћете их преузети. Можете подесити репликацију са производњом. Већ можете да користите резервне копије које сте конфигурисали, надам се. ВАЛ-Е, ВАЛ-Г или Барман. Чак и ако користите неку врсту Цлоуд решења као што је РДС или Цлоуд СКЛ, онда можете користити логичке думпове. Али ипак вам саветујемо да користите резервне копије, јер ћете овим приступом задржати и физичку структуру датотека, што ће вам омогућити да будете још ближе метрикама које бисте видели у продукцији како бисте ухватили проблеме који постоје.

• Други је место где желите да угостите Лабораторију за базе података. То може бити Цлоуд, може бити Он-премисе. Овде је важно рећи да ЗФС подржава компресију података. И то ради прилично добро.

Замислите да ће за сваки такав клон, у зависности од операција које радимо са базом, расти нека врста дев-а. За ово ће дев-у такође бити потребан простор. Али због чињенице да смо узели базу од 4,5 терабајта, ЗФС ће је компримовати на 3,5 терабајта. Ово може да варира у зависности од подешавања. И још увек имамо места за дев.

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

• Ово су програмери, ДБА за валидацију упита, за оптимизацију.

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

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

Са овим приступом:

1. Мала вероватноћа грешака на "проду", јер смо све промене тестирали на подацима у пуној величини.

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

3. И нема баријере, нема чекања између тестова. Заправо можете отићи и проверити. И овако ће бити боље како будемо убрзавали развој.

• Биће мање рефакторисања. Мање грешака ће завршити у продукцији. Касније ћемо их мање рефакторисати.

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

1. Ово је корисно јер делимо ресурсе тестних столова.

Већ добро, али шта се још може убрзати?

Захваљујући оваквом систему, можемо у великој мери да смањимо праг за улазак у такво тестирање.

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

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

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

Шта вам то омогућава? Можете узети одређени упит и послати га на посебан канал за базу података. Аутоматски ћемо поставити танки клон за неколико секунди. Хајде да покренемо овај захтев. Прикупљамо метрике и препоруке. Хајде да покажемо визуелизацију. И онда ће овај клон остати да се овај упит некако оптимизује, додају индекси итд.

Такође нам Слацк даје могућности за сарадњу ван оквира. Пошто је ово само канал, можете започети дискусију о овом захтеву одмах у нити за такав захтев, пинговати своје колеге, ДБА који су унутар компаније.

Али, наравно, постоје проблеми. Пошто је ово стварни свет, а ми користимо сервер који хостује много клонова одједном, морамо да компримујемо количину меморије и ЦПУ снаге која је доступна клоновима.

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

Јасно је да су важни исти подаци. Али ми то већ имамо. И желимо да постигнемо исту конфигурацију. И можемо дати такву скоро идентичну конфигурацију.

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

Подсетимо се како Постгрес ради са меморијом. Имамо два кеша. Један из система датотека и један изворни Постгрес, тј. Схаред Буффер Цацхе.

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

А друга кеш меморија користи сав расположиви простор.

А када направимо неколико клонова на једној машини, испада да постепено попуњавамо меморију. И на добар начин, Схаред Буффер Цацхе је 25% укупне количине меморије која је доступна на машини.

И испоставило се да ако не променимо овај параметар, онда ћемо моћи да покренемо само 4 инстанце на једној машини, односно укупно 4 ова танка клона. А ово је, наравно, лоше, јер желимо да их имамо много више.

Али са друге стране, Буффер Цацхе се користи за извршавање упита за индексе, односно план зависи од тога колико су наши кешови велики. А ако само узмемо овај параметар и смањимо га, онда се наши планови могу много променити.

На пример, ако имамо велику кеш меморију на прод, онда ће Постгрес радије користити индекс. А ако не, онда ће постојати СекСцан. А шта би била поента да нам се планови не поклопе?

Али овде долазимо до закључка да у ствари план у Постгресу не зависи од специфичне величине наведене у Схаред Буффер-у у плану, већ од ефективне_цацхе_сизе.

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

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

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

• Зависи од оптерећења које је тренутно на прод.

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

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

А ако желите да тајминг буде близак ономе што ћемо видети у продукцији, онда треба да узмемо најсличнији хардвер и, евентуално, чак и више да сви клонови одговарају. Али ово је компромис, тј. добићете исте планове, видећете колико података ће одређени упит прочитати и моћи ћете да закључите да ли је овај упит добар (или миграција) или лош, још увек га треба оптимизовати .

Хајде да погледамо како је Јое посебно оптимизован.

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

Пишемо поруку каналу, клон нам је распоређен. И видећемо да ће такав захтев бити завршен за 2,5 минута. Ово је прва ствар коју примећујемо.

Б Јое ће вам показати аутоматске препоруке на основу плана и метрике.

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

Погледајмо ближе шта се догодило. Заиста, видимо да смо прочитали скоро један и по гигабајта података из кеша датотека или чак са диска. А ово није добро, јер имамо само 142 реда.

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

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

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

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

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

Друга важна прича је да желимо да план представимо на неки разумљивији начин. Имплементирали смо визуелизацију користећи Фламе Грапхс.

Ово је другачији захтев, интензивнији. И градимо Фламе Грапхове према два параметра: ово је количина података коју је одређени чвор рачунао у плану и времену, тј. време извршења чвора.

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

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

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

Постоји нови приступ визуелизацији - ово је објаснити.далибо.цом. Они раде визуелизацију стабла, али је веома тешко упоредити чворове једни са другима. Овде можете добро разумети структуру, међутим, ако постоји велики захтев, онда ћете морати да скролујете напред-назад, али и опцију.

сарадњу

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

Чини нам се да је важно тестирати на подацима у пуној величини. Да бисмо то урадили, направили смо алатку Упдате Датабасе Лаб, која је доступна у отвореном коду. Можете користити и Јое бот. Можете га одмах узети и имплементирати код себе. Сви водичи су тамо доступни.

Такође је важно напоменути да само решење није револуционарно, јер постоји Делпхик, али је решење за предузећа. Потпуно је затворен, веома је скуп. Посебно смо специјализовани за Постгрес. Ово су све производи отвореног кода. Придружи нам се!

Овде завршавам. Хвала вам!

pitanja

Здраво! Хвала на извештају! Веома интересантно, посебно мени, јер сам пре извесног времена решио отприлике исти проблем. И тако имам низ питања. Надам се да ћу добити бар део тога.

Питам се како израчунавате место за ову средину? Технологија значи да под одређеним околностима ваши клонови могу нарасти до максималне величине. Грубо говорећи, ако имате базу података од десет терабајта и 10 клонова, онда је лако симулирати ситуацију у којој сваки клон тежи 10 јединствених података. Како израчунате ово место, односно ону делту о којој сте говорили, у којој ће живети ови клонови?

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

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

Постоји неки ттл за сваки клон. У основи, имамо фиксни ттл.

Шта ако није тајна?

1 сат, односно мировање - 1 сат. Ако се не користи, онда га лупамо. Али овде нема изненађења, пошто можемо да подигнемо клон за неколико секунди. А ако вам поново затреба, молим вас.

Интересује ме и избор технологија, јер, на пример, из ових или оних разлога користимо неколико метода паралелно. Зашто ЗФС? Зашто нисте користили ЛВМ? Споменули сте да је било проблема са ЛВМ-ом. Шта су били проблеми? По мом мишљењу, најоптималнија опција је са складиштем, у смислу перформанси.

Шта је главни проблем са ЗФС-ом? Чињеница да морате покренути на истом хосту, тј. све инстанце ће живјети у оквиру истог ОС-а. А у случају складиштења, можете повезати различиту опрему. А уско грло су само они блокови који се налазе на систему за складиштење. И питање избора технологија је занимљиво. Зашто не ЛВМ?

Конкретно, можемо разговарати о ЛВМ-у на састанку. О складиштењу - само је скупо. ЗФС систем можемо имплементирати било где. Можете га применити на својој машини. Можете једноставно преузети спремиште и применити га. ЗФС је инсталиран скоро свуда ако говоримо о Линуку. Односно, добијамо веома флексибилно решење. И сам ЗФС даје много изван оквира. Можете да отпремите података колико желите, повежете велики број дискова, постоје снимци. И, као што сам рекао, лако је управљати. То јест, чини се веома пријатним за употребу. Тестиран је, има много година. Он има веома велику заједницу која расте. ЗФС је веома поуздано решење.

Николај Самохвалов: Могу ли даље да коментаришем? Зовем се Николај, радимо заједно са Анатолијем. Слажем се да је складиштење одлично. А неки од наших купаца имају Пуре Стораге итд.

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

Али ЗФС је доступан свима. ДелПхик-а је већ довољно, имају 300 клијената. Од тога, Фортуне 100 има 50 клијената, односно намењени су НАСА-и итд. Време је да сви добију ову технологију. И зато имамо отворено језгро. Имамо део интерфејса који није отвореног кода. Ово је платформа коју ћемо показати. Али желимо да буде доступно свима. Желимо да направимо револуцију како би сви тестери престали да погађају на лаптоповима. Морамо написати СЕЛЕЦТ и одмах видети да је спор. Престаните да чекате да вам ДБА каже о томе. Овде је главни циљ. И мислим да ћемо сви доћи до овога. И правимо ову ствар за свакога. Због тога ЗФС, јер ће бити доступан свуда. Хвала заједници на решавању проблема и лиценци отвореног кода, итд.*

Велики поздрав! Хвала на извештају! Моје име је Максим. Бавили смо се истим питањима. Одлучили су сами. Како делите ресурсе између ових клонова? Сваки клон може да ради своје ствари у било ком тренутку: један тестира једно, други друго, неко прави индекс, неко има тежак посао. А ако још увек можете да делите са ЦПУ-ом, а затим са ИО-ом, како делите? Ово је прво питање.

А друго питање је о различитости трибина. Рецимо да имам ЗФС овде и све је кул, али клијент на прод нема ЗФС, већ ект4, на пример. Како у овом случају?

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

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

Имам два питања. Ово је веома кул ствар. Да ли је било случајева да су подаци о производњи критични, као што су бројеви кредитних картица? Да ли је већ нешто спремно или је то посебан задатак? И друго питање - постоји ли нешто овако за МиСКЛ?

О подацима. Радићемо замагљивање док то не урадимо. Али ако примените тачно Јое, ако не дате приступ програмерима, онда нема приступа подацима. Зашто? Зато што Џо не приказује податке. Приказује само метрику, планове и то је то. То је намерно урађено, јер је то један од захтева нашег клијента. Желели су да могу да оптимизују без давања приступа свима.

О МиСКЛ-у. Овај систем се може користити за све што чува стање на диску. А пошто радимо Постгрес, сада прво радимо сву аутоматизацију за Постгрес. Желимо да аутоматизујемо добијање података из резервне копије. Правилно конфигуришемо Постгрес. Знамо како да ускладимо планове итд.

Али пошто је систем проширив, може се користити и за МиСКЛ. А таквих примера има. Јандекс има сличну ствар, али је нигде не објављују. Користе га унутар Иандек.Метрица. А постоји само прича о МиСКЛ-у. Али технологије су исте, ЗФС.

Хвала на извештају! Имам и пар питања. Споменули сте да се клонирање може користити за аналитику, на пример за прављење додатних индекса тамо. Можете ли рећи нешто више о томе како то функционише?

И одмах ћу поставити друго питање о сличности трибина, сличности планова. План такође зависи од статистике коју прикупља Постгрес. Како решавате овај проблем?

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

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

Индекс ће бити креиран сваки пут?

Можете направити тако да додирнемо податке, направимо снимке, а затим ћемо се опоравити са овог снимка и покренути нове захтеве. То јест, можете учинити тако да можете подизати нове клонове са већ причвршћеним индексима.

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

Ево још једног проблема. Ако користите решење у облаку, онда су тамо доступне само логичке депоније, јер вам Гугл, Амазон не дозвољавају да узмете физичку копију. Биће проблема.

Хвала на извештају. Овде су била два добра питања о МиСКЛ-у и дељењу ресурса. Али, у ствари, све се своди на то да ово није тема конкретног ДБМС-а, већ датотечног система у целини. И, сходно томе, одатле треба решавати и питања дељења ресурса, не на крају да је то Постгрес, већ у систему датотека, на серверу, на пример.

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

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

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

Из претходних слојева који су били из претходних репликација.

Претходни слојеви ће отпасти, али ће се односити на стари слој, и да ли ће узети нове слике са последњег слоја који је примљен у ажурирању?

Генерално, да.

Тада ћемо као последицу имати до смокве слојева. И временом ће их требати компримовати?

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

Здраво, хвала на извештају! Питање о Јоеу. Рекли сте да купац није желео свима да омогући приступ подацима. Строго говорећи, ако особа има резултат Екплаин Анализе, онда може да погледа податке.

Тако је то. На пример, можемо написати: „ИЗАБИР ОД ГДЈЕ е-маил = на то“. То јест, нећемо видети саме податке, али можемо видети неке индиректне знакове. Ово се мора разумети. Али с друге стране, све је ту. Имамо ревизију дневника, имамо контролу над другим колегама који такође виде шта програмери раде. А ако неко то покуша да уради, онда ће им служба безбедности доћи и порадити на овом питању.

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

Сада постоји веза за Слацк, тј. не постоји други месинџер, али заиста желим да пружим подршку и за друге гласнике. Шта можете да урадите? Можете да примените ДБ Лаб без Џоа, идите уз помоћ РЕСТ АПИ-ја или уз помоћ наше платформе и креирате клонове и повежете се са ПСКЛ-ом. Али то се може урадити ако сте спремни да својим програмерима дате приступ подацима, јер више неће бити екрана.

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

Онда да, то се може урадити.

Извор: ввв.хабр.цом