Сайн уу! Намайг Голов Николай гэдэг. Өмнө нь би Avito-д ажиллаж, Дата платформыг зургаан жил удирдаж байсан, өөрөөр хэлбэл бүх мэдээллийн сан дээр ажилласан: аналитик (Vertica, ClickHouse), стриминг болон OLTP (Redis, Tarantool, VoltDB, MongoDB, PostgreSQL). Энэ хугацаанд би маш олон тооны мэдээллийн сантай - маш өөр, ер бусын, тэдгээрийг ашиглах стандарт бус тохиолдлуудтай харьцсан.
Би одоогоор ManyChat-д ажиллаж байна. Үндсэндээ энэ бол шинэ, амбицтай, хурдацтай хөгжиж буй стартап юм. Намайг анх компанид элсэхэд "Залуу стартап одоо DBMS болон мэдээллийн сангийн зах зээлээс юу авах ёстой вэ?" гэсэн сонгодог асуулт гарч ирэв.
Энэ нийтлэлд, миний тайлан дээр үндэслэн , би энэ асуултанд хариулах болно. Тайлангийн видео хувилбарыг эндээс үзэх боломжтой .
Түгээмэл мэддэг мэдээллийн сан 2020
2020 он боллоо, би эргэн тойрноо хартал гурван төрлийн мэдээллийн сан харагдлаа.
Эхний төрөл - сонгодог OLTP мэдээллийн сан: PostgreSQL, SQL Server, Oracle, MySQL. Тэдгээр нь нэлээд эрт бичигдсэн боловч хөгжүүлэгчдийн нийгэмлэгт маш сайн танил тул хамааралтай хэвээр байна.
Хоёр дахь төрөл нь суурь нь "тэг". Тэд SQL, уламжлалт бүтэц, ACID-ээс татгалзаж, суулгасан sharding болон бусад сэтгэл татам шинж чанаруудыг нэмж сонгодог загвараас холдохыг оролдсон. Жишээлбэл, энэ нь Кассандра, MongoDB, Redis эсвэл Tarantool юм. Эдгээр бүх шийдлүүд нь зах зээлд цоо шинэ зүйлийг санал болгохыг хүссэн бөгөөд тодорхой ажлуудыг хийхэд маш тохиромжтой байсан тул өөрсдийн байр сууриа эзэлжээ. Би эдгээр мэдээллийн сангуудыг NOSQL нэр томъёогоор илэрхийлэх болно.
"Тэг"-үүд дуусч, бид NOSQL мэдээллийн санд дассан бөгөөд миний бодлоор дэлхий дараагийн алхамыг хийсэн. удирддаг мэдээллийн сан. Эдгээр мэдээллийн сан нь сонгодог OLTP мэдээллийн сан эсвэл шинэ NoSQL мэдээллийн сантай ижил цөмтэй. Гэхдээ тэдэнд DBA болон DevOps хэрэггүй бөгөөд үүлэн доторх удирдлагатай техник хангамж дээр ажилладаг. Хөгжүүлэгчийн хувьд энэ нь хаа нэгтээ ажилладаг "зүгээр л суурь" боловч сервер дээр хэрхэн суулгаж, серверийг хэн тохируулж, хэн шинэчилж байгааг хэн ч тоодоггүй.
Ийм мэдээллийн сангийн жишээ:
- AWS RDS нь PostgreSQL/MySQL-д зориулсан удирддаг боодол юм.
- DynamoDB нь Redis болон MongoDB-тэй төстэй баримт бичигт суурилсан мэдээллийн сангийн AWS аналог юм.
- Amazon Redshift бол удирддаг аналитик мэдээллийн сан юм.
Эдгээр нь үндсэндээ хуучин мэдээллийн сангууд боловч техник хангамжтай ажиллах шаардлагагүй, удирддаг орчинд бий болсон.
Анхаарна уу. Жишээ нь AWS орчинд зориулагдсан боловч тэдгээрийн аналогууд нь Microsoft Azure, Google Cloud эсвэл Yandex.Cloud дээр байдаг.
Энэ талаар шинэ зүйл юу вэ? 2020 онд эдгээрийн аль нь ч байхгүй.
Сервергүй ойлголт
2020 онд зах зээл дээр үнэхээр шинэ зүйл бол сервергүй эсвэл сервергүй шийдлүүд юм.
Би ердийн үйлчилгээ эсвэл арын програмын жишээг ашиглан энэ нь юу гэсэн үг болохыг тайлбарлахыг хичээх болно.
Ердийн backend програмыг ашиглахын тулд бид сервер худалдаж авах эсвэл түрээслэх, кодыг түүн рүү хуулж, эцсийн цэгийг гадуур нийтлэх, түрээс, цахилгаан, дата төвийн үйлчилгээний төлбөрийг тогтмол төлдөг. Энэ бол стандарт схем юм.
Өөр арга бий юу? Сервергүй үйлчилгээгээр та боломжтой.
Энэ аргын гол анхаарал юу вэ: сервер байхгүй, үүлэн дотор виртуал жишээ түрээслэх ч байхгүй. Үйлчилгээг ашиглахын тулд кодыг (функцуудыг) агуулах руу хуулж, эцсийн цэгт нийтлээрэй. Дараа нь бид энэ функц руу залгах бүртээ төлбөр төлж, ажиллаж байгаа техник хангамжийг үл тоомсорлодог.
Би энэ аргыг зургаар харуулахыг хичээх болно.
Сонгодог байршуулалт. Манайд тодорхой ачаалалтай үйлчилгээ бий. Бид хоёр тохиолдол гаргадаг: физик серверүүд эсвэл AWS дахь тохиолдлууд. Эдгээр тохиолдлуудад гадны хүсэлтийг илгээж, тэнд боловсруулдаг.
Зурган дээрээс харж байгаагаар серверүүд адилхан хаягддаггүй. Нэг нь 100% ашиглагдсан, хоёр хүсэлт байна, нэг нь ердөө 50% - хэсэгчлэн идэвхгүй байна. Хэрэв гурван биш, 30 хүсэлт ирвэл бүх систем ачааллыг даван туулж чадахгүй бөгөөд удааширч эхэлнэ.
Сервергүй байршуулалт. Сервергүй орчинд ийм үйлчилгээ нь инстанц эсвэл сервергүй байдаг. Халаасан нөөцийн тодорхой сан байдаг - байрлуулсан функцийн код бүхий жижиг бэлтгэсэн Docker контейнерууд. Систем нь гадны хүсэлтийг хүлээн авдаг бөгөөд сервергүй хүрээ нь код бүхий жижиг контейнерийг босгодог: энэ хүсэлтийг боловсруулж, контейнерыг устгадаг.
Нэг хүсэлт - нэг контейнер босгосон, 1000 хүсэлт - 1000 чингэлэг. Техник хангамжийн сервер дээр байрлуулах нь үүлэн үйлчилгээ үзүүлэгчийн ажил юм. Энэ нь сервергүй хүрээгээр бүрэн далдлагдсан. Энэ үзэл баримтлалд бид дуудлага бүрийн төлбөрийг төлдөг. Жишээлбэл, өдөрт нэг дуудлага ирдэг - бид нэг дуудлагын төлбөрийг төлсөн, минут тутамд сая ирдэг - бид саяыг төлсөн. Эсвэл секундын дотор энэ нь бас тохиолддог.
Сервергүй функцийг нийтлэх үзэл баримтлал нь харьяалалгүй үйлчилгээнд тохиромжтой. Хэрэв танд (төрийн) бүрэн бүтэн үйлчилгээ хэрэгтэй бол бид үйлчилгээнд мэдээллийн сан нэмнэ. Энэ тохиолдолд төлөвтэй ажиллах үед төлөвтэй функц бүр мэдээллийн сангаас бичиж, уншдаг. Түүнээс гадна, нийтлэлийн эхэнд дурдсан гурван төрлийн аль нэгийг нь мэдээллийн сангаас.
Эдгээр бүх мэдээллийн сангийн нийтлэг хязгаарлалт нь юу вэ? Эдгээр нь байнгын ашиглагддаг үүл эсвэл техник хангамжийн серверийн (эсвэл хэд хэдэн серверийн) зардал юм. Бид сонгодог эсвэл удирддаг мэдээллийн сан ашигладаг эсэх, Devops болон админтай эсэх нь хамаагүй, бид техник хангамж, цахилгаан, дата төвийн түрээсийн төлбөрийг 24/7 төлдөг. Хэрэв бид сонгодог суурьтай бол бид эзэн, боолын төлбөрийг төлдөг. Хэрэв энэ нь ачаалал ихтэй sharded мэдээллийн сан бол бид 10, 20 эсвэл 30 серверийн төлбөрийг төлдөг бөгөөд бид байнга төлдөг.
Зардлын бүтцэд байнга нөөцлөгдсөн серверүүд байгаа нь өмнө нь зайлшгүй муу зүйл гэж үздэг байсан. Уламжлалт өгөгдлийн сангууд нь холболтын тооны хязгаарлалт, масштабын хязгаарлалт, гео тархсан зөвшилцөл гэх мэт бусад бэрхшээлтэй тулгардаг - тэдгээрийг тодорхой мэдээллийн санд ямар нэгэн байдлаар шийдэж болох боловч бүгдийг нэг дор биш, тийм ч тохиромжтой биш юм.
Сервергүй мэдээллийн сан - онол
2020 оны асуулт: Мэдээллийн санг сервергүй болгох боломжтой юу? Хүн бүр сервергүй backend-ийн талаар сонссон ... өгөгдлийн санг сервергүй болгохыг хичээцгээе?
Энэ нь хачирхалтай сонсогдож байна, учир нь мэдээллийн сан нь бүрэн бүтэн үйлчилгээ бөгөөд сервергүй дэд бүтцэд тийм ч тохиромжтой биш юм. Үүний зэрэгцээ мэдээллийн сангийн төлөв маш том байна: гигабайт, терабайт, аналитик мэдээллийн санд петабайт хүртэл. Үүнийг хөнгөн жинтэй Docker саванд өсгөх нь тийм ч хялбар биш юм.
Нөгөөтэйгүүр, бараг бүх орчин үеийн мэдээллийн сан нь асар их хэмжээний логик, бүрэлдэхүүн хэсгүүдийг агуулдаг: гүйлгээ, бүрэн бүтэн байдлын зохицуулалт, журам, харилцааны хамаарал, маш их логик. Маш олон мэдээллийн сангийн логикийн хувьд жижиг төлөв хангалттай. Гигабайт болон терабайтыг шууд асуулга гүйцэтгэхэд оролцдог мэдээллийн сангийн логикийн багахан хэсэг нь шууд ашигладаг.
Үүний дагуу санаа нь: хэрвээ логикийн нэг хэсэг нь харьяалалгүй гүйцэтгэлийг зөвшөөрдөг бол суурийг Төрийн болон харьяалалгүй хэсгүүдэд хувааж яагаад болохгүй гэж.
OLAP шийдлүүдэд сервергүй
Практик жишээнүүдийг ашиглан мэдээллийн санг Төрийн болон харьяалалгүй хэсгүүдэд хуваах нь ямар байхыг харцгаая.
Тухайлбал, манайд аналитик мэдээллийн сан бий: гадаад өгөгдөл (зүүн талд байгаа улаан цилиндр), өгөгдлийн санд өгөгдлийг ачаалах ETL процесс, мэдээллийн сан руу SQL асуулга илгээдэг шинжээч. Энэ бол мэдээллийн агуулахын үйл ажиллагааны сонгодог схем юм.
Энэ схемд ETL-ийг нөхцөлт байдлаар нэг удаа гүйцэтгэдэг. Дараа нь та өгөгдлийн сан нь ETL-ээр дүүрсэн өгөгдлөөр ажилладаг серверүүдийн төлбөрийг байнга төлөх шаардлагатай бөгөөд ингэснээр асуулга илгээх зүйл бий.
AWS Athena Serverless-д хэрэгжсэн өөр аргыг авч үзье. Татаж авсан өгөгдөл хадгалагддаг байнгын зориулалтын техник хангамж байдаггүй. Үүний оронд:
- Хэрэглэгч Athena руу SQL асуулга илгээдэг. Athena optimizer нь SQL асуулгад дүн шинжилгээ хийж, асуулга гүйцэтгэхэд шаардлагатай тодорхой өгөгдлийг мета өгөгдлийн сангаас (Мета өгөгдөл) хайдаг.
- Цуглуулсан өгөгдөл дээр үндэслэн оновчтой болгогч нь шаардлагатай өгөгдлийг гадаад эх сурвалжаас түр хадгалах (түр зуурын мэдээллийн сан) руу татаж авдаг.
- Хэрэглэгчийн SQL асуулга түр хадгалах санд хийгдэж үр дүнг нь хэрэглэгч рүү буцаана.
- Түр хадгалах санг цэвэрлэж, нөөцийг чөлөөлнө.
Энэ архитектурт бид зөвхөн хүсэлтийг гүйцэтгэх процессын төлбөрийг төлдөг. Хүсэлт байхгүй - зардал байхгүй.
Энэ бол ажлын арга бөгөөд зөвхөн Athena Serverless-д төдийгүй Redshift Spectrum-д (AWS-д) хэрэгждэг.
Athena жишээ нь Сервергүй мэдээллийн сан нь хэдэн арван, хэдэн зуун терабайт өгөгдөл бүхий бодит асуулга дээр ажилладаг болохыг харуулж байна. Хэдэн зуун терабайтын хувьд хэдэн зуун сервер шаардагдана, гэхдээ бид тэдгээрийн төлбөрийг төлөх шаардлагагүй - бид хүсэлтийг төлдөг. Хүсэлт бүрийн хурд нь Vertica гэх мэт тусгай аналитик мэдээллийн баазтай харьцуулахад (маш) бага боловч бид сул зогсолтын үед төлбөр төлдөггүй.
Ийм мэдээллийн санг ховор аналитик түр зуурын асуулгад ашиглах боломжтой. Жишээлбэл, бид асар их хэмжээний өгөгдөл дээр таамаглалыг туршихаар аяндаа шийдсэн үед. Афина эдгээр тохиолдлуудад төгс төгөлдөр юм. Тогтмол хүсэлтийн хувьд ийм систем нь үнэтэй байдаг. Энэ тохиолдолд зарим тусгай шийдэлд өгөгдлийг кэшлээрэй.
OLTP шийдэлд сервергүй
Өмнөх жишээнд OLAP (аналитик) даалгавруудыг авч үзсэн. Одоо OLTP даалгавруудыг харцгаая.
Өргөтгөх боломжтой PostgreSQL эсвэл MySQL-ийг төсөөлье. Хамгийн бага нөөцтэй PostgreSQL эсвэл MySQL-ийн энгийн удирддаг жишээг бий болгоцгооё. Жишээ нь илүү их ачаалал авах үед бид унших ачааллын хэсгийг хуваарилах нэмэлт хуулбаруудыг холбох болно. Хэрэв хүсэлт, ачаалал байхгүй бол бид хуулбарыг унтраадаг. Эхний хувилбар нь мастер, үлдсэн хэсэг нь хуулбар юм.
Энэхүү санаа нь Aurora Serverless AWS хэмээх мэдээллийн санд хэрэгждэг. Энэ зарчим нь энгийн: гадны програмуудын хүсэлтийг прокси флот хүлээн авдаг. Ачаалал нэмэгдэж байгааг хараад энэ нь урьдчилан халаасан хамгийн бага тохиолдлуудаас тооцоолох нөөцийг хуваарилдаг - холболтыг аль болох хурдан хийдэг. Идэвхгүй болгох тохиолдлууд ижил аргаар явагдана.
Аврора дотор Аврора багтаамжийн нэгж, ACU гэсэн ойлголт байдаг. Энэ бол (нөхцөлтэйгээр) жишээ (сервер) юм. Тодорхой ACU бүр мастер эсвэл боол байж болно. Хүчин чадлын нэгж бүр өөрийн гэсэн RAM, процессор, хамгийн бага дисктэй байдаг. Үүний дагуу нэг нь мастер, бусад нь зөвхөн хуулбарыг уншдаг.
Эдгээр Аврора багтаамжийн нэгжүүдийн тоо нь тохируулж болох параметр юм. Хамгийн бага тоо хэмжээ нь нэг эсвэл тэг байж болно (энэ тохиолдолд хүсэлт байхгүй бол мэдээллийн сан ажиллахгүй).
Суурь хүсэлтийг хүлээн авах үед прокси флот нь Aurora CapacityUnits-ийг нэмэгдүүлж, системийн гүйцэтгэлийн нөөцийг нэмэгдүүлдэг. Нөөцийг нэмэгдүүлэх, багасгах чадвар нь системд нөөцийг "зөвлөх" боломжийг олгодог: бие даасан ACU-г автоматаар харуулах (тэдгээрийг шинээр сольж) болон татан авсан нөөцийн одоогийн бүх шинэчлэлтийг нэвтрүүлэх.
Аврора сервергүй суурь нь унших ачааллыг нэмэгдүүлэх боломжтой. Гэхдээ баримт бичигт энэ тухай шууд заагаагүй байна. Тэд олон мастерыг өргөж чадах юм шиг санагдаж магадгүй юм. Ямар ч ид шид байхгүй.
Энэхүү мэдээллийн сан нь урьдчилан тааварлах боломжгүй хандалттай системд их хэмжээний мөнгө зарцуулахаас зайлсхийхэд тохиромжтой. Жишээлбэл, MVP эсвэл маркетингийн нэрийн хуудас үүсгэх үед бид ихэвчлэн тогтвортой ачааллыг хүлээдэггүй. Үүний дагуу, хэрэв нэвтрэх боломжгүй бол бид тохиолдлын төлбөр төлөхгүй. Гэнэтийн ачаалал, тухайлбал, хурал, сурталчилгааны кампанит ажлын дараа, олон хүмүүс сайт руу зочилж, ачаалал эрс нэмэгдэх үед Aurora Serverless энэ ачааллыг автоматаар авч, дутуу нөөцийг (ACU) хурдан холбодог. Дараа нь хурал өнгөрч, хүн бүр прототипийн талаар мартаж, серверүүд (ACU) харанхуй болж, зардал тэг болж буурдаг - тохиромжтой.
Энэ шийдэл нь бичих ачааллыг томруулдаггүй тул тогтвортой өндөр ачаалалд тохиромжгүй. Эдгээр бүх холболт, нөөцийн салалт нь "масштаб цэг" гэж нэрлэгддэг цэг дээр тохиолддог - мэдээллийн сан нь гүйлгээ эсвэл түр зуурын хүснэгтээр дэмжигдээгүй үед тохиолддог. Жишээлбэл, долоо хоногийн дотор масштабын цэг тохиолдохгүй байж магадгүй бөгөөд суурь нь ижил нөөц дээр ажилладаг бөгөөд зүгээр л өргөжүүлэх эсвэл агших боломжгүй юм.
Ямар ч ид шид байхгүй - энэ бол ердийн PostgreSQL юм. Гэхдээ машин нэмэх, салгах үйл явц нь хэсэгчлэн автоматжуулсан.
Дизайнаар сервергүй
Aurora Serverless нь Serverless-ийн зарим давуу талыг ашиглахын тулд үүлэнд зориулж дахин бичсэн хуучин мэдээллийн сан юм. Одоо би сервергүй хандлагын хувьд үүлэнд зориулж анх бичсэн баазын талаар танд хэлэх болно - Дизайнаар сервергүй. Энэ нь физик серверүүд дээр ажиллана гэсэн таамаглалгүйгээр шууд боловсруулсан.
Энэ суурийг Snowflake гэж нэрлэдэг. Энэ нь гурван гол блоктой.
Эхнийх нь мета өгөгдлийн блок юм. Энэ нь аюулгүй байдал, мета өгөгдөл, гүйлгээ, асуулгын оновчлолтой холбоотой асуудлыг шийддэг хурдан санах ойн үйлчилгээ юм (зүүн талд байгаа зурагт үзүүлсэн).
Хоёрдахь блок нь тооцоолол хийхэд зориулагдсан виртуал тооцооллын кластеруудын багц юм (зураг дээр цэнхэр тойрог байгаа).
Гурав дахь блок нь S3 дээр суурилсан өгөгдөл хадгалах систем юм. S3 нь AWS дахь хэмжээсгүй объектын хадгалалт бөгөөд бизнесийн хувьд хэмжээсгүй Dropbox-той адил юм.
Хүйтэн эхлэлтэй гэж үзвэл Snowflake хэрхэн ажилладагийг харцгаая. Өөрөөр хэлбэл, мэдээллийн сан байгаа, түүнд өгөгдөл ачаалагдсан, ажиллаж байгаа асуулга байхгүй байна. Үүний дагуу, хэрэв мэдээллийн санд хүсэлт ирээгүй бол бид хурдан санах ойн мета өгөгдлийн үйлчилгээг (эхний блок) сайжруулсан. Бидэнд хүснэгтийн өгөгдөл хадгалагддаг S3 хадгалах сан байдаг бөгөөд үүнийг микро хуваалт гэж нэрлэдэг. Энгийн болгохын тулд: хэрэв хүснэгтэд гүйлгээ орсон бол бичил хуваалтууд нь гүйлгээний өдрүүд юм. Өдөр бүр тусдаа бичил хуваалт, тусдаа файл юм. Өгөгдлийн сан энэ горимд ажиллах үед та зөвхөн өгөгдөлд эзлэх зайг төлнө. Түүнээс гадна, нэг суудалд ногдох хувь хэмжээ маш бага (ялангуяа их хэмжээний шахалтыг харгалзан үзвэл). Мета өгөгдлийн үйлчилгээ нь мөн тогтмол ажилладаг боловч асуулгыг оновчтой болгохын тулд танд маш их нөөц хэрэггүй бөгөөд үйлчилгээг shareware гэж үзэж болно.
Одоо нэг хэрэглэгч манай мэдээллийн санд ирээд SQL асуулга илгээсэн гэж төсөөлье. SQL асуулгыг боловсруулахад нэн даруй Мета өгөгдлийн үйлчилгээ рүү илгээдэг. Үүний дагуу хүсэлтийг хүлээн авсны дараа энэ үйлчилгээ нь хүсэлт, боломжтой өгөгдөл, хэрэглэгчийн зөвшөөрөлд дүн шинжилгээ хийж, хэрэв бүх зүйл хэвийн бол хүсэлтийг боловсруулах төлөвлөгөө гаргадаг.
Дараа нь үйлчилгээ нь тооцоолох кластерийг эхлүүлэх ажлыг эхлүүлнэ. Тооцооллын кластер нь тооцоолол хийдэг серверүүдийн кластер юм. Өөрөөр хэлбэл, энэ нь 1 сервер, 2 сервер, 4, 8, 16, 32 - таны хүссэн хэмжээгээр агуулж болох кластер юм. Та хүсэлт гаргавал энэ кластер шууд эхэлнэ. Энэ нь үнэхээр секунд зарцуулдаг.
Дараа нь кластер ажиллаж эхэлсний дараа таны хүсэлтийг боловсруулахад шаардлагатай микро хуваалтуудыг S3-аас кластерт хуулж эхэлнэ. Өөрөөр хэлбэл, SQL асуулгыг гүйцэтгэхийн тулд нэг хүснэгтээс хоёр хуваалт, хоёр дахь хуваалт хэрэгтэй гэж төсөөлөөд үз дээ. Энэ тохиолдолд бүх хүснэгтийг бүхэлд нь биш, зөвхөн шаардлагатай гурван хуваалтыг кластерт хуулах болно. Тийм ч учраас бүх зүйл нэг өгөгдлийн төвд байрладаг бөгөөд маш хурдан сувгуудаар холбогдсон байдаг тул дамжуулах үйл явц бүхэлдээ маш хурдан явагддаг: хэдхэн секундын дотор, маш ховор тохиолдолд хэдэн минутын дотор, хэрэв бид аймшигтай хүсэлтийн талаар ярихгүй бол. Үүний дагуу микро хуваалтуудыг тооцоолох кластерт хуулж, дууссаны дараа SQL хайлтыг энэ тооцооллын кластер дээр гүйцэтгэдэг. Энэ хүсэлтийн үр дүн нь нэг мөр, хэд хэдэн мөр эсвэл хүснэгт байж болно - тэдгээр нь хэрэглэгч рүү гаднаас илгээгдэж, түүнийг татаж авах, өөрийн BI хэрэглүүрт харуулах эсвэл өөр аргаар ашиглах боломжтой.
SQL асуулга бүр нь өмнө нь ачаалагдсан өгөгдлүүдийн нэгтгэлийг уншихаас гадна мэдээллийн санд шинэ өгөгдлийг ачаалах/үүсгэх боломжтой. Өөрөөр хэлбэл, энэ нь жишээлбэл, өөр хүснэгтэд шинэ бичлэг оруулах асуулга байж болох бөгөөд энэ нь тооцоолох кластер дээр шинэ хуваалт гарч ирэхэд хүргэдэг бөгөөд энэ нь эргээд нэг S3 санах ойд автоматаар хадгалагддаг.
Хэрэглэгч ирэхээс эхлээд кластерийг өсгөх, өгөгдөл ачаалах, асуулга явуулах, үр дүн гаргах хүртэлх дээр тайлбарласан хувилбар нь виртуал тооцооллын кластер, виртуал агуулахыг ашигласан минутын үнээр төлдөг. Үнэ нь AWS бүс болон кластерийн хэмжээнээс хамаарч өөр өөр байдаг ч дунджаар цагт хэдхэн доллар байдаг. Дөрвөн машинаас бүрдсэн кластер нь хоёр машинаас хоёр дахин үнэтэй, найман машинаас бүрдсэн кластер хоёр дахин үнэтэй хэвээр байна. Хүсэлтийн нарийн төвөгтэй байдлаас хамааран 16, 32 машиныг сонгох боломжтой. Гэхдээ та кластер ажиллаж байх үед л төлдөг, учир нь ямар ч хүсэлт байхгүй үед гараа салгаж аваад 5-10 минут хүлээсний дараа (тохируулж болох параметр) өөрөө унтардаг. нөөцийг чөлөөлж, эрх чөлөөтэй болно.
Бүрэн бодит хувилбар бол та хүсэлт илгээх үед кластер гарч ирэхэд нэг минутын дараа дахин нэг минут тоологдож, дараа нь таван минут унтрах бөгөөд та энэ кластерыг долоон минутын турш ажиллуулахад төлбөр төлөх болно. сар жилээр биш.
Нэг хэрэглэгчийн тохиргоонд Snowflake ашиглан тайлбарласан эхний хувилбар. Одоо олон хэрэглэгчид байгаа гэж төсөөлөөд үз дээ, энэ нь бодит хувилбарт илүү ойр байна.
Манай мэдээллийн санг олон тооны энгийн аналитик SQL асуулгаар байнга бөмбөгддөг маш олон шинжээч, Tableau тайлангууд байна гэж бодъё.
Нэмж дурдахад, бидэнд өгөгдөл ашиглан аймшигт зүйл хийхийг оролдож, хэдэн арван терабайтаар ажиллаж, тэрбум, их наяд өгөгдлийн эгнээнд дүн шинжилгээ хийдэг шинэлэг Data Scientists байна гэж бодъё.
Дээр дурдсан хоёр төрлийн ажлын ачааллын хувьд Snowflake нь өөр өөр хүчин чадалтай хэд хэдэн бие даасан тооцоолох кластеруудыг бий болгох боломжийг олгодог. Үүнээс гадна эдгээр тооцооллын кластерууд нь бие даасан боловч нийтлэг тогтвортой өгөгдөлтэй ажилладаг.
Олон тооны хөнгөн асуулгын хувьд та 2-3 жижиг кластер, тус бүр нь ойролцоогоор 2 машин үүсгэж болно. Энэ зан үйлийг бусад зүйлсийн дунд автомат тохиргоог ашиглан хэрэгжүүлж болно. Тиймээс та "Цасан ширхгүүд, жижиг бөөгнөрөл босго. Хэрэв үүн дээрх ачаалал тодорхой параметрээс дээш байвал ижил төстэй хоёр, гурав дахь хэсгийг нэмэгдүүлнэ. Ачаалал буурч эхлэхэд илүүдлийг нь унтраа”. Хичнээн шинжээч ирж тайлан үзэж эхэлсэн ч хүн бүрт хангалттай нөөц бий.
Үүний зэрэгцээ, шинжээчид унтаж байгаа бөгөөд хэн ч тайланг харахгүй бол кластерууд бүрэн харанхуй болж магадгүй бөгөөд та тэдний төлбөрийг төлөхөө болино.
Үүний зэрэгцээ, хүнд асуултуудын хувьд (Data Scientists-ээс) та 32 машинд зориулж нэг маш том кластер босгох боломжтой. Энэ кластер нь таны аварга хүсэлт тэнд ажиллаж байх тэр минут, цагуудад л төлнө.
Дээр тайлбарласан боломж нь зөвхөн 2 төдийгүй илүү олон төрлийн ажлын ачааллыг кластерт (ETL, мониторинг, тайлангийн материал болгох,...) хуваах боломжийг олгодог.
Цасан ширхгийг тоймлоё. Суурь нь сайхан санаа, үр дүнтэй хэрэгжилтийг хослуулсан. ManyChat дээр бид Snowflake-г ашиглан өөрт байгаа бүх өгөгдөлд дүн шинжилгээ хийдэг. Бидэнд жишээн дээрх шиг гурван кластер байхгүй, гэхдээ өөр өөр хэмжээтэй 5-аас 9 хүртэл. Бидэнд ердийн 16 машин, 2 машин, мөн зарим ажилд зориулсан супер жижиг 1 машин байдаг. Тэд ачааллыг амжилттай хуваарилж, маш их хэмнэх боломжийг бидэнд олгодог.
Мэдээллийн сан нь унших, бичих ачааллыг амжилттай хэмждэг. Энэ нь зөвхөн унших ачааллыг үүрдэг ижил "Аврора" -тай харьцуулахад асар том ялгаа бөгөөд асар том нээлт юм. Snowflake нь эдгээр тооцооллын кластеруудыг ашиглан бичих ажлын ачааллаа нэмэгдүүлэх боломжийг танд олгоно. Өөрөөр хэлбэл, миний дурьдсанчлан, бид ManyChat-д хэд хэдэн кластер ашигладаг бөгөөд жижиг, супер жижиг кластеруудыг ихэвчлэн ETL, өгөгдөл ачаалахад ашигладаг. Шинжээчид аль хэдийн дунд кластерууд дээр амьдардаг бөгөөд энэ нь ETL ачаалалд огт нөлөөлдөггүй тул маш хурдан ажилладаг.
Үүний дагуу мэдээллийн сан нь OLAP даалгавруудад тохиромжтой. Гэсэн хэдий ч харамсалтай нь энэ нь OLTP ажлын ачаалалд хараахан тохирохгүй байна. Нэгдүгээрт, энэ мэдээллийн сан нь багана хэлбэртэй бөгөөд үүнээс үүдэлтэй бүх үр дагавартай. Хоёрдугаарт, хүсэлт болгоны хувьд шаардлагатай бол тооцоолох кластер босгож, өгөгдлөөр дүүргэх арга нь харамсалтай нь OLTP ачааллын хувьд хангалттай хурдан биш юм. OLAP даалгаврын хувьд секунд хүлээх нь хэвийн үзэгдэл боловч OLTP даалгаврын хувьд энэ нь хүлээн зөвшөөрөгдөхгүй; 100 мс, эсвэл 10 мс илүү сайн байх болно.
Үр дүн
Мэдээллийн санг харьяалалгүй болон төлөвтэй хэсэгт хуваах замаар сервергүй мэдээллийн сан бий болно. Дээрх бүх жишээн дээр Stateful хэсэг нь харьцангуйгаар S3-д бичил хуваалтуудыг хадгалдаг, харин Stateless нь оновчтой болгох, мета өгөгдөлтэй ажиллах, аюулгүй байдлын асуудлуудыг зохицуулж, бие даасан хөнгөн жинтэй харьяалалгүй үйлчилгээ гэдгийг та анзаарсан байх.
SQL асуулгыг гүйцэтгэх нь Snowflake тооцооллын кластерууд гэх мэт сервергүй горимд гарч ирэх, зөвхөн шаардлагатай өгөгдлийг татаж авах, хайлтыг гүйцэтгэх, "гарах" боломжтой хөнгөн төлөвийн үйлчилгээ гэж ойлгож болно.
Сервергүй үйлдвэрлэлийн түвшний өгөгдлийн санг ашиглах боломжтой, тэд ажиллаж байна. Эдгээр сервергүй мэдээллийн сангууд нь OLAP даалгавруудыг шийдвэрлэхэд аль хэдийн бэлэн болсон байна. Харамсалтай нь, OLTP даалгаврын хувьд тэдгээр нь нюансуудтай ашиглагддаг, учир нь хязгаарлалтууд байдаг. Нэг талаараа энэ нь хасах зүйл юм. Гэхдээ нөгөө талаас энэ бол боломж юм. Уншигчдын нэг нь Аврорагийн хязгаарлалтгүйгээр OLTP мэдээллийн санг бүрэн сервергүй болгох арга замыг олох байх.
Танд сонирхолтой санагдсан гэж найдаж байна. Сервергүй бол ирээдүй :)
Эх сурвалж: www.habr.com