Саяхныг хүртэл Odnoklassniki нь SQL Server дээр бодит цаг хугацаанд боловсруулсан 50 орчим ТБ өгөгдлийг хадгалж байсан. Ийм хэмжээний хувьд SQL DBMS ашиглан хурдан бөгөөд найдвартай, тэр ч байтугай өгөгдлийн төвийн доголдолд тэсвэртэй хандалт хийх нь бараг боломжгүй юм. Ихэвчлэн ийм тохиолдолд NoSQL хадгалалтын аль нэгийг ашигладаг боловч бүх зүйлийг NoSQL руу шилжүүлэх боломжгүй: зарим байгууллагууд ACID гүйлгээний баталгаа шаарддаг.
Энэ нь биднийг NewSQL хадгалах санг ашиглахад хүргэсэн, өөрөөр хэлбэл NoSQL системийн алдааг тэсвэрлэх чадвар, өргөтгөх чадвар, гүйцэтгэлийг хангадаг DBMS, гэхдээ нэгэн зэрэг сонгодог системд танил болсон ACID баталгааг хадгалах. Энэ шинэ ангиллын үйлдвэрлэлийн систем цөөхөн байдаг тул бид өөрсдөө ийм системийг хэрэгжүүлж, арилжааны ажиллагаанд оруулсан.
Энэ нь хэрхэн ажилладаг, юу болсон талаар - зүслэгийн доор уншина уу.
Өнөөдөр Одноклассники сайтын сарын үзэгчид 70 сая гаруй өвөрмөц зочинтой байна. Бид Дэлхийн хамгийн том нийгмийн сүлжээнүүд бөгөөд хэрэглэгчдийн хамгийн их цаг зарцуулдаг хорин сайтуудын нэг. OK дэд бүтэц нь маш өндөр ачааллыг зохицуулдаг: нэг фронтод нэг сая гаруй HTTP хүсэлт/сек. 8000 гаруй ширхэг серверийн флотын хэсгүүд нь хоорондоо ойрхон байрладаг - Москвагийн дөрвөн мэдээллийн төвд байрладаг бөгөөд энэ нь сүлжээний хоцролтыг 1 мс-ээс багагүй байлгах боломжийг олгодог.
Бид Cassandra-г 2010 оноос хойш 0.6 хувилбараас эхлэн ашиглаж байна. Өнөөдөр хэдэн арван кластер ажиллаж байна. Хамгийн хурдан кластер нь секундэд 4 сая гаруй үйлдлийг боловсруулдаг бол хамгийн том нь 260 TB-г хадгалдаг.
Гэхдээ эдгээр нь бүгд хадгалахад ашигладаг энгийн NoSQL кластерууд юм өгөгдөл. Бид Odnoklassniki-г үүсгэн байгуулснаас хойш ашиглагдаж байсан Microsoft SQL Server-ийн үндсэн хадгалалтыг солихыг хүссэн. Хадгалалт нь 300 гаруй SQL Server Standard Edition машинаас бүрдсэн бөгөөд үүнд 50 TB-ийн өгөгдөл - аж ахуйн нэгжүүд багтсан. Энэ өгөгдлийг ACID гүйлгээний нэг хэсэг болгон өөрчилсөн бөгөөд шаардлагатай .
SQL серверийн зангилаануудад өгөгдөл түгээхийн тулд бид босоо болон хэвтээ аль алиныг нь ашигласан (хэсэглэх). Түүхийн хувьд бид энгийн өгөгдөл хуваах схемийг ашигласан: аж ахуйн нэгж бүр нь токентой холбоотой байсан - аж ахуйн нэгжийн ID-ийн функц. Ижил токен бүхий байгууллагуудыг ижил SQL сервер дээр байрлуулсан. Үндсэн болон хүүхдийн бичлэгийн тэмдэгтүүд үргэлж таарч, нэг сервер дээр байрладаг байхаар мастер-дэлгэрэнгүй харилцааг хэрэгжүүлсэн. Нийгмийн сүлжээнд бараг бүх бүртгэлийг хэрэглэгчийн нэрийн өмнөөс үүсгэдэг бөгөөд энэ нь нэг функциональ дэд систем дэх хэрэглэгчийн бүх өгөгдөл нэг сервер дээр хадгалагддаг гэсэн үг юм. Өөрөөр хэлбэл, бизнесийн гүйлгээ нь бараг үргэлж нэг SQL серверийн хүснэгтүүдийг хамардаг бөгөөд энэ нь локал ACID гүйлгээг ашиглан өгөгдлийн тогтвортой байдлыг хангах боломжийг олгосон. түгээсэн ACID гүйлгээ.
Sharding болон SQL-г хурдасгахын тулд:
- Хуваалцах үед байгууллагын ID өөр сервер дээр байрлаж болзошгүй тул бид Гадаад түлхүүрийн хязгаарлалтыг ашигладаггүй.
- DBMS CPU-ийн нэмэлт ачааллын улмаас бид хадгалагдсан процедур болон триггерийг ашигладаггүй.
- Дээр дурдсан бүх зүйл болон дискнээс санамсаргүй уншдаг маш олон учраас бид JOIN-г ашигладаггүй.
- Гүйлгээнээс гадна бид түгжрэлийг багасгахын тулд Read Uncommitted тусгаарлах түвшинг ашигладаг.
- Бид зөвхөн богино хэмжээний гүйлгээг хийдэг (дунджаар 100 мс-ээс богино).
- Олон тооны гацсан тул бид олон эгнээний UPDATE болон DELETE-г ашигладаггүй - бид нэг удаад зөвхөн нэг бичлэгийг шинэчилдэг.
- Бид үргэлж зөвхөн индексүүд дээр асуулга хийдэг - бидний хувьд хүснэгтийг бүрэн скан хийх төлөвлөгөөтэй асуулга нь мэдээллийн баазыг хэт ачаалж, амжилтгүй болоход хүргэдэг.
Эдгээр алхмууд нь SQL серверүүдийн бараг хамгийн их гүйцэтгэлийг шахах боломжийг бидэнд олгосон. Гэсэн хэдий ч асуудал улам бүр нэмэгдсээр байв. Тэднийг харцгаая.
SQL-тэй холбоотой асуудлууд
- Бид өөрөө бичсэн хэлтэрхийг ашигласан тул шинэ хэлтэрхий нэмэхийг админууд гараар хийсэн. Энэ бүх хугацаанд өргөтгөх боломжтой өгөгдлийн хуулбарууд нь хүсэлтэд үйлчлэхгүй байсан.
- Хүснэгт дэх бичлэгийн тоо өсөхийн хэрээр одоо байгаа хүснэгтэд индекс нэмэх үед оруулах, өөрчлөх хурд буурч, зогсолттой үед индексүүдийг үүсгэх, дахин үүсгэх хурд багасдаг;
- Үйлдвэрлэлд бага хэмжээний Windows-д зориулсан SQL Server байгаа нь дэд бүтцийн менежментэд хүндрэл учруулдаг
Гэхдээ гол асуудал нь
алдааг тэсвэрлэх чадвар
Сонгодог SQL сервер нь алдааг тэсвэрлэх чадвар муутай байдаг. Танд ганцхан өгөгдлийн сангийн сервер байгаа бөгөөд гурван жилд нэг удаа бүтэлгүйтдэг гэж бодъё. Энэ хугацаанд сайт 20 минутын турш ажиллахгүй байгаа нь хүлээн зөвшөөрөгдөхүйц юм. Хэрэв танд 64 сервер байгаа бол сайт гурван долоо хоногт нэг удаа унтардаг. Хэрэв танд 200 сервер байгаа бол долоо хоног бүр сайт ажиллахгүй. Энэ бол асуудал.
SQL серверийн алдааг тэсвэрлэх чадварыг сайжруулахын тулд юу хийж болох вэ? Википедиа биднийг бүтээхийг урьж байна : бүрэлдэхүүн хэсгүүдийн аль нэг нь эвдэрсэн тохиолдолд нөөцлөлт байдаг.
Энэ нь үнэтэй тоног төхөөрөмжийн флотыг шаарддаг: олон тооны давхардал, оптик шилэн, дундын хадгалалт, нөөцийг оруулах нь найдвартай ажиллахгүй: шилжүүлэлтийн 10 орчим хувь нь үндсэн зангилааны ард галт тэрэг шиг нөөц зангилааны эвдрэлээр төгсдөг.
Гэхдээ ийм өндөр хүртээмжтэй кластерын гол сул тал нь түүний байрладаг дата төв ажиллахгүй бол хүртээмжгүй байх явдал юм. Odnoklassniki нь дөрвөн дата төвтэй бөгөөд тэдгээрийн аль нэг нь бүрэн доголдсон тохиолдолд бид ажиллах ёстой.
Үүний тулд бид ашиглаж болно SQL серверт суулгасан хуулбар. Энэхүү шийдэл нь програм хангамжийн өртөгөөс шалтгаалж илүү үнэтэй бөгөөд хуулбарлахтай холбоотой алдартай асуудлуудтай тулгардаг - синхрон хуулбарлахтай холбоотой урьдчилан таамаглах боломжгүй гүйлгээний саатал, асинхрон хуулбарлах үед хуулбарлах (үр дүнд нь алдагдсан өөрчлөлтүүд) хойшлогдох. далд утга Энэ сонголтыг бидэнд бүрэн ашиглах боломжгүй болгож байна.
Эдгээр бүх асуудал нь эрс шийдлийг шаарддаг бөгөөд бид тэдгээрийг нарийвчлан шинжилж эхэлсэн. Энд бид SQL Server голчлон юу хийдэг - гүйлгээтэй танилцах хэрэгтэй.
Энгийн гүйлгээ
Хэрэглээний SQL програмистын үүднээс хамгийн энгийн гүйлгээг авч үзье: цомогт зураг нэмэх. Цомог, гэрэл зургуудыг өөр өөр ялтсуудад хадгалдаг. Цомог нь нийтийн гэрэл зургийн тоолууртай. Дараа нь ийм гүйлгээг дараах үе шатуудад хуваана.
- Бид цомгийг түлхүүрээр түгждэг.
- Зургийн хүснэгтэд оруулга үүсгэ.
- Хэрэв зураг нь нийтийн статустай бол цомогт нийтийн зургийн тоолуур нэмж, бичлэгийг шинэчилж, гүйлгээг хийнэ үү.
Эсвэл псевдокодоор:
TX.start("Albums", id);
Album album = albums.lock(id);
Photo photo = photos.create(…);
if (photo.status == PUBLIC ) {
album.incPublicPhotosCount();
}
album.update();
TX.commit();Бизнесийн гүйлгээний хамгийн түгээмэл хувилбар бол мэдээллийн сангаас програмын серверийн санах ой руу өгөгдлийг уншиж, ямар нэг зүйлийг өөрчлөх, шинэ утгыг мэдээллийн санд хадгалах явдал гэдгийг бид харж байна. Ихэвчлэн ийм гүйлгээнд бид хэд хэдэн аж ахуйн нэгж, хэд хэдэн хүснэгтийг шинэчилдэг.
Гүйлгээ хийх үед өөр системээс ижил өгөгдөлд нэгэн зэрэг өөрчлөлт орж болно. Жишээлбэл, Антиспам нь хэрэглэгчийг ямар нэгэн байдлаар сэжиглэж байгаа тул хэрэглэгчийн бүх зургийг олон нийтэд харуулахгүй байх ёстой гэж үзэж болох тул тэдгээрийг зохицуулахаар илгээх шаардлагатай бөгөөд энэ нь photo.status-ыг өөр утгаар өөрчилж, харгалзах тоолуурыг унтраана гэсэн үг юм. Мэдээжийн хэрэг, хэрэв энэ үйл ажиллагаа нь хэрэглээний атомын баталгаагүй, өрсөлдөгчидтэй өөрчлөлтүүдийг тусгаарлахгүйгээр явагдах болно. , дараа нь үр дүн нь шаардагдах зүйл биш байх болно - зургийн тоолуур буруу утгыг харуулах эсвэл бүх зургийг зохицуулахаар илгээхгүй.
Нэг гүйлгээний хүрээнд янз бүрийн аж ахуйн нэгжүүдийг удирддаг ижил төстэй олон кодыг Одноклассники бүхэл бүтэн туршид бичсэн байдаг. -аас NoSQL руу шилжих туршлага дээр үндэслэн Хамгийн том сорилт (мөн цаг хугацааны хөрөнгө оруулалт) нь өгөгдлийн тогтвортой байдлыг хангах код боловсруулахаас гардаг гэдгийг бид мэднэ. Тиймээс бид шинэ хадгалах сангийн гол шаардлага бол хэрэглээний логикийн хувьд бодит ACID гүйлгээг хангах явдал гэж үзсэн.
Бусад чухал шаардлагууд нь:
- Хэрэв дата төв бүтэлгүйтвэл шинэ санах ой руу унших, бичих боломжтой байх ёстой.
- Одоогийн хөгжлийн хурдыг хадгалах. Өөрөөр хэлбэл, шинэ репозитортой ажиллахдаа кодын хэмжээ ойролцоогоор ижил байх ёстой, архивт юу ч нэмэх шаардлагагүй, зөрчилдөөнийг шийдвэрлэх алгоритм боловсруулах, хоёрдогч индексийг хадгалах гэх мэт.
- Мэдээллийг унших, гүйлгээг боловсруулах үед шинэ санах ойн хурд нэлээд өндөр байх ёстой байсан бөгөөд энэ нь жишээлбэл, эрдэм шинжилгээний хатуу, бүх нийтийн боловч удаан шийдлүүдийг ашиглах боломжгүй гэсэн үг юм. .
- Автомат шууд масштаблах.
- Ердийн хямд сервер ашиглах, чамин техник хангамж худалдаж авах шаардлагагүй.
- Компанийн хөгжүүлэгчид хадгалах санг хөгжүүлэх боломж. Өөрөөр хэлбэл, Java хэл дээр байгаа бол өмчийн эсвэл нээлттэй эхийн шийдлүүдэд давуу эрх олгосон.
Шийдвэр, шийдвэр
Боломжит шийдлүүдэд дүн шинжилгээ хийснээр бид хоёр боломжит архитектурын сонголттой болсон:
Эхнийх нь ямар ч SQL серверийг авч, шаардлагатай алдааны хүлцэл, масштабын механизм, failover кластер, зөрчилдөөнийг шийдвэрлэх, хуваарилагдсан, найдвартай, хурдан ACID гүйлгээг хэрэгжүүлэх явдал юм. Бид энэ сонголтыг маш энгийн бус, хөдөлмөр их шаарддаг гэж үнэлэв.
Хоёрдахь сонголт бол гүйлгээ, SQL-г өөрөө хэрэгжүүлэх, гүйлгээ хийх, ачаалах кластер, зөрчил шийдвэрлэх зэрэг бэлэн NoSQL санах ойг авах явдал юм. Өнгөц харахад ACID гүйлгээ битгий хэл SQL-ийг хэрэгжүүлэх ажил ч хэдэн жил шаардагдах ажил мэт харагдаж байна. Гэвч дараа нь бидний практикт ашигладаг SQL функцийн багц нь ANSI SQL-ээс хол байгааг ойлгосон ANSI SQL-ээс хол. CQL-г илүү нарийвчлан судалж үзэхэд энэ нь бидэнд хэрэгтэй зүйлд маш ойрхон байгааг ойлгосон.
Кассандра ба CQL
Тэгэхээр Кассандра ямар сонирхолтой вэ, ямар чадвартай вэ?
Нэгдүгээрт, энд та үндсэн түлхүүр дээр SELECT эсвэл UPDATE хийх боломжтой янз бүрийн өгөгдлийн төрлийг дэмждэг хүснэгтүүдийг үүсгэж болно.
CREATE TABLE photos (id bigint KEY, owner bigint,…);
SELECT * FROM photos WHERE id=?;
UPDATE photos SET … WHERE id=?;Хуулбарлах өгөгдлийн нийцтэй байдлыг хангахын тулд Кассандра ашигладаг . Хамгийн энгийн тохиолдолд энэ нь нэг эгнээний гурван хуулбарыг кластерын өөр өөр зангилаанууд дээр байрлуулах үед ихэнх зангилаа (өөрөөр хэлбэл гурвын хоёр нь) энэ бичих үйл ажиллагааны амжилтыг баталгаажуулсан бол бичихийг амжилттай гэж үзнэ гэсэн үг юм. . Унших үед ихэнх зангилааны санал асуулга авч, тэдгээрийг баталгаажуулсан бол мөрийн өгөгдлийг нийцтэй гэж үзнэ. Тиймээс гурван хуулбартай бол нэг зангилаа бүтэлгүйтсэн тохиолдолд өгөгдлийн бүрэн, шуурхай нийцтэй байдал баталгаатай болно. Энэ арга нь бидэнд илүү найдвартай схемийг хэрэгжүүлэх боломжийг олгосон: хамгийн хурдан хоёроос хариу хүлээж, бүх гурван хуулбар руу хүсэлт илгээх. Гурав дахь хуулбарын хожуу хариултыг энэ тохиолдолд хасна. Хариу өгөхдөө хоцорсон зангилаа нь тоормос, JVM дахь хог цуглуулах, Линукс цөм дэх шууд санах ойг сэргээх, техник хангамжийн доголдол, сүлжээнээс салгах зэрэг ноцтой асуудалтай байж болно. Гэхдээ энэ нь үйлчлүүлэгчийн үйл ажиллагаа, өгөгдөлд ямар нэгэн байдлаар нөлөөлөхгүй.
Гурван зангилаатай холбоо барьж, хоёроос хариу авах аргыг нэрлэдэг : нэмэлт хуулбар авах хүсэлтийг "унахаас" өмнө илгээдэг.
Кассандрагийн өөр нэг давуу тал бол Batchlog бөгөөд таны хийсэн багц өөрчлөлтүүд бүрэн хэрэгжих эсвэл огт хэрэгжихгүй байх боломжийг олгодог механизм юм. Энэ нь ACID-д А-г шийдвэрлэх боломжийг олгодог - атомын чанар.
Кассандра дахь гүйлгээнд хамгийн ойр байдаг зүйл бол "". Гэхдээ тэд "бодит" ACID-ийн гүйлгээнээс хол байдаг: үнэндээ энэ бол хийх боломж юм хүнд жинтэй Paxos протоколыг ашиглан зөвшилцлийг ашиглан зөвхөн нэг бичлэгийн өгөгдөл дээр. Тиймээс ийм гүйлгээний хурд бага байна.
Кассандра бидэнд юу дутагдаж байв
Тиймээс бид Кассандра дахь ACID-ийн бодит гүйлгээг хэрэгжүүлэх шаардлагатай болсон. Үүнийг ашигласнаар бид сонгодог DBMS-ийн өөр хоёр тохиромжтой функцийг хялбархан хэрэгжүүлж болох юм: тогтмол хурдан индексүүд нь зөвхөн үндсэн түлхүүрээр бус өгөгдлийг сонгох боломжийг олгодог, мөн автоматаар нэмэгдэх ID-ийн ердийн генератор юм.
C*Нэг
Ийнхүү шинэ DBMS үүссэн C*Нэг, гурван төрлийн серверийн зангилаанаас бүрдэнэ:
- Хадгалалт - (бараг) стандарт Кассандра серверүүд нь өгөгдлийг дотоод диск дээр хадгалах үүрэгтэй. Өгөгдлийн ачаалал, хэмжээ нэмэгдэхийн хэрээр тэдгээрийн тоо хэмжээг арав, зуугаар хялбархан өргөжүүлж болно.
- Гүйлгээний зохицуулагчид - гүйлгээний гүйцэтгэлийг хангах.
- Үйлчлүүлэгч нь бизнесийн үйл ажиллагаа явуулж, гүйлгээг эхлүүлдэг програмын серверүүд юм. Ийм үйлчлүүлэгч олон мянган байж болно.
Бүх төрлийн серверүүд нь нийтлэг кластерын нэг хэсэг бөгөөд өөр хоорондоо харилцахын тулд Кассандра мессежийн дотоод протоколыг ашигладаг. кластерын мэдээлэл солилцоход зориулагдсан. Heartbeat-ийн тусламжтайгаар серверүүд харилцан бүтэлгүйтлийн талаар суралцаж, нэг өгөгдлийн схем - хүснэгт, тэдгээрийн бүтэц, хуулбарыг хадгалах; хуваалтын схем, кластер топологи гэх мэт.
Үйлчлүүлэгчид
Стандарт драйверуудын оронд Fat Client горимыг ашигладаг. Ийм зангилаа нь өгөгдлийг хадгалахгүй, харин хүсэлтийг гүйцэтгэх зохицуулагчийн үүрэг гүйцэтгэдэг, өөрөөр хэлбэл, Үйлчлүүлэгч өөрөө хүсэлтийнхээ зохицуулагчийн үүрэг гүйцэтгэдэг: хадгалалтын хуулбарыг асууж, зөрчилдөөнийг шийддэг. Энэ нь алсын зохицуулагчтай харилцахыг шаарддаг стандарт драйвераас илүү найдвартай, хурдан төдийгүй хүсэлтийн дамжуулалтыг хянах боломжийг олгодог. Үйлчлүүлэгч дээр нээлттэй гүйлгээнээс гадна хүсэлтийг хадгалах газар руу илгээдэг. Хэрэв үйлчлүүлэгч гүйлгээ нээсэн бол гүйлгээний бүх хүсэлтийг гүйлгээний зохицуулагч руу илгээнэ.
C*Нэг гүйлгээ зохицуулагч
Зохицуулагч бол бидний C*One-д эхнээс нь хэрэгжүүлсэн зүйл юм. Энэ нь гүйлгээ, түгжээ, гүйлгээний дарааллыг удирдах үүрэгтэй.
Үйлчлүүлсэн гүйлгээ бүрийн хувьд зохицуулагч цагийн тэмдэг үүсгэдэг: дараагийн гүйлгээ бүр өмнөх гүйлгээнээс их байна. Кассандрагийн зөрчил шийдвэрлэх систем нь цагийн тэмдэгт (хоёр зөрчилдөөнтэй, хамгийн сүүлийн үеийн тэмдэгтэй нь одоогийн гэж тооцогддог) дээр суурилдаг тул зөрчил нь дараагийн гүйлгээний талд үргэлжлэн шийдэгдэх болно. Ингээд бид хэрэгжүүлсэн - тархсан систем дэх зөрчилдөөнийг шийдвэрлэх хямд арга.
Түгжээ
Тусгаарлахын тулд бид хамгийн энгийн аргыг ашиглахаар шийдсэн - бичлэгийн үндсэн түлхүүр дээр суурилсан гутранги түгжээ. Өөрөөр хэлбэл, гүйлгээ хийхдээ бичлэгийг эхлээд түгжиж, дараа нь уншиж, өөрчилж, хадгалах ёстой. Амжилттай гүйцэтгэсний дараа л бичлэгийн түгжээг тайлж, өрсөлдөгч гүйлгээг ашиглах боломжтой.
Ийм түгжээг хэрэгжүүлэх нь тархаагүй орчинд энгийн зүйл юм. Тархсан системд хоёр үндсэн сонголт байдаг: кластер дээр тархсан түгжээг хэрэгжүүлэх, эсвэл ижил бүртгэлтэй гүйлгээг үргэлж ижил зохицуулагчаар үйлчилдэг байхаар гүйлгээг түгээх.
Манай тохиолдолд өгөгдөл нь SQL дахь орон нутгийн гүйлгээний бүлгүүдийн дунд аль хэдийн хуваарилагдсан тул зохицуулагчид орон нутгийн гүйлгээний бүлгүүдийг хуваарилахаар шийдсэн: нэг зохицуулагч нь 0-ээс 9 хүртэлх жетоноор бүх гүйлгээг гүйцэтгэдэг, хоёр дахь нь 10-аас 19 хүртэлх жетоноор, гэх мэт. Үүний үр дүнд зохицуулагчийн тохиолдол бүр нь гүйлгээний бүлгийн мастер болдог.
Дараа нь түгжээг зохицуулагчийн санах ойд энгийн HashMap хэлбэрээр хийж болно.
Зохицуулагчийн алдаа
Нэг зохицуулагч нь зөвхөн бүлэг гүйлгээнд үйлчилдэг тул гүйлгээг хийх хоёр дахь оролдлогын хугацаа дуусахын тулд түүний бүтэлгүйтсэн баримтыг хурдан тодорхойлох нь маш чухал юм. Үүнийг хурдан бөгөөд найдвартай болгохын тулд бид бүрэн холбогдсон чуулгын сонсголын протоколыг ашигласан:
Мэдээллийн төв бүр дор хаяж хоёр зохицуулагч зангилаатай. Зохицуулагч бүр зүрхний цохилтын мэдээг үе үе бусад зохицуулагчид илгээж, үйл ажиллагааныхаа талаар, мөн кластер дахь аль зохицуулагчаас зүрхний цохилтын ямар мессежийг хамгийн сүүлд хүлээн авсан тухай мэдээлдэг.
Бусад хүмүүсээс зүрхний цохилтын мессежийн нэг хэсэг болгон ижил төстэй мэдээллийг хүлээн авч, зохицуулагч бүр аль кластерийн зангилаа ажиллаж, аль нь ажиллахгүй байгааг өөрөө шийддэг бөгөөд хэрэв X зангилаа нь кластерын ихэнх зангилаанаас хэвийн байдлын талаар мэдээлэл авсан бол чуулгын зарчмыг баримтална. Y зангилаанаас мессеж хүлээн авбал , Y ажиллана. Мөн эсрэгээр, ихэнх нь Y зангилаанаас мессеж алга болсон гэж мэдээлмэгц Y татгалзсан болно. Хэрэв чуулга X зангилаанаас мессеж хүлээн авахаа больсон гэж мэдэгдвэл X зангилаа өөрөө бүтэлгүйтсэн гэж үзэх нь сонин байна.
Зүрхний цохилтын мессежийг өндөр давтамжтайгаар, секундэд 20 орчим удаа, 50 мс давтамжтайгаар илгээдэг. Жава хэл дээр хог цуглуулагчаас үүссэн түр зогсолтын урттай харьцуулж болохуйц тул програмын хариуг 50 мс дотор баталгаажуулахад хэцүү байдаг. Бид G1 хогийн цуглуулагчийг ашиглан энэ хариу өгөх хугацаанд хүрч чадсан бөгөөд энэ нь GC-ийн түр зогсолтын үргэлжлэх хугацааны зорилтыг тодорхойлох боломжийг бидэнд олгодог. Гэсэн хэдий ч заримдаа коллекторын завсарлага 50 мс-ээс хэтрэх нь ховор тохиолддог бөгөөд энэ нь алдааг буруу илрүүлэхэд хүргэдэг. Үүнээс урьдчилан сэргийлэхийн тулд зохицуулагч нь зүрхний цохилтын эхний мессеж алга болох үед алсын зангилааны эвдрэлийн талаар мэдээлдэггүй, зөвхөн хэд хэдэн дараалсан алга болсон тохиолдолд бид 200 дахь зохицуулагчийн зангилааны эвдрэлийг илрүүлж чадсан юм ms.
Гэхдээ аль зангилаа ажиллахаа больсныг хурдан ойлгоход хангалтгүй юм. Бид энэ талаар ямар нэгэн зүйл хийх хэрэгтэй байна.
Захиалга
Сонгодог схемд мастер бүтэлгүйтсэн тохиолдолд аль нэгийг нь ашиглан шинэ сонгууль эхлүүлэхийг хэлнэ алгоритмууд. Гэсэн хэдий ч ийм алгоритмууд нь цаг хугацааны нэгдэл, сонгуулийн үйл явцын урттай холбоотой сайн мэддэг асуудлуудтай байдаг. Бүрэн холбогдсон сүлжээнд зохицуулагчийг солих схемийг ашиглан бид ийм нэмэлт саатлаас зайлсхийж чадсан:
Бид 50-р бүлэгт гүйлгээ хийхийг хүсч байна гэж бодъё. Орлуулах схемийг, өөрөөр хэлбэл, үндсэн зохицуулагчийн алдаа гарсан тохиолдолд 50-р бүлгийн аль зангилаа гүйлгээг гүйцэтгэхийг урьдчилан тодорхойлъё. Бидний зорилго бол дата төв доголдсон тохиолдолд системийн ажиллагааг хангах явдал юм. Эхний нөөц нь өөр мэдээллийн төвийн зангилаа, хоёр дахь нөөц нь гуравны нэгийн зангилаа байх болно гэдгийг тодорхойлъё. Энэ схемийг нэг удаа сонгосон бөгөөд кластерын топологи өөрчлөгдөх хүртэл, өөрөөр хэлбэл шинэ зангилаа орох хүртэл өөрчлөгддөггүй (энэ нь маш ховор тохиолддог). Хуучин нь бүтэлгүйтсэн тохиолдолд шинэ идэвхтэй мастер сонгох журам үргэлж дараах байдалтай байх болно: эхний нөөц идэвхтэй мастер болж, хэрэв ажиллахаа больсон бол хоёр дахь нөөц идэвхтэй мастер болно.
Энэ схем нь бүх нийтийн алгоритмаас илүү найдвартай, учир нь шинэ мастерийг идэвхжүүлэхийн тулд хуучин нэгний бүтэлгүйтлийг тодорхойлоход хангалттай.
Гэхдээ одоо аль мастер ажиллаж байгааг үйлчлүүлэгчид хэрхэн ойлгох вэ? 50 мс-ийн дотор олон мянган үйлчлүүлэгчид мэдээлэл илгээх боломжгүй. Үйлчлүүлэгч энэ мастер ажиллахаа больсоныг хараахан мэдээгүй байгаа гүйлгээг нээх хүсэлтийг илгээх нөхцөл байдал үүсч, хүсэлтийн хугацаа дуусах болно. Үүнээс урьдчилан сэргийлэхийн тулд үйлчлүүлэгчид гүйлгээ нээх хүсэлтийг группын мастер болон түүний нөөцөд нэгэн зэрэг илгээдэг боловч тухайн үед идэвхтэй мастер нь л энэ хүсэлтэд хариу өгөх болно. Үйлчлүүлэгч нь гүйлгээний хүрээнд дараагийн бүх харилцааг зөвхөн идэвхтэй мастертай хийх болно.
Нөөцлөлтийн мастерууд өөрсдийнх биш гүйлгээний хүлээн авсан хүсэлтийг төрөөгүй гүйлгээний дараалалд байрлуулж, хэсэг хугацаанд хадгалдаг. Хэрэв идэвхтэй мастер нас барвал шинэ мастер нь дарааллаас гүйлгээ нээх хүсэлтийг боловсруулж, үйлчлүүлэгчид хариу өгнө. Хэрэв үйлчлүүлэгч хуучин мастертай аль хэдийн гүйлгээ нээсэн бол хоёр дахь хариуг үл тоомсорлодог (мэдээжийн хэрэг, ийм гүйлгээ дуусахгүй бөгөөд үйлчлүүлэгч дахин давтагдах болно).
Гүйлгээ хэрхэн ажилладаг
Үйлчлүүлэгч зохицуулагч руу ийм ийм үндсэн түлхүүрээр гүйлгээ нээх хүсэлт илгээсэн гэж бодъё. Зохицуулагч нь энэ аж ахуйн нэгжийг түгжиж, санах ойд түгжих хүснэгтэд байрлуулна. Шаардлагатай бол зохицуулагч нь энэ аж ахуйн нэгжийг хадгалалтаас уншиж, үр дүнгийн өгөгдлийг зохицуулагчийн санах ойд гүйлгээний төлөвт хадгална.
Үйлчлүүлэгч гүйлгээний өгөгдөлд өөрчлөлт оруулахыг хүсвэл тухайн байгууллагыг өөрчлөх хүсэлтийг зохицуулагч руу илгээдэг бөгөөд зохицуулагч шинэ өгөгдлийг гүйлгээний төлөвийн хүснэгтэд санах ойд байрлуулдаг. Энэ нь бичлэгийг дуусгана - хадгалах санд ямар ч бичлэг хийгдэхгүй.
Үйлчлүүлэгч идэвхтэй гүйлгээний нэг хэсэг болгон өөрчилсөн өгөгдлийг хүссэн тохиолдолд зохицуулагч дараах байдлаар ажиллана.
- хэрэв ID нь гүйлгээнд аль хэдийн орсон бол өгөгдлийг санах ойноос авдаг;
- хэрэв санах ойд ID байхгүй бол дутуу өгөгдлийг санах ойд байгаа цэгүүдтэй нэгтгэн уншиж, үр дүнг үйлчлүүлэгчид өгнө.
Тиймээс үйлчлүүлэгч өөрийн өөрчлөлтийг уншиж болно, гэхдээ бусад үйлчлүүлэгчид эдгээр өөрчлөлтүүдийг харахгүй, учир нь тэдгээр нь зөвхөн зохицуулагчийн санах ойд хадгалагддаг бөгөөд тэдгээр нь Кассандра зангилаанд хараахан ороогүй байна.
Үйлчлүүлэгч үүрэг илгээх үед үйлчилгээний санах ойд байсан төлөвийг зохицуулагч бүртгэлтэй багцаар хадгалж, бүртгэлтэй багц хэлбэрээр Кассандра хадгалах сан руу илгээдэг. Дэлгүүрүүд энэ багцыг атомаар (бүрэн) ашиглахын тулд шаардлагатай бүх зүйлийг хийдэг бөгөөд түгжээг суллаж, үйлчлүүлэгчид гүйлгээ амжилттай хийгдсэнийг баталгаажуулдаг зохицуулагчид хариу илгээдэг.
Мөн буцаахын тулд зохицуулагч зөвхөн гүйлгээний төлөвт эзлэгдсэн санах ойг чөлөөлөх хэрэгтэй.
Дээрх сайжруулалтын үр дүнд бид ACID-ийн зарчмуудыг хэрэгжүүлсэн.
- Атом чанар. Энэ нь системд ямар ч гүйлгээг хэсэгчлэн бүртгэхгүй, эсвэл түүний бүх дэд үйл ажиллагаа хийгдэх эсвэл аль нь ч дуусахгүй гэсэн баталгаа юм. Бид энэ зарчмыг Кассандра дахь бүртгэлийн багцаар дамжуулан баримталдаг.
- Тогтвортой байдал. Амжилттай гүйлгээ бүр нь тодорхойлолтоор зөвхөн хүчинтэй үр дүнг бүртгэдэг. Хэрэв гүйлгээг нээж, үйл ажиллагааны зарим хэсгийг гүйцэтгэсний дараа үр дүн нь хүчингүй болох нь тогтоогдвол буцаах ажиллагааг гүйцэтгэнэ.
- Тусгаарлалт. Гүйлгээ хийгдэх үед зэрэгцээ гүйлгээ нь түүний үр дүнд нөлөөлөх ёсгүй. Өрсөлдөгч гүйлгээг зохицуулагч дээр гутранги түгжээ ашиглан тусгаарладаг. Гүйлгээнээс гадуур уншихад тусгаарлах зарчмыг Read Committed түвшинд хэрэгжүүлдэг.
- Уян хатан байдал. Доод түвшний асуудлаас үл хамааран - системийн уналт, техник хангамжийн доголдол - амжилттай гүйцэтгэсэн гүйлгээгээр хийсэн өөрчлөлтүүд үйл ажиллагаа сэргэх үед хадгалагдан үлдэх ёстой.
Индексээр унших
Энгийн хүснэгтийг авч үзье:
CREATE TABLE photos (
id bigint primary key,
owner bigint,
modified timestamp,
…)Энэ нь ID (үндсэн түлхүүр), эзэмшигч, өөрчлөгдсөн огноотой. Та маш энгийн хүсэлт гаргах хэрэгтэй - "сүүлийн өдрийн" өөрчлөлтийн огноо бүхий эзэмшигчийн мэдээллийг сонгоно уу.
SELECT *
WHERE owner=?
AND modified>?Ийм асуулга хурдан боловсруулагдахын тулд сонгодог SQL DBMS-д индексийг баганаар (эзэмшигч, өөрчилсөн) бүтээх хэрэгтэй. Бид үүнийг маш амархан хийж чадна, учир нь бид ACID-ийн баталгаатай болсон!
C* One дахь индексүүд
Бичлэгийн ID нь үндсэн түлхүүр болох гэрэл зураг бүхий эх хүснэгт байдаг.
Индексийн хувьд C*One нь эхийн хуулбар болох шинэ хүснэгтийг үүсгэдэг. Түлхүүр нь индексийн илэрхийлэлтэй ижил бөгөөд эх хүснэгтийн бичлэгийн үндсэн түлхүүрийг агуулна.
Одоо "сүүлийн өдрийн эзэмшигч" гэсэн асуултыг өөр хүснэгтээс сонгох байдлаар дахин бичиж болно.
SELECT * FROM i1_test
WHERE owner=?
AND modified>?Эх хүснэгтийн зураг болон индекс хүснэгт i1 дэх өгөгдлийн нийцтэй байдлыг зохицуулагч автоматаар хадгалдаг. Зөвхөн өгөгдлийн схем дээр үндэслэн өөрчлөлтийг хүлээн авах үед зохицуулагч өөрчлөлтийг зөвхөн үндсэн хүснэгтэд төдийгүй хуулбар хэлбэрээр үүсгэж хадгалдаг. Индекс хүснэгтэд нэмэлт үйлдэл хийгдээгүй, бүртгэлийг уншдаггүй, түгжээг ашигладаггүй. Өөрөөр хэлбэл, индекс нэмэх нь бараг ямар ч нөөц зарцуулдаггүй бөгөөд өөрчлөлт оруулах хурдад бараг ямар ч нөлөө үзүүлэхгүй.
ACID ашиглан бид SQL-тэй төстэй индексүүдийг хэрэгжүүлж чадсан. Эдгээр нь тогтвортой, өргөтгөх боломжтой, хурдан, зохицох боломжтой, CQL асуулгын хэлэнд суулгагдсан байдаг. Индексийг дэмжихийн тулд програмын кодыг өөрчлөх шаардлагагүй. Бүх зүйл SQL шиг энгийн. Хамгийн гол нь индексүүд нь анхны гүйлгээний хүснэгтэд өөрчлөлт оруулах хурдад нөлөөлдөггүй.
Юу болов
Бид гурван жилийн өмнө C*One-г хөгжүүлж, арилжааны зориулалтаар ашиглаж эхэлсэн.
Эцэст нь бид юу авсан бэ? Нийгмийн сүлжээн дэх өгөгдлийн хамгийн чухал төрлүүдийн нэг болох зураг боловсруулах, хадгалах дэд системийн жишээн дээр үүнийг үнэлье. Бид гэрэл зургийн биетийн тухай биш, харин бүх төрлийн мета мэдээллийн тухай ярьж байна. Одоо Одноклассники 20 орчим тэрбум ийм бүртгэлтэй бөгөөд систем нь секундэд 80 мянган унших хүсэлтийг боловсруулдаг бөгөөд өгөгдлийг өөрчлөхтэй холбоотой секундэд 8 мянган ACID гүйлгээг боловсруулдаг.
Бид хуулбарлах хүчин зүйл = 1-тэй SQL-г ашиглах үед (гэхдээ RAID 10-д) зургийн мета мэдээлэл нь Microsoft SQL Server дээр ажилладаг 32 машинаас бүрдэх өндөр боломжтой кластер дээр хадгалагдсан (нэмэх 11 нөөц). Мөн нөөцлөлтийг хадгалах 10 серверийг хуваарилсан. Нийт 50 үнэтэй машин. Үүний зэрэгцээ систем нь нөөцгүй, нэрлэсэн ачаалалтай ажилладаг байв.
Шинэ систем рүү шилжсэний дараа бид хуулбарлах хүчин зүйл = 3 - өгөгдлийн төв бүрт хуулбарыг хүлээн авсан. Систем нь 63 Кассандра хадгалах цэг, 6 зохицуулагч машин, нийт 69 серверээс бүрдэнэ. Гэхдээ эдгээр машинууд нь хамаагүй хямд бөгөөд тэдгээрийн нийт өртөг нь SQL системийн зардлын 30 орчим хувийг эзэлдэг. Үүний зэрэгцээ ачааллыг 30% -д байлгадаг.
C*One программыг нэвтрүүлснээр хоцролтын хугацаа мөн багассан: SQL дээр бичих үйлдэл 4,5 мс орчим болсон. C*One дээр - ойролцоогоор 1,6 мс. Гүйлгээний үргэлжлэх хугацаа дунджаар 40 мс-ээс бага, амлалт нь 2 мс, унших, бичих хугацаа дунджаар 2 мс байна. 99-р хувь - ердөө 3-3,1 мс, завсарлагааны тоо 100 дахин буурсан - бүгд таамаглалыг өргөнөөр ашигласантай холбоотой.
Одоогийн байдлаар ихэнх SQL серверийн зангилаанууд нь зөвхөн C*One ашиглан бүтээгдэж байна. Бид C*One-г үүлэн дээрээ ажиллахаар тохируулсан , энэ нь шинэ кластеруудыг байршуулах ажлыг хурдасгах, тохиргоог хялбаршуулах, ажиллагааг автоматжуулах боломжтой болсон. Эх кодгүй бол үүнийг хийх нь илүү хэцүү бөгөөд төвөгтэй байх болно.
Одоо бид бусад хадгалах байгууламжуудаа үүлэн систем рүү шилжүүлэхээр ажиллаж байна, гэхдээ энэ бол огт өөр түүх юм.
Эх сурвалж: www.habr.com