Алыскы келечекте керексиз маалыматтарды автоматтык түрдө жок кылуу СУБДнун маанилүү милдеттеринин бири болуп калат [1]. Ошол эле учурда, биз өзүбүз керексиз маалыматтарды жок кылуу же арзаныраак сактоо тутумдарына жылдыруу жөнүндө кам көрүшүбүз керек. Сиз бир нече миллион саптарды жок кылууну чечтиңиз дейли. Айрыкча шарт белгилүү болсо жана ылайыктуу индекс бар болсо, бир кыйла жөнөкөй тапшырма. "DELETE FROM table1 WHERE col1 = :value" - эмне жөнөкөй болушу мүмкүн, туурабы?
Videos:
-
Мен биринчи курстан бери, башкача айтканда 2007-жылдан бери Highload программасынын комитетиндемин.
-
Мен Postgres менен 2005-жылдан бери иштейм. Аны көптөгөн долбоорлордо колдонгон.
-
2007-жылдан бери RuPostges менен группа.
-
Meetup'та биз 2100+ катышуучуга жеттик. Бул дүйнөдө Нью-Йорктон кийинки экинчи орунда турат, Сан-Франциско узак убакыт бою басып өткөн.
-
Мен Калифорнияда бир нече жылдан бери жашайм. Мен америкалык компаниялар, анын ичинде ири компаниялар менен көбүрөөк иштешем. Алар Postgresтин активдүү колдонуучулары. Жана ар кандай кызыктуу нерселер бар.
менин компаниям. Биз өнүгүүнүн басаңдоосун жок кылган милдеттерди автоматташтыруу менен алектенебиз.
Эгер сиз бир нерсе кылып жатсаңыз, анда кээде Postgresтин айланасында кандайдыр бир сайгычтар болот. Админ сиз үчүн тест стенди орнотушун күтүшүңүз керек же DBA сизге жооп беришин күтүшүңүз керек дейли. Жана биз иштеп чыгуу, тестирлөө жана башкаруу процессинде мындай тоскоолдуктарды таап, аларды автоматташтыруу жана жаңы ыкмалардын жардамы менен жоюуга аракет кылабыз.
Мен жакында Лос-Анжелестеги VLDBде болдум. Бул маалымат базалары боюнча эң чоң конференция. Ал эми келечекте МББ гана сактабастан, маалыматтарды автоматтык түрдө жок кыла тургандыгы тууралуу маалымат бар болчу. Бул жаңы тема.
Зеттабайттар дүйнөсүндө уламдан-улам көбүрөөк маалыматтар бар - бул 1 000 000 петабайт. Ал эми азыр бизде дүйнөдө сакталган 100 зеттабайттан ашык маалымат бар экени болжолдонууда. Ал эми алардын саны барган сайын көбөйүүдө.
Жана аны менен эмне кылуу керек? Аны алып салуу керек экени анык. Бул кызыктуу баяндамага шилтеме. Бирок ушул убакка чейин МБМде бул ишке ашырыла элек.
Акчаны санай алгандар эки нерсени каалашат. Алар бизди жок кылышыбызды каалашат, андыктан техникалык жактан биз муну кыла алышыбыз керек.
Мен мындан ары айта турган нерсе - бул бир топ реалдуу кырдаалдарды камтыган абстракттуу жагдай, башкача айтканда, мага жана анын тегерегиндеги маалымат базаларына көп жолу, көп жылдар бою эмне болгон нерселердин бир түрү. Тырмоолор бардык жерде жана ар ким аларды дайыма басып турат.
Бизде база же бир нече база өсүп жатат дейли. Ал эми кээ бир жазуулар, албетте, таштанды. Мисалы, колдонуучу ал жерде бир нерсе кыла баштады, бирок аны аягына чыгарган жок. Ал эми бир нече убакыт өткөндөн кийин, биз бул бүтпөгөн мындан ары сактоо мүмкүн эмес экенин билебиз. Башкача айтканда, мейкиндикти үнөмдөө, ишти жакшыртуу, ж.б.у.с. үчүн кээ бир таштандыларды тазалагыбыз келет.
Жалпысынан алганда, кандайдыр бир таблицадагы конкреттүү нерселерди, конкреттүү сызыктарды алып салууну автоматташтыруу милдети турат.
Ал эми бизде бүгүн айта турган мындай өтүнүч бар, башкача айтканда, таштанды чыгаруу боюнча.
Тажрыйбалуу иштеп чыгуучудан муну талап кылдык. Ал бул өтүнүчтү кабыл алды, өзү текшерди - баары иштейт. Сахнада сыналган - баары жакшы. Чыгылган - баары иштейт. Күнүнө бир жолу иштетебиз – баары жакшы.
Маалымат базасы өсөт жана өсөт. Күнүмдүк DELETE бир аз жайыраак иштей баштайт.
Андан кийин биз азыр маркетинг компаниябыз бар экенин түшүнөбүз жана трафик бир нече эсе көп болот, ошондуктан биз керексиз нерселерди убактылуу токтотууну чечтик. Жана кайра унутуп.
Бир нече айдан кийин алар эстеди. Жана ал иштеп чыгуучу чыгып кетти же башка нерсе менен алек болсо, башкага аны кайтарууну тапшырды.
Ал иштеп чыгууну, коюуну текшерди - баары жакшы. Албетте, сиз дагы эле топтолгон нерселерди тазалашыңыз керек. Ал баарын текшерди.
Андан кийин эмне болот? Ошондо биз үчүн баары ыдырап кетет. Ал кандайдыр бир учурда баары кулап түшө тургандай төмөндөйт. Баары шок абалда, эмне болуп жатканын эч ким түшүнбөйт. Анан иш ушул ДЕЛЕТЕде экен.
Бир жерден ката кеттиби? Бул жерде ката болушу мүмкүн болгон тизмеси. Булардын кайсынысы эң маанилүү?
-
Мисалы, эч кандай кароо болгон эмес, б.а. DBA эксперти аны караган эмес. Тажрыйбалуу көз менен көйгөйдү дароо табат жана андан тышкары, ал бир нече миллион линиялар топтолгон продюсерге кире алат.
-
Балким, алар бир нерсени туура эмес текшеришкендир.
-
Балким, жабдык эскирген жана бул базаны жаңыртуу керек.
-
Же маалымат базасында бир нерсе туура эмес, биз Postgresтен MySQLге өтүшүбүз керек.
-
Же операцияда катачылык бардыр.
-
Балким, ишти уюштурууда катачылыктар болуп, кимдир-бирөөнү жумуштан кетирип, мыктыларды жумушка алуу керекпи?
DBA текшерүүсү болгон эмес. Эгерде DBA болгондо, ал бул бир нече миллион саптарды көрмөк жана эч кандай экспериментсиз эле: "Алар андай кылышпайт" деп айтмак. Айталы, эгер бул код GitLab, GitHubда болсо жана кодду карап чыгуу процесси болмок жана DBAнын макулдугусуз бул операция продукцияда ишке ашат деген нерсе жок болсо, анда DBA мындай дейт: "Муну жасоо мүмкүн эмес. .”
Жана ал сизде дисктин IO менен көйгөйлөрү пайда болот жана бардык процесстер жинди болуп калат, кулпулар болушу мүмкүн, ошондой эле сиз автовакуумду бир нече мүнөткө бөгөттөйсүз деп айтат, андыктан бул жакшы эмес.
Экинчи ката - туура эмес жерден текшеришкен. Продукцияда көптөгөн керексиз маалыматтар топтолгонунан кийин көрдүк, бирок иштеп чыгуучунун бул маалымат базасында маалыматы жок жана сахналаштыруу учурунда бул таштандыны эч ким жараткан эмес. Ошого жараша 1 линия тез эле иштелип чыккан.
Биздин тесттер алсыз экенин түшүнөбүз, башкача айтканда, курулган процесс көйгөйлөрдү кармабайт. Адекваттуу DB эксперименти жүргүзүлгөн эмес.
Идеалдуу эксперимент ошол эле жабдууларда жүргүзүлөт. Муну бир эле жабдууда жасоо дайыма эле мүмкүн боло бербейт, бирок ал маалымат базасынын толук көлөмдүү көчүрмөсү болушу абдан маанилүү. Бул мен бир нече жылдан бери кабар айтып келе жатам. Анан бир жыл мурун мен бул тууралуу айткан элем, мунун баарын YouTubeдан көрө аласыз.
Мүмкүн биздин жабдуулар начардыр? Эгер карасаңыз, күтүү убактысы секирип кетти. Пайдалануу 100% экенин көрдүк. Албетте, бул заманбап NVMe дисктер болсо, анда, балким, биз үчүн бир топ жеңил болмок. А балким, биз андан баш тартмакпыз.
Эгер сизде булут бар болсо, анда жаңыртуу ошол жерде оңой жасалат. Жаңы жабдыктарда жаңы репликалар көтөрүлдү. өтүү. Ошондо баары жакшы. Абдан оңой.
Кандайдыр бир жол менен кичине дисктерге тийсе болобу? Жана бул жерде, жөн гана DBA жардамы менен, биз текшерүү пунктун тюнинг деп аталган белгилүү бир темага кирип жатабыз. Көрсө, бизде постту тюнинг болгон эмес.
текшерүү пункту деген эмне? Бул ар кандай DBMS бар. Эстутумда өзгөргөн маалыматтар болгондо, ал дароо дискке жазылбайт. Маалыматтар өзгөргөндүгү тууралуу маалымат алгач алдын ала жазуу журналына жазылат. Жана кайсы бир учурда, DBMS чыныгы барактарды дискке таштоого убакыт келди деп чечет, ошондуктан бизде катачылык болсо, биз азыраак REDO жасай алабыз. Бул оюнчук сыяктуу. Өлтүрсөк, оюнду акыркы чекиттен баштайбыз. Жана бардык DBMS аны ишке ашырат.
Postgresтин жөндөөлөрү артта калып жатат. Алар 10-15 жылдык маалыматтар жана транзакциялар үчүн иштелип чыккан. Ал эми көзөмөл-өткөрүү пункту да четте калбайт.
Бул жерде биздин Postgres текшерүү отчетунан алынган маалымат, б.а. автоматтык ден соолук текшерүү. Ал эми бул жерде бир нече терабайттын кээ бир базасы. Ал эми дээрлик 90% учурларда мажбурлап өткөрүү пункттары экенин жакшы көрүүгө болот.
Бул эмнени билдирет? Ал жерде эки жөндөө бар. Текшерүү пункту тайм-аут менен келиши мүмкүн, мисалы, 10 мүнөттөн кийин. Же бир топ маалыматтар толтурулганда келип чыгышы мүмкүн.
Ал эми демейки боюнча max_wal_saze 1 гигабайтка коюлган. Чынында, бул Postgresте 300-400 мегабайттан кийин болот. Сиз ушунчалык көп маалыматтарды өзгөрттүңүз жана текшерүү пунктуңуз ишке ашат.
Ал эми аны эч ким жөндөбөсө, сервис өсүп, компания көп киреше тапса, анда транзакциялар көп болсо, анда пост мүнөтүнө бир жолу, кээде 30 секунд сайын келип, кээде бири-бирин кайталайт. Бул абдан жаман.
Жана биз анын азыраак келишине ынанышыбыз керек. Башкача айтканда, биз max_wal_size көтөрө алабыз. Анан азыраак келип калат.
Бирок, биз аны кантип туурараак кылуу керек, башкача айтканда, конкреттүү маалыматтарга таянуу менен орнотууларды тандоо жөнүндө чечимди кантип кабыл алуу керектиги боюнча бүтүндөй методологияны иштеп чыктык.
Ушуга ылайык, биз маалымат базалары боюнча эки катар эксперименттерди жасап жатабыз.
Биринчи серия - биз max_wal_size өзгөртөбүз. Анан биз чоң операция жасап жатабыз. Биринчиден, биз аны 1 гигабайттын демейки жөндөөсүндө жасайбыз. Жана биз миллиондогон саптарды массалык DELETE жасайбыз.
Бул биз үчүн кандай оор экенин көрүүгө болот. Биз дисктин IO абдан начар экенин көрүп жатабыз. Биз канча WAL жаратканыбызды карайбыз, анткени бул абдан маанилүү. Карап көрөлү, пост канча жолу болду. Ал эми жакшы эмес экенин көрүп жатабыз.
Кийинки биз max_wal_size көбөйтөт. Биз кайталайбыз. Көбөйтөбүз, кайталайбыз. Жана көп жолу. Негизи 10 упай жакшы, мында 1, 2, 4, 8 гигабайт. Жана биз белгилүү бир системанын жүрүм-турумун карайбыз. Бул жерде жабдуулар продукциядагыдай болушу керек экени түшүнүктүү. Сизде бирдей дисктер, бирдей көлөмдөгү эс тутум жана ошол эле Postgres орнотуулары болушу керек.
Жана ушундай жол менен биз системабызды алмаштырабыз, жана биз ДББ начар массалык DELETE болгон учурда өзүн кандай алып барарын билебиз, ал текшерүү пункту кандай болорун билебиз.
Орусча айтканда, өткөрмө пункттары өткөрмө пункттары.
Мисал: бир нече миллион саптарды индекс боюнча DELETE, саптар беттер боюнча "чачырап" кеткен.
Бул жерде бир мисал. Бул кандайдыр бир база. Ал эми max_wal_size үчүн 1 гигабайт демейки жөндөө менен, биздин дисктер жаздыруу үчүн текчеге барары айкын көрүнүп турат. Бул сүрөт өтө оорулуу бейтаптын мүнөздүү белгиси, башкача айтканда, ал өзүн чындап эле жаман сезген. Жана бир эле операция болгон, жөн гана бир нече миллион саптарды DELETE болгон.
Эгерде мындай операцияга өндүрүштө уруксат берилсе, анда биз жөн эле жата беребиз, анткени бир DELETE бизди текчеде өлтүрөрү анык.
Андан ары, кайда 16 гигабайт, ал тиштери мурунтан эле кеткени көрүнүп турат. Тиш жакшыраак, башкача айтканда, биз шыпты тыкылдатып жатабыз, бирок анчалык деле жаман эмес. Ал жерде кандайдыр бир эркиндик бар болчу. Оң жакта жазуу. Ал эми операциялардын саны - экинчи график. Ал эми 16 гигабайт болгондо бир аз жеңилирээк дем алып жатканыбыз анык.
Ал эми 64 гигабайт бул толугу менен жакшырып калганын көрүүгө болот. Азыртадан эле тиштер айтылат, башка операциялардан аман калуу жана диск менен бир нерсе кылуу үчүн көбүрөөк мүмкүнчүлүктөр бар.
Эмнеге андай?
Мен майда-чүйдөсүнө чейин бир аз тереңдеп чыгам, бирок бул тема, текшерүү пунктун кантип тууралоо керек, бүтүндөй отчетту алып келиши мүмкүн, андыктан мен көп жүктөбөйм, бирок кандай кыйынчылыктар бар экенин бир аз айтып берем.
Эгерде текшерүү пункту өтө тез-тез болуп турса жана биз сызыктарыбызды ырааттуу эмес, индекс боюнча табабыз, бул жакшы, анткени биз бүт таблицаны жок кылбайбыз, анда алгач биз биринчи баракка, андан кийин миңинчисине тийип калышыбыз мүмкүн. анан биринчисине кайтып келди. Ал эми биринчи барактын ортосунда текшерүү пункту аны дискке сактап койгон болсо, анда ал аны кайра сактап калат, анткени биз аны экинчи жолу булгадык.
Жана биз текшерүү пунктун көп жолу сактап калууга мажбурлайбыз. Кантип ага ашыкча операциялар болмок.
Бирок бул баары эмес. Барактар Postgresте 8 килобайт жана Linuxта 4 килобайт. Жана full_page_writes параметри бар. Ал демейки боюнча иштетилген. Ал эми бул туура, анткени аны өчүрүп койсок, анда ал бузулуп калса, барактын жарымы гана сакталып калуу коркунучу бар.
Алдыңкы журналдын WALга жазуу жүрүм-туруму ушундай: бизде текшерүү пункту болгондо жана биз баракты биринчи жолу өзгөрткөндө, биз жөн гана өзгөрткөнүбүзгө карабастан, бүт барак, б.а., бардык 8 килобайт алдыга журналга кирет. 100 байт салмактагы линия. Жана биз баракты толугу менен жазып алышыбыз керек.
Кийинки өзгөрүүлөрдө белгилүү бир кортеж гана болот, бирок биз биринчи жолу бардыгын жазып жатабыз.
Демек, текшерүү пункту дагы кайталанган болсо, анда биз баарын нөлдөн баштап, бүт бетти түртүшүбүз керек. Тез-тез текшерүү пункттары менен, биз бир эле барактарды басып өткөндө, full_page_writes = on болушу мүмкүн болгондон көп болот, б.а. биз көбүрөөк WAL түзөбүз. Көбүрөөк көчүрмөлөргө, архивге, дискке жөнөтүлөт.
Ал эми, ошого жараша бизде эки кыскартуу бар.
Эгерде биз max_wal_size көлөмүн көбөйтсөк, анда биз текшерүү пунктуна да, wal жазуучуга да жеңилдейбиз. Жана бул сонун.
Келгиле, терабайтка салып, аны менен жашайлы. Мунун эмнеси жаман? Бул жаман, анткени иштен чыгып калса, биз сааттап чыгабыз, анткени өткөрүү пункту көп убакыт мурун болгон жана көп нерсе өзгөргөн. Жана биз мунун баарын REDO кылышыбыз керек. Ошентип, биз эксперименттердин экинчи сериясын жасайбыз.
Биз операция жасайбыз жана текшерүү пункту качан бүтөөрүн көрөбүз, биз атайын -9 Postgres өлтүрөбүз.
Ошондон кийин биз аны кайра баштайбыз жана ал бул жабдууда канчага чейин көтөрүлөрүн, б.а. бул жаман кырдаалда канча REDO болоорун көрөбүз.
Абал начар экенин эки жолу белгилейм. Биринчиден, биз пост бүтө электе эле кырсыкка учурадык, андыктан жогото турган нерселерибиз көп. Экинчиден, бизде массалык операция болду. Ал эми текшерүү пункттары күтүү убактысында болсо, анда, кыязы, акыркы өткөрүү пунктунан бери WAL азыраак түзүлмөк. Башкача айтканда, бул эки эсе жеңилүү болуп саналат.
Биз мындай кырдаалды ар кандай max_wal_size өлчөмдөрү үчүн өлчөйбүз жана эгер max_wal_size 64 гигабайт болсо, анда эки эсе начар учурда биз 10 мүнөткө көтөрүлөбүз деп түшүнөбүз. Ал эми бизге туура келеби же жокпу деп ойлойбуз. Бул бизнес суроо. Биз бул сүрөттү бизнес чечимдерине жооптуу адамдарга көрсөтүп, “Бир маселе жаралса, эң көп канча убакыт жата алабыз? Эң жаман абалда 3-5 мүнөт жатып алсак болобу? Жана сиз чечим чыгарасыз.
Бул жерде бир кызыктуу жагдай бар. Конференцияда Патрони жөнүндө бир нече баяндамабыз бар. А балким сиз аны колдонуп жаткандырсыз. Бул Postgres үчүн autofailover болуп саналат. Бул тууралуу GitLab жана Data Egret сүйлөштү.
Эгер сизде 30 секундадан кийин автоматтык түрдө өчүрүү болсо, анда биз 10 мүнөт жатып алабызбы? Анткени биз ушул убакка чейин репликага өтөбүз, баары жакшы болот. Бул талаштуу жагдай. Мен так жооп билбейм. Мен жөн гана бул тема аварияны калыбына келтирүү жөнүндө гана эмес деп ойлойм.
Эгерде биз ийгиликсиздиктен кийин узак калыбына келсек, анда биз башка көптөгөн кырдаалдарда ыңгайсыз болобуз. Мисалы, ошол эле эксперименттерде, биз бир нерсе кылып, кээде 10 мүнөт күтүүгө туура келет.
Мен дагы деле алыска бармак эмесмин, атүгүл бизде автоматтык түрдө өчүрүү бар. Эреже катары, 64, 100 гигабайт сыяктуу баалуулуктар жакшы баалуулуктар болуп саналат. Кээде ал азыраак тандоо да арзырлык. Жалпысынан алганда, бул тымызын илим.
Итерацияларды жасоо үчүн, мисалы, max_wal_size =1, 8, массалык операцияны көп жолу кайталашыңыз керек. Сиз жасадыңыз. Жана ошол эле базада сиз муну кайра кылгыңыз келет, бирок сиз бардыгын жок кылгансыз. Эмне кылуу керек?
Чечимибиз, мындай жагдайларда кайталануу үчүн эмне кылабыз, мен кийинчерээк сүйлөшөм. Жана бул эң туура мамиле.
Бирок бул учурда биздин жолубуз болду. Эгерде бул жерде айтылгандай "БАШТАЛУУ, ӨЧҮРҮҮ, КАЙТЫРУУ" болсо, анда биз ЖОК КЫЛУУну кайталай алабыз. Башкача айтканда, өзүбүз жокко чыгарган болсок, кайра кайталай алабыз. Жана физикалык жактан сизде маалыматтар бир жерде болот. Сиз эч кандай шишик да албайт. Мындай DELETEлерди кайталай аласыз.
Бул ROLLBACK менен DELETE текшерүү пунктун жөндөө үчүн идеалдуу, эгер сизде туура орнотулган маалымат базасы лабораториялары жок болсо да.
Бир «и» мамычасы бар табак жасадык. Postgresтин пайдалуу тилкелери бар. Атайын суралмайынча алар көрүнбөйт. Булар: ctid, xmid, xmax.
Ctid физикалык дарек болуп саналат. Нөл барак, беттеги биринчи кортеж.
ROOLBACK кийин кортеж ошол эле жерде калганын көрүүгө болот. Башкача айтканда, биз дагы бир жолу аракет кылсак болот, ал дагы ошондой болот. Бул башкысы.
Xmax - кортеждин өлүү убактысы. Мөөр басылган, бирок Postgres транзакциянын артка кайтарылганын билет, андыктан ал 0 болобу же артка кайтарылган транзакциябы айырмасы жок. Бул DELETE үстүнөн кайталоо жана системанын жүрүм-турумунун жапырт операцияларын текшерүү мүмкүн экенин көрсөтүп турат. Сиз кедейлер үчүн маалымат базасы лабораторияларын түзө аласыз.
Бул программисттер жөнүндө. DBA жөнүндө да, алар дайыма программисттерди бул үчүн урушушат: "Эмне үчүн мынчалык узак жана татаал операцияларды жасап жатасыңар?". Бул такыр башка перпендикуляр тема. Мурда башкаруу болгон, азыр өнүгүү болот.
Албетте, биз майдаланып кеткен жокпуз. Бул түшүнүктүү. Миллиондогон саптардын үймөгү үчүн мындай DELETEди бөлбөй коюу мүмкүн эмес. Бул 20 мүнөттө жасалат, баары жатып калат. Бирок, тилекке каршы, атүгүл тажрыйбалуу иштеп чыгуучулар да абдан чоң компанияларда ката кетиришет.
Эмне үчүн бузуу маанилүү?
-
Эгер диск катуу экенин көрсөк, анда аны жайлайлы. Эгерде биз бузулуп калсак, анда тыныгууларды кошуп, дроссельди басаңдата алабыз.
-
Ал эми башкаларга көпкө чейин бөгөт койбойбуз. Кээ бир учурларда маанилүү эмес, эгер сиз эч ким иштебеген чыныгы таштандыны жок кылып жатсаңыз, анда сиз автовакуумдан башка эч кимди блоктобойсуз, анткени ал транзакциянын аягына чыгышын күтөт. Бирок, эгер сиз башка бирөө сурай турган нерсени алып салсаңыз, анда алар бөгөттөлөт, кандайдыр бир чынжыр реакциясы болот. Вебсайттарда жана мобилдик тиркемелерде узак транзакциялардан качуу керек.
Бул кызыктуу. Мен иштеп чыгуучулар: "Кандай пакеттин өлчөмүн тандашым керек?" деп сураганын көп көрөм.
Пачканын өлчөмү канчалык чоң болсо, транзакциянын кошумча чыгымдары, б.а., транзакциялардан түшкөн кошумча чыгымдар ошончолук аз болору түшүнүктүү. Бирок, ошол эле учурда, бул бүтүм үчүн убакыт көбөйөт.
Менде абдан жөнөкөй эреже бар: мүмкүн болушунча көп алыңыз, бирок секундасына аткарылуучу файлдарды ашпаңыз.
Эмне үчүн бир секунд? Түшүндүрмө өтө жөнөкөй жана баарына түшүнүктүү, атүгүл техникалык эмес адамдарга да. Биз реакцияны көрүп жатабыз. 50 миллисекундду алалы. Эгер бир нерсе өзгөргөн болсо, анда биздин көзүбүз реакция кылат. Эгер азыраак болсо, анда кыйыныраак. Эгер бир нерсе 100 миллисекунддан кийин жооп берсе, мисалы, сиз чычканды чыкылдатсаңыз жана ал сизге 100 миллисекунддан кийин жооп берсе, сиз буга чейин эле бир аз кечигүүнү сезесиз. Секунд мурунтан эле тормоз катары кабыл алынат.
Ошого жараша массалык операцияларыбызды 10 секунддук жарылууларга бөлсөк, анда биз кимдир бирөөгө бөгөт коюу коркунучу бар. Жана ал бир нече секунд иштейт, жана адамдар буга чейин эле байкашат. Ошондуктан, мен бир секунддан ашык кылбаганды жакшы көрөм. Бирок, ошол эле учурда, транзакциянын кошумча чыгымдары байкаларлык болот, анткени, аны абдан майдалап эмес. База кыйыныраак болуп, башка ар кандай көйгөйлөр жаралышы мүмкүн.
Биз пакеттин өлчөмүн тандайбыз. Ар бир учурда биз аны башкача кыла алабыз. Автоматташтырылышы мүмкүн. Ал эми биз бир пакетти кайра иштетүүнүн натыйжалуулугуна ынандык. Башкача айтканда, биз бир пакетти DELETE же UPDATE жасайбыз.
Баса, мен айтып жаткандардын баары ЖӨЛҮҮ жөнүндө гана эмес. Сиз ойлогондой, бул маалыматтар боюнча кандайдыр бир жапырт операциялар.
Ал эми пландын мыкты экенин көрүп жатабыз. Сиз индексти скандоону көрө аласыз, индексти гана сканерлөө андан да жакшы. Ал эми бизде аз сандагы маалыматтар бар. Ал эми бир секунддан азыраак аткарылат. Супер.
Анан дагы деградация болбошуна ынанышыбыз керек. Биринчи пакеттер тез эле иштеп, андан кийин начарлап, начарлап, начарлайт. Процесс ушунчалык көп сыноо керек. Дал ушул маалымат базасы лабораториялары үчүн.
Ал эми биз дагы эле бир нерсени даярдашыбыз керек, бул өндүрүштө муну туура жолго салууга мүмкүндүк берет. Мисалы, журналга убакытты жаза алабыз, азыр кайда экенибизди жана азыр кимди өчүргөнүбүздү жаза алабыз. Жана бул бизге кийин эмне болуп жатканын түшүнүүгө мүмкүндүк берет. Жана бир нерсе туура эмес болуп калса, көйгөйдү тез табыңыз.
Эгерде биз сурамдардын натыйжалуулугун текшеришибиз керек болсо жана биз көп жолу кайталашыбыз керек болсо, анда бот сыяктуу нерсе бар. Ал даяр. Бул күн сайын ондогон иштеп чыгуучулар тарабынан колдонулат. Жана ал 30 секунданын ичинде суроо-талабы боюнча чоң терабайттык базаны, өзүңүздүн көчүрмөңүздү кантип берүүнү билет. Жана сиз ошол жерден бир нерсени өчүрүп, RESET деп айтып, кайра өчүрө аласыз. Сиз бул жол менен эксперимент болот. Мен бул нерсенин келечегин көрөм. А биз буга чейин эле жасап жатабыз.
Бөлүү стратегиялары деген эмне? Мен пакеттеги иштеп чыгуучулар колдонуп жаткан 3 түрдүү бөлүү стратегиясын көрүп жатам.
Биринчиси абдан жөнөкөй. Бизде сандык ID бар. Жана аны ар кандай интервалдарга бөлүп, ошону менен иштейли. Жаман жагы айкын. Биринчи сегментте бизде чыныгы таштанды 100 сап болушу мүмкүн, экинчисинде 5 сапта же такыр жок, же 1 саптын баары таштанды болуп чыгат. Абдан бирдей эмес иш, бирок аны бузуу оңой. Алар максималдуу ID алып, талкалап салышты. Бул жөнөкөй мамиле.
Экинчи стратегия - тең салмактуу мамиле. Бул Gitlab колдонулат. Алар столду алып, сканерлешти. Биз ID топтомдорунун чектерин таптык, ошондуктан ар бир пакетте так 10 000 жазуу бар. Анан аларды кезекке койгула. Анан кайра иштетебиз. Муну бир нече жипте кыла аласыз.
Биринчи стратегияда да, демек, сиз муну бир нече темада кыла аласыз. Бул кыйын эмес.
Бирок салкыныраак жана жакшыраак ыкма бар. Бул үчүнчү стратегия. Ал эми мүмкүн болгондо, аны тандап алган жакшы. Муну атайын көрсөткүчтүн негизинде жасайбыз. Бул учурда, бул, балким, биздин таштанды абалы жана ID ылайык индекси болот. Биз идентификаторду үймөккө барбаш үчүн индексти гана сканерлөө үчүн кошобуз.
Жалпысынан, индексти сканерлөө индексти сканерлөөдөн тезирээк.
Жана биз жок кылгыбыз келген идентификаторлорубузду тез табабыз. BATCH_SIZE биз алдын ала тандайбыз. Жана биз аларды гана албастан, аларды өзгөчө жол менен алып, дароо бузуп алабыз. Бирок биз бекитип жатабыз, эгер алар кулпуланган болсо, биз аларды бекитпей, кийинкилерин алып кетебиз. Бул кулпуланган жаңыртуу үчүн. Postgresтин бул супер өзгөчөлүгү, эгер кааласак, бир нече жипте иштөөгө мүмкүнчүлүк берет. Бул бир агымда мүмкүн. Ал эми бул жерде CTE бар - бул бир өтүнүч. Ал эми бизде бул CTEнин экинчи кабатында чыныгы өчүрүү жүрүп жатат - returning *. Идентификаторду кайтарсаңыз болот, бирок бул жакшыраак *ар бир сапта көп маалымат жок болсо.
Эмне үчүн муктажбыз? Бул бизге отчет беришибиз керек. Биз азыр чындыгында ушунчалык көп саптарды жок кылдык. Ал эми бизде ID же ушуга окшош created_at боюнча чектер бар. Сиз минимум, макс. Дагы бир нерсе кылса болот. Бул жерде сиз көп нерселерди аласыз. Ал эми мониторинг жүргүзүү үчүн абдан ыңгайлуу.
Индекс жөнүндө дагы бир эскертүү бар. Эгерде биз бул тапшырма үчүн атайын индекс керек деп чечсек, анда ал үймөктөрдө гана жаңыртууларды бузбасын текшеришибиз керек. Башкача айтканда, Postgres мындай статистикага ээ. Муну таблицаңыз үчүн pg_stat_user_tables бөлүмүнөн көрүүгө болот. Сиз ысык жаңыртуулар колдонулуп жатканын же колдонулбагандыгын көрө аласыз.
Жаңы индексиңиз аларды жөн эле кесип салган учурлар бар. Жана сизде мурунтан эле иштеп жаткан башка жаңыртуулар бар, жайлатыңыз. Индекс пайда болгону үчүн эле эмес (ар бир индекс жаңыртууларды бир аз жайлатат, бирок бир аз), бирок бул жерде дагы эле аны бузат. Жана бул таблица үчүн атайын оптималдаштыруу мүмкүн эмес. Бул кээде болот. Бул аз гана адамдар эсинде ушунчалык кылдаттык. Ал эми бул тырмоо менен басуу оңой. Кээде башка тараптан мамиле табуу керек болуп калат да, дагы эле бул жаңы индекссиз, же башка индексти түзүш керек, же башка жол менен, мисалы, экинчи ыкманы колдонсоңуз болот.
Бирок бул эң оптималдуу стратегия, кантип партияларга бөлүү жана бир өтүнүч менен партияларды кантип атуу, бир аз өчүрүү ж.б.у.с.
Узак транзакциялар
Бөгөттөлгөн автовакуум -
бөгөт коюу маселеси -
№5 ката - бул чоң ката. Окметрден келген Николай Postgres мониторинги жөнүндө айтып берди. Ideal Postgres мониторинг, тилекке каршы, жок. Кээ бирлери жакыныраак, кээ бирлери алысыраак. Окметр идеалдуу болууга жетишерлик жакын, бирок көп нерсе жетишпейт жана кошуу керек. Сиз буга даяр болушуңуз керек.
Мисалы, өлүк кортеждер эң жакшы көзөмөлдөнөт. Эгер үстөлдө өлүк нерселер көп болсо, анда бир нерсе туура эмес. Азыр реакция кылган жакшы, антпесе деградация болуп, жатып калышыбыз мүмкүн. Бул болот.
Эгерде чоң IO бар болсо, анда бул жакшы эмес экени түшүнүктүү.
Узак транзакциялар да. OLTPде узак транзакцияларга жол берилбеши керек. Жана бул жерде сиз бул үзүндүнү алып, буга чейин узун транзакцияларга көз салууга мүмкүндүк берген үзүндүгө шилтеме.
Эмне үчүн узак транзакциялар жаман? Анткени бардык кулпулар аягында гана чыгарылат. А биз бардыгын бузабыз. Мындан тышкары, биз бардык столдор үчүн автовакуумду бөгөттөйбүз. Бул такыр жакшы эмес. Репликада ысык күтүү режими иштетилген болсо да, ал дагы эле начар. Жалпысынан алганда, эч жерде ал узак бүтүмдөрдү качуу үчүн жакшы.
Эгерде бизде чаң сорулбаган көптөгөн үстөлдөр болсо, анда биз эскертүүгө ээ болушубуз керек. Бул жерде мындай абал болушу мумкун. Автовакуумдун иштешине кыйыр түрдө таасир эте алабыз. Бул Авитодон үзүндү, мен аны бир аз жакшырттым. Жана бул автовакуум менен бизде эмне бар экенин көрүү үчүн кызыктуу курал болуп чыкты. Мисалы, кээ бир столдор ошол жерде күтүп турушат жана өз кезегин күтүшпөйт. Ошондой эле мониторинг жүргүзүү жана эскертүү болушу керек.
Жана блокторду чыгарат. Блок дарактардан турган токой. Мен бирөөдөн бир нерсе алып, аны жакшыртканды жакшы көрөм. Бул жерде мен Data Egretден салкын рекурсивдүү CTE алдым, анда кулпу дарактарынын токою көрсөтүлгөн. Бул жакшы диагностикалык курал болуп саналат. Жана анын негизинде, сиз да мониторинг кура аласыз. Бирок бул кылдаттык менен жасалышы керек. Сиз өзүңүз үчүн кичинекей билдирүү_таймоо жасашыңыз керек. Жана lock_timeout керек.
Кээде бул каталардын баары суммасында пайда болот.
Менимче, бул жерде негизги ката уюштуруучулукта. Бул уюштуруучулук, анткени техника тартпайт. Бул номер 2 - алар туура эмес жерде текшеришкен.
Биз туура эмес жерден текшерип алдык, анткени бизде өндүрүштүк клон жок болчу, аны текшерүү оңой. Иштеп чыгуучунун өндүрүшкө таптакыр мүмкүнчүлүгү жок болушу мүмкүн.
А биз ал жактан текшерген жокпуз. Ошол жерден текшергенибизде өзүбүз көрмөкпүз. Иштеп чыгуучу мунун баарын DBAсыз да көрдү, эгерде ал аны жакшы чөйрөдө текшерсе, анда бирдей көлөмдөгү маалыматтар жана бирдей жайгашкан. Мына ушундай деградациянын баарын көрүп, уялып калмак.
Автовакуум жөнүндө көбүрөөк маалымат. Биз бир нече миллион саптарды массалык шыпыргандан кийин, дагы эле REPACK кылышыбыз керек. Бул индекстер үчүн өзгөчө маанилүү болуп саналат. Биз ал жерде баарын тазалагандан кийин өздөрүн жаман сезишет.
Ал эми күнүмдүк тазалоо иштерин кайра алып келүүнү кааласаңыз, анда мен аны тез-тез, бирок азыраак жасоону сунуштайт элем. Ал мүнөтүнө бир жолу же андан да көп болушу мүмкүн. Жана сиз эки нерсени көзөмөлдөшүңүз керек: бул нерседе каталар жок жана артта калбашы керек. Мен көрсөткөн амал муну чечет.
Биз жасаган нерсе ачык булак. Ал GitLab сайтында жайгаштырылган. Жана биз муну адамдар DBAсыз деле текшере тургандай кылып жасайбыз. Биз маалымат базасы лабораториясын жасап жатабыз, башкача айтканда, Джо иштеп жаткан базалык компонентти чакырабыз. Жана сиз өндүрүштүн көчүрмөсүн басып алат. Азыр Джону боштук үчүн ишке ашыруу бар, сиз ошол жерде айта аласыз: "мындай суроону түшүндүрүп бериңиз" жана маалымат базасынын көчүрмөсү үчүн натыйжаны дароо алыңыз. Ал жерден ЖОК кылсаңыз да болот, аны эч ким байкабайт.
Сизде 10 терабайт бар дейли, биз маалымат базасы лабораториясын да 10 терабайт кылабыз. Ал эми бир убакта 10 терабайт маалымат базасы менен 10 иштеп чыгуучу бир убакта иштей алат. Ар ким каалаганын кыла алат. Жок кыла алат, түшүрө алат, ж.б. Бул фантазия. Бул тууралуу эртең сүйлөшөбүз.
Бул жука камдоо деп аталат. Бул тымызын камсыз кылуу. Бул өнүгүүдөгү, тестирлөөдөгү артта калууларды жок кылган жана дүйнөнү бул жагынан жакшыраак жерге айландырган кандайдыр бир фантазия. Башкача айтканда, бул жөн гана жапырт операциялар менен көйгөйлөрдөн качууга мүмкүндүк берет.
Мисал: 5 терабайт маалымат базасы, көчүрмөсүн 30 секундага жетпеген убакытта алуу. Жана ал тургай өлчөмүнөн көз каранды эмес, башкача айтканда, канча терабайт маанилүү эмес.
Бүгүн барууга болот жана куралдарыбызды казып. Ал жерде эмне бар экенин көрүү үчүн катталсаңыз болот. Сиз бул ботту орното аласыз. Бул бекер. Жаз.
суроолор
Көбүнчө реалдуу кырдаалдарда таблицада калышы керек болгон маалыматтар жок кылынышы керек болгон маалыматтардан алда канча аз экени аныкталат. Башкача айтканда, мындай кырдаалда мындай ыкманы ишке ашыруу оңой болот, качан жаңы объект түзүп, керектүү маалыматтарды гана көчүрүп, эски таблицаны көчүрүү оңой. Сиз которулуп жаткан учурда бул учурда программалык мамиле керек экени түшүнүктүү. Бул мамиле кандай?
Бул абдан жакшы мамиле жана абдан жакшы милдет. Бул pg_repack жасаган нерсеге абдан окшош, ID'лерди 4 байт кылганыңызда эмне кылышыңыз керек болсо абдан окшош. Көптөгөн алкактар муну бир нече жыл мурун жасашкан жана жөн гана плиталар чоңойгон жана аларды 8 байтка айландыруу керек.
Бул милдет абдан кыйын. Биз жасадык. Жана сиз абдан этият болушуңуз керек. Кулпулары бар, ж.б.. Бирок жасалып жатат. Башкача айтканда, стандарттык ыкма pg_repack менен баруу болуп саналат. Сиз мындай белгини жарыялайсыз. Жана ага көз ирмемдик маалыматтарды жүктөөдөн мурун, сиз бардык өзгөрүүлөргө көз салган бир пластинаны жарыялайсыз. Кээ бир өзгөрүүлөргө көз салбай турган айла бар. Назик жактары бар. Андан кийин сиз өзгөртүүлөр менен которуласыз. Баарын жапканыбызда кыска тыныгуу болот, бирок жалпысынан бул жасалып жатат.
Эгер сиз GitHub'да pg_repack карасаңыз, анда IDти int 4тен int 8ге айландыруу тапшырмасы болгондо, pg_repack өзүн колдонуу идеясы пайда болгон. Бул да мүмкүн, бирок бул бир аз бузукулук, бирок бул үчүн да иштейт. Сиз pg_repack колдонгон триггерге кийлигишип, ошол жерден айта аласыз: "Бизге бул маалымат керек эмес", б.а. биз өзүбүзгө керектүү нерсени гана өткөрүп беребиз. Анан ал жөн эле которулат жана ушуну менен бүттү.
Бул ыкма менен биз дагы эле таблицанын экинчи көчүрмөсүн алабыз, анда маалыматтар индекстелген жана кооз индекстер менен абдан бирдей топтолгон.
Bloat жок, бул жакшы мамиле. Бирок бул үчүн автоматташтыруу, б.а. универсалдуу чечим кабыл алуу аракеттери болуп жатканын билем. Мен сени бул автоматташтыруу менен байланыштыра алам. Бул Python тилинде жазылган, бул жакшы нерсе.
Мен MySQL дүйнөсүнөн бир аз эмесмин, ошондуктан угууга келдим. Жана биз бул ыкманы колдонобуз.
Бирок бизде 90% болгондо гана болот. Эгерде бизде 5% болсо, анда аны колдонуу абдан жакшы эмес.
Отчет үчүн рахмат! Продукциянын толук көчүрмөсүн жасоо үчүн ресурстар жок болсо, жүктү же өлчөмүн эсептөө үчүн алгоритм же формула барбы?
Жакшы суроо. Азырынча биз көп терабайттык маалымат базаларын таба алдык. Ал жактагы аппараттык камсыздоо бирдей болбосо да, мисалы, эстутум аз, процессор жана дисктер так бирдей эмес, бирок биз муну жасайбыз. Эгер такыр эч жерде жок болсо, анда ойлонуу керек. Эртеңге чейин ойлонуп көрөйүн, сен келдиң, сүйлөшөбүз, жакшы суроо экен.
Баяндама үчүн рахмат! Сиз адегенде мындай жана мындай чектөөлөрү бар сонун Postgres бар экендиги жөнүндө баштадыңыз, бирок ал өнүгүп жатат. Жана мунун баары чоң балдак. Мунун баары Postgresтин өнүгүшүнө карама-каршы келбейт, анда кандайдыр бир DELETE deferent пайда болот же биз бул жерде кээ бир кызыктай каражаттарыбыз менен булгап жаткан нерсебизди төмөн деңгээлде кармап турушу керекпи?
Эгерде биз SQLде бир транзакцияда көптөгөн жазууларды жок кылуу же жаңыртуу керек десек, анда Postgres аны кантип ал жерде тарата алат? Бизде физикалык жактан чектөөлөр бар. Биз дагы көпкө чейин жасайбыз. Ал эми биз ушул убакта кулпулайбыз, ж.б.
Индекс менен бүттү.
Мен ошол эле текшерүү пунктун тюнинг автоматташтырылышы мүмкүн деп болжолдой алам. Бир күнү болушу мүмкүн. Бирок мен суроону такыр түшүнбөйм.
Суроо туулат, тиги жакта-бул жерде жүрүп, сеники параллелдүү болгон өнүгүү вектору барбы? Ошол. Алар бул жөнүндө ойлоно элекпи?
Мен азыр колдонула турган принциптер жөнүндө айттым. Дагы бир бот бар , муну менен сиз автоматтык текшерүү пунктун тюнинг кыла аласыз. Ал бир күнү Postgresте болобу? Билбейм, али талкуулана элек. Биз андан али алыспыз. Бирок жаңы системаларды жасаган окумуштуулар бар. Жана алар бизди автоматтык индекстерге түртүшөт. өнүгүүлөр бар. Мисалы, сиз автотюнингди карасаңыз болот. Ал автоматтык түрдө параметрлерди тандайт. Бирок ал азырынча сиз үчүн текшерүү пунктун тюнинг кылбайт. Башкача айтканда, ал аткарууну, буферди ж.б.
Ал эми текшерүү пунктун жөндөө үчүн сиз муну кыла аласыз: эгер сизде миң кластер жана ар кандай аппараттык каражаттар, булуттагы ар кандай виртуалдык машиналар болсо, биздин ботту колдоно аласыз. автоматташтыруу. Жана max_wal_size сиздин максаттуу орнотууларыңызга ылайык автоматтык түрдө тандалат. Бирок, тилекке каршы, азырынча бул өзөктө жакын эмес.
Кутмандуу күнүң менен! Сиз узакка созулган транзакциялардын коркунучу жөнүндө айттыңыз. Автовакуум өчүрүлгөн учурда бөгөттөлөт деп айттыңыз. Бул бизге дагы кандай зыян келтирет? Анткени биз мейкиндикти бошотуп, аны пайдалана билүү жөнүндө көбүрөөк айтып жатабыз. Бизге дагы эмне жетишпейт?
Автовакуум бул жерде эң чоң көйгөй эмес. Ал эми узак бүтүм башка бүтүмдөрдү кулпулап калышы мүмкүн экенин, бул мүмкүнчүлүк дагы кооптуу болуп саналат. Ал жолугушу мүмкүн же жолукпай калышы мүмкүн. Ал жолуккан болсо, анда ал абдан жаман болушу мүмкүн. Ал эми autovacuum менен - бул да көйгөй. OLTPде узак транзакцияларда эки көйгөй бар: кулпулар жана автовакуум. Эгерде сизде репликада күтүү режиминде ысык пикир иштетилген болсо, анда сиз дагы эле мастерде автовакуумдук кулпу аласыз, ал репликадан келет. Бирок жок дегенде кулпулар болбойт. Жана локтор болот. Биз маалыматтарды өзгөртүү жөнүндө сөз болуп жатат, ошондуктан кулпулар бул жерде маанилүү пункт болуп саналат. Ал эми мунун баары узакка созулса, анда барган сайын көбүрөөк транзакциялар жабылат. Алар башкаларды уурдай алышат. Жана лок дарактары пайда болот. Мен үзүндүгө шилтеме бердим. Жана бул көйгөй автовакуумдагы көйгөйгө караганда тезирээк байкалат, ал топтолушу мүмкүн.
Баяндама үчүн рахмат! Сиз отчетуңузду туура эмес тестирлөөдөн баштадыңыз. Биз ошол эле жабдууларды, базаны ошол эле жол менен алышыбыз керек деген оюбузду уланттык. Биз иштеп чыгуучуга база бердик дейли. Жана ал өтүнүчтү аткарды. Анан ал жакшы окшойт. Бирок ал түз үчүн эмес, түз үчүн текшерет, мисалы, бизде жүк 60-70%. Жана бул тюнингди колдонсок дагы, ал жакшы иштебейт.
Командада эксперттин болушу жана чыныгы фон жүктөмү менен эмне болорун алдын ала айта алган DBA эксперттерин колдонуу маанилүү. Биз жөн гана таза өзгөрүүлөрдү айдап жатканда, биз сүрөттү көрөбүз. Бирок дагы өнүккөн ыкма, биз дагы бир эле нерсени жасаганда, бирок өндүрүш менен окшоштурулган жүк менен. Бул абдан сонун. Ага чейин чоңоюш керек. Бул чоң кишидей. Биз жөн гана бизде эмне бар экенин карап чыктык, ошондой эле бизде ресурстар жетиштүүбү деп карадык. Бул жакшы суроо.
Биз буга чейин таштанды тандоо кылып жатканда жана бизде, мисалы, жок кылынган желек бар
Postgresте автовакуум автоматтык түрдө ушундай кылат.
Ой, ал жасайбы?
Автовакуум - бул таштанды жыйноочу.
рахмат!
Баяндама үчүн рахмат! Бардык таштандылар негизги үстөлдүн бир жеринен капталына киргидей кылып бөлүштүрүү менен маалымат базасын тез арада долбоорлоо мүмкүнчүлүгү барбы?
Албетте бар.
Колдонулбашы керек болгон үстөлдү бекитип алган болсок, анда өзүбүздү коргой алабызбы?
Албетте бар. Бирок бул тоок менен жумуртка суроосуна окшош. Келечекте эмне болорун баарыбыз биле турган болсок, анда, албетте, баарын салкын кылабыз. Бирок бизнес өзгөрүп жатат, жаңы тилкелер, жаңы өтүнүчтөр бар. Анан - ой, биз аны алып салгыбыз келет. Бирок, бул идеалдуу жагдай, жашоодо ал кездешет, бирок дайыма эмес. Бирок жалпысынан бул жакшы идея. Жөн эле кыскартыңыз жана бүттү.
Source: www.habr.com