Дараах мэдээллийн санд Yandex-ийн оруулсан хувь нэмрийг хянан үзэх болно.
- clickhouse
- Odyssey
- Тодорхой хугацааны дараа сэргээх (WAL-G)
- PostgreSQL (алдаа, Amcheck, Heapcheck орно)
- Ногоон чавга
Видео:
Сайн уу дэлхий! Намайг Андрей Бородин гэдэг. Yandex.Cloud дээр миний хийдэг зүйл бол Yandex.Cloud болон Yandex.Cloud үйлчлүүлэгчдийн ашиг сонирхлын үүднээс нээлттэй харилцааны мэдээллийн санг хөгжүүлэх явдал юм.
Энэ ярианд бид нээлттэй мэдээллийн санд тулгарч буй бэрхшээлүүдийн талаар ярих болно. Яагаад чухал вэ? Учир нь шумуул шиг дараа нь заан болдог жижиг, жижиг асуудал. Олон кластертай бол тэд томордог.
Гэхдээ энэ нь гол зүйл биш юм. Гайхалтай зүйл тохиолддог. Сая тохиолдлын нэгд тохиолддог зүйлс. Мөн үүлэн орчинд та үүнд бэлэн байх ёстой, учир нь ямар нэг зүйл өргөн цар хүрээтэй байх үед гайхалтай зүйл гарах магадлал өндөр байдаг.
Гэхдээ! Нээлттэй мэдээллийн сангийн давуу тал юу вэ? Ямар ч асуудлыг шийдэх онолын боломж танд байгаа нь баримт юм. Та эх кодтой, програмчлалын мэдлэгтэй. Бид үүнийг нэгтгэж, энэ нь ажилладаг.
Нээлттэй эхийн программ хангамж дээр ажиллахад ямар арга барил байдаг вэ?
- Хамгийн энгийн арга бол програм хангамжийг ашиглах явдал юм. Хэрэв та протокол ашигладаг бол, стандарт ашигладаг бол, формат ашигладаг бол, нээлттэй эхийн програм хангамж дээр асуулга бичдэг бол та үүнийг аль хэдийн дэмждэг.
- Та түүний экосистемийг томруулж байна. Та алдааг эрт илрүүлэх магадлалыг нэмэгдүүлнэ. Та энэ системийн найдвартай байдлыг нэмэгдүүлнэ. Та зах зээлд хөгжүүлэгчдийн хүртээмжийг нэмэгдүүлнэ. Та энэ программ хангамжийг сайжруул. Хэрэв та зүгээр л загварлаг болж, тэнд ямар нэгэн зүйл хийсэн бол та аль хэдийн хувь нэмэр оруулагч болсон байна.
- Өөр нэг ойлгомжтой арга бол нээлттэй эхийн програм хангамжийг ивээн тэтгэх явдал юм. Жишээлбэл, Google-ийн сайн мэдэх Google Summer of Code хөтөлбөр, Google нь дэлхийн өнцөг булан бүрээс ирсэн олон тооны оюутнуудад ойлгомжтой мөнгө төлж, тодорхой лицензийн шаардлагыг хангасан нээлттэй програм хангамжийн төслүүдийг боловсруулдаг.
- Энэ нь олон нийтийн анхаарлыг холдуулахгүйгээр програм хангамжийг хөгжүүлэх боломжийг олгодог тул энэ нь маш сонирхолтой арга юм. Технологийн аварга компани болох Google бид энэ функцийг хүсч байна гэж хэлдэггүй, бид энэ алдааг засахыг хүсч байна, энд л ухах хэрэгтэй. Google хэлэхдээ: "Хийж байгаа зүйлээ хий. Зүгээр л өмнөх шигээ ажилла, тэгвэл бүх зүйл сайхан болно."
- Нээлттэй эх сурвалжид оролцох дараагийн арга бол оролцоо юм. Нээлттэй эхийн програм хангамжид асуудал тулгараад, хөгжүүлэгчид байгаа үед таны хөгжүүлэгчид асуудлыг шийдэж эхэлдэг. Тэд таны дэд бүтцийг илүү үр ашигтай, хөтөлбөрүүдийг илүү хурдан, найдвартай болгож эхэлдэг.
Нээлттэй эхийн програм хангамжийн салбарт хамгийн алдартай Yandex төслүүдийн нэг бол ClickHouse юм. Энэ бол Yandex.Metrica-д тулгарч буй сорилтод хариу үйлдэл үзүүлэх үүднээс үүссэн мэдээллийн сан юм.
Мэдээллийн сангийн хувьд экосистемийг бий болгож, бусад хөгжүүлэгчидтэй (зөвхөн Yandex дотор биш) хөгжүүлэхийн тулд нээлттэй эх сурвалжаар хийсэн. Одоо энэ бол олон янзын компаниуд оролцож байгаа том төсөл юм.
Yandex.Cloud дээр бид ClickHouse-ийг Yandex Object Storage дээр, өөрөөр хэлбэл үүлэн хадгалах сангийн дээд талд үүсгэсэн.
Энэ нь яагаад үүлэнд чухал вэ? Учир нь ямар ч мэдээллийн сан энэ гурвалжин, энэ пирамид, санах ойн төрлүүдийн шатлалд ажилладаг. Та хурдан боловч жижиг бүртгэлтэй, хямд том боловч удаан SSD, хатуу диск болон бусад блок төхөөрөмжүүдтэй. Хэрэв та пирамидын дээд хэсэгт үр ашигтай байвал хурдан мэдээллийн сантай болно. Хэрэв та энэ пирамидын доод хэсэгт үр ашигтай байвал танд масштабтай мэдээллийн сан байна. Үүнтэй холбогдуулан доороос өөр давхарга нэмэх нь мэдээллийн сангийн өргөтгөх чадварыг нэмэгдүүлэх логик арга юм.
Үүнийг яаж хийх байсан бэ? Энэ бол энэ тайлангийн чухал цэг юм.
- Бид ClickHouse-г MDS-ээр дамжуулан хэрэгжүүлж чадна. MDS нь Yandex үүл хадгалах дотоод интерфейс юм. Энэ нь нийтлэг S3 протоколоос илүү төвөгтэй боловч блок төхөөрөмжид илүү тохиромжтой. Энэ нь өгөгдөл бичихэд илүү тохиромжтой. Энэ нь илүү их програмчлал шаарддаг. Программистууд программ хийх болно, энэ нь бүр сайн, сонирхолтой юм.
- S3 нь зарим төрлийн ажлын ачаалалд бага дасан зохицох зардлаар интерфэйсийг илүү хялбар болгодог илүү түгээмэл арга юм.
Мэдээжийн хэрэг, ClickHouse экосистемийг бүхэлд нь функцээр хангаж, Yandex.Cloud дотор шаардлагатай даалгаврыг гүйцэтгэхийг хүсч байгаа тул бид ClickHouse нийгэмлэгийг бүхэлд нь ашиг тус хүртэх болно гэдэгт итгэлтэй байхаар шийдсэн. Бид ClickHouse-г MDS дээр биш, харин ClickHouse-г S3 дээр хэрэгжүүлсэн. Мөн энэ бол маш их ажил юм.
Ашигласан материал:
"Файлын системийн хийсвэр давхарга"
"AWS SDK S3 нэгдэл"
"S3-д зориулсан IDisk интерфэйсийн үндсэн хэрэгжилт"
"IDisk интерфейстэй бүртгэл хадгалах системийг нэгтгэх"
"S3 болон SeekableReadBuffer-д зориулсан хөдөлгүүрийн дэмжлэгийг бүртгэх"
"Storage Stripe Log S3 дэмжлэг"
"S3-д зориулсан Storage MergeTree-н анхны дэмжлэг"
"MergeTree S3-ийг бүрэн дэмждэг"
"S3 дээр ReplicatedMergeTree-г дэмжих"
"S3 санах ойд өгөгдмөл итгэмжлэл болон захиалгат толгойг нэмэх"
"Динамик прокси тохиргоотой S3"
"Прокси шийдэгчтэй S3"
Энэ бол ClickHouse-д виртуал файлын системийг хэрэгжүүлэх татах хүсэлтийн жагсаалт юм. Энэ бол маш олон тооны татах хүсэлт юм.
Ашигласан материал:
"DiskS3 хатуу холбоосууд оновчтой хэрэгжилт"
"S3 HTTP клиент - Хариултын урсгалыг санах ой руу хуулахаас зайлсхий"
“Хариултын урсгалыг бүхэлд нь S3 HTTP-д санах ой руу хуулахаас зайлсхий
үйлчлүүлэгч"
"S3 дискний файлуудыг тэмдэглэж, индексжүүлэх чадвар"
"DiskLocal-аас DiskS3 руу хэсгүүдийг зэрэгцүүлэн шилжүүлэх"
Гэвч ажил үүгээр дууссангүй. Энэ функцийг хийсний дараа энэ функцийг оновчтой болгохын тулд нэмэлт ажил хийх шаардлагатай болсон.
Ашигласан материал:
"SelectedRows болон SelectedBytes үйл явдлуудыг нэмэх"
"S3 хүсэлтээс system.events руу профайл үүсгэх үйл явдлуудыг нэмэх"
"QueryTimeMicroseconds, SelectQueryTimeMicroseconds болон InsertQueryTimeMicroseconds нэмэх"
Тэгээд л оношлогдох, хяналт тавих, удирдах боломжтой болгох хэрэгтэй байсан.
Энэ ажлын үр дүнг бүхэл бүтэн нийгэмлэг, бүх ClickHouse экосистем хүлээн авахын тулд энэ бүгдийг хийсэн.
Хувь хүний хувьд надад илүү ойр байдаг гүйлгээний мэдээллийн сан, OLTP мэдээллийн сан руу шилжье.
Энэ бол нээлттэй эхийн DBMS боловсруулах хэлтэс юм. Эдгээр залуус гүйлгээний нээлттэй мэдээллийн санг сайжруулахын тулд гудамжны ид шидийг хийж байна.
Бид хэрхэн, юу хийдэг талаар жишээ болгон ярьж болох төслүүдийн нэг бол Postgres дахь Connection Pooler юм.
Postgres бол процессын мэдээллийн сан юм. Энэ нь мэдээллийн сан нь гүйлгээг зохицуулах боломжтой аль болох цөөн сүлжээний холболттой байх ёстой гэсэн үг юм.
Нөгөөтэйгүүр, үүлэн орчинд нэг кластерт нэг дор мянган холболт ирэх нь ердийн нөхцөл байдал юм. Холболт үүсгэгчийн даалгавар бол хэдэн мянган холболтыг цөөн тооны серверийн холболтод оруулах явдал юм.
Холболтын нэгтгэгч нь мэдээллийн санд үр дүнтэй хүрэхийн тулд байтуудыг дахин зохион байгуулдаг утасны оператор гэж хэлж болно.
Харамсалтай нь орос хэлэнд холболтын нэгдэл гэдэг сайн үг байдаггүй. Заримдаа үүнийг олон талт холболт гэж нэрлэдэг. Хэрэв та холболтын нэгтгэгчийг юу гэж нэрлэхээ мэдэж байгаа бол надад хэлээрэй, би орос техникийн зөв хэлээр ярихдаа маш их баяртай байх болно.
Бид удирддаг postgres кластерт тохирох холболтын нэгтгэгчийг судалсан. PgBouncer бол бидний хувьд хамгийн сайн сонголт байсан. Гэхдээ бид PgBouncer-тэй холбоотой хэд хэдэн асуудалтай тулгарсан. Олон жилийн өмнө Володя Бородин бид PgBouncer ашигладаг, бидэнд бүх зүйл таалагддаг, гэхдээ нюансууд байдаг, ажиллах зүйл байгаа гэсэн тайланг гаргаж байсан.
Тэгээд бид ажилласан. Бид тулгарсан асуудлаа засч, Bouncer-ийг нөхөж, татах хүсэлтийг дээд тал руу түлхэхийг оролдсон. Гэхдээ үндсэн нэг урсгалтай ажиллахад хэцүү байсан.
Бид нөхөөстэй Bouncers-аас каскад цуглуулах хэрэгтэй болсон. Бидэнд олон дан урсгалтай Bouncers байгаа үед дээд давхарга дээрх холболтууд Bouncers-ийн дотоод давхарга руу шилждэг. Энэ бол бүтээн байгуулалт, нааш цааш өргөжүүлэхэд хэцүү, менежмент муутай систем юм.
Бид Одиссей гэж нэрлэгддэг өөрийн холболт үүсгэгчийг бүтээсэн гэсэн дүгнэлтэд хүрсэн. Бид үүнийг эхнээс нь бичсэн.
2019 онд PgCon бага хурал дээр би энэ цуглуулагчийг хөгжүүлэгчдийн нийгэмлэгт танилцуулсан. Одоо бид GitHub дээр 2 хүрэхгүй одтой, өөрөөр хэлбэл төсөл амьд байна, төсөл нь алдартай.
Хэрэв та Yandex.Cloud дээр Postgres кластер үүсгэсэн бол энэ нь кластерыг нааш цааш нь масштаблах үед дахин тохируулагдсан Odyssey-тай кластер байх болно.
Энэ төслөөс бид юу сурсан бэ? Өрсөлдөгч төслийг эхлүүлэх нь ямагт түрэмгий алхам бөгөөд хангалттай хурдан шийдэгдээгүй, бидэнд тохирсон цаг хугацааны интервалаар шийдэгдэхгүй байгаа асуудлууд байна гэж хэлэхэд энэ нь туйлын арга хэмжээ юм. Гэхдээ энэ бол үр дүнтэй арга хэмжээ юм.
PgBouncer илүү хурдан хөгжиж эхэлсэн.
Одоо бусад төслүүд гарч ирэв. Жишээлбэл, Red Hat хөгжүүлэгчдийн бүтээсэн pgagroal. Тэд ижил төстэй зорилго тавьж, ижил төстэй санаануудыг хэрэгжүүлдэг, гэхдээ мэдээжийн хэрэг, өөрсдийн онцлог шинж чанартай бөгөөд энэ нь pgagroal хөгжүүлэгчдэд илүү ойр байдаг.
Postgres нийгэмлэгтэй хамтран ажиллах өөр нэг тохиолдол бол цаг хугацааны хувьд сэргээх явдал юм. Энэ бол бүтэлгүйтлийн дараа сэргээх, энэ бол нөөцлөлтөөс сэргээх явдал юм.
Олон нөөцлөлт байдаг бөгөөд тэдгээр нь бүгд өөр өөр байдаг. Бараг бүх Postgres борлуулагч өөрийн нөөцийн шийдэлтэй байдаг.
Хэрэв та бүх нөөцлөлтийн системийг авч, онцлог матриц үүсгэж, энэ матриц дахь тодорхойлогчийг хошигнолоор тооцвол энэ нь тэг болно. Энэ юу гэсэн үг вэ? Хэрэв та тодорхой нөөц файл авбал бусад бүх хэсгээс угсарч болохгүй. Хэрэгжүүлээд байгаагаараа, зорилгынхоо хувьд, шингэсэн санаагаараа онцлогтой. Мөн тэд бүгд тодорхой байна.
Биднийг энэ асуудал дээр ажиллаж байх үед CitusData WAL-G төслийг эхлүүлсэн. Энэ бол үүлэн орчинг харгалзан бүтээсэн нөөц систем юм. Одоо CitusData аль хэдийн Microsoft-ын нэг хэсэг болсон. Тэр үед WAL-G-ийн анхны хувилбаруудад дурдсан санаанууд бидэнд үнэхээр таалагдсан. Тэгээд бид энэ төсөлд хувь нэмрээ оруулж эхэлсэн.
Одоо энэ төсөлд олон арван хөгжүүлэгчид байгаа боловч WAL-G-ийн шилдэг 10 оролцогчид 6 Yandexoids багтсан байна. Тэнд бид олон санаагаа авчирсан. Мэдээжийн хэрэг, бид тэдгээрийг өөрсдөө хэрэгжүүлж, өөрсдөө туршиж, өөрсдөө үйлдвэрлэлд нэвтрүүлж, өөрсдөө ашигладаг, WAL-G том нийгэмлэгтэй харилцаж, дараа нь хаашаа шилжихээ өөрсдөө шийддэг.
Бидний үзэж байгаагаар одоо энэхүү нөөцлөх систем, түүний дотор бидний хүчин чармайлтыг харгалзан үзэх нь үүлэн орчинд оновчтой болсон. Энэ нь Postgres-ийг үүлэн дээр нөөцлөх хамгийн сайн зардал юм.
Энэ нь юу гэсэн үг вэ? Бид маш том санааг дэвшүүлж байсан: нөөцлөх нь найдвартай, ашиглахад хямд, сэргээхэд аль болох хурдан байх ёстой.
Үйл ажиллагаа явуулахад яагаад хямд байх ёстой гэж? Юу ч эвдэрсэн үед та нөөцлөлттэй гэдгээ мэдэхгүй байх ёстой. Бүх зүйл хэвийн ажиллаж, та аль болох бага CPU зарцуулж, дискний нөөцөө аль болох бага ашиглаж, үнэ цэнэтэй үйлчилгээнийхээ ачаалалд саад учруулахгүйн тулд сүлжээнд аль болох цөөн байт илгээдэг.
Бүх зүйл эвдэрсэн үед, жишээлбэл, админ нь өгөгдлийг унагасан, ямар нэг зүйл буруу болсон, та яаралтай өнгөрсөн рүү буцах шаардлагатай бол та бүх мөнгөөр сэргээгдэх болно, учир нь та мэдээллээ хурдан, бүрэн бүтэн байлгахыг хүсч байна.
Мөн бид энэ энгийн санааг сурталчилсан. Тэгээд бид үүнийг хэрэгжүүлж чадсан юм шиг санагдаж байна.
Гэхдээ энэ нь бүгд биш юм. Бид өөр нэг жижиг зүйлийг хүсч байсан. Бид олон янзын мэдээллийн санг хүсч байсан. Манай бүх үйлчлүүлэгчид Postgres ашигладаггүй. Зарим хүмүүс MySQL, MongoDB ашигладаг. Нийгэмд бусад хөгжүүлэгчид FoundationDB-ийг дэмждэг. Мөн энэ жагсаалт байнга өргөжиж байна.
Нийгэмлэг мэдээллийн баазыг үүлэн доторх менежменттэй орчинд ажиллуулах санааг дуртай. Мөн хөгжүүлэгчид өөрсдийн мэдээллийн баазыг хадгалдаг бөгөөд үүнийг манай нөөц системээр Postgres-ийн хамт жигд нөөцлөх боломжтой.
Энэ түүхээс бид юу сурсан бэ? Манай бүтээгдэхүүн бол хөгжлийн хэлтсийн хувьд кодын мөр биш, мэдэгдэл биш, файл биш юм. Манай бүтээгдэхүүн татах хүсэлт биш юм. Энэ бол бидний нийгэмд хүргэх санаанууд юм. Энэ бол технологийн туршлага, технологийн үүлэн орчин руу шилжих хөдөлгөөн юм.
Postgres гэх мэт мэдээллийн сан байдаг. Би Postgres цөмд хамгийн их дуртай. Би олон нийттэй Postgres цөмийг хөгжүүлэхэд маш их цаг зарцуулдаг.
Гэхдээ энд Yandex.Cloud нь удирддаг мэдээллийн сангийн дотоод суурилуулалттай гэдгийг хэлэх ёстой. Энэ нь Yandex.Mail дээр нэлээд эрт эхэлсэн. Постгресийг удирдахад хүргэсэн туршлага нь шуудан Postgres руу шилжихийг хүссэн үед хуримтлагдсан.
Мэйл нь үүлтэй маш төстэй шаардлага тавьдаг. Энэ нь таныг өгөгдлийн аль ч цэгт гэнэтийн экспоненциал өсөлтөд хүргэх чадвартай байх шаардлагатай. Захидал нь олон тооны хүсэлтийг байнга гаргадаг асар олон тооны хэрэглэгчдийн хэдэн зуун сая шуудангийн хайрцгаар аль хэдийн ачаалалтай байсан.
Энэ нь Postgres-ийг хөгжүүлж буй багийн хувьд нэлээд ноцтой сорилт байсан юм. Тухайн үед бидэнд тулгарсан аливаа асуудлыг нийгэмд мэдээлж байсан. Мөн эдгээр асуудлуудыг зарим газар бусад мэдээллийн санд төлбөртэй дэмжлэг үзүүлэх түвшинд, бүр илүү дээр нь засч залруулж, засч залруулсан. Өөрөөр хэлбэл, та PgSQL хакер руу захидал илгээж, 40 минутын дотор хариу авах боломжтой. Зарим мэдээллийн сан дахь төлбөртэй дэмжлэг нь таны алдаанаас илүү чухал зүйл гэж бодож магадгүй юм.
Одоо Postgres-ийн дотоод суурилуулалт нь хэдэн петабайт өгөгдөл юм. Эдгээр нь секундэд хэдэн сая хүсэлт юм. Эдгээр нь олон мянган кластерууд юм. Энэ нь маш том хэмжээтэй.
Гэхдээ нэг нюанс бий. Энэ нь гоёмсог сүлжээний хөтчүүд дээр биш, харин нэлээд энгийн техник хангамж дээр амьдардаг. Мөн сонирхолтой шинэ зүйлсийг тусгайлан тестлэх орчин бий.
Туршилтын орчинд тодорхой агшинд бид мэдээллийн сангийн индексийн дотоод хувиргагчийг зөрчсөн гэсэн мессеж хүлээн авсан.
Инвариант гэдэг нь бидний үргэлж хадгална гэж найдаж буй зарим төрлийн харилцаа юм.
Бидний хувьд маш хүнд нөхцөл байдал. Энэ нь зарим өгөгдөл алдагдсан байж болзошгүйг харуулж байна. Мөн өгөгдөл алдагдах нь үнэхээр сүйрлийн зүйл юм.
Бидний удирддаг мэдээллийн санд дагаж мөрддөг ерөнхий санаа бол хүчин чармайлт гаргасан ч өгөгдлийг алдахад хэцүү байх болно. Хэдийгээр та тэдгээрийг зориудаар устгасан ч удаан хугацааны туршид байхгүй байгааг үл тоомсорлох шаардлагатай болно. Мэдээллийн аюулгүй байдал бол бидний маш шаргуу дагаж мөрддөг шашин юм.
Эндээс бид бэлэн биш байж магадгүй нөхцөл байдал үүсч магадгүй гэсэн нөхцөл байдал үүсч байна. Тэгээд бид энэ байдалд бэлдэж эхэлсэн.
Бидний хийсэн хамгийн эхний зүйл бол эдгээр олон мянган кластеруудын гуалиныг булах явдал байв. Бид аль кластерууд нь өгөгдлийн хуудасны шинэчлэлтийг алдаж байгаа асуудалтай програм хангамжтай дискнүүд дээр байрлаж байгааг олж мэдсэн. Бүх Postgres өгөгдлийн кодыг тэмдэглэсэн. Мөн бид мэдээллийн эвдрэлийг илрүүлэхэд зориулагдсан код бүхий дотоод өөрчлөлтийн зөрчлийг харуулсан мессежүүдийг тэмдэглэв.
Энэ нөхөөсийг олон нийт хэлэлцэлгүйгээр бараг хүлээн зөвшөөрсөн, учир нь тодорхой тохиолдол бүрт ямар нэгэн муу зүйл тохиолдсон нь илт байсан тул бүртгэлд мэдэгдэх шаардлагатай байв.
Үүний дараа бид бүртгэлийг сканнердах хяналттай болсон. Мөн сэжигтэй мессеж ирсэн тохиолдолд тэр жижүүрийг сэрээж, жижүүр үүнийг засдаг.
Гэхдээ! Бүртгэлийг сканнердах нь нэг кластер дээр хямдхан үйл ажиллагаа бөгөөд мянган кластерт сүйрлийн үнэтэй байдаг.
Бид нэртэй өргөтгөл бичсэн . Энэ нь өмнөх алдаануудын статистикийг хямд, хурдан сонгох боломжтой мэдээллийн сангийн харагдацыг бий болгодог. Хэрэв бид жижүүрийг сэрээх шаардлагатай бол гигабайт файлуудыг сканнердахгүйгээр, харин хэш хүснэгтээс хэдэн байт гаргаж авах замаар энэ талаар олж мэдэх болно.
Энэ өргөтгөлийг, жишээлбэл, хадгалах санд баталсан . Хэрэв та үүнийг ашиглахыг хүсвэл өөрөө суулгаж болно. Мэдээжийн хэрэг, энэ нь нээлттэй эх сурвалж юм.
Гэхдээ энэ нь бүгд биш юм. Бид индексүүдээс өөрчлөгдөөгүй зөрчлийг илрүүлэхийн тулд олон нийтийн бүтээсэн өргөтгөл болох Amcheck-ийг ашиглаж эхэлсэн.
Хэрэв та үүнийг масштабаар ажиллуулбал алдаанууд байгааг бид олж мэдсэн. Бид тэдгээрийг засаж эхэлсэн. Бидний засварыг хүлээн авлаа.
Энэ өргөтгөл нь GiST & GIT индексүүдэд дүн шинжилгээ хийх боломжгүй гэдгийг бид олж мэдсэн. Бид тэднийг дэмжсэн. Гэхдээ энэ дэмжлэгийг олон нийт хэлэлцэж байна, учир нь энэ нь харьцангуй шинэ функц бөгөөд маш олон нарийн ширийн зүйл байдаг.
Мөн бид хуулбарлах удирдагч, мастер дээрх зөрчлийн индексийг шалгахдаа бүх зүйл сайн ажилладаг боловч хуулбар, дагагч дээр авлигыг хайх нь тийм ч үр дүнтэй биш болохыг олж мэдсэн. Бүх инвариантуудыг шалгадаггүй. Мөн нэг инвариант биднийг маш их зовоосон. Хуулбаруудыг шалгахын тулд бид нэг жил хагасын турш олон нийттэй харилцахад зарцуулсан.
Бид бүх can... протоколуудыг дагаж мөрдөх код бичсэн. Бид энэ нөхөөсийг Crunchy Data-аас Питер Гагантай нэлээд удаан ярилцсан. Тэрээр энэ нөхөөсийг хүлээн авахын тулд Postgres дахь одоо байгаа В модыг бага зэрэг өөрчлөх шаардлагатай болсон. Түүнийг хүлээн зөвшөөрсөн. Одоо хуулбар дээрх индексийг шалгах нь бидэнд тохиолдсон зөрчлийг илрүүлэхэд хангалттай үр дүнтэй болсон. Өөрөөр хэлбэл эдгээр нь дискний програм хангамжийн алдаа, Postgres дахь алдаа, Линуксийн цөм дэх алдаа, техник хангамжийн асуудлаас үүдэлтэй байж болох зөрчил юм. Бидний бэлтгэж байсан асуудлын эх сурвалжуудын нэлээд өргөн жагсаалт.
Гэхдээ индексээс гадна овоо, өөрөөр хэлбэл өгөгдөл хадгалагдах газар гэх мэт хэсэг байдаг. Мөн шалгах боломжтой инвариантууд тийм ч олон байдаггүй.
Бидэнд Heapcheck нэртэй өргөтгөл бий. Бид үүнийг хөгжүүлж эхэлсэн. Үүнтэй зэрэгцэн бидэнтэй хамт EnterpriseDB компани модулийг бичиж эхэлсэн бөгөөд үүнийг Heapcheck гэж нэрлэдэг. Зөвхөн бид үүнийг PgHeapcheck гэж нэрлэсэн бөгөөд тэд үүнийг Heapcheck гэж нэрлэсэн. Тэд ижил төстэй функцтэй, арай өөр гарын үсэгтэй, гэхдээ ижил санаатай байдаг. Тэдгээрийг зарим газар арай илүү хэрэгжүүлсэн. Тэд үүнийг өмнө нь нээлттэй эх сурвалжид нийтэлсэн.
Одоо бид тэдний тэлэлтийг хөгжүүлж байна, учир нь энэ нь тэдний тэлэлт байхаа больсон, харин нийгэмлэгийн тэлэлт юм. Ирээдүйд энэ нь хүн бүрт нийлүүлэгдэх цөмийн нэг хэсэг бөгөөд ингэснээр ирээдүйн асуудлын талаар урьдчилан мэдэж болно.
Зарим газарт бид хяналтын системдээ хуурамч эерэг үзүүлэлттэй байна гэсэн дүгнэлтэд хүртэл хүрсэн. Жишээлбэл, 1С систем. Өгөгдлийн санг ашиглахдаа Postgres заримдаа унших боломжтой өгөгдлийг бичдэг ч pg_dump уншиж чаддаггүй.
Энэ байдал манай асуудал илрүүлэх системд авлига мэт харагдсан. Жижүүрийг сэрээв. Жижүүр юу болж байгааг харав. Хэсэг хугацааны дараа үйлчлүүлэгч ирээд асуудалтай байна гэж хэлсэн. Асуудал юу болохыг үйлчлэгч тайлбарлав. Гэхдээ асуудал нь Postgres-ийн цөмд байна.
Би энэ функцийн талаархи хэлэлцүүлгийг олсон. Тэгээд тэр бид ийм шинж чанартай тулгарсан бөгөөд энэ нь тааламжгүй байсан гэж бичжээ, хүн энэ нь юу болохыг олж мэдэхийн тулд шөнө сэрдэг.
Нийгэмлэг "Өө, бид үүнийг үнэхээр засах хэрэгтэй байна" гэж хариулав.
Надад энгийн зүйрлэл бий. Хэрэв та элсний ширхэгтэй гутал өмсөж байгаа бол зарчмын хувьд та цаашаа явж болно - асуудалгүй. Хэдэн мянган хүнд гутал зардаг бол ерөөсөө элсгүй гутал хийцгээе. Хэрэв таны гутлын хэрэглэгчдийн нэг нь марафон гүйх гэж байгаа бол та маш сайн гутал хийж, дараа нь бүх хэрэглэгчдэдээ хүргэхийг хүсч байна. Ийм гэнэтийн хэрэглэгчид үргэлж үүлэн орчинд байдаг. Кластерыг ямар нэгэн анхны аргаар ашигладаг хэрэглэгчид үргэлж байдаг. Та үүнд үргэлж бэлтгэлтэй байх ёстой.
Бид энд юу сурсан бэ? Бид энгийн зүйлийг сурсан: хамгийн гол нь нийгэмд асуудал байгаа гэдгийг тайлбарлах явдал юм. Хэрэв олон нийт асуудлыг хүлээн зөвшөөрсөн бол асуудлыг шийдэхийн тулд байгалийн өрсөлдөөн бий болно. Яагаад гэвэл хүн бүр чухал асуудлыг шийдэхийг хүсдэг. Бүх борлуулагчид, бүх хакерууд өөрсдөө энэ тармуур дээр гишгэж чадна гэдгээ ойлгодог тул тэдгээрийг арилгахыг хүсч байна.
Хэрэв та ямар нэгэн асуудал дээр ажиллаж байгаа ч энэ нь чамаас өөр хэнд ч төвөг учруулахгүй, гэхдээ та үүнийг системтэйгээр боловсруулж, эцэст нь асуудал гэж үзэж байгаа бол таны татах хүсэлтийг хүлээн авах нь гарцаагүй. Таны засварыг хүлээн авах болно, таны сайжруулалт эсвэл сайжруулах хүсэлтийг олон нийт хянан үзэх болно. Эцсийн эцэст бид мэдээллийн санг бие биедээ илүү сайн болгодог.
Сонирхолтой мэдээллийн сан бол Greenplum юм. Энэ бол миний сайн мэддэг Postgres кодын санд суурилсан маш зэрэгцээ мэдээллийн сан юм.
Greenplum нь сонирхолтой функцтэй - оновчтой хүснэгтүүдийг хавсаргана. Эдгээр нь та хурдан нэмж болох хүснэгтүүд юм. Тэдгээр нь багана эсвэл эгнээ байж болно.
Гэхдээ кластер байхгүй, өөрөөр хэлбэл хүснэгтэд байгаа өгөгдлийг аль нэг индекст байгаа дарааллаар нь цэгцлэх функц байхгүй байсан.
Таксины залуус над дээр ирээд: "Андрей, чи Постгресийг мэднэ. Мөн энд бараг ижил байна. 20 минут руу шилжүүл. Та үүнийг аваад хий” гэсэн. Тийм ээ, би Постгресийг мэддэг, 20 минутын турш солигддог гэж би бодсон - би үүнийг хийх хэрэгтэй.
Гэхдээ үгүй ээ, 20 минут болоогүй, би үүнийг хэдэн сараар бичсэн. PgConf.Russia бага хурлын үеэр би Пивоталаас Хейки Линакангас руу хандаж, “Үүнд ямар нэгэн асуудал байна уу? Яагаад хавсралтын оновчтой хүснэгтийн кластер байхгүй байна вэ?" Тэрээр: "Та өгөгдлийг авна. Та эрэмбэлж, дахин зохион байгуул. Энэ бол зүгээр л ажил." Би: "Өө, тийм ээ, чи зүгээр л аваад хийх хэрэгтэй." Тэр: "Тийм ээ, үүнийг хийхийн тулд бидэнд чөлөөтэй гар хэрэгтэй." Би үүнийг заавал хийх хэрэгтэй гэж бодсон.
Хэдэн сарын дараа би энэ функцийг хэрэгжүүлсэн татах хүсэлтийг илгээсэн. Энэхүү татах хүсэлтийг Пивотал нийгэмлэгтэй хамтран хянан үзсэн. Мэдээжийн хэрэг, алдаанууд байсан.
Гэхдээ хамгийн сонирхолтой нь энэ татах хүсэлтийг нэгтгэхэд Greenplum-аас алдаанууд илэрсэн. Бид нуруулдан хүснэгтүүд нь кластерт байх үед гүйлгээг эвддэг болохыг олж мэдсэн. Мөн энэ бол засч залруулах ёстой зүйл юм. Тэгээд тэр миний сая хүрсэн газар байна. Миний төрөлхийн хариу үйлдэл бол яахав, би ч бас үүнийг хийгээч.
Би энэ алдааг зассан. Засварчид руу татах хүсэлт илгээсэн. Тэр алагдсан.
Үүний дараа энэ функцийг PostgreSQL 12-д зориулсан Greenplum хувилбараас авах шаардлагатай болсон. Өөрөөр хэлбэл 20 минутын адал явдал шинэ сонирхолтой адал явдлуудаар үргэлжилж байна. Нийгэмлэг шинэ, хамгийн чухал шинж чанаруудыг таслан зогсоож буй өнөөгийн хөгжлийг хөндөх нь сонирхолтой байв. Энэ нь хөлдсөн байна.
Гэхдээ үүгээр дууссангүй. Эцсийн эцэст бид энэ бүхний баримт бичгийг бичих шаардлагатай болсон.
Би бичиг баримт бичиж эхэлсэн. Азаар Pivotal-ын баримтат киночид ирсэн. Англи хэл бол тэдний төрөлх хэл юм. Тэд надад бичиг баримт бүрдүүлэхэд тусалсан. Үнэндээ тэд өөрсдөө миний санал болгосон зүйлийг жинхэнэ англи хэлээр дахин бичсэн.
Энд л адал явдал дууссан бололтой. Тэгээд юу болсныг та мэдэх үү? Таксины залуус над дээр ирээд: "Одоо ч гэсэн хоёр адал явдал байна, тус бүр нь 10 минут." Тэгээд би тэдэнд юу хэлэх ёстой вэ? Би одоо масштабын талаар тайлан өгье, дараа нь бид таны адал явдлуудыг харах болно гэж хэлсэн, учир нь энэ бол сонирхолтой ажил юм.
Энэ хэргээс бид юу сурсан бэ? Нээлттэй эх сурвалжтай ажиллах нь үргэлж тодорхой хүнтэй ажилладаг учраас олон нийттэй байнга хамтран ажилладаг. Яагаад гэвэл үе шат болгондоо би зарим хөгжүүлэгч, зарим тестер, зарим хакер, зарим баримт бичиг, зарим архитектортой ажиллаж байсан. Би Greenplum-тай ажиллаагүй, Greenplum-ийн эргэн тойронд байгаа хүмүүстэй ажиллаж байсан.
Гэхдээ! Өөр нэг чухал зүйл бий - энэ бол зүгээр л ажил. Энэ нь та ирж, кофе ууж, код бичнэ үү. Бүх төрлийн энгийн инвариантууд ажилладаг. Үүнийг ердийн байдлаар хий - энэ нь зүгээр байх болно! Мөн энэ нь нэлээд сонирхолтой ажил юм. Yandex.Cloud үйлчлүүлэгчид болох манай кластерын хэрэглэгчид Yandex дотор болон гаднаас энэ ажилд хүсэлт гаргаж байна. Мөн бидний оролцох төслүүдийн тоо нэмэгдэж, бидний оролцоо ч нэмэгдэнэ гэж бодож байна.
Тэгээд л болоо. Асуултууд руугаа орцгооё.
Асуулт хуралдаан
Сайн уу? Бидэнд өөр нэг асуулт хариулт байна. Андрей Бородин студид. Энэ бол Yandex.Cloud болон Yandex-ийн нээлттэй эх сурвалжид оруулсан хувь нэмрийн талаар танд хэлсэн хүн юм. Одоо бидний тайлан бүхэлдээ Үүлний тухай биш, гэхдээ бид ийм технологид суурилсан болно. Yandex дотор хийсэн зүйлгүйгээр Yandex.Cloud-д ямар ч үйлчилгээ байхгүй байсан тул надад хувь хүнийхээ зүгээс баярлалаа. Нэвтрүүлгийн эхний асуулт: "Таны дурдсан төсөл бүр юун дээр бичигдсэн бэ?"
WAL-G дахь нөөцлөх системийг Go дээр бичсэн. Энэ бол бидний ажиллаж байсан шинэ төслүүдийн нэг юм. Тэр яг үнэндээ дөнгөж 3 настай. Мөн мэдээллийн сан нь ихэвчлэн найдвартай байдлын тухай байдаг. Энэ нь мэдээллийн сан нь нэлээд хуучирсан бөгөөд ихэвчлэн C хэл дээр бичигдсэн гэсэн үг юм. Postgres төсөл 30 орчим жилийн өмнө эхэлсэн. Дараа нь C89 зөв сонголт байсан. Мөн үүн дээр Postgres бичигдсэн байдаг. ClickHouse гэх мэт илүү орчин үеийн мэдээллийн сангууд ихэвчлэн C++ хэл дээр бичигдсэн байдаг. Бүх системийн хөгжүүлэлт нь C болон C++ дээр суурилдаг.
Клоуд дахь зардлыг хариуцдаг санхүүгийн менежерийн асуулт: "Клоуд яагаад нээлттэй эхийг дэмжихэд мөнгө зарцуулдаг вэ?"
Санхүүгийн менежерт өгөх энгийн хариулт энд байна. Бид үйлчилгээгээ сайжруулахын тулд үүнийг хийдэг. Бид ямар арга замаар илүү сайн хийж чадах вэ? Бид аливаа зүйлийг илүү үр дүнтэй, хурдан хийж, илүү өргөн цар хүрээтэй болгож чадна. Гэхдээ бидний хувьд энэ түүх нь хамгийн түрүүнд найдвартай байдлын тухай юм. Жишээлбэл, нөөцлөх системд бид түүнд хамаарах засваруудыг 100% хянадаг. Код нь юу болохыг бид мэднэ. Мөн бид шинэ хувилбаруудыг үйлдвэрлэлд нэвтрүүлэхэд илүү таатай байна. Энэ нь юуны түрүүнд өөртөө итгэх итгэл, хөгжилд бэлэн байх, найдвартай байдлын тухай юм
Өөр нэг асуулт: "Yandex.Cloud-д амьдардаг гадаад хэрэглэгчдийн шаардлага нь дотоод Cloud-д амьдардаг дотоод хэрэглэгчээс ялгаатай юу?"
Мэдээжийн хэрэг ачааллын профайл өөр байна. Гэхдээ миний хэлтсийн үүднээс онцгой, сонирхолтой бүх тохиолдлууд нь стандартын бус ачаалал дээр үүсдэг. Төсөөлөлтэй хөгжүүлэгчид, гэнэтийн зүйлийг хийдэг хөгжүүлэгчид дотоод болон гадаад аль алинд нь олддог. Үүнтэй холбогдуулан бид бүгдээрээ ойролцоогоор адилхан. Yandex мэдээллийн сангийн үйл ажиллагааны цорын ганц чухал шинж чанар нь Yandex дотор бид сургамжтай байх явдал юм. Хэзээ нэгэн цагт зарим бэлэн байдлын бүс бүрэн сүүдэрт ордог бөгөөд Yandex-ийн бүх үйлчилгээ ямар нэгэн байдлаар үргэлжлүүлэн ажиллах ёстой. Энэ бол жижиг ялгаа юм. Гэхдээ энэ нь өгөгдлийн сан болон сүлжээний стекийн интерфейс дээр маш их судалгааны хөгжүүлэлтийг бий болгодог. Үгүй бол гадаад болон дотоод суурилуулалт нь найдвартай байдал, гүйцэтгэлийг сайжруулахын тулд онцлог шинж чанарууд болон ижил төстэй хүсэлтүүдийг үүсгэдэг.
Дараагийн асуулт: "Таны хийдэг ихэнх зүйлийг бусад үүлнүүд ашигладаг гэсэн та хувьдаа ямар бодолтой байдаг вэ?" Бид тодорхой нэгийг нэрлэхгүй, гэхдээ Yandex.Cloud дээр хийгдсэн олон төслүүдийг бусад хүмүүсийн үүлэнд ашигладаг.
Энэ сайхан байна. Нэгдүгээрт, энэ нь бид зөв зүйл хийсэний шинж тэмдэг юм. Мөн энэ нь эго-г мааждаг. Мөн бид зөв шийдвэр гаргасан гэдэгтээ илүү итгэлтэй байна. Нөгөөтэйгүүр, энэ нь ирээдүйд шинэ санаа, гуравдагч этгээдийн хэрэглэгчдийн шинэ хүсэлтийг бидэнд авчирна гэж найдаж байна. GitHub дээрх ихэнх асуудлуудыг бие даасан системийн администраторууд, хувь хүний DBA-ууд, бие даасан архитекторууд, хувь хүний инженерүүд бий болгодог боловч заримдаа системчилсэн туршлагатай хүмүүс ирж, тодорхой тохиолдлын 30% -д нь ийм асуудал тулгардаг бөгөөд үүнийг хэрхэн шийдвэрлэх талаар бодож үзье гэж хэлдэг. Энэ бол бидний хамгийн их хүлээж байгаа зүйл юм. Бид бусад үүлэн платформуудтай туршлага хуваалцахыг тэсэн ядан хүлээж байна.
Та марафоны талаар их ярьсан. Таныг Москвад марафон гүйж байсныг би мэднэ. Үр дүнд нь? PostgreSQL-ийн залуусыг гүйцэж түрүүлсэн үү?
Үгүй ээ, Олег Бартунов маш хурдан гүйдэг. Тэр надаас нэг цагийн өмнө дуусгасан. Ерөнхийдөө би хэр хол явсандаа сэтгэл хангалуун байна. Миний хувьд дөнгөж дуусгах нь амжилт байсан. Ерөнхийдөө postgres нийгэмлэгт маш олон гүйгч байгаа нь гайхалтай юм. Аэробик спорт болон системийн програмчлалын хүсэл хоёрын хооронд ямар нэгэн хамаарал байгаа юм шиг надад санагдаж байна.
Та ClickHouse-д гүйгч байхгүй гэж хэлж байна уу?
Тэд тэнд байгаа гэдгийг би баттай мэдэж байна. ClickHouse нь бас мэдээллийн сан юм. Дашрамд хэлэхэд, Олег одоо надад захидал бичиж байна: "Бид тайлангийн дараа гүйх үү?" Энэ бол гайхалтай санаа юм.
Никитагийн нэвтрүүлгийн өөр нэг асуулт: "Та яагаад Greenplum-ийн алдааг өөрөө засч, өсвөр насныханд өгөөгүй юм бэ?" Алдаа нь юу, ямар үйлчилгээнд байгаа нь тодорхойгүй байгаа нь үнэн, гэхдээ энэ нь таны ярьсан зүйл гэсэн үг юм.
Тиймээ, зарчмын хувьд хэн нэгэнд өгч болох байсан. Би зүгээр л кодыг нь өөрчилсөн. Тэгээд тэр даруйдаа үргэлжлүүлэн хийх нь зүйн хэрэг байв. Зарчмын хувьд, багтай туршлага хуваалцах санаа нь сайн санаа юм. Бид Greenplum-ийн даалгавруудыг хэлтсийнхээ бүх гишүүдэд хуваалцах нь гарцаагүй.
Бид өсвөр насныхны тухай ярьж байгаа тул энд нэг асуулт байна. Тэр хүн Postgres-д анхны амлалт үүсгэхээр шийдсэн. Тэр анхны амлалт өгөхийн тулд юу хийх хэрэгтэй вэ?
Энэ бол "хаанаас эхлэх вэ?" гэсэн сонирхолтой асуулт юм. Цөм дэх ямар нэг зүйлээс эхлэх нь ихэвчлэн хэцүү байдаг. Жишээ нь Postgres-д хийх зүйлсийн жагсаалт байдаг. Гэвч үнэн хэрэгтээ энэ бол тэдний хийх гэж оролдсон боловч бүтэлгүйтсэн зүйлийн нэг хуудас юм. Эдгээр нь нарийн төвөгтэй зүйлүүд юм. Мөн ихэвчлэн та цөм хөгжүүлэгчдийн анхаарлыг бага татдаг экосистемээс зарим хэрэгслүүд, сайжруулж болох зарим өргөтгөлүүдийг олж болно. Үүний дагуу тэнд өсөх олон цэгүүд бий. Жил бүр Google Summer of code программ дээр postgres нийгэмлэг нь шийдвэрлэх боломжтой олон янзын сэдвүүдийг дэвшүүлдэг. Энэ жил бид гурван оюутантай болсон гэж бодож байна. Нэг нь Yandex-д чухал ач холбогдолтой сэдвээр WAL-G дээр бичсэн. Greenplum-д бүх зүйл Postgres нийгэмлэгийнхээс хамаагүй хялбар байдаг, учир нь Greenplum-ийн хакерууд татах хүсэлтийг маш сайн хүлээн авч, тэр даруй хянаж эхэлдэг. Postgres руу засвар илгээх нь хэдэн сарын асуудал боловч Greenplum нэг өдрийн дараа ирж, таны юу хийснийг харах болно. Өөр нэг зүйл бол Greenplum одоогийн асуудлыг шийдэх хэрэгтэй. Greenplum нь өргөн хэрэглэгддэггүй тул таны асуудлыг олоход нэлээд хэцүү байдаг. Мэдээжийн хэрэг, хамгийн түрүүнд бид асуудлыг шийдэх хэрэгтэй.
Эх сурвалж: www.habr.com