Танилцуулга
Сайн уу. Би бол ningenMe, вэб хөгжүүлэгч.
Гарчиг дээр дурдсанчлан миний түүх бол MySQL дээр 300 сая бичлэгийг устгасан түүх юм.
Би үүнийг сонирхож эхэлсэн тул би сануулга хийхээр шийдсэн (заавар).
Нүүр хуудас - Анхааруулга
Миний ашигладаг, засвар үйлчилгээ хийдэг багц сервер нь MySQL-ээс сүүлийн сарын өгөгдлийг өдөрт нэг удаа цуглуулдаг тогтмол процесстой.
Ихэвчлэн энэ үйл явц 1 цагийн дотор дуусдаг бол энэ удаад 7, 8 цагийн турш дуусаагүй бөгөөд дохиолол зогссонгүй...
Шалтгаан хайж байна
Би процессыг дахин эхлүүлж, бүртгэлүүдийг харахыг оролдсон боловч ямар ч буруу зүйл олж харсангүй.
Асуултыг зөв индексжүүлсэн. Гэхдээ би юу болж байгааг бодоход мэдээллийн сангийн хэмжээ нэлээд том байгааг ойлгосон.
hoge_table | 350'000'000 |350 сая бичлэг. Индексжүүлэлт зөв ажиллаж байгаа бололтой, зүгээр л маш удаан.
Сард шаардлагатай мэдээлэл цуглуулах нь ойролцоогоор 12 бичлэг байсан. Сонгох команд нэлээд удсан, гүйлгээ хийгдээгүй удсан бололтой.
DB
Энэ нь үндсэндээ өдөр бүр 400 орцоор өсдөг хүснэгт юм. Мэдээллийн сан нь зөвхөн сүүлийн нэг сарын хугацаанд мэдээлэл цуглуулах ёстой байсан тул яг ийм хэмжээний өгөгдлийг тэсвэрлэх болно гэж таамаглаж байсан боловч харамсалтай нь эргүүлэх үйлдлийг оруулаагүй болно.
Энэ мэдээллийн санг би боловсруулаагүй. Би үүнийг өөр хөгжүүлэгчээс авсан тул энэ нь техникийн өр юм шиг санагдсан.
Өдөр бүр оруулдаг өгөгдлийн хэмжээ ихсэж, эцэст нь хязгаартаа хүрсэн үе ирлээ. Ийм их хэмжээний өгөгдөлтэй ажиллахдаа тэдгээрийг салгах шаардлагатай гэж үздэг боловч харамсалтай нь үүнийг хийгээгүй.
Тэгээд би үйл ажиллагаанд орсон.
Залруулга
Логикийг өөрчлөхөөс илүү мэдээллийн сангийн хэмжээг багасгаж, боловсруулах хугацааг багасгах нь илүү оновчтой байсан.
Хэрэв та 300 сая бичлэгийг устгавал нөхцөл байдал эрс өөрчлөгдөх ёстой, тиймээс би үүнийг хийхээр шийдсэн ... Өө, энэ нь мэдээж хэрэг болно гэж бодсон.
1-р алхам
Найдвартай нөөцлөлтийг бэлтгэсний дараа би хүсэлт илгээж эхлэв.
「Хүсэлт илгээж байна」
DELETE FROM hoge_table WHERE create_time <= 'YYYY-MM-DD HH:MM:SS';"..."
"..."
“Хмм... Хариу алга. Магадгүй процесс удаан үргэлжлэх болов уу?" - Би бодсон, гэхдээ би графана руу харахад дискний ачаалал маш хурдан нэмэгдэж байгааг харав.
"Аюултай" гэж би дахин бодсон бөгөөд тэр даруй хүсэлтийг зогсоов.
2-р алхам
Бүх зүйлд дүн шинжилгээ хийсний дараа би өгөгдлийн хэмжээ нь бүгдийг нэг дор устгахад хэтэрхий том болохыг ойлгосон.
Би 1 орчим бичлэгийг устгах боломжтой скрипт бичихээр шийдэж, үүнийг эхлүүлсэн.
「Би скриптийг хэрэгжүүлдэг」
"Одоо энэ мэдээж хэрэг болно" гэж би бодлоо.
3-р алхам
Хоёр дахь арга нь ажилласан боловч маш их хөдөлмөр шаардсан.
Шаардлагагүй мэдрэлгүйгээр бүх зүйлийг болгоомжтой хийхэд хоёр долоо хоног шаардагдана. Гэсэн хэдий ч энэ хувилбар нь үйлчилгээний шаардлагад нийцэхгүй байсан тул бид үүнээс татгалзах шаардлагатай болсон.
Тиймээс би юу хийхээр шийдсэн юм:
Хүснэгтийг хуулж, нэрийг нь өөрчил
Өмнөх алхамаас харахад ийм их хэмжээний өгөгдлийг устгах нь адилхан их ачаалал үүсгэдэг гэдгийг би ойлгосон. Тиймээс би insert ашиглан эхнээс нь шинэ хүснэгт үүсгэж, устгах гэж байсан өгөгдлөө түүн рүү зөөхөөр шийдсэн.
| hoge_table | 350'000'000|
| tmp_hoge_table | 50'000'000|Хэрэв та шинэ хүснэгтийг дээрхтэй ижил хэмжээтэй болговол өгөгдөл боловсруулах хурд мөн 1/7 дахин хурдан болно.
Хүснэгтийг үүсгэж, нэрийг нь өөрчилсний дараа би үүнийг мастер хүснэгт болгон ашиглаж эхэлсэн. Одоо би 300 сая бичлэгтэй хүснэгтийг унагавал бүх зүйл сайхан болно.
Таслах эсвэл хаях нь устгахаас бага ачаалал үүсгэдэг болохыг олж мэдээд энэ аргыг ашиглахаар шийдсэн.
Гүйцэтгэл
「Хүсэлт илгээж байна」
INSERT INTO tmp_hoge_table SELECT FROM hoge_table create_time > 'YYYY-MM-DD HH:MM:SS';
"..."
"..."
"Эм...?"
4-р алхам
Өмнөх санаа бүтнэ гэж бодсон боловч оруулах хүсэлтийг илгээсний дараа олон алдаа гарч ирэв. MySQL бол уучлахгүй.
Би аль хэдийн маш их ядарсан байсан тул би үүнийг дахиж хийхийг хүсэхгүй байна гэж бодож эхэлсэн.
Би суугаад бодоод, магадгүй нэг удаад хэтэрхий олон оруулах асуултууд байсан байх гэж ойлгосон ...
Би мэдээллийн санд 1 өдрийн дотор боловсруулах ёстой өгөгдлийн хэмжээг оруулах хүсэлтийг илгээхийг оролдсон. Боллоо!
Үүний дараа бид ижил хэмжээний өгөгдөл авах хүсэлтийг илгээсээр байна. Нэг сарын дата устгах шаардлагатай тул бид энэ үйлдлийг ойролцоогоор 35 удаа давтана.
Хүснэгтийн нэрийг өөрчлөх
Энд аз миний талд байсан: бүх зүйл хэвийн болсон.
Сэрэмжлүүлэг алга болсон
Багц боловсруулах хурд нэмэгдсэн.
Өмнө нь энэ процесс нэг цаг орчим үргэлжилдэг байсан бол одоо 2 минут орчим болдог.
Бүх асуудал шийдэгдсэн гэдэгт итгэлтэй байсны дараа би 300 сая бичлэгийг унагасан. Би ширээгээ устгаад дахин төрөхийг мэдэрсэн.
Дүгнэлт
Багц боловсруулахад эргэлтийн боловсруулалт байхгүй байгааг би ойлгосон бөгөөд энэ нь гол асуудал юм. Энэ төрлийн архитектурын алдаа нь цаг хугацаа алдахад хүргэдэг.
Өгөгдлийн сангаас бүртгэлийг устгахдаа өгөгдлийн хуулбарлах үеийн ачааллын талаар та бодож байна уу? MySQL-г хэт ачаалахгүй байцгаая.
Мэдээллийн санг сайн мэддэг хүмүүс ийм асуудалтай тулгарах нь гарцаагүй. Бусад хүмүүст энэ нийтлэл хэрэгтэй байсан гэж найдаж байна.
Уншсанд баярлалаа!
Энэ нийтлэл танд таалагдсан эсэх, орчуулга нь ойлгомжтой эсэх, танд хэрэг болсон эсэхийг бидэнд хэлвэл бид маш их баяртай байх болно.
Эх сурвалж: www.habr.com