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

Backend иштеп чыгуучусу SQL сурамынын "проддо" жакшы иштей турганын кантип түшүнөт? Ири же тез өнүгүп жаткан компанияларда "продукцияга" ар ким эле жете бербейт. Ал эми жеткиликтүүлүк менен, бардык суроо-талаптар оорутпай текшерилиши мүмкүн эмес, жана маалымат базасынын көчүрмөсүн түзүү көп сааттарды талап кылат. Бул көйгөйлөрдү чечүү үчүн биз жасалма DBA түздүк - Джо. Ал буга чейин бир нече компанияларда ийгиликтүү ишке ашырылган жана ондон ашык иштеп чыгуучуларга жардам берет.

Videos:

Баарына салам! Менин атым Анатолий Стэнслер. Мен бир компанияда иштейм postgres.ai. Биз иштеп чыгуучулардан, DBAлардан жана QAлардан Postgres ишине байланыштуу кечигүүлөрдү алып салуу менен иштеп чыгуу процессин тездетүүгө умтулабыз.

Биздин мыкты кардарларыбыз бар жана бүгүн отчеттун бир бөлүгү биз алар менен иштөөдө жолуккан учурларга арналат. Мен аларга олуттуу маселелерди чечүүгө кандайча жардам бергенибиз жөнүндө айтып берем.

Биз татаал жүктүү миграцияны иштеп чыгып, жасап жатканыбызда өзүбүзгө: “Бул миграция күчөйбү?” деген суроону беребиз. Биз карап чыгууну колдонобуз, биз тажрыйбалуу кесиптештердин, DBA эксперттеринин билимдерин колдонобуз. Ал эми учуп кетеби же учпайбы деп айта алышат.

Бирок, балким, биз аны толук көлөмдөгү нускаларда өзүбүз сынап көрсөк жакшы болмок. Ал эми бүгүн биз тестирлөөнүн кандай жолдору бар жана аны кантип жакшыраак жана кандай куралдар менен жасаса болору жөнүндө сүйлөшөбүз. Ошондой эле биз мындай ыкмалардын оң жана терс жактары жана бул жерде эмнени оңдой аларыбыз жөнүндө сүйлөшөбүз.

Ким түздөн-түз өндүрүшкө индекстерди жасаган же кандайдыр бир өзгөртүүлөрдү киргизген? Бир аз. Ал эми бул маалыматтардын жоголушуна же иштебей калууга алып келди? Анда сен бул ооруну билесиң. Кудайга шүгүр, резервдер бар.

Биринчи ыкма өндүрүштө тестирлөө болуп саналат. Же болбосо, иштеп чыгуучу жергиликтүү машинада отурганда, анын тесттик маалыматтары бар, кандайдыр бир чектелген тандоо бар. Жана биз өндүрүшкө чыгабыз, жана биз ушундай кырдаалга туш болобуз.

Бул ооруйт, кымбат. Болбогону жакшыдыр.

Жана аны жасоонун эң жакшы жолу кайсы?

Келгиле, сахналаштырууну алалы жана ал жерде проддун бир бөлүгүн тандап алалы. Же эң жакшы дегенде, чыныгы продюсерди, бардык маалыматтарды алалы. Ал эми биз аны жергиликтүү деңгээлде иштеп чыккандан кийин, биз кошумча түрдө сахналаштырууну текшеребиз.

Бул бизге каталардын айрымдарын алып салууга, башкача айтканда, аларды иштеп чыгууга жол бербөөгө мүмкүндүк берет.

Кандай көйгөйлөр бар?

• Маселе, биз бул инсценировканы кесиптештерибиз менен бөлүшөбүз. Жана көп учурда сиз кандайдыр бир өзгөрүүлөрдү жасайсыз, бам - жана эч кандай маалымат жок, иш ылдыйда. Сахналоо көп терабайт болгон. Анан кайра көтөрүлүш үчүн көпкө күтүш керек. Ал эми эртең аны жыйынтыктайлы деп чечтик. Болду, бизде өнүгүү бар.
• Анан, албетте, ал жерде биздин көптөгөн кесиптештерибиз, көптөгөн командалар иштешет. Жана аны кол менен жасоо керек. Жана бул ыңгайсыз.

Ал эми маалымат базасына кандайдыр бир өзгөртүүлөрдү киргизип, маалыматтарга тийип, структурасын өзгөртөлү десек, бизде бир гана аракет, бир ок бар экенин айтууга болот. А эгер бир нерсе туура эмес болуп кетсе, миграцияда ката болсо, анда биз тез эле артка жылбайбыз.

Бул мурунку ыкмага караганда жакшыраак, бирок дагы эле кандайдыр бир ката өндүрүшкө кетип калуу ыктымалдыгы жогору.

Ар бир иштеп чыгуучуга тесттик стендди, толук көлөмдөгү көчүрмөнү берүүгө бизге эмне тоскоолдук кылат? Эмне тоскоол болуп жатканы түшүнүктүү деп ойлойм.

Кимде терабайттан чоңураак маалымат базасы бар? Бөлмөнүн жарымынан көбү.

Ал эми мындай ири өндүрүш болгондо ар бир иштеп чыгуучуга станокторду кармоо абдан кымбатка турганы, анын үстүнө көп убакытты талап кылаары түшүнүктүү.

Бизде бардык өзгөртүүлөр толук көлөмдөгү көчүрмөлөрдү сынап көрүү абдан маанилүү экенин түшүнгөн кардарларыбыз бар, бирок алардын маалымат базасы терабайттан аз жана ар бир иштеп чыгуучу үчүн тесттик стендди сактоо үчүн ресурстар жок. Ошондуктан, алар таштандыларды жергиликтүү өз машинасына жүктөп алып, ушундай жол менен сынап көрүшү керек. Бул көп убакытты талап кылат.

Эгер сиз муну инфраструктуранын ичинде жасасаңыз да, саатына бир терабайт маалыматты жүктөп алуу абдан жакшы. Бирок алар логикалык таштандыларды колдонушат, алар булуттан жергиликтүү түрдө жүктөп алышат. Алар үчүн ылдамдыгы саатына болжол менен 200 гигабайт. Логикалык таштандыдан айлануу, индекстерди жыйноо жана башкалар үчүн дагы деле убакыт керек.

Бирок алар бул ыкманы колдонушат, анткени бул продюсерди ишенимдүү сактоого мүмкүндүк берет.

Бул жерде эмне кылсак болот? Келгиле, сыноо отургучтарын арзан кылалы жана ар бир иштеп чыгуучуга өзүнүн тест стендисин берели.

Жана бул мүмкүн.

Жана бул ыкмада, биз ар бир иштеп чыгуучу үчүн ичке клондорду жасаганда, аны бир машинада бөлүшө алабыз. Мисалы, сизде 10ТБ маалымат базасы бар болсо жана аны 10 иштеп чыгуучуга бергиңиз келсе, сизде XNUMX х XNUMXТБ маалымат базасы болушунун кереги жок. Ар бир иштеп чыгуучу үчүн бир машинанын жардамы менен ичке обочолонгон көчүрмөлөрдү жасоо үчүн бир гана машина керек. Анын кантип иштээрин бир аздан кийин айтып берем.

Чыныгы мисал:

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

• Биз 30 секунданын ичинде көз карандысыз көчүрмөлөрдү ала алабыз.

Сыноо үчүн стендди күтүүнүн кереги жок жана анын канчалык чоң экенине көз каранды. Сиз аны секунданын ичинде ала аласыз. Бул толугу менен обочолонгон чөйрөлөр болот, бирок маалыматтарды өз ара бөлүшөт.

Бул сонун. Бул жерде биз сыйкыр жана параллелдүү аалам жөнүндө сөз болуп жатат.

Биздин учурда, бул OpenZFS системасын колдонуу менен иштейт.

OpenZFS - бул кутудан алынган сүрөттөрдү жана клондорду колдогон жазууга көчүрүү файл системасы. Бул ишенимдүү жана масштабдуу болуп саналат. Аны башкаруу абдан оңой. Бул түзмө-түз эки командада жайгаштырылышы мүмкүн.

Башка варианттар бар:

• lvm,

• Сактоо (мисалы, Pure Storage).

Мен айтып жаткан маалыматтар базасы лабораториясы модулдук. Бул параметрлерди колдонуу менен ишке ашырылышы мүмкүн. Бирок азыр биз OpenZFSге басым жасадык, анткени LVM менен көйгөйлөр бар болчу.

Бул кандай иштейт? Дайындарды өзгөрткөн сайын кайра жазуунун ордуна, биз жөн гана бул жаңы дайындар убакыттын жаңы учурунан, жаңы көз ирмемдик сүрөт экенин белгилеп, аны сактап калабыз.

Келечекте, биз артка кайткыбыз келгенде же эски версиядан жаңы клон жасагыбыз келгенде, биз жөн гана айтабыз: "Макул, бизге ушул сыяктуу белгиленген маалымат блокторун бергиле."

Жана бул колдонуучу мындай маалымат топтому менен иштейт. Ал акырындык менен аларды өзгөртүп, өзүнүн сүрөтүн жасайт.

А биз бутактайбыз. Биздин учурда ар бир иштеп чыгуучу түзөтүүчү өзүнүн клонуна ээ болуу мүмкүнчүлүгүнө ээ болот жана бөлүшүлгөн маалыматтар бардыгына бөлүшүлөт.

Үйдө мындай системаны жайылтуу үчүн эки маселени чечүү керек:

• Биринчиси, маалыматтын булагы, сиз аны кайдан аласыз. Сиз өндүрүш менен репликацияны орното аласыз. Сиз конфигурациялаган камдык көчүрмөлөрдү колдоно аласыз, мен үмүттөнөм. WAL-E, WAL-G же Барман. Эгер сиз RDS же Cloud SQL сыяктуу булуттун кандайдыр бир түрүн колдонуп жатсаңыз да, логикалык таштандыларды колдоно аласыз. Бирок биз сизге дагы эле резервдик көчүрмөлөрдү колдонууну сунуштайбыз, анткени бул ыкма менен сиз файлдардын физикалык структурасын сактап каласыз, бул бар болгон көйгөйлөрдү чечүү үчүн өндүрүштө көрө турган метрикага жакыныраак болууга мүмкүндүк берет.

• Экинчиси, маалымат базасы лабораториясын өткөргүңүз келген жер. Бул Булут болушу мүмкүн, ал On-premise болушу мүмкүн. Бул жерде ZFS маалыматтарды кысуу колдойт деп айтуу маанилүү. Жана аны абдан жакшы кылат.

Элестеткиле, ар бир ушундай клон үчүн, биз база менен жасаган операцияларга жараша, кандайдыр бир dev өсөт. Бул үчүн, dev да орун керек болот. Бирок биз 4,5 терабайт базаны алгандыктан, ZFS аны 3,5 терабайтка чейин кысып коёт. Бул жөндөөлөргө жараша өзгөрүшү мүмкүн. Бизде дагы деле иштеп чыгуучу орун бар.

Мындай система ар кандай учурларда колдонулушу мүмкүн.

• Булар иштеп чыгуучулар, суроо-талаптарды текшерүү, оптималдаштыруу үчүн DBAлар.

• Бул белгилүү бир миграцияны биз аны өндүрүшкө чыгарардан мурун текшерүү үчүн QA тестинде колдонсо болот. Ошондой эле биз жаңы функцияларды сынай турган реалдуу маалыматтар менен QA үчүн атайын чөйрөлөрдү түзө алабыз. Ал күтүү сааттын ордуна секунддарды талап кылат, ал эми жука нускалар колдонулбаган башка учурларда, балким, күндөр талап кылынат.

• Жана дагы бир окуя. Эгерде компанияда аналитика системасы орнотулган жок болсо, анда биз продукт базасынын жука клонун бөлүп алып, аны аналитикада колдонула турган узун сурамдарга же атайын индекстерге бере алабыз.

Бул ыкма менен:

1. "Прод" боюнча каталардын аз ыктымалдыгы, анткени биз толук өлчөмдөгү маалыматтар боюнча бардык өзгөртүүлөрдү сынап көрдүк.

2. Бизде тестирлөө маданияты бар, анткени азыр өзүңүздүн стендиңизди сааттап күтүүнүн кереги жок.

3. Жана эч кандай тоскоолдук, тесттердин ортосунда күтүү жок. Сиз чындап барып текшере аласыз. Жана биз өнүгүүнү тездеткен сайын бул жакшыраак болот.

• Рефакторинг азыраак болот. Продукцияда азыраак мүчүлүштүктөр пайда болот. Биз аларды кийинчерээк азыраак рефакциялайбыз.

• Биз кайтарылгыс өзгөрүүлөрдү артка кайтара алабыз. Бул стандарттуу мамиле эмес.

1. Бул пайдалуу, анткени биз тесттик стенддердин ресурстарын бөлүшөбүз.

Азыртадан эле жакшы, бирок дагы эмнени тездетсе болот?

Мындай системанын аркасында биз мындай тестирлөөгө өтүү босогосун бир топ кыскарта алабыз.

Азыр иштеп чыгуучу чыныгы толук көлөмдөгү маалыматтарга жетүү үчүн эксперт болушу керек болгон катаал чөйрө бар. Ал мындай мүмкүнчүлүккө ишенүү керек.

Бирок ал жок болсо кантип өстүрөт. Бирок, эгер сизде сыноо маалыматтарынын өтө кичинекей топтому бар болсочы? Ошондо сиз эч кандай чыныгы тажрыйба ала албайсыз.

Бул чөйрөдөн кантип чыгуу керек? Ар кандай деңгээлдеги иштеп чыгуучулар үчүн ыңгайлуу болгон биринчи интерфейс катары биз Slack ботун тандап алдык. Бирок бул башка интерфейс болушу мүмкүн.

Бул сизге эмне кылууга мүмкүндүк берет? Сиз белгилүү бир суроону алып, маалымат базасы үчүн атайын каналга жөнөтө аласыз. Биз секунданын ичинде жука клонду автоматтык түрдө жайгаштырабыз. Келгиле, бул өтүнүчтү аткаралы. Биз көрсөткүчтөрдү жана сунуштарды чогултабыз. Келгиле, визуализация көрсөтөлү. Анан бул клон бул суроону кандайдыр бир жол менен оптималдаштыруу, индекстерди кошуу үчүн калат.

Ошондой эле Slack бизге кутудан тышкары кызматташууга мүмкүнчүлүк берет. Бул жөн гана канал болгондуктан, сиз бул суроону дал ошол жерден ушундай суроо үчүн жипте талкуулап, кесиптештериңизге, компаниянын ичиндеги DBAларга пинг жөнөтө аласыз.

Бирок, албетте, көйгөйлөр бар. Бул чыныгы дүйнө жана биз бир эле учурда көптөгөн клондорду жайгаштырган серверди колдонуп жаткандыктан, клондор үчүн жеткиликтүү эстутумдун көлөмүн жана CPU күчүн кысуу керек.

Бирок бул тесттер ишеничтүү болушу үчүн, кандайдыр бир жол менен бул маселени чечүү керек.

Маанилүү жагдай ошол эле маалыматтар экени түшүнүктүү. Бирок бизде буга чейин эле бар. Жана биз ошол эле конфигурацияга жетүүнү каалайбыз. Жана биз ушундай дээрлик бирдей конфигурация бере алабыз.

Өндүрүштөгүдөй эле аппараттык жабдыктарга ээ болуу сонун болмок, бирок ал айырмаланышы мүмкүн.

Келгиле, Postgres эстутум менен кантип иштээрин эстеп көрөлү. Бизде эки кэш бар. Бир файл тутумунан жана бир түпкү Postgres, б.а. Shared Buffer Cache.

Белгилей кетчү нерсе, бөлүшүлгөн буфер кэш конфигурацияда кандай өлчөмдө көрсөткөнүңүзгө жараша Postgres башталганда бөлүнөт.

Ал эми экинчи кэш бардык жеткиликтүү мейкиндикти колдонот.

Ал эми бир станокто бир нече клон жасаганыбызда эстутумду акырындык менен толтурат экенбиз. Жана жакшы жол менен, Shared Buffer Cache машинада жеткиликтүү эс тутумдун жалпы көлөмүнүн 25% түзөт.

Ал эми бул параметрди өзгөртпөсөк, анда биз бир машинада 4 гана инстанцияны, башкача айтканда, мындай жука клондордун 4үн гана иштете алабыз. Жана бул, албетте, жаман, анткени биз алардын көп болушун каалайбыз.

Бирок, экинчи жагынан, буфер кэш индекстерге суроо-талаптарды аткаруу үчүн колдонулат, башкача айтканда, план биздин кэштерибиздин канчалык чоң экендигине жараша болот. Ал эми биз жөн эле бул параметрди алып, аны азайтсак, анда биздин пландар көп өзгөрүшү мүмкүн.

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

Бирок бул жерден биз Postgresтеги план пландагы Бөлүшүлгөн буферде көрсөтүлгөн конкреттүү өлчөмдөн көз каранды эмес, эффективдүү_кеш_өлчөмүнөн көз каранды деген жыйынтыкка келдик.

Effective_cache_size – бул биз үчүн жеткиликтүү болгон кэштин болжолдуу көлөмү, б.а. Буфер кэшинин жана файл тутумунун кэшинин суммасы. Бул конфигурация тарабынан орнотулган. Жана бул эс бөлүнгөн эмес.

Жана ушул параметрден улам биз Postgresти алдап, бизде бул маалыматтар жок болсо дагы, бизде көптөгөн маалыматтар бар деп айта алабыз. Ошентип, пландар өндүрүш менен толук дал келет.

Бирок бул убакытка таасир этиши мүмкүн. Ал эми биз сурамдарды убакыт боюнча оптималдаштырабыз, бирок убакыт көп факторлорго көз каранды болушу маанилүү:

• Бул учурда өндүрүлгөн жүккө жараша болот.

• Бул машинанын өзүнүн өзгөчөлүктөрүнө жараша болот.

Жана бул кыйыр параметр, бирок чындыгында биз натыйжаны алуу үчүн бул сурам окуй турган маалыматтардын көлөмү боюнча так оптималдаштыра алабыз.

Жана эгер сиз убакыттын биз өндүрүштө көрүүчүгө жакын болушун кааласаңыз, анда биз эң окшош жабдыктарды алышыбыз керек жана, балким, бардык клондор туура келиши үчүн. Бирок бул компромисс, башкача айтканда, сиз ошол эле пландарды аласыз, белгилүү бир суроо канча маалымат окуй турганын көрөсүз жана бул суроо жакшы (же миграция) же жаманбы деген жыйынтыкка келе аласыз, аны дагы эле оптималдаштыруу керек. .

Келгиле, Джо кантип оптималдашканын карап көрөлү.

Келгиле, реалдуу системадан өтүнүчтү алалы. Бул учурда маалымат базасы 1 терабайтты түзөт. Жана биз 10дон ашык жактырган жаңы посттордун санын санагыбыз келет.

Биз каналга билдирүү жазып жатабыз, биз үчүн клон жайгаштырылды. Ал эми мындай өтүнүч 2,5 мүнөттө бүтөөрүн көрөбүз. Бул биз байкаган биринчи нерсе.

Б Джо сизге планга жана метрикага негизделген автоматтык сунуштарды көрсөтөт.

Салыштырмалуу аз сандагы саптарды алуу үчүн сурам өтө көп маалыматтарды иштетээрин көрөбүз. Жана кандайдыр бир адистештирилген индекс керек, анткени биз суроодо чыпкаланган саптар өтө көп экенин байкадык.

Келгиле, эмне болгонун кененирээк карап чыгалы. Чынында эле, биз файл кэшинен же ал тургай дисктен дээрлик бир жарым гигабайт маалыматтарды окуганыбызды көрүп жатабыз. Ал эми бул жакшы эмес, анткени 142 гана сап алдык.

Жана, бул жерде бизде индексти сканерлөө бар жана тез эле иштеп чыгышы керек окшойт, бирок биз өтө көп саптарды чыпкалагандыктан (биз аларды санашыбыз керек болчу), суроо акырындык менен ишке ашты.

Ал эми бул суроодогу шарттар менен индекстеги шарттар жарым-жартылай дал келбегендиктен планда болду.

Келгиле, индексти тактоого аракет кылалы жана андан кийин сурамдын аткарылышы кандай өзгөрөрүн көрөлү.

Индексти түзүү бир топ убакытты талап кылды, бирок азыр биз суроону текшерип, 2,5 мүнөттүн ордуна убакыт болгону 156 миллисекундду түзөөрүн көрүп жатабыз, бул жетиштүү жакшы. Ал эми биз болгону 6 мегабайт маалыматтарды окуйбуз.

Ал эми азыр биз индексти гана сканерден колдонобуз.

Дагы бир маанилүү окуя, биз планды түшүнүктүүраак кылып көрсөткүбүз келет. Биз Flame Graphs аркылуу визуализацияны ишке ашырдык.

Бул башка өтүнүч, катуураак. Жана биз Flame Graphics эки параметр боюнча курабыз: бул белгилүү бир түйүн планда жана убакытта эсептелген маалыматтардын көлөмү, б.а. түйүндүн аткарылуу убактысы.

Бул жерде биз бири-бири менен белгилүү түйүндөрдү салыштырууга болот. Жана алардын кайсынысы аздыр-көптүр талап кылынары айкын болот, бул адатта башка көрсөтүү ыкмаларында кыйын.

Албетте, ар бир адам description.depesz.com билет. Бул визуализациянын жакшы өзгөчөлүгү - биз текст планын сактап, ошондой эле сорттоо үчүн кээ бир негизги параметрлерди таблицага киргизебиз.

Жана бул теманы изилдей элек иштеп чыгуучулар да түшүндүрүү.depesz.com сайтын колдонушат, анткени аларга кайсы метрика маанилүү жана кайсынысы маанилүү эмес экенин аныктоо оңой.

Визуализацияга жаңы ыкма бар - бул explain.dalibo.com. Алар дарактын визуализациясын жасашат, бирок түйүндөрдү бири-бири менен салыштыруу абдан кыйын. Бул жерде сиз структурасын жакшы түшүнө аласыз, бирок, эгерде чоң суроо-талап болсо, анда алдыга жана артка жылдыруу керек болот, бирок ошондой эле вариант.

кызматташуу

Жана мен айткандай, Slack бизге кызматташууга мүмкүнчүлүк берет. Мисалы, кантип оптималдаштыруу керектиги түшүнүксүз болгон татаал суроого туш болсок, биз бул маселени кесиптештерибиз менен Slackдеги жипте тактап алсак болот.

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

Бул чечимдин өзү революциялык эмес экенин белгилей кетүү маанилүү, анткени Delphix бар, бирок бул ишкана чечими. Ал толугу менен жабык, бул абдан кымбат. Биз өзгөчө Postgres боюнча адистешкен. Булардын баары ачык булак продуктулары. Бизге кошул!

Мына ушул жерден бүтүрөм. Рахмат!

суроолор

Салам! Баяндама үчүн рахмат! Мен үчүн абдан кызыктуу, анткени мен бир нече убакыт мурун бир эле маселени чечтим. Ошондуктан менде бир топ суроолор бар. Мен анын жок дегенде бир бөлүгүн алам деп үмүттөнөм.

Кызык, бул чөйрөнүн ордун кантип эсептейсиз? Технология белгилүү бир шарттарда сиздин клондоруңуз максималдуу өлчөмдө өсө алат дегенди билдирет. Болжол менен айтканда, эгер сизде он терабайт маалымат базасы жана 10 клон болсо, анда ар бир клондун салмагы 10 уникалдуу маалымат болгон кырдаалды окшоштуруу оңой. Бул клондор жашай турган бул жерди, б.а. сиз айткан дельтаны кантип эсептейсиз?

Жакшы суроо. Бул жерде конкреттүү клондорду эсепке алуу маанилүү. Ал эми клондо кандайдыр бир өтө чоң өзгөрүү болсо, ал өсө баштаса, анда биз адегенде колдонуучуга бул тууралуу эскертүү бере алабыз же катачылыкка учурабаш үчүн бул клонду дароо токтотсок болот.

Ооба, менин суроом бар. Башкача айтканда, бул модулдардын жашоо циклин кантип камсыз кыласыз? Бизде бул көйгөй жана өзүнчө окуя бар. Бул кантип болот?

Ар бир клон үчүн бир аз ttl бар. Негизинен бизде туруктуу ттл бар.

Жашыруун болбосо эмне болот?

1 саат, башкача айтканда бош жүрүү - 1 саат. Эгерде ал колдонулбаса, анда биз аны ургулайбыз. Бирок бул жерде таң калыштуу эч нерсе жок, анткени биз клонду секунданын ичинде көтөрө алабыз. А эгер сизге кайра керек болсо, сураныч.

Мен дагы технологияларды тандоого кызыгам, анткени, мисалы, биз тигил же бул себептерден улам параллелдүү бир нече ыкмаларды колдонобуз. Эмне үчүн ZFS? Эмне үчүн LVM колдонгон жоксуз? Сиз LVM менен көйгөйлөр бар экенин айттыңыз. Кандай көйгөйлөр болду? Менин оюмча, эң оптималдуу вариант сактоо менен, аткаруу жагынан.

ZFS менен негизги көйгөй эмнеде? Сиз бир эле хостто иштешиңиз керек, башкача айтканда, бардык инстанциялар бир ОС ичинде жашайт. Ал эми сактоо учурда, ар кандай жабдууларды туташтыра аласыз. Ал эми кыйынчылык - бул сактоо тутумунда турган блоктор. Ал эми технологияларды тандоо маселеси кызыктуу. Эмне үчүн LVM эмес?

Тактап айтканда, LVMди жолугушууда талкуулай алабыз. сактоо жөнүндө - бул жөн гана кымбат. Биз ZFS системасын каалаган жерде ишке ашыра алабыз. Сиз аны машинаңызга орното аласыз. Сиз жөн гана репозиторийди жүктөп алып, аны жайылта аласыз. Эгерде биз Linux жөнүндө сөз кыла турган болсок, ZFS дээрлик бардык жерде орнотулган. Башкача айтканда, биз абдан ийкемдүү чечим алабыз. Жана ZFS өзү кутудан көп берет. Каалаганыңызча маалыматтарды жүктөй аласыз, көп сандагы дисктерди туташтыра аласыз, сүрөттөр бар. Мен айткандай, башкаруу оңой. Башкача айтканда, колдонуу абдан жагымдуу көрүнөт. Сыналган, жашы көп. Анын өсүп келе жаткан абдан чоң жамааты бар. ZFS абдан ишенимдүү чечим болуп саналат.

Николай Самохвалов: Мен дагы комментарий бере аламбы? Менин атым Николай, биз Анатолий менен чогуу иштейбиз. Сактагыч абдан жакшы экенине кошулам. Ал эми биздин кардарлардын кээ бир Pure Storage ж.б.

Модулдуулукка багыт алганыбызды Анатолий туура белгиледи. Ал эми келечекте сиз бир интерфейсти ишке ашыра аласыз - сүрөт тартуу, клон жасоо, клонду жок кылуу. Мунун баары оңой. Ал эми сактоо салкын, эгерде ал.

Бирок ZFS бардыгы үчүн жеткиликтүү. DelPhix буга чейин эле жетиштүү, алардын 300 кардарлары бар. Алардын ичинен Fortune 100 50 кардары бар, б.а. алар НАСАга багытталган, ж.б.. Бул технологияны ар бир адам алууга убакыт келди. Мына ошондуктан бизде ачык булактуу Core бар. Бизде ачык булак эмес интерфейс бөлүгү бар. Бул биз көрсөтө турган платформа. Бирок биз анын бардыгына жеткиликтүү болушун каалайбыз. Бардык тестирлөөчүлөр ноутбуктарда болжолдоону токтотушу үчүн биз революция жасагыбыз келет. Биз SELECT жазып, анын жай экенин дароо көрүшүбүз керек. DBA бул жөнүндө айтып беришин күтүүнү токтотуңуз. Мына негизги максат. Ошондо баарыбыз ушуга келебиз деп ойлойм. Жана биз муну ар бир адам үчүн жасайбыз. Ошондуктан ZFS, анткени ал бардык жерде жеткиликтүү болот. Коомчулукка көйгөйлөрдү чечкени жана ачык булак лицензиясы болгондугу үчүн рахмат, ж.б.

салам! Баяндама үчүн рахмат! Менин атым Максим. Ошол эле маселелерди чечтик. Алар өздөрү чечишти. Бул клондордун ортосунда ресурстарды кантип бөлүшөсүз? Ар бир клон каалаган убакта өз ишин жасай алат: бирөө бир нерсени сынайт, экинчиси башкасын, кимдир бирөө индексти түзөт, бирөөнүн жумушу оор. Эгерде сиз дагы эле CPU, анан IO боюнча бөлө алсаңыз, кантип бөлөсүз? Бул биринчи суроо.

Ал эми экинчи суроо трибунанын окшош эместигине байланыштуу. Айталы, менде ZFS бар жана баары сонун, бирок продюсердеги кардарда ZFS жок, мисалы, ext4. Бул учурда кантип?

Суроолор абдан жакшы. Мен бул көйгөйдү биз ресурстарды бөлүшүү менен бир аз айттым. Жана чечим бул. Сиз сахнада сынап жатканыңызды элестетиңиз. Сизде да ушундай кырдаал бир убакта болушу мүмкүн, кимдир бирөө бир жүк, башка бирөө берет. Натыйжада, сиз түшүнүксүз көрсөткүчтөрдү көрөсүз. Ал тургай, ошол эле көйгөй продукт менен болушу мүмкүн. Кайсы бир өтүнүчтү текшергиңиз келгенде жана анда кандайдыр бир көйгөй бар экенин көргөнүңүздө - ал жай иштейт, демек, чындыгында маселе суроо-талапта эмес, кандайдыр бир параллелдүү жүктүн бар экендигинде болгон.

Ошондуктан, бул жерде план кандай болот, планда кандай кадамдарды жасайбыз жана бул үчүн канча маалыматтарды чогултабыз дегенге көңүл буруу маанилүү. Биздин дисктер, мисалы, бир нерсе менен жүктөлөт, бул өзгөчө убакытка таасир этет. Бирок биз бул сурам канчалык жүктөлгөнүн маалыматтын көлөмү боюнча баалай алабыз. Ошол эле учурда кандайдыр бир өлүмдүн болушу өтө маанилүү эмес.

Менин эки суроом бар. Бул абдан сонун нерсе. Кредиттик карта номерлери сыяктуу өндүрүштүк маалыматтар маанилүү болгон учурлар болду беле? Буга чейин даяр нерсе барбы же бул өзүнчө ишпи? Ал эми экинчи суроо - MySQL үчүн ушундай нерсе барбы?

Маалыматтар жөнүндө. Антмайынча, баш аламандык жасайбыз. Бирок, эгер сиз Джоду так жайгаштырсаңыз, иштеп чыгуучуларга мүмкүнчүлүк бербесеңиз, анда маалыматтарга мүмкүнчүлүк жок. Неге? Анткени Джо маалыматтарды көрсөтпөйт. Бул көрсөткүчтөрдү, пландарды гана көрсөтөт жана ушуну менен бүттү. Бул атайын жасалган, анткени бул биздин кардарыбыздын талаптарынын бири. Алар баарына мүмкүнчүлүк бербестен оптималдаштырууну каалашкан.

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

Бирок система кеңейтилүүчү болгондуктан, аны MySQL үчүн да колдонсо болот. Жана мындай мисалдар бар. Яндексте ушуга окшош нерсе бар, бирок алар аны эч жерде жарыялашпайт. Алар аны Yandex.Metrica ичинде колдонушат. Жана жөн гана MySQL жөнүндө окуя бар. Бирок технологиялар бирдей, ZFS.

Баяндама үчүн рахмат! Менин дагы бир эки суроом бар. Сиз клондоштуруу аналитика үчүн колдонулушу мүмкүн экенин айттыңыз, мисалы, ал жерде кошумча индекстерди түзүү. Анын кантип иштээри жөнүндө бир аз көбүрөөк айтып бере аласызбы?

Ал эми стенддердин окшоштугу, пландардын окшоштугу тууралуу экинчи суроону дароо берем. План Postgres чогулткан статистикага да көз каранды. Бул маселени кантип чечесиз?

Аналитика боюнча конкреттүү учурлар жок, анткени биз аны пайдалана элекпиз, бирок мындай мүмкүнчүлүк бар. Эгерде биз индекстер жөнүндө сөз кыла турган болсок, анда суроо жүз миллиондогон жазуулардан турган таблицаны жана адатта өндүрүштө индекстелбеген тилкени кууп жатканын элестетиңиз. Ал эми биз ал жерде кээ бир маалыматтарды эсептеп келет. Эгерде бул суроо-талап өндүрүшкө жөнөтүлсө, анда ал өндүрүштө жөнөкөй болушу мүмкүн, анткени сурам ошол жерде бир мүнөткө иштетилет.

Макул, келгиле, бир нече мүнөткө токтоп калуу коркунучтуу эмес жука клон жасайлы. Жана аналитиканы окуу ыңгайлуураак болушу үчүн, биз маалыматтарга кызыккан тилкелерге индекстерди кошобуз.

индекс ар бир жолу түзүлөт?

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

Статистика жөнүндө суроого келсек, эгерде биз резервдик көчүрмөдөн калыбына келтирсек, репликация кылсак, анда биздин статистикабыз так ошондой болот. Анткени бизде бүт физикалык маалымат структурасы бар, башкача айтканда, биз маалыматтарды бардык статистикалык көрсөткүчтөр менен кошо алып келебиз.

Бул жерде дагы бир көйгөй бар. Эгер сиз булуттук чечимди колдонсоңуз, анда логикалык таштандылар гана бар, анткени Google, Amazon сизге физикалык көчүрмөнү алууга жол бербейт. көйгөй болот.

Отчет үчүн рахмат. Бул жерде MySQL жана ресурстарды бөлүшүү жөнүндө эки жакшы суроолор бар эле. Бирок, чындыгында, мунун баары бул конкреттүү DBMS темасы эмес, бүтүндөй файл тутумунун темасы экенине байланыштуу. Демек, ресурстарды бөлүшүү маселелери да Postgres эмес, файл тутумунда, серверде, мисалы, ошол жерден чечилиши керек.

Менин суроом бир аз башкача. Ал көп катмарлуу маалымат базасына жакыныраак, анда бир нече катмар бар. Мисалы, биз он терабайттык сүрөт жаңыртуусун орноттук, биз кайталап жатабыз. Жана биз бул чечимди атайын маалымат базалары үчүн колдонобуз. Репликация жүрүп жатат, маалыматтар жаңыртылууда. Бул жерде параллелдүү иштеген 100 кызматкер бар, алар тынымсыз бул түрдүү кадрларды ишке киргизишет. Эмне кылуу керек? Эч кандай чыр-чатактын жок экенине, алар бирин ишке киргизгенине, анан файл системасы өзгөргөнүнө жана бул сүрөттөрдүн баары кеткенине кантип ынануу керек?

Алар барышпайт, анткени ZFS ушундай иштейт. Репликациядан улам келип чыккан файл тутумундагы өзгөрүүлөрдү бир жипте өзүнчө сактай алабыз. Жана иштеп чыгуучулар маалыматтардын эски версияларында колдонгон клондорду сактаңыз. Ал эми бул биз үчүн иштейт, баары ушуга ылайыктуу.

Көрсө, жаңыртуу кошумча катмар катары ишке ашат жана бардык жаңы сүрөттөр ушул катмардын негизинде кетет, туурабы?

Мурунку репликациялардан болгон мурунку катмарлардан.

Мурунку катмарлар түшүп калат, бирок алар эски катмарга кайрылышат жана жаңыртууда кабыл алынган акыркы катмардан жаңы сүрөттөрдү тартабы?

Жалпысынан алганда, ооба.

Андан кийин, биз бир инжирге чейин катмарга ээ болобуз. Ал эми убакыттын өтүшү менен алар кысуу керек болот?

Ооба баары туура. Бир аз терезе бар. Биз жума сайын сүрөттөрдү сактап турабыз. Бул сизде кандай ресурс бар экенине жараша болот. Эгерде сизде көп маалыматтарды сактоо мүмкүнчүлүгү бар болсо, анда сиз сүрөттү узак убакытка сактай аласыз. Алар өз алдынча кетишпейт. Маалыматтын бузулушу болбойт. Эгерде көз ирмемдик сүрөттөр бизге көрүнгөндөй эскирип калса, башкача айтканда, бул компаниядагы саясатка байланыштуу болсо, анда биз аларды жөн эле жок кылып, орун бошотсок болот.

Салам, отчет үчүн рахмат! Джо жөнүндө суроо. Сиз кардар бардыгына маалыматтарга мүмкүнчүлүк берүүнү каалабагандыгын айттыңыз. Тактап айтканда, эгер адам Explain Analyze натыйжасына ээ болсо, анда ал маалыматтарды карап көрө алат.

Ушундай. Мисалы, биз жаза алабыз: "SELECT FROM WHERE email = to that". Башкача айтканда, биз маалыматтардын өзүн көрбөйбүз, бирок кээ бир кыйыр белгилерин көрө алабыз. Муну түшүнүү керек. Бирок, экинчи жагынан, баары бар. Бизде журналдын аудити бар, бизде иштеп чыгуучулардын эмне кылып жатканын көрүп турган башка кесиптештерибиз бар. А эгер кимдир бирөө ушуга аракет кылса, анда коопсуздук кызматы аларга келип, бул маселенин үстүнөн иштейт.

Кутмандуу күнүң менен! Баяндама үчүн рахмат! Менин кыска суроом бар. Эгерде компания Slack'ти колдонбосо, анда ага азыр кандайдыр бир милдеттүүлүк барбы же иштеп чыгуучулар тесттик тиркемени маалымат базасына туташтыруу үчүн инстанцияларды жайылта алабы?

Азыр Slack'ке шилтеме бар, башкача айтканда, башка мессенджер жок, бирок мен башка мессенджерлерге да колдоо көрсөткүм келет. Сиз эмне кыла аласыз? Сиз ДБ лабораториясын Джосуз жайгаштыра аласыз, REST API же биздин платформанын жардамы менен барып, клондорду түзүп, PSQL менен туташа аласыз. Бирок, эгерде сиз иштеп чыгуучуларыңызга маалыматтарга мүмкүнчүлүк берүүгө даяр болсоңуз болот, анткени мындан ары экран болбойт.

Мага бул катмардын кереги жок, бирок мага ушундай мүмкүнчүлүк керек.

Анда ооба, кылса болот.

Source: www.habr.com