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

SQL асуулга нь "бүтээгдэхүүн" дээр сайн ажиллах болно гэдгийг backend хөгжүүлэгч хэрхэн ойлгох вэ? Томоохон эсвэл хурдацтай хөгжиж буй компаниудад хүн бүр "бүтээгдэхүүн"-ийг олж авах боломжгүй байдаг. Мөн хандалт хийснээр бүх хүсэлтийг өвдөлтгүй шалгах боломжгүй бөгөөд мэдээллийн сангийн хуулбарыг бий болгоход олон цаг зарцуулдаг. Эдгээр асуудлыг шийдэхийн тулд бид зохиомол DBA-г бүтээсэн Жое. Энэ нь хэд хэдэн компанид аль хэдийн амжилттай хэрэгжиж, арав гаруй хөгжүүлэгчдэд тусалдаг.

Видео:

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

Бидэнд гайхалтай үйлчлүүлэгчид байгаа бөгөөд өнөөдөр тайлангийн нэг хэсэг нь тэдэнтэй ажиллаж байхдаа уулзаж байсан тохиолдлуудад зориулагдсан болно. Бид тэдэнд нэлээд ноцтой асуудлыг шийдвэрлэхэд хэрхэн тусалсан талаар би ярих болно.

Бид өндөр ачаалалтай нүүлгэн шилжүүлэлтийг боловсруулж, хийхдээ "Энэ шилжилт хөдөлгөөн өрнөх болов уу?" Гэсэн асуултыг өөрөөсөө асуудаг. Бид тоймыг ашигладаг, бид илүү туршлагатай хамт олон, DBA мэргэжилтнүүдийн мэдлэгийг ашигладаг. Тэгээд нисэх юм уу, үгүй ​​юу гэдгийг хэлж чадна.

Гэхдээ бид үүнийг бүрэн хэмжээний хуулбар дээр өөрсдөө туршиж үзсэн нь дээр байх. Өнөөдөр бид туршилтанд ямар арга барилууд байгаа, үүнийг хэрхэн, ямар хэрэгслээр илүү сайн хийж болох талаар л ярих болно. Бид ийм аргын давуу болон сул талууд, мөн энд юу засах талаар ярилцах болно.

Хэн бүтээгдэхүүн дээр шууд индекс хийсэн эсвэл ямар нэгэн өөрчлөлт хийсэн бэ? Бага зэрэг. Энэ нь хэний хувьд өгөгдөл алдагдах эсвэл сул зогсолт хийхэд хүргэсэн бэ? Тэгвэл та энэ өвдөлтийг мэднэ. Бурханд баярлалаа, нөөцлөлтүүд байгаа.

Эхний арга бол бүтээгдэхүүн дээр туршилт хийх явдал юм. Эсвэл хөгжүүлэгч орон нутгийн машин дээр сууж байхдаа туршилтын өгөгдөлтэй, ямар нэг хязгаарлагдмал сонголттой байдаг. Бид үйлдвэрлэхээр гарч ирээд ийм нөхцөл байдалд хүрдэг.

Өвдөж байна, үнэтэй. Үгүй байсан нь дээр байх.

Мөн үүнийг хийх хамгийн сайн арга юу вэ?

Тайлбарыг аваад тэндээс бүтээгдэхүүний зарим хэсгийг сонгоцгооё. Эсвэл сайндаа л жинхэнэ бүтээгдэхүүн, бүх өгөгдлийг авъя. Мөн бид үүнийг орон нутагтаа хөгжүүлсний дараа бид найруулгыг нэмж шалгах болно.

Энэ нь бидэнд зарим алдааг арилгах, өөрөөр хэлбэл тэдгээрийг ашиглахаас урьдчилан сэргийлэх боломжийг олгоно.

Ямар асуудал тулгарч байна вэ?

• Асуудал нь бид энэ тайзыг хамтран ажиллагсадтайгаа хуваалцаж байгаа явдал юм. Мөн маш олон удаа энэ нь та ямар нэг өөрчлөлт хийх гэж тохиолддог, bam - ямар ч мэдээлэл байхгүй, ажил ус зайлуулах доош байна. Тайзны хэмжээ олон терабайт байсан. Тэгээд дахин босох хүртэл удаан хүлээх хэрэгтэй. Тэгээд маргааш эцэслэхээр шийдлээ. Ингээд л болоо, манайд хөгжил бий.
• Тэгээд мэдээж тэнд олон хамт олон, олон баг ажиллаж байгаа. Мөн үүнийг гараар хийх ёстой. Мөн энэ нь эвгүй юм.

Хэрэв бид мэдээллийн санд ямар нэгэн өөрчлөлт оруулах, өгөгдөлд хүрч, бүтцийг өөрчлөхийг хүсч байвал бидэнд ганцхан оролдлого, нэг цохилт байгаа гэдгийг хэлэх нь зүйтэй болов уу. Хэрэв ямар нэг зүйл буруу болвол, шилжилт хөдөлгөөнд алдаа гарсан бол бид хурдан буцахгүй.

Энэ нь өмнөх арга барилаас илүү сайн боловч үйлдвэрлэлд ямар нэгэн алдаа гарах магадлал өндөр хэвээр байна.

Хөгжүүлэгч бүрт туршилтын сандал, бүрэн хэмжээний хуулбар өгөхөд юу саад болж байна вэ? Юу саад болж байгаа нь ойлгомжтой гэж бодож байна.

Хэн терабайтаас их мэдээллийн сантай вэ? Өрөөний талаас илүү.

Ийм том үйлдвэрлэл байгаа үед хөгжүүлэгч бүрт машин байлгах нь маш их зардал шаарддаг, үүнээс гадна удаан хугацаа шаарддаг нь ойлгомжтой.

Бидэнд бүх өөрчлөлтийг бүрэн хэмжээний хуулбар дээр туршиж үзэх нь маш чухал гэдгийг ойлгосон үйлчлүүлэгчид байгаа боловч тэдний мэдээллийн сан нь терабайтаас бага бөгөөд хөгжүүлэгч бүрийн хувьд туршилтын сандал хадгалах нөөц байхгүй байна. Тиймээс тэд дотооддоо хогийн цэгүүдийг машиндаа татаж аваад ийм маягаар турших ёстой. Энэ нь маш их цаг хугацаа шаарддаг.

Хэдийгээр та үүнийг дэд бүтцийн хүрээнд хийсэн ч цагт нэг терабайт өгөгдөл татаж авах нь маш сайн хэрэг юм. Гэхдээ тэд логик хогийн цэгүүдийг ашигладаг, тэд үүлэн дээрээс орон нутагт татаж авдаг. Тэдний хувьд хурд нь цагт 200 гигабайт юм. Логик хогийн цэгээс эргэх, индексийг эргүүлэх гэх мэт цаг хугацаа шаардагддаг.

Гэхдээ тэд энэ аргыг ашигладаг, учир нь энэ нь бүтээгдэхүүнийг найдвартай байлгах боломжийг олгодог.

Бид энд юу хийж чадах вэ? Туршилтын ванданг хямд болгож, хөгжүүлэгчид бүр өөрийн гэсэн тестийн вандан сандал өгцгөөе.

Мөн энэ нь боломжтой юм.

Энэ аргын хувьд бид хөгжүүлэгч бүрт нимгэн клон хийхдээ үүнийг нэг машин дээр хуваалцах боломжтой. Жишээлбэл, хэрэв танд 10TB мэдээллийн сан байгаа бөгөөд үүнийг 10 хөгжүүлэгчид өгөхийг хүсч байвал XNUMX x XNUMXTB мэдээллийн сантай байх шаардлагагүй. Нэг машин ашиглан хөгжүүлэгч бүрт нимгэн тусгаарлагдсан хуулбар хийхэд танд зөвхөн нэг машин хэрэгтэй. Энэ нь хэрхэн ажилладаг талаар би жаахан дараа хэлье.

Бодит жишээ:

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

• Бид 30 секундын дотор бие даасан хуулбарыг авах боломжтой.

Та туршилтын тавиурыг хүлээх шаардлагагүй бөгөөд хэр том байхаас хамаарна. Та үүнийг хэдхэн секундын дотор авах боломжтой. Энэ нь бүрэн тусгаарлагдсан орчин байх болно, гэхдээ хоорондоо мэдээлэл солилцдог.

Энэ үнэхээр сайхан. Энд бид ид шид ба зэрэгцээ ертөнцийн тухай ярьж байна.

Манай тохиолдолд энэ нь OpenZFS системийг ашиглан ажилладаг.

OpenZFS нь хормын хувилбар болон хувилан гаргахыг дэмждэг бичих дээр хуулбарлах файлын систем юм. Энэ нь найдвартай, өргөтгөх боломжтой. Түүнийг удирдахад тун амархан. Үүнийг шууд утгаараа хоёр багт байрлуулж болно.

Бусад сонголтууд байдаг:

• lvm,

• Хадгалах (жишээ нь, Цэвэр хадгалах).

Миний яриад байгаа Database Lab нь модульчлагдсан. Эдгээр сонголтыг ашиглан хэрэгжүүлэх боломжтой. Гэхдээ одоохондоо бид OpenZFS дээр анхаарлаа хандуулсан, учир нь LVM-тэй холбоотой асуудал гарсан.

Хэрхэн ажилладаг? Өгөгдлийг өөрчлөх болгондоо дарж бичихийн оронд бид энэ шинэ өгөгдлийг цаг хугацааны шинэ цэг, шинэ агшин зуурын зураг гэж тэмдэглэснээр л хадгалдаг.

Ирээдүйд бид буцаах эсвэл хуучин хувилбараас шинэ клон хийхийг хүсэх үед "За, ийм тэмдэглэгдсэн өгөгдлийн блокуудыг бидэнд өг" гэж л хэлдэг.

Мөн энэ хэрэглэгч ийм өгөгдлийн багцтай ажиллах болно. Тэр аажмаар тэдгээрийг өөрчилж, өөрийн агшин зуурын зургийг хийх болно.

Мөн бид салбарлана. Манай тохиолдолд хөгжүүлэгч бүр өөрийн засварласан клонтой болох боломжтой бөгөөд хуваалцсан өгөгдлийг хүн бүр хуваалцах болно.

Ийм системийг гэртээ байрлуулахын тулд та хоёр асуудлыг шийдэх хэрэгтэй.

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

• Хоёр дахь нь та мэдээллийн сангийн лабораторийг байрлуулахыг хүсч байна. Энэ нь Үүлэн байж болно, газар дээр нь байж болно. ZFS нь өгөгдөл шахалтыг дэмждэг гэдгийг энд хэлэх нь чухал юм. Мөн үүнийг маш сайн хийдэг.

Ийм клон бүрийн хувьд бидний суурьтай хийсэн үйлдлээс хамааран ямар нэгэн төрлийн хөгжүүлэгчид өснө гэж төсөөлөөд үз дээ. Үүний тулд dev-д бас зай хэрэгтэй болно. Гэхдээ бид 4,5 терабайтын суурийг авсан тул ZFS үүнийг 3,5 терабайт хүртэл шахах болно. Энэ нь тохиргооноос хамаарч өөр өөр байж болно. Мөн бидэнд хөгжүүлэгч хийх зай байгаа.

Ийм системийг янз бүрийн тохиолдолд ашиглаж болно.

• Эдгээр нь хөгжүүлэгчид, асуулга баталгаажуулах, оновчтой болгох DBA юм.

• Үүнийг үйлдвэрлэлд нэвтрүүлэхээс өмнө тодорхой шилжилт хөдөлгөөнийг шалгахын тулд QA тестэнд ашиглаж болно. Мөн бид бодит өгөгдөл бүхий QA-д зориулсан тусгай орчныг бий болгож, шинэ функцийг туршиж үзэх боломжтой. Нимгэн хуулбарыг ашиглаагүй тохиолдолд хэдэн цаг хүлээхийн оронд хэдэн секунд, магадгүй бусад тохиолдолд хэдэн өдөр шаардагдах болно.

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

Энэ хандлагаар:

1. "Бүтээгдэхүүн" дээр алдаа гарах магадлал бага, учир нь бид бүх өөрчлөлтийг бүрэн хэмжээний өгөгдөл дээр туршиж үзсэн.

2. Одоо та өөрийн индэрээ олон цагаар хүлээх шаардлагагүй болсон тул бид тест хийх соёлтой.

3. Мөн ямар ч саад бэрхшээл байхгүй, шалгалтын хооронд хүлээх шаардлагагүй. Та үнэхээр очиж шалгаж болно. Мөн бид хөгжлийг хурдасгах тусам энэ нь илүү дээр байх болно.

• Рефакторинг бага байх болно. Цөөн алдаа нь бүтээгдэхүүнд дуусна. Бид дараа нь тэдгээрийг бага дахин боловсруулах болно.

• Бид эргэлт буцалтгүй өөрчлөлтүүдийг эргүүлж чадна. Энэ бол стандарт арга биш юм.

1. Бид туршилтын вандан нөөцийг хуваалцдаг учраас энэ нь ашигтай юм.

Аль хэдийн сайн, гэхдээ өөр юуг хурдасгах вэ?

Ийм системийн ачаар бид ийм шалгалтанд орох босгыг эрс багасгаж чадна.

Одоо хөгжүүлэгч жинхэнэ бүрэн хэмжээний өгөгдөлд хандахын тулд мэргэжилтэн болох ёстой харгис тойрог байна. Түүнд ийм хүртээмжтэй байх ёстой.

Гэхдээ тэнд байхгүй бол яаж өсөх вэ. Гэхдээ танд маш бага хэмжээний тестийн өгөгдөл байгаа бол яах вэ? Тэгвэл та ямар ч бодит туршлага олж авахгүй.

Энэ тойргоос яаж гарах вэ? Аль ч түвшний хөгжүүлэгчдэд тохиромжтой анхны интерфейсийн хувьд бид Slack ботыг сонгосон. Гэхдээ энэ нь өөр ямар ч интерфейс байж болно.

Энэ нь танд юу хийхийг зөвшөөрдөг вэ? Та тодорхой асуулга авч, мэдээллийн санд зориулсан тусгай суваг руу илгээж болно. Бид хэдхэн секундын дотор нимгэн клоныг автоматаар байрлуулах болно. Энэ хүсэлтийг хэрэгжүүлье. Бид хэмжүүр, зөвлөмжийг цуглуулдаг. Дүрслэл үзүүлье. Дараа нь энэ клон хэвээр байх бөгөөд ингэснээр энэ асуулгыг ямар нэгэн байдлаар оновчтой болгох, индекс нэмэх гэх мэт боломжтой болно.

Мөн Slack нь бидэнд хайрцагнаас гадуур хамтран ажиллах боломжийг олгодог. Энэ бол зүгээр л суваг тул та энэ хүсэлтийг яг тэндээс ийм хүсэлт гаргах сэдвээр ярилцаж, хамт ажиллагсаддаа, компани доторх DBA-д ping хийж болно.

Гэхдээ мэдээж асуудал бий. Энэ бол бодит ертөнц бөгөөд бид нэг дор олон клон байршуулах сервер ашиглаж байгаа тул бид клонуудад ашиглах боломжтой санах ой болон CPU-ийн хүчийг шахах хэрэгтэй.

Гэхдээ эдгээр туршилтууд үнэмшилтэй байхын тулд та ямар нэгэн байдлаар энэ асуудлыг шийдэх хэрэгтэй.

Чухал цэг нь ижил өгөгдөл гэдэг нь тодорхой байна. Гэхдээ бидэнд аль хэдийн байгаа. Мөн бид ижил тохиргоонд хүрэхийг хүсч байна. Мөн бид ийм бараг ижил тохиргоог өгч чадна.

Үйлдвэрлэлийнхтэй ижил тоног төхөөрөмжтэй байх нь сайхан байх болно, гэхдээ энэ нь өөр байж болно.

Postgres санах ойтой хэрхэн ажилладагийг санацгаая. Бидэнд хоёр кэш байна. Нэг файлын систем ба нэг Postgres, өөрөөр хэлбэл Хуваалцсан буфер кэш.

Postgres эхлэхэд тохиргоонд заасан хэмжээнээс хамааран Shared Buffer Cache хуваарилагдана гэдгийг анхаарах нь чухал.

Хоёрдахь кэш нь боломжтой бүх зайг ашигладаг.

Нэг машин дээр хэд хэдэн клон хийх үед бид аажмаар санах ойг дүүргэдэг. Сайнаар хэлэхэд Shared Buffer Cache нь машин дээрх нийт санах ойн 25% -ийг эзэлдэг.

Хэрэв бид энэ параметрийг өөрчлөхгүй бол нэг машин дээр ердөө 4 тохиолдол, өөрөөр хэлбэл эдгээр нимгэн клонуудын 4-ийг ажиллуулах боломжтой болох нь харагдаж байна. Энэ нь мэдээжийн хэрэг муу, учир нь бид тэднээс илүү ихийг хүсч байна.

Гэхдээ нөгөө талаас, буфер кэш нь индексийн хүсэлтийг гүйцэтгэхэд ашиглагддаг, өөрөөр хэлбэл төлөвлөгөө нь бидний кэш хэр том байхаас хамаарна. Хэрэв бид зүгээр л энэ параметрийг аваад үүнийг бууруулбал бидний төлөвлөгөө маш их өөрчлөгдөж болно.

Жишээлбэл, хэрэв бид бүтээгдэхүүн дээр их хэмжээний кэштэй бол Postgres индекс ашиглахыг илүүд үздэг. Хэрэв үгүй ​​​​бол SeqScan байх болно. Хэрэв бидний төлөвлөгөө давхцахгүй бол ямар хэрэг байх вэ?

Гэхдээ энд бид үнэндээ Postgres дахь төлөвлөгөө нь төлөвлөгөөний Хуваалцсан буферт заасан тодорхой хэмжээнээс хамаардаггүй, үр дүнтэй_кэш_хэмжээнээс хамаардаг гэсэн дүгнэлтэд хүрч байна.

Үр дүнтэй_кэшийн_хэмжээ нь бидний ашиглах боломжтой кэшийн тооцоолсон хэмжээ, өөрөөр хэлбэл буфер кэш болон файлын системийн кэшийн нийлбэр юм. Үүнийг тохиргоогоор тохируулна. Мөн энэ санах ойг хуваарилаагүй байна.

Энэ параметрийн улмаас бид Postgres-ийг хуурч, бидэнд энэ өгөгдөл байхгүй байсан ч гэсэн маш их мэдээлэл байгаа гэж хэлж болно. Тиймээс төлөвлөгөө нь үйлдвэрлэлтэй бүрэн давхцах болно.

Гэхдээ энэ нь цаг хугацааны хувьд нөлөөлж болно. Мөн бид асуултуудыг цаг хугацааны хувьд оновчтой болгодог боловч цаг хугацаа нь олон хүчин зүйлээс хамаардаг нь чухал юм.

• Энэ нь одоогоор бүтээгдэхүүн дээр байгаа ачааллаас хамаарна.

• Энэ нь тухайн машины шинж чанараас хамаарна.

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

Хэрэв та цаг хугацаа нь бидний харж буй бүтээгдэхүүнд ойр байхыг хүсч байвал бүх клонууд тохирохын тулд бид хамгийн төстэй техник хангамжийг авах хэрэгтэй бөгөөд магадгүй бүр илүү ихийг авах хэрэгтэй. Гэхдээ энэ бол буулт, өөрөөр хэлбэл та ижил төлөвлөгөөг авах болно, та тодорхой асуулга хэр их өгөгдөл уншихыг харж, энэ асуулга сайн (эсвэл шилжих) эсвэл муу эсэхийг дүгнэх боломжтой, үүнийг оновчтой болгох шаардлагатай хэвээр байна. .

Жо-г хэрхэн тусгайлан оновчтой болгосныг харцгаая.

Бодит системээс хүсэлт авъя. Энэ тохиолдолд мэдээллийн сан 1 терабайт байна. Мөн бид 10-аас дээш лайк авсан шинэ бичлэгүүдийн тоог тоолохыг хүсч байна.

Бид суваг руу мессеж бичиж байна, бидэнд зориулж клон байрлуулсан байна. Ийм хүсэлтийг 2,5 минутын дотор дуусгахыг бид харах болно. Энэ бол бидний анзаарсан хамгийн эхний зүйл юм.

Б Жо төлөвлөгөө болон хэмжүүр дээр үндэслэн танд автомат зөвлөмжийг харуулах болно.

Харьцангуй цөөн тооны мөр авахын тулд асуулга хэт их өгөгдөл боловсруулдаг болохыг бид харах болно. Асуулгад хэт олон шүүсэн мөр байгааг анзаарсан тул зарим төрлийн тусгай индекс шаардлагатай байна.

Юу болсныг нарийвчлан харцгаая. Үнэхээр бид файлын кэш эсвэл дискнээс бараг нэг хагас гигабайт өгөгдлийг уншсан гэдгийг бид харж байна. Энэ нь сайн биш, учир нь бид ердөө 142 мөр авсан.

Энд бид индекс скан хийж байгаа бөгөөд хурдан ажиллах ёстой байсан бололтой, гэхдээ бид хэт олон мөрийг шүүсэн (бид тэдгээрийг тоолох шаардлагатай байсан) асуулга аажмаар бүтсэн.

Асуулгад байгаа нөхцөлүүд болон индекс дэх нөхцөлүүд хэсэгчлэн таарахгүй байгаатай холбоотойгоор төлөвлөгөөнд ийм зүйл тохиолдсон.

Индексийг илүү нарийвчлалтай болгохыг хичээцгээе, үүний дараа асуулгын гүйцэтгэл хэрхэн өөрчлөгдөхийг харцгаая.

Индексийг бий болгоход нэлээд удаан хугацаа зарцуулсан боловч одоо бид асуулгыг шалгаж үзэхэд 2,5 минутын оронд ердөө 156 миллисекунд байгаа нь хангалттай сайн байна. Мөн бид зөвхөн 6 мегабайт өгөгдлийг уншдаг.

Одоо бид зөвхөн индексийн сканнерыг ашигладаг.

Өөр нэг чухал түүх бол бид төлөвлөгөөг илүү ойлгомжтой байдлаар танилцуулахыг хүсч байна. Бид Flame Graphs ашиглан дүрслэлийг хэрэгжүүлсэн.

Энэ бол өөр хүсэлт, илүү хүчтэй. Мөн бид хоёр параметрийн дагуу Flame Graphs-ийг бүтээдэг: энэ нь тухайн зангилааны төлөвлөгөө, цаг хугацаанд тооцсон өгөгдлийн хэмжээ, өөрөөр хэлбэл зангилааны гүйцэтгэлийн хугацаа юм.

Энд бид тодорхой зангилаануудыг бие биетэйгээ харьцуулж болно. Тэдгээрийн аль нь илүү их эсвэл бага хэмжээгээр авах нь тодорхой болно, энэ нь ихэвчлэн бусад дүрслэх аргуудыг хийхэд хэцүү байдаг.

Мэдээжийн хэрэг, хүн бүр тайлбарлах.depesz.com-г мэддэг. Энэхүү дүрслэлийн сайн шинж чанар нь бид текстийн төлөвлөгөөг хадгалж, мөн зарим үндсэн параметрүүдийг хүснэгтэд оруулснаар эрэмбэлэх боломжтой болно.

Энэ сэдвийг хараахан судалж амжаагүй хөгжүүлэгчид тайлбарлах.depesz.com сайтыг ашигладаг, учир нь аль хэмжигдэхүүн чухал, аль нь чухал биш болохыг олж мэдэх нь тэдэнд илүү хялбар байдаг.

Дүрслэх шинэ хандлага бий - энэ бол тайлбарлах.dalibo.com юм. Тэд модны дүрслэлийг хийдэг боловч зангилааг бие биетэйгээ харьцуулах нь маш хэцүү байдаг. Энд та бүтцийг сайн ойлгож чадна, гэхдээ хэрэв том хүсэлт байгаа бол та нааш цааш гүйлгэх хэрэгтэй болно, гэхдээ бас сонголт.

хамтын ажиллагаа

Мөн миний хэлсэнчлэн Slack бидэнд хамтран ажиллах боломжийг олгодог. Жишээлбэл, хэрвээ бид хэрхэн оновчтой болгох нь тодорхойгүй нарийн төвөгтэй асуулгатай тулгарвал бид Slack дахь thread дээр хамтран ажиллагсадтайгаа энэ асуудлыг тодруулж болно.

Бүрэн хэмжээний өгөгдөл дээр туршилт хийх нь чухал юм шиг санагдаж байна. Үүнийг хийхийн тулд бид нээлттэй эх сурвалж дээр ашиглах боломжтой Update Database Lab хэрэгслийг хийсэн. Та мөн Жо ботыг ашиглаж болно. Та яг одоо аваад өөрийн байрандаа хэрэгжүүлж болно. Бүх гарын авлагууд тэнд байдаг.

Энэ шийдэл нь өөрөө хувьсгалт биш гэдгийг анхаарах нь чухал, учир нь Delphix байдаг, гэхдээ энэ нь аж ахуйн нэгжийн шийдэл юм. Энэ нь бүрэн хаалттай, энэ нь маш үнэтэй юм. Бид Postgres-д тусгайлан мэргэшсэн. Эдгээр нь бүгд нээлттэй эхийн бүтээгдэхүүн юм. Бидэнтэй нэгд!

Энэ бол миний төгсгөл. Баярлалаа!

Асуултууд

Сайн уу? Мэдээлэл өгсөнд баярлалаа! Хэсэг хугацааны өмнө би ижил асуудлыг шийдэж байсан болохоор маш сонирхолтой, ялангуяа надад. Тиймээс надад хэд хэдэн асуулт байна. Би ядаж нэг хэсгийг нь авна гэж найдаж байна.

Та энэ орчныг хэрхэн тооцдог вэ? Технологи нь тодорхой нөхцөлд таны клонууд хамгийн их хэмжээгээр өсөх боломжтой гэсэн үг юм. Товчоор хэлбэл, хэрэв танд арван терабайт мэдээллийн сан, 10 клон байгаа бол клон бүр 10 өвөрмөц өгөгдөлтэй байх нөхцөл байдлыг дуурайхад хялбар байдаг. Эдгээр клонууд амьдрах энэ газрыг, өөрөөр хэлбэл таны хэлсэн бэлчирийг яаж тооцоолох вэ?

Сайн асуулт. Энд тодорхой клонуудыг бүртгэх нь чухал юм. Хэрэв клонд хэтэрхий том өөрчлөлт гарсан бол энэ нь өсч эхэлбэл бид эхлээд хэрэглэгчдэд энэ талаар анхааруулга өгөх эсвэл энэ клоныг нэн даруй зогсоож, алдаа гарахгүй байх боломжтой.

Тийм ээ, надад нэг асуулт байна. Өөрөөр хэлбэл, эдгээр модулиудын амьдралын мөчлөгийг хэрхэн хангах вэ? Бидэнд энэ асуудал, тусдаа түүх бий. Энэ нь яаж болдог вэ?

Клон бүрт тодорхой хэмжээний ttl байдаг. Үндсэндээ бид тогтсон ttl-тэй.

Нууц биш бол яах вэ?

1 цаг, өөрөөр хэлбэл сул зогсолт - 1 цаг. Хэрэв үүнийг ашиглаагүй бол бид үүнийг цохино. Гэхдээ энд гайхах зүйл алга, учир нь бид хэдхэн секундын дотор клоныг өсгөж чадна. Хэрэв танд дахин хэрэгтэй бол гуйя.

Жишээлбэл, бид нэг шалтгааны улмаас хэд хэдэн аргыг зэрэгцүүлэн ашигладаг тул би технологийн сонголтыг сонирхож байна. Яагаад ZFS гэж? Та яагаад LVM ашиглаагүй юм бэ? LVM-д асуудал гарсан гэж та хэлсэн. Ямар асуудлууд байсан бэ? Миний бодлоор хамгийн оновчтой сонголт бол гүйцэтгэлийн хувьд хадгалах төхөөрөмж юм.

ZFS-ийн гол асуудал юу вэ? Та нэг хост дээр ажиллах ёстой, өөрөөр хэлбэл бүх тохиолдлууд нэг үйлдлийн систем дотор амьдрах болно. Мөн хадгалах тохиолдолд та өөр өөр тоног төхөөрөмжийг холбож болно. Мөн түгжрэл нь зөвхөн хадгалах системд байгаа блокууд юм. Технологийн сонголтын асуудал нь сонирхолтой юм. Яагаад LVM болохгүй гэж?

Тодруулбал, бид уулзалт дээр LVM-ийн талаар ярилцаж болно. Хадгалах тухай - энэ нь зүгээр л үнэтэй юм. Бид хаана ч ZFS системийг хэрэгжүүлж чадна. Та үүнийг өөрийн машин дээр байрлуулж болно. Та зүгээр л репозиторыг татаж аваад байрлуулж болно. Хэрэв бид Линуксийн тухай ярьж байгаа бол 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-д ижил төстэй зүйл байдаг, гэхдээ тэд үүнийг хаана ч нийтэлдэггүй. Тэд үүнийг Yandex.Metrica дотор ашигладаг. Мөн MySQL-ийн тухай түүх бий. Гэхдээ технологи нь адилхан, ZFS.

Мэдээлэл өгсөнд баярлалаа! Надад бас хэдэн асуулт байна. Та клончлолыг аналитик, жишээлбэл, тэнд нэмэлт индекс бий болгоход ашиглаж болно гэж хэлсэн. Энэ нь хэрхэн ажилладаг талаар бага зэрэг хэлж чадах уу?

Би тэр даруй хоёр дахь асуултыг индэрүүдийн ижил төстэй байдал, төлөвлөгөөний ижил төстэй байдлын талаар асуух болно. Төлөвлөгөө нь Postgres-ийн цуглуулсан статистик мэдээллээс хамаарна. Та энэ асуудлыг хэрхэн шийдэж байна вэ?

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

За, хэдэн минут зогсоход аймшигтай биш нимгэн клон хийцгээе. Мөн аналитикийг уншихад илүү таатай байхын тулд бид өгөгдлийг сонирхож буй баганад индекс нэмэх болно.

Индексийг тухай бүр үүсгэх үү?

Та үүнийг хийж болно, ингэснээр бид өгөгдөлд хүрч, агшин зуурын зураг авснаар бид энэ хормын хувилбараас сэргэж, шинэ хүсэлт гаргах болно. Өөрөөр хэлбэл, та үүнийг аль хэдийн хавсаргасан индексүүдээр шинэ клон үүсгэх боломжтой болгож чадна.

Статистикийн тухай асуултын хувьд, хэрэв бид нөөцлөлтөөс сэргээж, хуулбарлах юм бол бидний статистик нь яг ижил байх болно. Бидэнд бүхэл бүтэн физик өгөгдлийн бүтэц байгаа тул бид өгөгдлийг бүх статистик хэмжигдэхүүнтэй хамт авчрах болно.

Энд бас нэг асуудал байна. Хэрэв та үүлэн шийдлийг ашигладаг бол Google, Amazon танд физик хуулбарыг авахыг зөвшөөрдөггүй тул зөвхөн логик хогийн цэгүүд байдаг. Асуудал гарна.

Мэдээлэл өгсөнд баярлалаа. Энд MySQL болон нөөц хуваалцах талаар хоёр сайн асуулт байсан. Гэвч үнэн хэрэгтээ энэ нь тодорхой DBMS-ийн сэдэв биш, харин файлын системийг бүхэлд нь хамарч байгаатай холбоотой юм. Үүний дагуу нөөцийг хуваалцах асуудлыг Postgres биш, харин файлын систем, сервер, жишээ нь эндээс шийдэх ёстой.

Миний асуулт арай өөр байна. Энэ нь хэд хэдэн давхарга байдаг олон давхаргат мэдээллийн сантай илүү ойр байдаг. Жишээлбэл, бид арван терабайт зургийн шинэчлэлтийг тохируулсан, бид хуулбарлаж байна. Мөн бид энэ шийдлийг мэдээллийн санд тусгайлан ашигладаг. Хуулбарлаж байна, өгөгдлийг шинэчилж байна. Энд зэрэгцээ ажиллаж байгаа 100 ажилтан байдаг бөгөөд тэд эдгээр янз бүрийн цохилтуудыг байнга эхлүүлдэг. Юу хийх вэ? Ямар ч зөрчилдөөн байхгүй, тэд нэгийг эхлүүлсэн, дараа нь файлын систем өөрчлөгдөж, эдгээр зургууд бүгд явсан эсэхийг хэрхэн баталгаажуулах вэ?

ZFS ингэж ажилладаг учраас тэд явахгүй. Бид хуулбарлахаас үүдэлтэй файлын системийн өөрчлөлтийг нэг хэлхээнд тусад нь хадгалах боломжтой. Өгөгдлийн хуучин хувилбарууд дээр хөгжүүлэгчид ашигладаг клонуудыг хадгал. Энэ нь бидний хувьд ажилладаг, бүх зүйл эмх цэгцтэй байна.

Шинэчлэлт нь нэмэлт давхарга хэлбэрээр хийгдэх бөгөөд энэ давхарга дээр үндэслэн бүх шинэ зургууд аль хэдийн гарах болно, тийм үү?

Өмнөх хуулбаруудаас авсан өмнөх давхаргуудаас.

Өмнөх давхаргууд унах боловч хуучин давхаргад хамаарах бөгөөд шинэчлэлтэнд хүлээн авсан сүүлийн давхаргаас шинэ зураг авах уу?

Ерөнхийдөө тийм.

Үүний үр дүнд бид инжир хүртэл давхаргатай болно. Мөн цаг хугацаа өнгөрөхөд тэдгээрийг шахах шаардлагатай юу?

Тиймээ бүх зүйл зөв. Цонх байна. Бид долоо хоног бүр агшин зуурын зураг хөтөлдөг. Энэ нь танд ямар нөөц байгаа эсэхээс хамаарна. Хэрэв та маш их өгөгдөл хадгалах чадвартай бол хормын хувилбарыг удаан хугацаанд хадгалах боломжтой. Тэд өөрсдөө явахгүй. Өгөгдлийн эвдрэл гарахгүй. Хэрэв хормын хувилбарууд хуучирсан бол, өөрөөр хэлбэл компанийн бодлогоос шалтгаалж байгаа бол бид тэдгээрийг устгаад зай гаргах боломжтой.

Сайн байна уу, тайланд баярлалаа! Жогийн тухай асуулт. Үйлчлүүлэгч хүн бүрт өгөгдөлд хандах боломжийг олгохыг хүсээгүй гэж та хэлсэн. Хатуухан хэлэхэд, хэрэв хүн тайлбарлах шинжилгээний үр дүнд хүрсэн бол тэр өгөгдлийг харж чадна.

Ийм л байна. Жишээлбэл, бид "SELECT FROM WHERE email = to that" гэж бичиж болно. Өөрөөр хэлбэл, бид өгөгдлийг өөрөө харахгүй, гэхдээ бид зарим шууд бус шинж тэмдгүүдийг харж болно. Үүнийг ойлгох ёстой. Гэхдээ нөгөө талаас бүх зүйл тэнд байгаа. Бид бүртгэлийн аудит хийдэг, хөгжүүлэгчид юу хийж байгааг хардаг бусад хамт олонд хяналт тавьдаг. Хэрэв хэн нэгэн үүнийг хийх гэж оролдвол хамгаалалтын алба тэдэн дээр ирж, энэ асуудал дээр ажиллах болно.

Өдрийн мэнд Мэдээлэл өгсөнд баярлалаа! Надад товч асуулт байна. Хэрэв компани Slack ашигладаггүй бол одоо үүнийг дагаж мөрдөх шаардлагатай юу эсвэл хөгжүүлэгчид туршилтын програмыг мэдээллийн сантай холбохын тулд инстанцуудыг ашиглах боломжтой юу?

Одоо Slack-ийн холбоос байна, өөрөөр хэлбэл өөр мессенжер байхгүй, гэхдээ би бусад мессенжерүүдэд ч бас дэмжлэг үзүүлэхийг үнэхээр хүсч байна. Чи юу хийж чадах вэ? Та DB Lab-ийг Жогүйгээр суулгаж, REST API эсвэл манай платформын тусламжтайгаар явж, клон үүсгэж, PSQL-тэй холбогдож болно. Гэхдээ та хөгжүүлэгчиддээ өгөгдөлд хандах эрх өгөхөд бэлэн байгаа бол үүнийг хийж болно, учир нь ямар ч дэлгэц байхгүй болно.

Надад энэ давхарга хэрэггүй, гэхдээ надад ийм боломж хэрэгтэй байна.

Тэгвэл тийм ээ, хийж болно.

Эх сурвалж: www.habr.com