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

Backend әзірлеушісі SQL сұрауы «өнімде» жақсы жұмыс істейтінін қалай түсінеді? Ірі немесе қарқынды дамып келе жатқан компанияларда «өнімге» барлығы бірдей қол жеткізе бермейді. Ал қол жетімділікпен барлық сұрауларды ауыртпалықсыз тексеру мүмкін емес және дерекқордың көшірмесін жасау жиі сағатты алады. Бұл мәселелерді шешу үшін біз жасанды DBA – Джо құрдық. Ол қазірдің өзінде бірнеше компанияларда сәтті енгізілді және оннан астам әзірлеушілерге көмектеседі.

Бейне:

Бәріңе сәлем! Менің атым Анатолий Стэнслер. Мен компанияда жұмыс істеймін postgres.ai. Біз Postgres жұмысына байланысты кідірістерді әзірлеушілерден, DBA және QA-дан алып тастау арқылы әзірлеу процесін жылдамдатуға дайынбыз.

Біздің тамаша клиенттеріміз бар және бүгін есептің бір бөлігі олармен жұмыс істеу кезінде кездескен жағдайларға арналады. Мен оларға айтарлықтай күрделі мәселелерді шешуге қалай көмектескеніміз туралы айтатын боламын.

Күрделі күрделі көші-қонды дамытып, жасап жатқанда, біз өзімізге: «Бұл көші-қон басталады ма?» деген сұрақты қоямыз. Біз шолуды қолданамыз, біз тәжірибелі әріптестердің, DBA сарапшыларының білімін қолданамыз. Және олар ұшатын-ұшпайтынын айта алады.

Бірақ біз оны толық өлшемді көшірмелерде өзіміз сынасақ жақсы болар еді. Ал бүгін біз тестілеудің қандай тәсілдері бар және оны қалай жақсырақ және қандай құралдармен жасауға болатыны туралы сөйлесетін боламыз. Біз сондай-ақ мұндай тәсілдердің жақсы және жаман жақтары туралы және мұнда нені түзете алатынымыз туралы айтатын боламыз.

Кім тікелей өнімде индекстер жасады немесе қандай да бір өзгерістер енгізді? Біраз. Бұл кім үшін деректердің жоғалуына немесе тоқтап қалуына әкелді? Сонда сіз бұл ауырсынуды білесіз. Құдайға шүкір резервтік көшірмелер бар.

Бірінші тәсіл - өнімде тестілеу. Немесе әзірлеуші ​​жергілікті машинада отырғанда, оның сынақ деректері бар, таңдаудың қандай да бір түрі бар. Біз өндіріске шығып, осындай жағдайға тап боламыз.

Ауырды, қымбат. Болмағаны дұрыс шығар.

Және мұны істеудің ең жақсы жолы қандай?

Қойылымды алайық және сол жерде өнімнің бір бөлігін таңдайық. Немесе ең жақсы жағдайда, нақты өнімді, барлық деректерді алайық. Біз оны жергілікті жерде әзірлегеннен кейін, біз қойылымды қосымша тексереміз.

Бұл кейбір қателерді жоюға мүмкіндік береді, яғни олардың өндірісте болуын болдырмайды.

Қандай проблемалар бар?

• Мәселе мынада, бұл қойылымды әріптестерімізбен бөлісеміз. Көбінесе сіз қандай да бір өзгерістер жасайсыз, бам - және ешқандай деректер жоқ, жұмыс ағынды. Сахналау көп терабайт болды. Және оның қайтадан көтерілуін ұзақ күту керек. Ал біз оны ертең аяқтаймыз деп шешеміз. Міне, бізде даму бар.
• Және, әрине, онда көптеген әріптестеріміз, көптеген ұжымдар жұмыс істейді. Және оны қолмен жасау керек. Және бұл ыңғайсыз.

Ал бізде бір ғана әрекет, бір ату бар екенін айта кеткен жөн, егер біз деректер базасына біраз өзгерістер енгізгіміз келсе, деректерге қол тигіземіз, құрылымды өзгертеміз. Ал егер бірдеңе дұрыс болмаса, көші-қонда қателік орын алса, біз тез кері оралмаймыз.

Бұл алдыңғы тәсілге қарағанда жақсырақ, бірақ қандай да бір қателіктің өндіріске түсу ықтималдығы әлі де жоғары.

Әрбір әзірлеушіге сынақ үстелін, толық өлшемді көшірмені беруге бізге не кедергі? Менің ойымша, не кедергі болатыны анық.

Кімде терабайттан үлкен дерекқор бар? Бөлменің жартысынан көбі.

Ал мұндай үлкен өндіріс болған кезде әрбір әзірлеушіге станоктарды ұстау өте қымбатқа түсетіні, оның үстіне ұзақ уақыт алатыны анық.

Бізде барлық өзгерістерді толық өлшемді көшірмелерде сынау өте маңызды екенін түсінген клиенттер бар, бірақ олардың дерекқоры терабайттан аз және әрбір әзірлеуші ​​үшін сынақ стенді сақтау үшін ресурстар жоқ. Сондықтан, олар қоқыстарды жергілікті түрде өз машинасына жүктеп алып, осылайша сынақтан өткізуі керек. Бұл көп уақытты алады.

Егер сіз мұны инфрақұрылымның ішінде жасасаңыз да, сағатына бір терабайт деректерді жүктеп алу өте жақсы. Бірақ олар логикалық қоқыстарды пайдаланады, олар бұлттан жергілікті түрде жүктеп алады. Олар үшін жылдамдық сағатына шамамен 200 гигабайтты құрайды. Логикалық қоқыстан айналу, индекстерді жинау және т.б. үшін әлі де уақыт қажет.

Бірақ олар бұл тәсілді пайдаланады, өйткені бұл оларға өнімді сенімді ұстауға мүмкіндік береді.

Мұнда не істей аламыз? Сынақ стендтерін арзан етейік және әрбір әзірлеушіге өз сынақ стендісін берейік.

Және бұл мүмкін.

Және бұл тәсілде әрбір әзірлеушіге жұқа клондар жасағанда, біз оны бір машинада бөлісе аламыз. Мысалы, сізде 10TB дерекқорыңыз болса және оны 10 әзірлеушіге бергіңіз келсе, сізге XNUMX x XNUMXTB дерекқоры қажет емес. Бір құрылғыны пайдаланып әрбір әзірлеушіге жұқа оқшауланған көшірмелер жасау үшін сізге тек бір машина қажет. Оның қалай жұмыс істейтінін сәл кейінірек айтамын.

Нақты мысал:

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

• Біз тәуелсіз көшірмелерді 30 секундта ала аламыз.

Сынақ стендін күтудің қажеті жоқ және оның қаншалықты үлкен екеніне байланысты. Сіз оны бірнеше секундта ала аласыз. Бұл толығымен оқшауланған орталар болады, бірақ деректерді өзара бөліседі.

Бұл тамаша. Мұнда біз сиқыр мен параллель ғалам туралы айтып отырмыз.

Біздің жағдайда бұл OpenZFS жүйесі арқылы жұмыс істейді.

OpenZFS - көшіру-жазуға арналған файлдық жүйе, суретті және клондарды қораптан тыс қолдайды. Бұл сенімді және ауқымды. Оны басқару өте оңай. Оны сөзбе-сөз екі командада орналастыруға болады.

Басқа нұсқалар бар:

• lvm,

• Сақтау (мысалы, Pure Storage).

Мен айтып отырған деректер қоры зертханасы модульдік. Бұл опцияларды қолдану арқылы жүзеге асыруға болады. Бірақ әзірге біз OpenZFS-ке назар аудардық, өйткені LVM-де проблемалар болды.

Бұл қалай жұмыс істейді? Деректерді өзгерткен сайын қайта жазудың орнына, біз бұл жаңа деректер уақыттың жаңа нүктесінен, жаңа суреттен алынғанын белгілеу арқылы оны сақтаймыз.

Болашақта біз кері қайтарғымыз келгенде немесе ескі нұсқадан жаңа клон жасағымыз келгенде, біз жай ғана: «Жарайды, бізге осылай белгіленген деректер блоктарын беріңіз» дейміз.

Және бұл пайдаланушы мұндай деректер жиынтығымен жұмыс істейді. Ол оларды бірте-бірте өзгертеді, өзінің суретін жасайды.

Ал біз саламыз. Біздің жағдайда әрбір әзірлеушіде өзі өңдейтін өз клонына ие болу мүмкіндігі болады және ортақ деректер барлығына ортақ болады.

Мұндай жүйені үйде орналастыру үшін сізге екі мәселені шешу керек:

• Біріншісі - деректер көзі, сіз оны қайдан аласыз. Өндіріспен репликацияны орнатуға болады. Сіз конфигурациялаған сақтық көшірмелерді пайдалана аласыз деп үміттенемін. WAL-E, WAL-G немесе Барман. RDS немесе Cloud SQL сияқты бұлтты шешімнің қандай да бір түрін пайдалансаңыз да, логикалық қоқыстарды пайдалануға болады. Бірақ біз сізге әлі де сақтық көшірмелерді пайдалануды ұсынамыз, өйткені бұл тәсілмен сіз файлдардың физикалық құрылымын сақтайсыз, бұл бар проблемаларды шешу үшін өндірісте көретін көрсеткіштерге жақынырақ болуға мүмкіндік береді.

• Екіншісі - дерекқор зертханасын орналастырғыңыз келетін жер. Бұл бұлтты болуы мүмкін, ол жергілікті болуы мүмкін. Бұл жерде ZFS деректерді қысуды қолдайтынын айту маңызды. Және ол мұны өте жақсы жасайды.

Әрбір осындай клон үшін базамен жасайтын операцияларға байланысты қандай да бір әзірлеуші ​​​​өсетінін елестетіп көріңіз. Бұл үшін әзірлеушіге де орын қажет. Бірақ біз 4,5 терабайт негізді алғандықтан, ZFS оны 3,5 терабайтқа дейін қысады. Бұл параметрлерге байланысты өзгеруі мүмкін. Бізде әлі де әзірлеушілерге орын бар.

Мұндай жүйе әртүрлі жағдайларда қолданылуы мүмкін.

• Бұл әзірлеушілер, сұрауды тексеруге, оңтайландыруға арналған DBA.

• Бұл белгілі бір тасымалдауды біз оны өнімге шығарар алдында тексеру үшін QA тестінде пайдалануға болады. Сондай-ақ біз нақты деректермен QA үшін арнайы орталарды көтере аламыз, онда олар жаңа функционалдылықты тексере алады. Күту сағатының орнына секундтар қажет, ал жұқа көшірмелер пайдаланылмайтын басқа жағдайларда күндер қажет.

• Және тағы бір жағдай. Егер компанияда аналитикалық жүйе орнатылмаған болса, онда біз өнім базасының жұқа клонын бөліп алып, оны ұзақ сұрауларға немесе аналитикада қолдануға болатын арнайы индекстерге бере аламыз.

Бұл тәсілмен:

1. «Өнімдегі» қателердің ықтималдығы төмен, өйткені біз барлық өзгерістерді толық өлшемді деректерде тексердік.

2. Бізде тестілеу мәдениеті қалыптасқан, өйткені қазір өз стендіңізді сағаттап күтудің қажеті жоқ.

3. Ал сынақтар арасында ешқандай кедергі, күту жоқ. Сіз шынымен барып тексере аласыз. Бұл дамуды тездеткен сайын жақсырақ болады.

• Рефакторинг аз болады. Азырақ қателер өнімде аяқталады. Біз оларды кейінірек қайта қарастырамыз.

• Біз қайтымсыз өзгерістерді кері қайтара аламыз. Бұл стандартты тәсіл емес.

1. Бұл тиімді, өйткені біз сынақ алаңдарының ресурстарын бөлісеміз.

Қазірдің өзінде жақсы, бірақ тағы не тездетуге болады?

Осындай жүйенің арқасында біз мұндай тестілеуге кіру шегін айтарлықтай төмендете аламыз.

Енді нақты толық өлшемді деректерге қол жеткізу үшін әзірлеуші ​​сарапшы болуы керек кезде тұйық шеңбер бар. Оған мұндай рұқсатқа сену керек.

Бірақ ол жоқ болса, қалай өсіру керек. Бірақ сізде сынақ деректерінің өте аз жиынтығы болса ше? Сонда сіз нақты тәжірибе алмайсыз.

Бұл шеңберден қалай шығуға болады? Кез келген деңгейдегі әзірлеушілерге ыңғайлы бірінші интерфейс ретінде біз Slack ботын таңдадық. Бірақ бұл кез келген басқа интерфейс болуы мүмкін.

Ол сізге не істеуге мүмкіндік береді? Сіз белгілі бір сұрауды қабылдап, оны дерекқорға арналған арнайы арнаға жібере аласыз. Біз бірнеше секунд ішінде жұқа клонды автоматты түрде орналастырамыз. Осы сұрауды орындайық. Біз көрсеткіштер мен ұсыныстарды жинаймыз. Көрнекілігін көрсетейік. Содан кейін бұл сұрауды қандай да бір жолмен оңтайландыруға, индекстерді қосуға және т.б. болатындай бұл клон қалады.

Сондай-ақ Slack бізге қораптан тыс жұмыс істеуге мүмкіндік береді. Бұл жай ғана арна болғандықтан, сіз осы сұрауды дәл сол жерде осындай сұрауға арналған ағында талқылауды бастай аласыз, әріптестеріңізге, компания ішіндегі DBA-ға пинг жібере аласыз.

Бірақ, әрине, проблемалар бар. Бұл шынайы әлем және біз бірден көптеген клондарды орналастыратын серверді пайдаланып жатқандықтан, клондарға қолжетімді жад көлемін және процессор қуатын қысуымыз керек.

Бірақ бұл сынақтардың сенімді болуы үшін сіз бұл мәселені қандай да бір жолмен шешуіңіз керек.

Маңызды тұсы сол деректер екені анық. Бірақ бізде ол қазірдің өзінде бар. Біз де сол конфигурацияға қол жеткізгіміз келеді. Және біз осындай дерлік бірдей конфигурацияны бере аламыз.

Өндірістегідей жабдыққа ие болғаны жақсы болар еді, бірақ ол әртүрлі болуы мүмкін.

Postgres жадымен қалай жұмыс істейтінін еске түсірейік. Бізде екі кэш бар. Біреуі файлдық жүйеден және бір жергілікті Postgres, яғни ортақ буфер кэшінен.

Конфигурацияда қандай өлшемді көрсеткеніңізге байланысты Postgres іске қосылғанда ортақ буфер кэшінің бөлінетінін ескеру маңызды.

Ал екінші кэш барлық қолжетімді кеңістікті пайдаланады.

Ал бір станокта бірнеше клон жасағанда, жадыны біртіндеп толтыратынымыз белгілі болды. Жақсы мағынада, ортақ буфер кэш құрылғыда қолжетімді жадтың жалпы көлемінің 25% құрайды.

Ал егер бұл параметрді өзгертпесек, онда біз бір машинада тек 4 дананы, яғни барлығы осы жұқа клондардың 4-ін іске қоса алатынымыз белгілі болды. Және бұл, әрине, жаман, өйткені біз олардың көп болғанын қалаймыз.

Бірақ екінші жағынан, буфер кэш индекстерге сұраныстарды орындау үшін пайдаланылады, яғни жоспар біздің кэштеріміздің қаншалықты үлкен екеніне байланысты. Ал егер біз осы параметрді алып, оны азайтатын болсақ, онда біздің жоспарларымыз көп нәрсені өзгертуі мүмкін.

Мысалы, өнімде үлкен кэш болса, Postgres индексті пайдалануды жөн көреді. Егер жоқ болса, SeqScan болады. Ал егер біздің жоспарларымыз сәйкес келмесе, оның мәні неде?

Бірақ бұл жерде біз Postgres-тегі жоспар жоспардағы Ортақ буферде көрсетілген нақты өлшемге тәуелді емес, ол эффективті_кэш_өлшеміне байланысты деген қорытындыға келдік.

Тиімді_кэш_өлшемі - бізге қолжетімді кэштің болжалды көлемі, яғни буфер кэшінің және файлдық жүйе кэшінің қосындысы. Бұл конфигурация арқылы орнатылады. Және бұл жад бөлінбейді.

Осы параметрдің арқасында бізде бұл деректер болмаса да, бізде көптеген деректер бар деп Postgres-ті алдауға болады. Осылайша, жоспарлар өндіріспен толығымен сәйкес келеді.

Бірақ бұл уақытқа әсер етуі мүмкін. Біз сұрауларды уақыт бойынша оңтайландырамыз, бірақ уақыт көптеген факторларға байланысты болуы маңызды:

• Бұл қазіргі уақытта өндірілетін жүктемеге байланысты.

• Бұл машинаның өзіне тән сипаттамаларына байланысты.

Және бұл жанама параметр, бірақ іс жүзінде біз нәтиже алу үшін осы сұрау оқитын деректер көлемі бойынша оңтайландыра аламыз.

Ал егер сіз уақыттың өнімде көретінімізге жақын болуын қаласаңыз, онда барлық клондар сәйкес болуы үшін біз ең ұқсас жабдықты алуымыз керек және, мүмкін, одан да көп. Бірақ бұл ымыраға келу, яғни сіз бірдей жоспарларды аласыз, белгілі бір сұраудың қанша деректер оқитынын көресіз және бұл сұрау жақсы (немесе көшіру) немесе нашар ма деген қорытынды жасай аласыз, оны әлі де оңтайландыру қажет. .

Джоның қалай арнайы оңтайландырылғанын қарастырайық.

Нақты жүйеден сұрауды алайық. Бұл жағдайда деректер қоры 1 терабайтты құрайды. Біз 10-нан астам лайк жинаған жаңа посттардың санын есептегіміз келеді.

Біз арнаға хабарлама жазып жатырмыз, бізге клон орналастырылды. Ал мұндай сұраныс 2,5 минутта аяқталатынын көреміз. Бұл біз байқайтын бірінші нәрсе.

B Joe сізге жоспар мен көрсеткіштерге негізделген автоматты ұсыныстарды көрсетеді.

Жолдардың салыстырмалы түрде аз санын алу үшін сұрау тым көп деректерді өңдейтінін көреміз. Сұрауда сүзілген жолдар тым көп екенін байқағандықтан, қандай да бір мамандандырылған индекс қажет.

Не болғанын егжей-тегжейлі қарастырайық. Шынында да, біз файл кэшінен немесе тіпті дискіден бір жарым гигабайт дерлік деректерді оқығанымызды көреміз. Бұл жақсы емес, өйткені бізде бар болғаны 142 жол бар.

Бұл жерде бізде индексті сканерлеу бар сияқты және тез жұмыс істеу керек еді, бірақ біз тым көп жолдарды сүзгіден өткізгендіктен (біз оларды санауымыз керек еді), сұраныс баяу орындалды.

Бұл сұраудағы шарттар мен индекстегі шарттар жартылай сәйкес келмеуіне байланысты жоспарда орын алды.

Индексті дәлірек етуге тырысайық және одан кейін сұраудың орындалуы қалай өзгеретінін көрейік.

Индексті құру өте ұзақ уақытқа созылды, бірақ қазір біз сұрауды тексеріп, 2,5 минуттың орнына уақыт бар болғаны 156 миллисекунд екенін көреміз, бұл жеткілікті жақсы. Ал біз тек 6 мегабайт деректерді оқимыз.

Енді біз тек индексті сканерлеуді қолданамыз.

Тағы бір маңызды оқиға, біз жоспарды біршама түсінікті түрде ұсынғымыз келеді. Біз Flame Graphs көмегімен визуализацияны жүзеге асырдық.

Бұл басқа сұраныс, одан да күшті. Ал біз жалын графигін екі параметр бойынша құрастырамыз: бұл белгілі бір түйін жоспарда және мерзімде есептелетін деректер көлемі, яғни түйіннің орындалу уақыты.

Мұнда біз нақты түйіндерді бір-бірімен салыстыра аламыз. Және олардың қайсысы көбірек немесе аз алатыны белгілі болады, әдетте оны басқа көрсету әдістерінде орындау қиын.

Әрине, бәрі түсіндіреді.depesz.com. Бұл визуализацияның жақсы ерекшелігі - біз мәтіндік жоспарды сақтаймыз, сонымен қатар сұрыптау үшін кестеге кейбір негізгі параметрлерді енгіземіз.

Бұл тақырыпты әлі зерттемеген әзірлеушілер де түсіндірме.depesz.com сайтын пайдаланады, өйткені олар үшін қандай көрсеткіштер маңызды және қайсысы маңызды емес екенін анықтау оңайырақ.

Визуализацияның жаңа тәсілі бар - бұл description.dalibo.com. Олар ағаш визуализациясын жасайды, бірақ түйіндерді бір-бірімен салыстыру өте қиын. Мұнда сіз құрылымды жақсы түсіне аласыз, алайда үлкен сұраныс болса, алға-артқа айналдыру керек, сонымен қатар опция.

ынтымақтастық

Жоғарыда айтқанымдай, Slack бізге бірлесіп жұмыс істеуге мүмкіндік береді. Мысалы, егер біз қалай оңтайландыру керектігі белгісіз күрделі сұрауға тап болсақ, біз бұл мәселені әріптестерімізбен Slack ағынында түсіндіре аламыз.

Бізге толық өлшемді деректерде тестілеу маңызды болып көрінеді. Ол үшін біз ашық көзде қолжетімді Database Lab жаңарту құралын жасадық. Сіз Джо ботын да пайдалана аласыз. Сіз оны дәл қазір алып, оны өз орныңызда жүзеге асыра аласыз. Барлық гидтер сонда бар.

Сондай-ақ шешімнің өзі революциялық емес екенін атап өткен жөн, өйткені Delphix бар, бірақ бұл кәсіпорын шешімі. Ол толығымен жабық, бұл өте қымбат. Біз Postgres бойынша арнайы маманданамыз. Бұлардың барлығы ашық бастапқы өнімдер. Бізге қосылыңыздар!

Міне, мен аяқтаймын. Рақмет сізге!

Сіздің сұрақтарыңыз

Сәлеметсіз бе! Есеп үшін рахмет! Өте қызық, әсіресе мен үшін, өйткені мен біраз уақыт бұрын сол мәселені шешкенмін. Сондықтан менде көптеген сұрақтар бар. Мен оның кем дегенде бір бөлігін аламын деп үміттенемін.

Қызық, сіз бұл ортаның орнын қалай есептейсіз? Технология белгілі бір жағдайларда сіздің клондарыңыз максималды өлшемге дейін өсе алатынын білдіреді. Шамамен айтқанда, он терабайт дерекқорыңыз және 10 клоныңыз болса, әрбір клонның салмағы 10 бірегей деректер болатын жағдайды имитациялау оңай. Бұл клондар мекен ететін бұл жерді, яғни сіз айтқан атырауды қалай есептейсіз?

Жақсы сұрақ. Мұнда нақты клондарды қадағалау маңызды. Ал егер клонда тым үлкен өзгеріс болса, ол өсе бастайды, содан кейін біз алдымен пайдаланушыға бұл туралы ескерту жасай аламыз немесе сәтсіздікке ұшырамас үшін бұл клонды дереу тоқтата аламыз.

Иә, менің кірістірілген сұрағым бар. Яғни, бұл модульдердің өмірлік циклін қалай қамтамасыз етесіз? Бізде бұл мәселе және бөлек әңгіме бар. Бұл қалай болады?

Әрбір клон үшін біраз ttl бар. Негізінде бізде бекітілген ttl бар.

Құпия болмаса ше?

1 сағат, яғни бос тұру - 1 сағат. Егер ол пайдаланылмаса, біз оны ұрып-соғамыз. Бірақ бұл жерде таңқаларлық ештеңе жоқ, өйткені біз клонды бірнеше секундта көтере аламыз. Егер сізге қайтадан қажет болса, өтінемін.

Мені технологияларды таңдау да қызықтырады, өйткені, мысалы, біз бір немесе басқа себептерге байланысты бірнеше әдістерді қатар қолданамыз. Неліктен ZFS? Неліктен LVM қолданбады? LVM ақаулары бар екенін айттыңыз. Қандай проблемалар болды? Менің ойымша, өнімділік тұрғысынан ең оңтайлы нұсқа сақтаумен.

ZFS негізгі проблемасы неде? Бір хостта жұмыс істеу керек, яғни барлық даналар бір ОЖ ішінде өмір сүреді. Ал сақтау жағдайында әртүрлі жабдықты қосуға болады. Ал кедергі тек сақтау жүйесіндегі блоктар болып табылады. Ал технологияларды таңдау мәселесі қызық. Неліктен LVM емес?

Атап айтқанда, LVM-ді кездесуде талқылай аламыз. Сақтау туралы - бұл жай ғана қымбат. Біз ZFS жүйесін кез келген жерде енгізе аламыз. Оны құрылғыңызда орналастыруға болады. Сіз жай ғана репозиторийді жүктеп алып, оны орналастыра аласыз. Егер Linux туралы айтатын болсақ, ZFS дерлік барлық жерде орнатылған. Яғни, біз өте икемді шешім аламыз. Және қораптан тыс ZFS көп нәрсе береді. Сіз қалағаныңызша деректерді жүктей аласыз, көптеген дискілерді қоса аласыз, суреттер бар. Және, мен айтқанымдай, басқару оңай. Яғни, пайдалану өте жағымды сияқты. Ол сыналады, жасы көп. Оның өсіп келе жатқан өте үлкен қауымдастығы бар. ZFS - өте сенімді шешім.

Николай Самохвалов: Қосымша түсініктеме бере аламын ба? Менің атым Николай, біз Анатолиймен бірге жұмыс істейміз. Сақтау орны керемет екеніне келісемін. Біздің кейбір тұтынушыларымызда Pure Storage және т.

Анатолий модульдікке ден қойғанымызды дұрыс атап өтті. Болашақта сіз бір интерфейсті жүзеге асыра аласыз - суретке түсіру, клон жасау, клонды жою. Бәрі оңай. Ал сақтау өте жақсы, егер ол болса.

Бірақ ZFS барлығына қол жетімді. DelPhix қазірдің өзінде жеткілікті, олардың 300 клиенті бар. Олардың ішінде Fortune 100-де 50 клиент бар, яғни олар NASA-ға бағытталған және т.б. Барлығына бұл технологияны алатын уақыт келді. Сондықтан бізде ашық бастапқы Core бар. Бізде ашық бастапқы код емес интерфейс бөлігі бар. Бұл біз көрсететін платформа. Бірақ біз оның барлығына қолжетімді болғанын қалаймыз. Біз төңкеріс жасағымыз келеді, сонда барлық тестерлер ноутбуктерде болжауды тоқтатады. Біз SELECT жазуымыз керек және оның баяу екенін бірден көруіміз керек. DBA сізге бұл туралы айтуды күтуді тоқтатыңыз. Міне, басты мақсат. Осыған бәріміз де келеміз деп ойлаймын. Және біз бұл нәрсені барлығына ие болу үшін жасаймыз. Сондықтан ZFS, өйткені ол барлық жерде қол жетімді болады. Қауымдастыққа проблемаларды шешкені үшін және ашық бастапқы лицензия бар екендігі үшін рахмет, т.б. *

Сәлем! Есеп үшін рахмет! Менің атым Максим. Біз де сол мәселелермен айналыстық. Олар өз бетінше шешім қабылдады. Осы клондар арасында ресурстарды қалай бөлісесіз? Әрбір клон кез келген уақытта өз ісін жасай алады: біреуі бір нәрсені сынаса, екіншісі басқа, біреу индекс жасайды, біреудің жұмысы ауыр. Егер сіз әлі де CPU, содан кейін IO арқылы бөле алсаңыз, қалай бөлуге болады? Бұл бірінші сұрақ.

Ал екінші мәселе стендтердің бір-біріне ұқсамауында. Айталық, менде ZFS бар және бәрі жақсы, бірақ өнімдегі клиентте ZFS жоқ, мысалы, ext4. Бұл жағдайда қалай?

Сұрақтар өте жақсы. Мен бұл мәселені ресурстарды ортақ пайдалану фактісімен аздап айттым. Ал шешімі мынау. Сіз сахнада сынақтан өтіп жатырсыз деп елестетіңіз. Сізде де бір уақытта біреу бір жүкті, басқа біреуді беретін осындай жағдай болуы мүмкін. Нәтижесінде сіз түсініксіз көрсеткіштерді көресіз. Тіпті бірдей мәселе өнімде болуы мүмкін. Сіз қандай да бір сұрауды тексергіңіз келсе және онымен қандай да бір мәселе бар екенін көргенде - ол баяу жұмыс істейді, онда іс жүзінде мәселе сұрауда емес, параллельді жүктеменің қандай да бір түрі бар екенінде болды.

Сондықтан бұл жерде жоспардың қандай болатынына, жоспарда қандай қадамдар жасайтынымызға және бұл үшін қанша деректер жинайтынымызға назар аудару маңызды. Біздің дискілер, мысалы, бір нәрсемен жүктелетіні, бұл нақты уақытқа әсер етеді. Бірақ біз бұл сұраудың қаншалықты жүктелгенін деректер көлемі бойынша бағалай аламыз. Бір уақытта қандай да бір орындалудың болуы соншалықты маңызды емес.

Менің екі сұрағым бар. Бұл өте керемет нәрсе. Несие картасының нөмірлері сияқты өндіріс деректері маңызды болатын жағдайлар болды ма? Қазірдің өзінде дайын нәрсе бар ма, әлде бұл бөлек тапсырма ма? Екінші сұрақ - MySQL үшін осындай нәрсе бар ма?

Деректер туралы. Жасамайынша, біз күңгірттеу жасаймыз. Бірақ егер сіз дәл Джоны орналастырсаңыз, әзірлеушілерге рұқсат бермесеңіз, деректерге қол жетімділік болмайды. Неліктен? Өйткені Джо деректерді көрсетпейді. Ол тек көрсеткіштерді, жоспарларды көрсетеді және бәрі де солай. Бұл әдейі жасалды, өйткені бұл біздің клиентіміздің талаптарының бірі. Олар барлығына рұқсат бермей-ақ оңтайландыру мүмкіндігін алғысы келді.

MySQL туралы. Бұл жүйе күйді дискіде сақтайтын кез келген нәрсе үшін пайдаланылуы мүмкін. Біз Postgres жасап жатқандықтан, біз қазір Postgres үшін барлық автоматтандыруды жасаймыз. Біз сақтық көшірмеден деректерді алуды автоматтандыруды қалаймыз. Біз Postgres-ті дұрыс конфигурациялап жатырмыз. Біз жоспарларды қалай сәйкестендіру керектігін және т.б.

Бірақ жүйе кеңейтілетін болғандықтан, оны MySQL үшін де пайдалануға болады. Және мұндай мысалдар бар. Яндексте де осындай нәрсе бар, бірақ олар оны еш жерде жарияламайды. Олар оны Yandex.Metrica ішінде пайдаланады. Және MySQL туралы әңгіме бар. Бірақ технологиялар бірдей, ZFS.

Есеп үшін рахмет! Менің де бір-екі сұрағым бар. Сіз клондауды аналитика үшін, мысалы, сол жерде қосымша индекстер құру үшін пайдалануға болатынын айттыңыз. Оның қалай жұмыс істейтіні туралы аздап айтып бере аласыз ба?

Мен бірден екінші сұрақты стендтердің ұқсастығы, жоспарлардың ұқсастығы туралы қоямын. Жоспар Postgres жинаған статистикаға да байланысты. Бұл мәселені қалай шешесіз?

Сараптамаға сәйкес, нақты жағдайлар жоқ, өйткені біз оны әлі пайдаланбадық, бірақ мұндай мүмкіндік бар. Егер біз индекстер туралы айтатын болсақ, онда сұрау жүздеген миллион жазбалары бар кестені және әдетте өнімде индекстелмейтін бағанды ​​қуып келе жатқанын елестетіңіз. Біз сол жерде кейбір деректерді есептегіміз келеді. Егер бұл сұраныс өнімге жіберілсе, онда ол өнімде қарапайым болуы мүмкін, себебі сұрау сол жерде бір минут ішінде өңделеді.

Жарайды, бірнеше минутқа тоқтау қорқынышты емес жұқа клон жасайық. Ал аналитиканы оқуды ыңғайлы ету үшін біз деректерді қызықтыратын бағандарға индекстерді қосамыз.

Индекс әр жолы жасалады ма?

Сіз оны деректерге түртіп, суретке түсіретін етіп жасай аласыз, содан кейін біз осы суретті қалпына келтіреміз және жаңа сұрауларды жүргіземіз. Яғни, сіз оны қазірдің өзінде бекітілген индекстері бар жаңа клондарды көтере алатындай етіп жасай аласыз.

Статистика туралы сұраққа келсек, егер біз сақтық көшірмеден қалпына келтірсек, репликация жасасақ, онда біздің статистикамыз дәл солай болады. Өйткені бізде барлық физикалық деректер құрылымы бар, яғни біз деректерді барлық статистикалық көрсеткіштермен бірге әкелетін боламыз.

Міне, тағы бір мәселе. Егер сіз бұлтты шешімді пайдалансаңыз, онда тек логикалық қоқыс бар, өйткені Google, Amazon физикалық көшірмені алуға мүмкіндік бермейді. Проблема болады.

Есеп үшін рахмет. Мұнда MySQL және ресурстарды ортақ пайдалану туралы екі жақсы сұрақ болды. Бірақ, шын мәнінде, мұның бәрі бұл нақты ДҚБЖ тақырыбы емес, жалпы файлдық жүйенің тақырыбы екеніне байланысты. Тиісінше, ресурстарды бөлісу мәселелері де Postgres емес, файлдық жүйеде, мысалы, серверде шешілуі керек.

Менің сұрағым сәл басқаша. Ол көп деңгейлі мәліметтер базасына жақынырақ, мұнда бірнеше қабаттар бар. Мысалы, біз он терабайттық кескінді жаңартуды орнаттық, біз көшіріп жатырмыз. Және біз бұл шешімді дерекқорлар үшін арнайы қолданамыз. Көшіру орындалуда, деректер жаңартылуда. Мұнда 100 қызметкер параллель жұмыс істейді, олар үнемі осы әртүрлі кадрларды іске қосады. Не істеу? Ешқандай қақтығыс жоқ екеніне, олар біреуін іске қосқанына, содан кейін файлдық жүйе өзгергеніне және бұл суреттердің барлығы кеткеніне қалай көз жеткізуге болады?

Олар бармайды, өйткені ZFS осылай жұмыс істейді. Репликацияға байланысты болатын файлдық жүйе өзгерістерін бір ағында бөлек сақтай аламыз. Әзірлеушілер деректердің ескі нұсқаларында пайдаланатын клондарды сақтаңыз. Және бұл біз үшін жұмыс істейді, бәрі осыған сәйкес келеді.

Жаңарту қосымша қабат ретінде орын алады және барлық жаңа суреттер осы қабатқа негізделген, солай емес пе?

Алдыңғы көшірмелердегі алдыңғы қабаттардан.

Алдыңғы қабаттар құлап қалады, бірақ олар ескі қабатқа сілтеме жасайды және жаңартуда қабылданған соңғы қабаттан жаңа кескіндерді қабылдай ма?

Жалпы, иә.

Нәтижесінде бізде інжір қабатына дейін болады. Және уақыт өте келе оларды қысу керек пе?

Иә бәрі дұрыс. Біраз терезе бар. Біз апта сайынғы суреттерді сақтаймыз. Бұл сізде қандай ресурс бар екеніне байланысты. Егер сізде көп деректерді сақтау мүмкіндігі болса, суретті ұзақ уақыт сақтауға болады. Олар өз бетімен кетпейді. Деректердің бүлінуі болмайды. Егер суреттер бізге көрінетіндей ескірген болса, яғни бұл компаниядағы саясатқа байланысты болса, біз оларды жай ғана жойып, орынды босатамыз.

Сәлем, есеп үшін рахмет! Джо туралы сұрақ. Сіз тұтынушы деректерге барлығына рұқсат бергісі келмейтінін айттыңыз. Қатаң айтқанда, егер адамда Explain Analyze нәтижесі болса, ол деректерді көре алады.

Дәл солай. Мысалы, біз былай жаза аламыз: "SELECT FROM WHERE email = to that". Яғни, біз деректердің өзін көрмейміз, бірақ кейбір жанама белгілерді көре аламыз. Мұны түсіну керек. Бірақ екінші жағынан, бәрі бар. Бізде журнал аудиті бар, бізде әзірлеушілердің не істеп жатқанын көретін басқа әріптестер де бар. Ал егер біреу мұны істемек болса, онда қауіпсіздік қызметі оларға келіп, осы мәселемен айналысады.

Қайырлы күн! Есеп үшін рахмет! Менің қысқаша сұрағым бар. Егер компания Slack қолданбаса, қазір оған қандай да бір міндеттеме бар ма, әлде әзірлеушілер сынақ қосымшасын дерекқорларға қосу үшін даналарды орналастыруы мүмкін бе?

Енді Slack-ке сілтеме бар, яғни басқа мессенджер жоқ, бірақ мен басқа мессенджерлерге де қолдау көрсеткім келеді. Сіз не істей аласыз? Сіз ДБ зертханасын Джосыз орналастыра аласыз, REST API көмегімен немесе біздің платформаның көмегімен жүре аласыз және клондар жасай аласыз және PSQL арқылы қосыла аласыз. Бірақ мұны әзірлеушілерге деректерге рұқсат беруге дайын болсаңыз, жасауға болады, себебі енді ешқандай экран болмайды.

Маған бұл қабат қажет емес, бірақ маған мұндай мүмкіндік керек.

Сонда иә, мұны жасауға болады.

Ақпарат көзі: www.habr.com