MySQL-এ 300 মিলিয়ন রেকর্ড শারীরিকভাবে মুছে ফেলার গল্প

ভূমিকা

হ্যালো. আমি ningenMe, ওয়েব ডেভেলপার।

শিরোনামটি বলে, আমার গল্পটি MySQL-এ 300 মিলিয়ন রেকর্ড শারীরিকভাবে মুছে ফেলার গল্প।

আমি এতে আগ্রহী হয়েছিলাম, তাই আমি একটি অনুস্মারক (নির্দেশ) করার সিদ্ধান্ত নিয়েছি।

বাড়ি - সতর্কতা

আমি যে ব্যাচ সার্ভারটি ব্যবহার করি এবং বজায় রাখি তার একটি নিয়মিত প্রক্রিয়া রয়েছে যা দিনে একবার MySQL থেকে গত মাসের ডেটা সংগ্রহ করে।

সাধারণত এই প্রক্রিয়াটি প্রায় 1 ঘন্টার মধ্যে সম্পন্ন হয়, তবে এবার এটি 7 বা 8 ঘন্টার জন্য সম্পূর্ণ হয়নি এবং সতর্কতা পপ আপ হওয়া বন্ধ করেনি...

কারণ খুঁজছেন

আমি প্রক্রিয়াটি পুনরায় চালু করার এবং লগগুলি দেখার চেষ্টা করেছি, কিন্তু আমি কিছু ভুল দেখিনি।
ক্যোয়ারী সঠিকভাবে সূচিত করা হয়েছে. কিন্তু যখন আমি ভাবলাম কী ভুল হচ্ছে, আমি বুঝতে পেরেছি যে ডাটাবেসের আকার বেশ বড়।

hoge_table | 350'000'000 |

350 মিলিয়ন রেকর্ড। ইন্ডেক্সিং সঠিকভাবে কাজ করছে বলে মনে হচ্ছে, খুব ধীর।

প্রতি মাসে প্রয়োজনীয় তথ্য সংগ্রহ ছিল প্রায় 12 রেকর্ড। দেখে মনে হচ্ছে নির্বাচন কমান্ডটি দীর্ঘ সময় নিয়েছে এবং লেনদেনটি দীর্ঘ সময়ের জন্য কার্যকর হয়নি।

DB

এটি মূলত একটি টেবিল যা প্রতিদিন প্রায় 400 এন্ট্রি দ্বারা বৃদ্ধি পায়। ডাটাবেসটি শুধুমাত্র গত মাসের জন্য ডেটা সংগ্রহ করার কথা ছিল, তাই, আশা করা হয়েছিল যে এটি ঠিক এই পরিমাণ ডেটা সহ্য করবে, কিন্তু দুর্ভাগ্যবশত, ঘূর্ণন অপারেশনটি অন্তর্ভুক্ত করা হয়নি।

এই ডাটাবেস আমার দ্বারা বিকাশ করা হয়নি. আমি এটি অন্য বিকাশকারীর কাছ থেকে নিয়েছি, তাই এটি এখনও প্রযুক্তিগত ঋণের মতো অনুভূত হয়েছিল।

এমন একটি বিন্দু এসেছিল যখন প্রতিদিন ঢোকানো ডেটার পরিমাণ বড় হয়ে ওঠে এবং অবশেষে তার সীমাতে পৌঁছে যায়। এটি অনুমান করা হয় যে এত বড় পরিমাণে ডেটা নিয়ে কাজ করার সময়, তাদের আলাদা করা প্রয়োজন, কিন্তু দুর্ভাগ্যবশত, এটি করা হয়নি।

আর তখনই অ্যাকশনে এলাম।

সংশোধন

ডাটাবেসের আকার কমানো এবং লজিক পরিবর্তন করার চেয়ে এটি প্রক্রিয়াকরণের জন্য সময় কমানো আরও যুক্তিযুক্ত ছিল।

আপনি 300 মিলিয়ন রেকর্ড মুছে ফেললে পরিস্থিতির উল্লেখযোগ্য পরিবর্তন হওয়া উচিত, তাই আমি তা করার সিদ্ধান্ত নিয়েছি... ওহ, আমি ভেবেছিলাম এটি অবশ্যই কাজ করবে।

কর্ম ঘ

একটি নির্ভরযোগ্য ব্যাকআপ প্রস্তুত করার পরে, আমি অবশেষে অনুরোধ পাঠাতে শুরু করি।

'একটি অনুরোধ পাঠানো'

DELETE FROM hoge_table WHERE create_time <= 'YYYY-MM-DD HH:MM:SS';

"..."

"..."

"হুম... কোন উত্তর নেই। হয়তো প্রক্রিয়াটি দীর্ঘ সময় নেয়?" — আমি ভেবেছিলাম, কিন্তু ঠিক সেই ক্ষেত্রে, আমি গ্রাফনার দিকে তাকালাম এবং দেখলাম যে ডিস্কের লোড খুব দ্রুত বাড়ছে।
"বিপজ্জনক," আমি আবার ভাবলাম এবং অবিলম্বে অনুরোধটি বন্ধ করে দিলাম।

কর্ম ঘ

সবকিছু বিশ্লেষণ করার পরে, আমি বুঝতে পেরেছিলাম যে ডেটার ভলিউম এত বড় যে একবারে সবকিছু মুছে ফেলা যায় না।

আমি একটি স্ক্রিপ্ট লেখার সিদ্ধান্ত নিয়েছি যা প্রায় 1 রেকর্ড মুছে ফেলতে পারে এবং এটি চালু করে।

'আমি স্ক্রিপ্ট বাস্তবায়ন করি'

"এখন এটি অবশ্যই কাজ করবে," আমি ভেবেছিলাম।

কর্ম ঘ

দ্বিতীয় পদ্ধতিটি কাজ করেছিল, কিন্তু খুব শ্রম-নিবিড় হতে পরিণত হয়েছিল।
সাবধানে সবকিছু করতে, অপ্রয়োজনীয় স্নায়ু ছাড়া, প্রায় দুই সপ্তাহ সময় লাগবে। কিন্তু তবুও, এই দৃশ্যটি পরিষেবার প্রয়োজনীয়তা পূরণ করেনি, তাই আমাদের এটি থেকে দূরে সরে যেতে হয়েছিল।

তাই আমি যা করার সিদ্ধান্ত নিয়েছি তা এখানে:

টেবিলটি অনুলিপি করুন এবং এটির নাম পরিবর্তন করুন

পূর্ববর্তী ধাপ থেকে, আমি বুঝতে পেরেছি যে এত বড় পরিমাণ ডেটা মুছে ফেলার ফলে সমানভাবে বড় লোড তৈরি হয়। তাই আমি সন্নিবেশ ব্যবহার করে স্ক্র্যাচ থেকে একটি নতুন টেবিল তৈরি করার সিদ্ধান্ত নিয়েছি এবং আমি এতে যে ডেটা মুছতে যাচ্ছি তা সরানোর সিদ্ধান্ত নিয়েছি।

| 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';

"..."
"..."
"এম...?"

কর্ম ঘ

আমি ভেবেছিলাম পূর্বের ধারণাটি কাজ করবে, কিন্তু সন্নিবেশের অনুরোধ পাঠানোর পরে, একাধিক ত্রুটি দেখা দিয়েছে। মাইএসকিউএল ক্ষমাশীল নয়।

আমি ইতিমধ্যে এতটাই ক্লান্ত ছিলাম যে আমি ভাবতে শুরু করেছি যে আমি আর এটি করতে চাই না।

আমি বসে বসে ভাবলাম এবং বুঝতে পারলাম যে এক সময়ের জন্য হয়তো অনেকগুলি সন্নিবেশের প্রশ্ন ছিল...
ডাটাবেসের 1 দিনের মধ্যে যে পরিমাণ ডেটা প্রক্রিয়া করা উচিত তার জন্য আমি একটি সন্নিবেশের অনুরোধ পাঠানোর চেষ্টা করেছি। ঘটেছিলো!

ঠিক আছে, এর পরে আমরা একই পরিমাণ ডেটার জন্য অনুরোধ পাঠাতে থাকি। যেহেতু আমাদের এক মাসের মূল্যের ডেটা অপসারণ করতে হবে, আমরা এই অপারেশনটি প্রায় 35 বার পুনরাবৃত্তি করি৷

একটি টেবিলের নাম পরিবর্তন করা হচ্ছে

এখানে ভাগ্য আমার পাশে ছিল: সবকিছু মসৃণভাবে চলে গেছে।

সতর্কতা হারিয়ে গেছে

ব্যাচ প্রক্রিয়াকরণ গতি বৃদ্ধি পেয়েছে।

আগে এই প্রক্রিয়ায় প্রায় এক ঘণ্টা সময় লাগত, এখন লাগে ২ মিনিটের মতো।

আমি নিশ্চিত হওয়ার পরে যে সমস্ত সমস্যা সমাধান করা হয়েছে, আমি 300 মিলিয়ন রেকর্ড বাদ দিয়েছি। আমি টেবিলটি মুছে ফেললাম এবং পুনর্জন্ম অনুভব করলাম।

সারসংক্ষেপ

আমি বুঝতে পেরেছিলাম যে ব্যাচ প্রক্রিয়াকরণে ঘূর্ণন প্রক্রিয়াকরণ অনুপস্থিত ছিল এবং এটিই প্রধান সমস্যা ছিল। এই ধরনের স্থাপত্য ত্রুটি সময় নষ্ট করে।

ডাটাবেস থেকে রেকর্ড মুছে ফেলার সময় আপনি কি ডেটা প্রতিলিপির সময় লোড সম্পর্কে চিন্তা করেন? আসুন মাইএসকিউএল ওভারলোড না করি।

যারা ডাটাবেসে পারদর্শী তারা অবশ্যই এই ধরনের সমস্যার সম্মুখীন হবেন না। আপনার বাকি জন্য, আমি এই নিবন্ধটি দরকারী ছিল আশা করি.

পড়ার জন্য ধন্যবাদ!

আমরা খুব খুশি হব যদি আপনি আমাদের জানান যে আপনি এই নিবন্ধটি পছন্দ করেছেন কিনা, অনুবাদটি পরিষ্কার কিনা, এটি আপনার কাজে লেগেছে কিনা?

উত্স: www.habr.com