আমরা সাবলাইটে PostgreSQL এ লিখি: 1 হোস্ট, 1 দিন, 1TB৷

সম্প্রতি আমি আপনাকে বলেছি কিভাবে, স্ট্যান্ডার্ড রেসিপি ব্যবহার করে এসকিউএল পঠিত প্রশ্নের কর্মক্ষমতা বৃদ্ধি PostgreSQL ডাটাবেস থেকে। আজ আমরা কথা বলব কিভাবে রেকর্ডিং আরও দক্ষতার সাথে করা যেতে পারে কনফিগারেশনে কোনো "টুইস্ট" ব্যবহার না করেই ডাটাবেসে - কেবল সঠিকভাবে ডেটা প্রবাহকে সংগঠিত করে।

#1 সেকশনিং

কিভাবে এবং কেন এটা সংগঠিত মূল্য সম্পর্কে একটি নিবন্ধ প্রয়োগকৃত বিভাজন "তত্ত্বে" ইতিমধ্যে হয়েছে, এখানে আমরা আমাদের মধ্যে কিছু পন্থা প্রয়োগের অনুশীলন সম্পর্কে কথা বলব শত শত PostgreSQL সার্ভারের জন্য পর্যবেক্ষণ পরিষেবা.

"বিগত দিনের জিনিস..."

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

সময়গুলি প্রায় মহাকাব্যের মতো ছিল, PostgreSQL 9.x এর বিভিন্ন সংস্করণ প্রাসঙ্গিক ছিল, তাই সমস্ত পার্টিশনিং "ম্যানুয়ালি" করতে হয়েছিল - এর মাধ্যমে সারণী উত্তরাধিকার এবং ট্রিগার গতিশীল সঙ্গে রাউটিং EXECUTE.

ফলস্বরূপ সমাধানটি যথেষ্ট সর্বজনীন হয়ে উঠেছে যে এটি সমস্ত টেবিলে অনুবাদ করা যেতে পারে:

• একটি খালি "হেডার" প্যারেন্ট টেবিল ঘোষণা করা হয়েছিল, যা সমস্ত বর্ণনা করেছে প্রয়োজনীয় সূচক এবং ট্রিগার.
• ক্লায়েন্টের দৃষ্টিকোণ থেকে রেকর্ডটি "রুট" টেবিলে তৈরি করা হয়েছিল এবং অভ্যন্তরীণভাবে ব্যবহার করা হয়েছিল রাউটিং ট্রিগার BEFORE INSERT রেকর্ডটি "শারীরিকভাবে" প্রয়োজনীয় বিভাগে ঢোকানো হয়েছিল। যদি এখনও এমন কিছু না ছিল, আমরা একটি ব্যতিক্রম ধরলাম এবং...
• … ব্যবহার করে CREATE TABLE ... (LIKE ... INCLUDING ...) প্যারেন্ট টেবিলের টেমপ্লেটের উপর ভিত্তি করে তৈরি করা হয়েছিল পছন্দসই তারিখে একটি সীমাবদ্ধতা সহ বিভাগযাতে যখন ডেটা পুনরুদ্ধার করা হয়, তখন কেবল এটিতে পড়া হয়।

PG10: প্রথম প্রচেষ্টা

কিন্তু উত্তরাধিকারের মাধ্যমে বিভাজন ঐতিহাসিকভাবে একটি সক্রিয় লেখার প্রবাহ বা বিপুল সংখ্যক চাইল্ড পার্টিশনের সাথে মোকাবিলা করার জন্য উপযুক্ত নয়। উদাহরণস্বরূপ, আপনি মনে করতে পারেন যে প্রয়োজনীয় বিভাগ নির্বাচন করার জন্য অ্যালগরিদম ছিল দ্বিঘাত জটিলতা, যে এটি 100+ বিভাগের সাথে কাজ করে, আপনি নিজেই বুঝতে পারবেন কিভাবে...

PG10-এ এই পরিস্থিতি ব্যাপকভাবে সমর্থন বাস্তবায়ন করে অপ্টিমাইজ করা হয়েছিল নেটিভ পার্টিশনিং. অতএব, আমরা সঞ্চয়স্থান স্থানান্তরিত করার সাথে সাথেই এটি প্রয়োগ করার চেষ্টা করেছি, কিন্তু...

ম্যানুয়ালটি খনন করার পরে এটি পরিণত হয়েছে, এই সংস্করণে স্থানীয়ভাবে বিভাজিত টেবিলটি হল:

• সূচক বিবরণ সমর্থন করে না
• এটিতে ট্রিগার সমর্থন করে না
• কারো "বংশ" হতে পারে না
• সমর্থন করবেন না INSERT ... ON CONFLICT
• স্বয়ংক্রিয়ভাবে একটি বিভাগ তৈরি করতে পারে না

একটি রেক দিয়ে কপালে একটি বেদনাদায়ক ঘা পেয়ে, আমরা বুঝতে পেরেছিলাম যে অ্যাপ্লিকেশনটি পরিবর্তন না করে এটি করা অসম্ভব এবং ছয় মাসের জন্য আরও গবেষণা স্থগিত করে দিয়েছি।

PG10: দ্বিতীয় সুযোগ

সুতরাং, আমরা একে একে উদ্ভূত সমস্যাগুলি সমাধান করতে শুরু করেছি:

1. কারণ ট্রিগার এবং ON CONFLICT আমরা খুঁজে পেয়েছি যে আমাদের এখনও সেগুলি এখানে এবং সেখানে দরকার, তাই আমরা তাদের কাজ করার জন্য একটি মধ্যবর্তী পর্যায় তৈরি করেছি প্রক্সি টেবিল.
2. "রাউটিং" থেকে পরিত্রাণ পেয়েছেন ট্রিগারে - অর্থাৎ, থেকে EXECUTE.
3. তারা আলাদাভাবে এটি নিয়ে গেছে সমস্ত সূচী সহ টেমপ্লেট টেবিলযাতে তারা প্রক্সি টেবিলেও উপস্থিত না থাকে।

অবশেষে, এত কিছুর পরে, আমরা মূল টেবিলটি স্থানীয়ভাবে বিভাজন করেছি। একটি নতুন বিভাগ তৈরি করা এখনও অ্যাপ্লিকেশনের বিবেকের কাছে বাকি।

"সয়িং" অভিধান

যে কোনো বিশ্লেষণাত্মক ব্যবস্থার মতো, আমাদেরও ছিল "তথ্য" এবং "কাট" (অভিধান)। আমাদের ক্ষেত্রে, এই ক্ষমতাতে তারা অভিনয় করেছে, উদাহরণস্বরূপ, টেমপ্লেট শরীর অনুরূপ ধীরগতির প্রশ্ন বা ক্যোয়ারী নিজেই পাঠ্য.

"তথ্যগুলি" ইতিমধ্যে দীর্ঘদিন ধরে প্রতিদিন বিভাগ করা হয়েছিল, তাই আমরা শান্তভাবে পুরানো বিভাগগুলি মুছে ফেলেছি এবং তারা আমাদের বিরক্ত করেনি (লগ!) কিন্তু অভিধানে সমস্যা ছিল...

তাদের অনেক ছিল যে বলতে না, কিন্তু আনুমানিক 100TB "তথ্য" এর ফলে একটি 2.5TB অভিধান হয়েছে৷. আপনি এই জাতীয় টেবিল থেকে সুবিধামত কিছু মুছতে পারবেন না, আপনি পর্যাপ্ত সময়ে এটি সংকুচিত করতে পারবেন না এবং এটিতে লেখা ধীরে ধীরে ধীর হয়ে যায়।

একটি অভিধানের মতো... এতে, প্রতিটি এন্ট্রি ঠিক একবার উপস্থাপন করা উচিত... এবং এটি সঠিক, কিন্তু!... কেউ আমাদের থাকতে বাধা দিচ্ছে না প্রতিটি দিনের জন্য একটি পৃথক অভিধান! হ্যাঁ, এটি একটি নির্দিষ্ট অপ্রয়োজনীয়তা নিয়ে আসে, তবে এটি অনুমতি দেয়:

• দ্রুত লিখুন/পড়ুন ছোট অংশের আকারের কারণে
• কম মেমরি খরচ আরও কমপ্যাক্ট সূচকের সাথে কাজ করে
• কম ডেটা সঞ্চয় করুন দ্রুত পুরানো অপসারণ ক্ষমতার কারণে

পুরো জটিল ব্যবস্থার ফলে CPU লোড ~30%, ডিস্ক লোড ~50% কমেছে:

একই সময়ে, আমরা কম লোড সহ ডাটাবেসে ঠিক একই জিনিস লিখতে থাকি।

#2 ডাটাবেস বিবর্তন এবং রিফ্যাক্টরিং

তাই আমরা যা আছে তা স্থির করেছি প্রতিটি দিনের নিজস্ব বিভাগ আছে তথ্য সহ। আসলে, CHECK (dt = '2018-10-12'::date) — এবং একটি বিভাজন কী এবং একটি নির্দিষ্ট বিভাগে পড়ার জন্য একটি শর্ত রয়েছে।

যেহেতু আমাদের পরিষেবার সমস্ত রিপোর্ট একটি নির্দিষ্ট তারিখের প্রেক্ষাপটে তৈরি করা হয়েছে, তাই "অ-বিভাজন সময়" থেকে তাদের জন্য সূচীগুলি সব ধরনের হয়েছে (সার্ভার, তারিখ, পরিকল্পনা টেমপ্লেট), (সার্ভার, তারিখ, প্ল্যান নোড), (তারিখ, ত্রুটি শ্রেণী, সার্ভার)...

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

অপ্টিমাইজেশানের দিকটি সুস্পষ্ট - সহজ সমস্ত সূচী থেকে তারিখ ক্ষেত্র সরান বিভাজিত টেবিলে। আমাদের ভলিউম দেওয়া, লাভ সম্পর্কে 1TB/সপ্তাহ!

এখন মনে রাখবেন যে এই টেরাবাইটটি এখনও কোনওভাবে রেকর্ড করা ছিল। অর্থাৎ আমরাও ডিস্ক এখন কম লোড করা উচিত! এই ছবিটি পরিষ্কারভাবে পরিষ্কার থেকে প্রাপ্ত প্রভাব দেখায়, যার জন্য আমরা এক সপ্তাহ উত্সর্গ করেছি:

#3। পিক লোড "প্রসারণ"

লোড করা সিস্টেমের একটি বড় সমস্যা হল অপ্রয়োজনীয় সিঙ্ক্রোনাইজেশন কিছু অপারেশন যার প্রয়োজন নেই। কখনও কখনও "কারণ তারা লক্ষ্য করেনি", কখনও কখনও "এটি সহজ ছিল", তবে শীঘ্র বা পরে আপনাকে এটি থেকে মুক্তি পেতে হবে।

আগের ছবি জুম ইন করুন এবং দেখুন যে আমাদের একটি ডিস্ক আছে ডবল প্রশস্ততা সঙ্গে লোড অধীনে "পাম্প" সংলগ্ন নমুনার মধ্যে, যা স্পষ্টভাবে "পরিসংখ্যানগতভাবে" এই ধরনের সংখ্যক অপারেশনের সাথে ঘটবে না:

এই অর্জন করা বেশ সহজ. আমরা ইতিমধ্যে মনিটরিং শুরু করেছি প্রায় 1000 সার্ভার, প্রতিটি একটি পৃথক লজিক্যাল থ্রেড দ্বারা প্রক্রিয়া করা হয়, এবং প্রতিটি থ্রেড একটি নির্দিষ্ট ফ্রিকোয়েন্সিতে ডেটাবেসে পাঠানোর জন্য জমা হওয়া তথ্য পুনরায় সেট করে, এইরকম কিছু:

setInterval(sendToDB, interval)

সমস্যা এখানে অবিকল যে মিথ্যা সমস্ত থ্রেড প্রায় একই সময়ে শুরু হয়, তাই তাদের পাঠানোর সময় প্রায় সবসময় "বিন্দুতে" মিলে যায়। উফ #2...

ভাগ্যক্রমে, এটি ঠিক করা বেশ সহজ, একটি "এলোমেলো" রান-আপ যোগ করা হচ্ছে সময় দ্বারা:

setInterval(sendToDB, interval * (1 + 0.1 * (Math.random() - 0.5)))

#4। আমরা যা প্রয়োজন তা ক্যাশে করি

তৃতীয় প্রথাগত হাইলোড সমস্যা কোন ক্যাশে যেখানে তিনি পারে হতে।

উদাহরণস্বরূপ, আমরা প্ল্যান নোডগুলির পরিপ্রেক্ষিতে বিশ্লেষণ করা সম্ভব করেছি (এই সমস্ত Seq Scan on users), কিন্তু অবিলম্বে মনে করুন যে তারা বেশিরভাগ অংশে একই - তারা ভুলে গেছে।

না, অবশ্যই, ডাটাবেসে আবার কিছুই লেখা হয় না, এটি ট্রিগারটি কেটে দেয় INSERT ... ON CONFLICT DO NOTHING. কিন্তু এই ডেটা এখনও ডাটাবেসে পৌঁছায় এবং এটি অপ্রয়োজনীয় দ্বন্দ্ব পরীক্ষা করার জন্য পড়া করতে হবে. উফ #3...

ক্যাশিং সক্ষম করার আগে/পরে ডেটাবেসে পাঠানো রেকর্ডের সংখ্যার পার্থক্য স্পষ্ট:

এবং এটি স্টোরেজ লোডের সহগামী ড্রপ:

মোটে

"টেরাবাইট-প্রতি-দিন" শুধু ভয়ঙ্কর শোনাচ্ছে। আপনি যদি সবকিছু ঠিকঠাক করেন তবে এটি ঠিক 2^40 বাইট / 86400 সেকেন্ড = ~12.5MB/sযে এমনকি ডেস্কটপ IDE স্ক্রু রাখা. 🙂

কিন্তু গুরুত্ব সহকারে, এমনকি দিনের বেলায় লোডের দশগুণ "তির্যক" সহ, আপনি সহজেই আধুনিক এসএসডিগুলির ক্ষমতাগুলি পূরণ করতে পারেন।

উত্স: www.habr.com