In-Memory гэдэг нь програмын RAM-д хадгалагдсан өгөгдлийг хадгалахад зориулагдсан ойлголтуудын багц бөгөөд дискийг нөөцлөхөд ашигладаг. Сонгодог аргуудын хувьд өгөгдлийг дискэнд, санах ойг кэшэд хадгалдаг. Жишээлбэл, өгөгдөл боловсруулах backend бүхий вэб програм нь түүнийг хадгалах хүсэлтийг илгээдэг: үүнийг хүлээн авч, хувиргаж, сүлжээгээр маш олон өгөгдлийг дамжуулдаг. In-Memory-д тооцооллыг өгөгдөл рүү илгээдэг - тэдгээрийг боловсруулж, сүлжээ бага ачаалалтай байдаг хадгалах газар руу илгээдэг.
In-Memory-д өөр ямар боломжууд байдаг бөгөөд энэ нь ямар арга зам вэ? Владимир Плигин - GridGain-ийн инженер. Энэхүү тойм материал нь In-Memory программтай ажиллаж амжаагүй, туршиж үзэхийг хүсч байгаа эсвэл програм хангамж хөгжүүлэлт, архитектурын дизайны орчин үеийн чиг хандлагыг сонирхож буй вэб програмын backend хөгжүүлэгчдэд хэрэгтэй болно.
тайлбар. Уг нийтлэлийг Владимирын #GetIT Conf дээр хийсэн илтгэлийн хуулбар дээр үндэслэсэн болно. Бие даасан тусгаарлалтыг нэвтрүүлэхээс өмнө бид Москва, Санкт-Петербург хотод хөгжүүлэгчдийн уулзалт, бага хурлыг тогтмол зохион байгуулдаг байсан: бид чиг хандлага, өнөөгийн хөгжлийн асуудал, тулгамдсан асуудал, тэдгээрийг шийдвэрлэх арга замыг хэлэлцсэн. Одоо хурал хийх боломжгүй, гэхдээ өнгөрсөн үеийн хэрэгтэй материалаа хуваалцах цаг болжээ.
In-Memory-г хэн, хэрхэн ашигладаг
In-Memory нь хэрэглэгчийн хурдан харилцах эсвэл их хэмжээний өгөгдөл боловсруулах шаардлагатай тохиолдолд ихэвчлэн ашиглагддаг.
- Банкууд Жишээ нь, үйлчлүүлэгч програм ашиглах үед саатлыг багасгах эсвэл зээл олгохоос өмнө үйлчлүүлэгчид дүн шинжилгээ хийх зорилгоор In-Memory-г ашигла.
- Финтек Мэдээллийн боловсруулалт, дүн шинжилгээг аутсорсинг хийдэг банкуудын үйлчилгээ, хэрэглээний гүйцэтгэлийг сайжруулахын тулд In-Memory програмыг ашигладаг.
- Даатгалын компаниуд: эрсдэлийг тооцох, жишээлбэл, хэдэн жилийн турш хэрэглэгчийн мэдээлэлд дүн шинжилгээ хийх.
- Логистикийн компаниуд. Тэд маш олон өгөгдлийг боловсруулдаг, тухайлбал, олон мянган параметр бүхий ачаа, зорчигч тээврийн оновчтой маршрутыг тооцоолох, тээвэрлэлтийн байдлыг хянах.
- Жижиглэн худалдаа. In-Memory шийдэл нь үйлчлүүлэгчдэд илүү хурдан үйлчлэх, их хэмжээний мэдээллийг боловсруулахад тусалдаг: тээвэрлэлт, нэхэмжлэх, гүйлгээ, агуулахад олон мянган бараа байгаа эсэх, аналитик тайланг бэлтгэх.
- В зүйлс In-Memory нь уламжлалт мэдээллийн санг орлодог.
- Эмийн Жишээлбэл, компаниуд эмийн найрлагыг хослуулан ангилахын тулд In-Memory ашигладаг.
Манай үйлчлүүлэгчид In-Memory шийдлүүдийг хэрхэн ашигладаг, та өөрөө хэрхэн хэрэгжүүлэх талаар хэдэн жишээ хэлье.
In-Memory нь үндсэн санах ой юм
Манай үйлчлүүлэгчдийн нэг нь АНУ-аас эмнэлгийн шинжлэх ухааны тоног төхөөрөмжийн томоохон нийлүүлэгч юм. Тэд In-Memory шийдлийг үндсэн мэдээллийн сан болгон ашигладаг. Бүх өгөгдөл нь дискэнд хадгалагддаг бөгөөд идэвхтэй ашиглагдаж буй мэдээллийн дэд хэсэг нь RAM-д хадгалагддаг. Хадгалах хандалтын аргууд нь стандарт - GDBC (Ерөнхий мэдээллийн баазын холбогч) ба SQL асуулгын хэл юм.
Хамтдаа үүнийг In-Memory Database (IMDB) эсвэл Memory-Centric Storage гэж нэрлэдэг. Энэ ангиллын шийдлүүд олон нэртэй байдаг бөгөөд эдгээр нь цорын ганц биш юм.
IMDB онцлогууд:
- In-Memory-д хадгалагдаж, SQL-ээр дамжуулан ханддаг өгөгдөл нь бусад аргуудтай адил юм. Тэдгээр нь синхрончлогдсон, зөвхөн танилцуулах арга, тэдэнд хандах арга нь өөр юм. Гүйлгээ нь өгөгдөл хооронд ажилладаг.
- IMDB нь RAM-аас мэдээлэл авах нь дискнээс илүү хурдан байдаг тул харилцааны мэдээллийн сангаас хурдан байдаг.
- Дотоод оновчлолын алгоритмууд цөөн заавартай байдаг.
- IMDB нь программ дахь өгөгдөл, үйл явдал, гүйлгээг удирдахад тохиромжтой.
IMDB нь ACID: Atomicity, Consistency, болон тусгаарлалтыг хэсэгчлэн дэмждэг. Гэхдээ тэд "бат бөх чанарыг" дэмждэггүй - цахилгаан унтарсан үед бүх өгөгдөл алдагдана. Асуудлыг шийдэхийн тулд та хормын хувилбаруудыг ашиглаж болно - өгөгдлийн сангийн "хормын хувилбар", хатуу диск дээрх өгөгдлийн сангийн нөөцлөлттэй адил, эсвэл дахин ачаалсны дараа өгөгдлийг сэргээхийн тулд гүйлгээг (лог) бүртгэж болно.
Гэмтэлд тэсвэртэй програмуудыг бий болгох
Гэмтэлд тэсвэртэй вэб програмын сонгодог архитектурыг төсөөлье. Энэ нь дараах байдлаар ажилладаг: бүх хүсэлтийг серверүүдийн хооронд вэб тэнцвэржүүлэгчээр тараадаг. Серверүүд бие биенээ хуулбарлаж, осол гарсан тохиолдолд нөөцлөлт хийдэг тул энэ систем тогтвортой байна.
Тэнцвэржүүлэгч нь нэг сессийн бүх хүсэлтийг нэг сервер рүү чиглүүлдэг. Энэ нь зөөгч сесс механизм юм: сесс бүр нь дотооддоо хадгалагдаж, боловсруулагддаг сервертэй холбоотой байдаг.
Серверүүдийн аль нэг нь ажиллахаа больсон тохиолдолд юу болох вэ?
Архитектур нь давхардсан тул үйлчилгээнд нөлөөлөхгүй. Гэхдээ бид үхсэн серверийн сешнүүдийн нэг хэсгийг алдах болно. Үүний зэрэгцээ, эдгээр сессүүдтэй холбоотой хэрэглэгчид. Жишээлбэл, үйлчлүүлэгч захиалгаа өгөөд гэнэт түүнийг оффисоос нь шиддэг. Тэр дахин нэвтэрч, бүх зүйлийг дахин хийх шаардлагатай болно гэдгийг олж мэдээд сэтгэл дундуур байх болно.
Олон тооны хэрэглэгчдийг дэмжихийн тулд вэб програм шаардлагатай бөгөөд ингэснээр тэд тав тухтай ажиллах боломжтой болно. Гэхдээ татгалзсан тохиолдолд дараагийн хүсэлт бүрт сесс дэлгүүртэй харилцах хугацаа нэмэгдэх болно. Энэ нь бусад хэрэглэгчдийн дундаж хоцролтыг нэмэгдүүлдэг. Гэхдээ тэд дассанаасаа удаан хүлээхийг хүсэхгүй байна.
Энэ асуудлыг манай бусад үйлчлүүлэгч, АНУ-ын томоохон PASS үйлчилгээ үзүүлэгчийн нэгэн адил шийдэж болно. Энэ нь вэб сешнүүдийг кластер болгоход In-Memory ашигладаг. Үүнийг хийхийн тулд тэдгээрийг дотооддоо биш, харин төвлөрсөн санах ойн кластерт хадгалдаг. Энэ тохиолдолд сессүүд аль хэдийн RAM-д байгаа тул илүү хурдан боломжтой болно.
Сервер эвдэрсэн үед тэнцвэржүүлэгч нь сонгодог архитектурын нэгэн адил эвдэрсэн серверээс хүсэлтийг бусад серверүүд рүү илгээдэг. Гэхдээ чухал ялгаа бий: сешнүүдийг In-Memory кластерт хадгалдаг мөн серверүүд унасан серверийн сессүүдэд хандах боломжтой.
Энэхүү архитектур нь бүхэл системийн алдааг тэсвэрлэх чадварыг нэмэгдүүлдэг. Түүнээс гадна, зөөгч сесс механизмыг бүрмөсөн орхих боломжтой.
Гибрид гүйлгээний аналитик боловсруулалт (HTAP)
Ихэвчлэн гүйлгээний болон аналитик системийг тусад нь хадгалдаг. Тэднийг салгах үед үндсэн суурь нь ачааллын дор ирдэг. Аналитик боловсруулалтын хувьд аналитик боловсруулалт нь гүйлгээний үйл явцад саад учруулахгүйн тулд өгөгдлийг хуулбар руу хуулдаг. Гэхдээ хуулбарлах нь хоцрогдолтой тохиолддог - хоцрогдолгүйгээр хуулбарлах боломжгүй юм. Хэрэв бид үүнийг синхроноор хийвэл энэ нь үндсэн баазыг удаашруулж, бид ямар ч ялалт авахгүй.
HTAP-д бүх зүйл өөр өөрөөр ажилладаг - ижил өгөгдлийн санг програмаас гүйлгээ хийх ачаалал, дуусгахад удаан хугацаа шаардагдах аналитик асуулгад ашигладаг. Өгөгдөл RAM-д байх үед аналитик асуулга илүү хурдан хийгддэг бөгөөд мэдээллийн сантай сервер бага ачаалалтай байдаг (дунджаар).
Эрлийз арга нь гүйлгээний боловсруулалт болон аналитикийн хоорондох ханыг эвддэг. Хэрэв бид нэг хадгалах сан дээр аналитик хийвэл RAM-ийн өгөгдөл дээр аналитик асуулга ажиллуулна. Тэдгээр нь илүү үнэн зөв, илүү ойлгомжтой, хангалттай юм.
In-Memory шийдлүүдийг нэгтгэх
(Харьцангуй) энгийн арга - бүгдийг эхнээс нь хөгжүүл. Бид өгөгдлийг дискэнд хадгалж, халуун мэдээллийг санах ойд хадгалдаг. Энэ нь серверийг дахин ачаалах эсвэл тасалдах үед амьд үлдэхэд тусалдаг.
Дискэнд өгөгдөл хадгалагдах үед хоёр үндсэн хувилбар ажиллаж байна. Эхний тохиолдолд бид кластер эсвэл хэсгүүдийн эвдрэл, тогтмол дахин ачааллаас амьд үлдэхийг хүсч байна - бид үүнийг энгийн мэдээллийн сан болгон ашиглахыг хүсч байна. Хоёрдахь хувилбарт хэт их өгөгдөл байгаа тохиолдолд тэдгээрийн зарим нь санах ойд байдаг.
Хэрэв бүх зүйлийг эхнээс нь бүтээх боломжгүй бол In-Memory-г аль хэдийнээ суулгаж болно. одоо байгаа архитектур. Гэхдээ бүх In-Memory шийдлүүд үүнд тохирохгүй. Заавал биелүүлэх гурван нөхцөл бий. In-Memory шийдэл нь дараахь зүйлийг дэмжих ёстой.
- түүний доор байрлах мэдээллийн сантай холбогдох стандарт арга (жишээлбэл, MySQL);
- санах ойтой харилцах логикийг дахин бичиж, өөрчлөхгүйн тулд стандарт хайлтын хэл;
- гүйлгээний - харилцан үйлчлэлийн семантикийг хадгалах.
Хэрэв бүх гурван нөхцөл хангагдсан бол нэгтгэх боломжтой. Бид санах ойн мэдээллийн сүлжээг програм болон мэдээллийн сангийн хооронд байрлуулдаг. Одоо бичих хүсэлтийг үндсэн мэдээллийн санд, хэрэв өгөгдөл кэшэд байхгүй бол унших хүсэлтийг үндсэн мэдээллийн санд шилжүүлэх болно.
Хэрэв өгөгдөлд хурдан нэвтрэх, түүнийг боловсруулах нь танд чухал бол, жишээлбэл, бизнесийн аналитикийн хувьд та In-Memory-ийг хэрэгжүүлэх талаар бодож болно. Мөн хэрэгжүүлэхийн тулд та шинэ архитектурыг төлөвлөхдөө хоёр аргыг ашиглаж болно.
Эх сурвалж: www.habr.com