Giriş
Salam. Mən ningenMe, veb tərtibatçısıyam.
Başlıqda deyildiyi kimi, mənim hekayəm MySQL-də 300 milyon qeydin fiziki olaraq silinməsi ilə bağlıdır.
Bununla maraqlandım, ona görə də bir memo (təlimat) etmək qərarına gəldim.
Başlat - Xəbərdarlıq
İstifadə etdiyim və saxladığım toplu serverdə gündə bir dəfə MySQL-dən keçən ayın məlumatlarını toplayan müntəzəm proses var.
Adətən bu proses təxminən 1 saat ərzində tamamlanır, lakin bu dəfə 7 və ya 8 saat ərzində tamamlanmadı və siqnalın görünməsi dayanmadı...
Bir səbəb axtarırıq
Prosesi yenidən başlatmağa, qeydlərə baxmağa çalışdım, amma dəhşətli bir şey görmədim.
Sorğu düzgün indeksləşdirildi. Amma nəyin səhv olduğunu düşünəndə anladım ki, verilənlər bazasının həcmi kifayət qədər böyükdür.
hoge_table | 350'000'000 |350 milyon qeyd. İndeksləmə düzgün işləyirdi, sadəcə çox yavaş.
Tələb olunan aylıq məlumatların toplanması təxminən 12 qeyd idi. Deyəsən, seçmə əmri çox vaxt aparıb və əməliyyat uzun müddətdir icra olunmayıb.
DB
Əsasən, bu, hər gün təxminən 400 qeyd ilə böyüyən bir cədvəldir. Verilənlər bazası yalnız son bir ay üçün məlumat toplamalı idi, buna görə də hesablama onun tam olaraq bu miqdarda məlumatlara tab gətirəcəyi idi, lakin təəssüf ki, fırlanma əməliyyatı daxil edilmədi.
Bu verilənlər bazası mənim tərəfimdən hazırlanmamışdır. Mən onu başqa bir tərtibatçıdan götürdüm, ona görə də texniki borc kimi hiss etdim.
Gündəlik daxil edilən məlumatların həcminin çoxaldığı və nəhayət həddi çatdığı bir vaxt gəldi. Güman edilir ki, belə böyük həcmli məlumatlarla işləyərkən onları ayırmaq lazım olacaq, lakin bu, təəssüf ki, edilmədi.
Və sonra mən qarışdım.
Düzəliş
Məntiqin özünü dəyişdirməkdənsə, verilənlər bazasının özünü azaltmaq və emal müddətini azaltmaq daha rasional idi.
300 milyon qeyd silinsə vəziyyət əhəmiyyətli dərəcədə dəyişməlidir, ona görə də bunu etmək qərarına gəldim ... Eh, bunun mütləq işləyəcəyini düşündüm.
Fəaliyyət 1
Etibarlı ehtiyat nüsxəsini hazırladıqdan sonra nəhayət sorğular göndərməyə başladım.
「Sorğu göndərilir」
DELETE FROM hoge_table WHERE create_time <= 'YYYY-MM-DD HH:MM:SS';"..."
"..."
“Hmm... Cavab yoxdur. Bəlkə proses uzun çəkir? - Fikirləşdim, amma hər halda qrafana baxdım və gördüm ki, disk yükü çox sürətlə artır.
“Təhlükəli” – bir daha fikirləşdim və dərhal xahişi dayandırdım.
Fəaliyyət 2
Hər şeyi təhlil etdikdən sonra məlumatların miqdarının hər şeyi bir anda silmək üçün çox böyük olduğunu başa düşdüm.
Təxminən 1 girişi silə biləcək bir skript yazmağa qərar verdim və onu işə saldım.
「skriptin həyata keçirilməsi」
"İndi mütləq işləyəcək" deyə düşündüm.
Fəaliyyət 3
İkinci üsul işlədi, lakin çox vaxt apardı.
Hər şeyi səliqəli, lazımsız sinirlər olmadan etmək üçün təxminən iki həftə lazım olacaq. Amma yenə də bu ssenari xidmət tələblərinə cavab vermədiyi üçün ondan uzaqlaşmalı olduq.
Buna görə də, bunu etmək qərarına gəldim:
Cədvəli kopyalayın və adını dəyişdirin
Əvvəlki addımdan anladım ki, belə böyük miqdarda məlumatın silinməsi eyni dərəcədə böyük yük yaradır. Buna görə insertdən istifadə edərək sıfırdan yeni bir cədvəl yaratmağa və silmək istədiyim məlumatları ona köçürməyə qərar verdim.
| hoge_table | 350'000'000|
| tmp_hoge_table | 50'000'000|Yeni cədvəli yuxarıdakı kimi eyni ölçüdə etsəniz, məlumatların emal sürəti də 1/7 daha sürətli olmalıdır.
Cədvəl yaradıb adını dəyişdikdən sonra ondan master (əsas) cədvəl kimi istifadə etməyə başladım. İndi 300 milyon qeydi olan bir cədvəli atsam, hər şey yaxşı olacaq.
Kəsmə və ya buraxmanın silməkdən daha az yük yaratdığını bildim və bu üsuldan istifadə etmək qərarına gəldim.
İcra
「Sorğu göndərilir」
INSERT INTO tmp_hoge_table SELECT FROM hoge_table create_time > 'YYYY-MM-DD HH:MM:SS';
"..."
"..."
"Em...?"
Fəaliyyət 4
Əvvəlki ideyanın işləyəcəyini düşündüm, lakin daxiletmə sorğusunu göndərdikdən sonra çoxsaylı xəta yarandı. MySQL-in mərhəməti yoxdur.
Artıq o qədər yorulmuşdum ki, artıq bunu etmək istəmədiyimi düşünməyə başladım.
Oturdum və düşündüm və başa düşdüm ki, bəlkə bir dəfə çox əlavə sorğusu var ...
Mən verilənlər bazasının 1 gün ərzində emal etməli olduğu məlumatların miqdarı üçün əlavə sorğu göndərməyə çalışdım. baş verdi!
Yaxşı, bundan sonra biz eyni miqdarda məlumat üçün sorğu göndərməyə davam edirik. Aylıq məlumat miqdarını silməli olduğumuz üçün bu əməliyyatı təxminən 35 dəfə təkrarlayırıq.
Cədvəlin adının dəyişdirilməsi
Burada bəxt məndən yana idi: hər şey qaydasında getdi.
Xəbərdarlıq getdi
Toplu emal sürəti artdı.
Əvvəllər bu proses təxminən bir saat çəkirdisə, indi təxminən 2 dəqiqə çəkir.
Bütün problemlərin həll olunduğuna əmin olduqdan sonra 300 milyon qeydi atdım. Cədvəli sildim və yenidən doğulduğumu hiss etdim.
Xülasə
Mən başa düşdüm ki, toplu emalda fırlanan emal yoxdur və bu, əsas problem idi. Memarlıqda belə bir səhv vaxt itkisinə səbəb olur.
Məlumat bazasından qeydləri silərkən məlumatların təkrarlanması zamanı yükü düşünürsünüzmü? MySQL-i çox yükləməyək.
Verilənlər bazalarını yaxşı bilənlər belə bir problemlə mütləq qarşılaşmayacaqlar. Başqaları üçün ümid edirəm ki, bu məqalə faydalı oldu.
Oxuduğunuz üçün təşəkkür edirik!
Bu yazını bəyəndinizmi, tərcümə başa düşüləndirmi, sizə faydalı oldumu desəniz çox şad olarıq?
Mənbə: www.habr.com