Apache Ignite এ ডেটা কম্প্রেশন। Sber এর অভিজ্ঞতা

প্রচুর পরিমাণে ডেটা নিয়ে কাজ করার সময়, কখনও কখনও ডিস্কের জায়গার অভাবের সমস্যা দেখা দিতে পারে। এই সমস্যাটি সমাধান করার একটি উপায় হ'ল সংকোচন, যার জন্য ধন্যবাদ, একই সরঞ্জামগুলিতে, আপনি স্টোরেজ ভলিউম বাড়ানোর সামর্থ্য রাখতে পারেন। এই নিবন্ধে, আমরা Apache Ignite-এ ডেটা কম্প্রেশন কীভাবে কাজ করে তা দেখব। এই নিবন্ধটি শুধুমাত্র পণ্যের মধ্যে প্রয়োগ করা ডিস্ক কম্প্রেশন পদ্ধতি বর্ণনা করবে। ডেটা কম্প্রেশনের অন্যান্য পদ্ধতি (নেটওয়ার্কের মাধ্যমে, মেমরিতে), বাস্তবায়িত হোক বা না হোক, সুযোগের বাইরে থাকবে।

সুতরাং, অধ্যবসায় মোড সক্ষম করার সাথে, ক্যাশে ডেটার পরিবর্তনের ফলে, ইগনাইট ডিস্কে লেখা শুরু করে:

1. ক্যাশে বিষয়বস্তু
2. এহেড লগ লিখুন (এর পরে শুধু WAL)

বেশ কিছুদিন ধরে WAL কম্প্রেশনের জন্য একটি প্রক্রিয়া রয়েছে, যাকে WAL কমপ্যাকশন বলা হয়। সম্প্রতি প্রকাশিত Apache Ignite 2.8 আরও দুটি প্রক্রিয়া চালু করেছে যা আপনাকে ডিস্কে ডেটা সংকুচিত করার অনুমতি দেয়: ক্যাশের বিষয়বস্তু সংকুচিত করার জন্য ডিস্ক পৃষ্ঠা কম্প্রেশন এবং কিছু WAL এন্ট্রি সংকুচিত করার জন্য WAL পৃষ্ঠা স্ন্যাপশট কম্প্রেশন। নীচে এই তিনটি প্রক্রিয়া সম্পর্কে আরও বিশদ বিবরণ।

ডিস্ক পৃষ্ঠা সংকোচন

এগুলো কিভাবে কাজ করে

প্রথমে, আসুন খুব সংক্ষিপ্তভাবে দেখি কিভাবে Ignite ডেটা সঞ্চয় করে। পৃষ্ঠা মেমরি স্টোরেজ জন্য ব্যবহার করা হয়. পৃষ্ঠার আকার নোডের শুরুতে সেট করা হয় এবং পরবর্তী পর্যায়ে পরিবর্তন করা যায় না; এছাড়াও, পৃষ্ঠার আকারটি ফাইল সিস্টেম ব্লকের আকারের দুই শক্তি এবং একাধিক হতে হবে। পৃষ্ঠাগুলি প্রয়োজন অনুসারে ডিস্ক থেকে র‌্যামে লোড করা হয়; ডিস্কের ডেটার আকার বরাদ্দকৃত RAM-এর পরিমাণ অতিক্রম করতে পারে। ডিস্ক থেকে একটি পৃষ্ঠা লোড করার জন্য RAM-তে পর্যাপ্ত স্থান না থাকলে, পুরানো, আর ব্যবহৃত পৃষ্ঠাগুলি RAM থেকে উচ্ছেদ করা হবে।

ডেটা নিম্নলিখিত আকারে ডিস্কে সংরক্ষণ করা হয়: প্রতিটি ক্যাশে গোষ্ঠীর প্রতিটি পার্টিশনের জন্য একটি পৃথক ফাইল তৈরি করা হয়; এই ফাইলটিতে, পৃষ্ঠাগুলি ক্রমবর্ধমান সূচী ক্রমে একের পর এক প্রদর্শিত হয়। সম্পূর্ণ পৃষ্ঠা শনাক্তকারীতে ফাইলের ক্যাশে গ্রুপ শনাক্তকারী, পার্টিশন নম্বর এবং পৃষ্ঠা সূচী রয়েছে। সুতরাং, সম্পূর্ণ পৃষ্ঠা শনাক্তকারী ব্যবহার করে, আমরা প্রতিটি পৃষ্ঠার জন্য ফাইল এবং অফসেটটি অনন্যভাবে নির্ধারণ করতে পারি। আপনি Apache Ignite Wiki নিবন্ধে পেজিং মেমরি সম্পর্কে আরও পড়তে পারেন: অবিরাম দোকান জ্বালান - হুড অধীনে.

ডিস্ক পৃষ্ঠা কম্প্রেশন প্রক্রিয়া, আপনি নাম থেকে অনুমান করতে পারেন, পৃষ্ঠা স্তরে কাজ করে। যখন এই মেকানিজম সক্রিয় করা হয়, তখন RAM-তে ডেটা কোনো কম্প্রেশন ছাড়াই প্রক্রিয়া করা হয়, কিন্তু যখন পৃষ্ঠাগুলি RAM থেকে ডিস্কে সংরক্ষিত হয়, তখন সেগুলি সংকুচিত হয়।

তবে প্রতিটি পৃষ্ঠাকে পৃথকভাবে সংকুচিত করা সমস্যার সমাধান নয়; আপনাকে ফলস্বরূপ ডেটা ফাইলগুলির আকার কমাতে হবে। যদি পৃষ্ঠার আকার আর স্থির না হয়, আমরা আর ফাইলে একের পর এক পৃষ্ঠা লিখতে পারি না, কারণ এটি বেশ কয়েকটি সমস্যা তৈরি করতে পারে:

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

এই সমস্যাগুলির নিজস্ব স্তরে সমাধান এড়াতে, Apache Ignite-এ ডিস্ক পৃষ্ঠা সংকোচন একটি ফাইল সিস্টেম মেকানিজম ব্যবহার করে যার নাম স্পারস ফাইল। একটি স্পার্স ফাইল হল একটি যেখানে কিছু শূন্য-ভরা অঞ্চলকে "গর্ত" হিসাবে চিহ্নিত করা যেতে পারে। এই ক্ষেত্রে, এই গর্তগুলি সংরক্ষণ করার জন্য কোনও ফাইল সিস্টেম ব্লক বরাদ্দ করা হবে না, যার ফলে ডিস্কের স্থান সঞ্চয় হবে।

এটি যৌক্তিক যে একটি ফাইল সিস্টেম ব্লক মুক্ত করার জন্য, গর্তের আকার অবশ্যই ফাইল সিস্টেম ব্লকের চেয়ে বেশি বা সমান হতে হবে, যা পৃষ্ঠার আকার এবং অ্যাপাচি ইগনিটের উপর একটি অতিরিক্ত সীমাবদ্ধতা আরোপ করে: কম্প্রেশন কোন প্রভাব ফেলতে, পৃষ্ঠার আকার অবশ্যই ফাইল সিস্টেম ব্লকের আকারের চেয়ে কঠোরভাবে বড় হতে হবে। যদি পৃষ্ঠার আকার ব্লক আকারের সমান হয়, তাহলে আমরা কখনই একটি একক ব্লক মুক্ত করতে সক্ষম হব না, যেহেতু একটি একক ব্লক মুক্ত করার জন্য, সংকুচিত পৃষ্ঠাটি 0 বাইট দখল করতে হবে। যদি পৃষ্ঠার আকার 2 বা 4 ব্লকের আকারের সমান হয়, তাহলে আমাদের পৃষ্ঠাটি যথাক্রমে কমপক্ষে 50% বা 75%-এ সংকুচিত হলে আমরা ইতিমধ্যে অন্তত একটি ব্লক খালি করতে সক্ষম হব।

এইভাবে, প্রক্রিয়াটি কীভাবে কাজ করে তার চূড়ান্ত বিবরণ: ডিস্কে একটি পৃষ্ঠা লেখার সময়, পৃষ্ঠাটিকে সংকুচিত করার চেষ্টা করা হয়। যদি সংকুচিত পৃষ্ঠার আকার এক বা একাধিক ফাইল সিস্টেম ব্লকগুলিকে মুক্ত করার অনুমতি দেয়, তবে পৃষ্ঠাটি সংকুচিত আকারে লেখা হয় এবং মুক্ত করা ব্লকগুলির জায়গায় একটি "গর্ত" তৈরি করা হয় (একটি সিস্টেম কল চালানো হয় fallocate() পাঞ্চ হোল পতাকা সহ)। যদি সংকুচিত পৃষ্ঠার আকার ব্লকগুলিকে মুক্ত করার অনুমতি না দেয়, তাহলে পৃষ্ঠাটি সংরক্ষিত হয়, সংকুচিত না হয়। সমস্ত পৃষ্ঠা অফসেটগুলি কম্প্রেশন ছাড়াই একইভাবে গণনা করা হয়, পৃষ্ঠার আকার দ্বারা পৃষ্ঠা সূচককে গুণ করে৷ আপনার নিজের উপর পৃষ্ঠাগুলির কোন স্থানান্তর প্রয়োজন হয় না। পৃষ্ঠা অফসেটগুলি, ঠিক যেমন কম্প্রেশন ছাড়াই, ফাইল সিস্টেম ব্লকের সীমানায় পড়ে।

বর্তমান বাস্তবায়নে, Ignite শুধুমাত্র Linux OS এর অধীনে স্পার্স ফাইলের সাথে কাজ করতে পারে; সেই অনুযায়ী, এই অপারেটিং সিস্টেমে Ignite ব্যবহার করার সময় শুধুমাত্র ডিস্ক পৃষ্ঠা সংকোচন সক্রিয় করা যেতে পারে।

কম্প্রেশন অ্যালগরিদম যা ডিস্ক পৃষ্ঠা সংকোচনের জন্য ব্যবহার করা যেতে পারে: ZSTD, LZ4, Snappy। এছাড়াও, একটি অপারেটিং মোড (SKIP_GARBAGE) রয়েছে, যাতে পৃষ্ঠার অব্যবহৃত স্থান অবশিষ্ট ডেটাতে কম্প্রেশন প্রয়োগ না করেই ফেলে দেওয়া হয়, যা পূর্বে তালিকাভুক্ত অ্যালগরিদমের তুলনায় CPU-তে লোড কমিয়ে দেয়।

কর্মক্ষমতা প্রভাব

দুর্ভাগ্যবশত, আমি বাস্তব স্ট্যান্ডে প্রকৃত কর্মক্ষমতা পরিমাপ পরিচালনা করিনি, যেহেতু আমরা উৎপাদনে এই প্রক্রিয়াটি ব্যবহার করার পরিকল্পনা করি না, তবে আমরা তাত্ত্বিকভাবে অনুমান করতে পারি যে আমরা কোথায় হারব এবং কোথায় জিতব।

এটি করার জন্য, আমাদের মনে রাখতে হবে যে অ্যাক্সেস করার সময় পৃষ্ঠাগুলি কীভাবে পড়া এবং লেখা হয়:

• একটি রিড অপারেশন সম্পাদন করার সময়, এটি প্রথমে RAM এ অনুসন্ধান করা হয়; অনুসন্ধানটি ব্যর্থ হলে, পৃষ্ঠাটি ডিস্ক থেকে RAM এ লোড করা হয় একই থ্রেড দ্বারা যা পঠন সম্পাদন করে।
• যখন একটি লেখার অপারেশন সঞ্চালিত হয়, RAM-এর পৃষ্ঠাটি নোংরা হিসাবে চিহ্নিত করা হয়, তবে থ্রেডটি লেখাটি সম্পাদন করে পৃষ্ঠাটি অবিলম্বে ডিস্কে সংরক্ষিত হয় না। সমস্ত নোংরা পৃষ্ঠাগুলি আলাদা থ্রেডে চেকপয়েন্ট প্রক্রিয়ায় পরে ডিস্কে সংরক্ষণ করা হয়।

তাই রিড অপারেশনের উপর প্রভাব হল:

• পজিটিভ (ডিস্ক আইও), রিড ফাইল সিস্টেম ব্লকের সংখ্যা হ্রাসের কারণে।
• নেতিবাচক (সিপিইউ), অপারেটিং সিস্টেমের অতিরিক্ত লোডের কারণে স্পার্স ফাইলগুলির সাথে কাজ করার জন্য। এটাও সম্ভব যে অতিরিক্ত IO ক্রিয়াকলাপগুলি আরও জটিল স্পার্স ফাইল কাঠামো সংরক্ষণ করতে এখানে স্পষ্টভাবে উপস্থিত হবে (দুর্ভাগ্যবশত, আমি কীভাবে স্পারস ফাইলগুলি কাজ করে তার সমস্ত বিবরণের সাথে পরিচিত নই)।
• নেতিবাচক (সিপিইউ), পৃষ্ঠাগুলি ডিকম্প্রেস করার প্রয়োজনের কারণে।
• লেখার ক্রিয়াকলাপগুলিতে কোনও প্রভাব নেই।
• চেকপয়েন্ট প্রক্রিয়ার উপর প্রভাব (এখানে সবকিছুই রিড অপারেশনের মতো):
• ইতিবাচক (ডিস্ক আইও), লিখিত ফাইল সিস্টেম ব্লকের সংখ্যা হ্রাসের কারণে।
• নেতিবাচক (সিপিইউ, সম্ভবত ডিস্ক আইও), স্পার্স ফাইলগুলির সাথে কাজ করার কারণে।
• নেতিবাচক (CPU), পৃষ্ঠা সংকোচনের প্রয়োজনের কারণে।

স্কেলের কোন দিকে স্কেল টিপবে? এটি সবই পরিবেশের উপর নির্ভর করে, কিন্তু আমি বিশ্বাস করি যে ডিস্ক পৃষ্ঠা সংকোচন সম্ভবত বেশিরভাগ সিস্টেমে কর্মক্ষমতা অবনতির দিকে নিয়ে যাবে। অধিকন্তু, অন্যান্য DBMS-এর পরীক্ষা যা স্পার্স ফাইলগুলির সাথে একই পদ্ধতির ব্যবহার করে যখন কম্প্রেশন সক্ষম করা হয় তখন কার্যক্ষমতা হ্রাস পায়।

কিভাবে সক্রিয় এবং কনফিগার করবেন

উপরে উল্লিখিত হিসাবে, Apache Ignite-এর সর্বনিম্ন সংস্করণ যা ডিস্ক পৃষ্ঠা কম্প্রেশন সমর্থন করে 2.8 এবং শুধুমাত্র Linux অপারেটিং সিস্টেম সমর্থিত। নিম্নলিখিত হিসাবে সক্ষম এবং কনফিগার করুন:

• ক্লাস-পাথের মধ্যে অবশ্যই একটি ইগনিট-কম্প্রেশন মডিউল থাকতে হবে। ডিফল্টরূপে, এটি libs/ঐচ্ছিক ডিরেক্টরির Apache Ignite ডিস্ট্রিবিউশনে অবস্থিত এবং ক্লাস-পাথের মধ্যে অন্তর্ভুক্ত নয়। আপনি ডাইরেক্টরীটিকে একটি স্তরের উপরে libs-এ নিয়ে যেতে পারেন এবং তারপর আপনি যখন ignite.sh এর মাধ্যমে চালাবেন তখন এটি স্বয়ংক্রিয়ভাবে সক্রিয় হয়ে যাবে।
• অধ্যবসায় সক্রিয় করা আবশ্যক (এর মাধ্যমে সক্ষম DataRegionConfiguration.setPersistenceEnabled(true)).
• পৃষ্ঠার আকার ফাইল সিস্টেম ব্লক আকারের চেয়ে বড় হতে হবে (আপনি এটি ব্যবহার করে সেট করতে পারেন DataStorageConfiguration.setPageSize() ).
• প্রতিটি ক্যাশের জন্য যার ডেটা সংকুচিত করা প্রয়োজন, আপনাকে অবশ্যই কম্প্রেশন পদ্ধতি এবং (ঐচ্ছিকভাবে) কম্প্রেশন স্তর (পদ্ধতিগুলি) কনফিগার করতে হবে CacheConfiguration.setDiskPageCompression() , CacheConfiguration.setDiskPageCompressionLevel()).

ওয়াল কম্প্যাকশন

এগুলো কিভাবে কাজ করে

WAL কি এবং কেন এটি প্রয়োজন? খুব সংক্ষেপে: এটি এমন একটি লগ যাতে সমস্ত ইভেন্ট রয়েছে যা শেষ পর্যন্ত পৃষ্ঠার সঞ্চয়স্থান পরিবর্তন করে। পতনের ক্ষেত্রে পুনরুদ্ধার করতে সক্ষম হওয়ার জন্য এটি প্রাথমিকভাবে প্রয়োজন। যেকোন অপারেশন, ব্যবহারকারীকে নিয়ন্ত্রণ দেওয়ার আগে, প্রথমে WAL-এ একটি ইভেন্ট রেকর্ড করতে হবে, যাতে ব্যর্থতার ক্ষেত্রে, এটি লগে আবার প্লে করা যায় এবং সমস্ত ক্রিয়াকলাপ পুনরুদ্ধার করা যায় যার জন্য ব্যবহারকারী একটি সফল প্রতিক্রিয়া পেয়েছে, এমনকি যদি এই অপারেশনগুলি ডিস্কে পৃষ্ঠার সঞ্চয়স্থানে প্রতিফলিত হওয়ার সময় ছিল না (ইতিমধ্যেই উপরে এটি বর্ণনা করা হয়েছে যে পৃষ্ঠা স্টোরে প্রকৃত লেখা "চেকপয়েন্টিং" নামক একটি প্রক্রিয়ার মাধ্যমে করা হয় যা আলাদা থ্রেড দ্বারা কিছুটা বিলম্বিত হয়)।

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

লজিক্যাল রেকর্ড প্রতি প্রায়ই বেশ কিছু শারীরিক রেকর্ড আছে. অর্থাৎ, উদাহরণস্বরূপ, ক্যাশে একটি পুট অপারেশন পৃষ্ঠা মেমরির বেশ কয়েকটি পৃষ্ঠাকে প্রভাবিত করে (একটি পৃষ্ঠা যেখানে ডেটা নিজেই, সূচী সহ পৃষ্ঠাগুলি, মুক্ত-তালিকা সহ পৃষ্ঠাগুলি)। কিছু সিন্থেটিক পরীক্ষায়, আমি দেখেছি যে শারীরিক রেকর্ডগুলি WAL ফাইলের 90% পর্যন্ত দখল করেছে। যাইহোক, এগুলি খুব অল্প সময়ের জন্য প্রয়োজন (ডিফল্টরূপে, চেকপয়েন্টগুলির মধ্যে ব্যবধান 3 মিনিট)। এর প্রাসঙ্গিকতা হারানোর পরে এই তথ্য পরিত্রাণ পেতে যুক্তিসঙ্গত হবে. WAL কমপ্যাকশন মেকানিজম ঠিক এটিই করে: এটি ফিজিক্যাল রেকর্ড থেকে মুক্তি পায় এবং জিপ ব্যবহার করে অবশিষ্ট লজিক্যাল রেকর্ডগুলিকে সংকুচিত করে, যখন ফাইলের আকার খুব উল্লেখযোগ্যভাবে হ্রাস পায় (কখনও কখনও কয়েকবার)।

দৈহিকভাবে, WAL একটি নির্দিষ্ট আকারের (ডিফল্টভাবে 10MB) বেশ কয়েকটি সেগমেন্ট (ডিফল্টরূপে 64) নিয়ে গঠিত, যা একটি বৃত্তাকার পদ্ধতিতে ওভাররাইট করা হয়। বর্তমান সেগমেন্টটি পূর্ণ হওয়ার সাথে সাথে পরবর্তী বিভাগটিকে বর্তমান হিসাবে বরাদ্দ করা হয় এবং ভরাট অংশটি একটি পৃথক থ্রেড দ্বারা সংরক্ষণাগারে অনুলিপি করা হয়। WAL কমপ্যাকশন ইতিমধ্যেই আর্কাইভ সেগমেন্টের সাথে কাজ করে। এছাড়াও, একটি পৃথক থ্রেড হিসাবে, এটি চেকপয়েন্টের কার্য সম্পাদনের উপর নজর রাখে এবং আর্কাইভ সেগমেন্টগুলিতে সংকোচন শুরু করে যার জন্য শারীরিক রেকর্ডের আর প্রয়োজন নেই।

কর্মক্ষমতা প্রভাব

যেহেতু WAL কমপ্যাকশন একটি পৃথক থ্রেড হিসাবে কাজ করে, তাই সঞ্চালিত ক্রিয়াকলাপগুলির উপর কোনও সরাসরি প্রভাব থাকা উচিত নয়। কিন্তু এটি এখনও CPU (কম্প্রেশন) এবং ডিস্কে অতিরিক্ত ব্যাকগ্রাউন্ড লোড রাখে (আর্কাইভ থেকে প্রতিটি WAL সেগমেন্ট পড়া এবং সংকুচিত সেগমেন্টগুলি লেখা), তাই যদি সিস্টেমটি তার সর্বোচ্চ ক্ষমতায় চলছে, এটি কর্মক্ষমতার অবনতির দিকে নিয়ে যাবে।

কিভাবে সক্রিয় এবং কনফিগার করবেন

আপনি সম্পত্তি ব্যবহার করে WAL কমপ্যাকশন সক্ষম করতে পারেন WalCompactionEnabled в DataStorageConfiguration (DataStorageConfiguration.setWalCompactionEnabled(true)) এছাড়াও, DataStorageConfiguration.setWalCompactionLevel() পদ্ধতি ব্যবহার করে, আপনি যদি ডিফল্ট মান (BEST_SPEED) নিয়ে সন্তুষ্ট না হন তবে আপনি কম্প্রেশন স্তর সেট করতে পারেন।

WAL পৃষ্ঠার স্ন্যাপশট কম্প্রেশন

এগুলো কিভাবে কাজ করে

আমরা ইতিমধ্যে খুঁজে পেয়েছি যে WAL রেকর্ডগুলি যৌক্তিক এবং শারীরিকভাবে বিভক্ত। প্রতিটি পৃষ্ঠায় প্রতিটি পরিবর্তনের জন্য, পৃষ্ঠা মেমরিতে একটি শারীরিক WAL রেকর্ড তৈরি করা হয়। দৈহিক রেকর্ডগুলিও 2টি উপপ্রকারে বিভক্ত: পৃষ্ঠার স্ন্যাপশট রেকর্ড এবং ডেল্টা রেকর্ড। প্রতিবার যখন আমরা একটি পৃষ্ঠায় কিছু পরিবর্তন করি এবং একটি পরিষ্কার অবস্থা থেকে একটি নোংরা অবস্থায় স্থানান্তর করি, এই পৃষ্ঠাটির একটি সম্পূর্ণ অনুলিপি WAL (পৃষ্ঠা স্ন্যাপশট রেকর্ড) এ সংরক্ষণ করা হয়। এমনকি যদি আমরা WAL-এ শুধুমাত্র একটি বাইট পরিবর্তন করি, রেকর্ডটি পৃষ্ঠার আকারের চেয়ে সামান্য বড় হবে। যদি আমরা ইতিমধ্যেই নোংরা পৃষ্ঠায় কিছু পরিবর্তন করি, তাহলে WAL-এ একটি ডেল্টা রেকর্ড তৈরি হয়, যা পৃষ্ঠার আগের অবস্থার তুলনায় শুধুমাত্র পরিবর্তনগুলি প্রতিফলিত করে, কিন্তু পুরো পৃষ্ঠা নয়। যেহেতু পৃষ্ঠাগুলির অবস্থাকে নোংরা থেকে পরিষ্কার করার জন্য পুনরায় সেট করা চেকপয়েন্ট প্রক্রিয়া চলাকালীন সঞ্চালিত হয়, চেকপয়েন্ট শুরু হওয়ার পরপরই, প্রায় সমস্ত ফিজিক্যাল রেকর্ডে শুধুমাত্র পৃষ্ঠাগুলির স্ন্যাপশট থাকবে (যেহেতু চেকপয়েন্ট শুরু হওয়ার পরপরই সমস্ত পৃষ্ঠাগুলি পরিষ্কার হয়) , তারপর যখন আমরা পরবর্তী চেকপয়েন্টের কাছে যাই, ডেল্টা রেকর্ড ভগ্নাংশটি বড় হতে শুরু করে এবং পরবর্তী চেকপয়েন্টের শুরুতে পুনরায় সেট করা হয়। কিছু কৃত্রিম পরীক্ষায় পরিমাপ দেখায় যে প্রকৃত রেকর্ডের মোট ভলিউমে পৃষ্ঠার স্ন্যাপশটগুলির ভাগ 90% এ পৌঁছেছে।

WAL পৃষ্ঠার স্ন্যাপশট সংকোচনের ধারণাটি একটি তৈরি পৃষ্ঠা কম্প্রেশন টুল ব্যবহার করে পৃষ্ঠার স্ন্যাপশটগুলিকে সংকুচিত করা (ডিস্ক পৃষ্ঠা সংকোচন দেখুন)। একই সময়ে, WAL-এ, রেকর্ডগুলি ক্রমানুসারে সংরক্ষিত হয় শুধুমাত্র-অ্যাপেন্ড মোডে এবং ফাইল সিস্টেম ব্লকের সীমানায় রেকর্ডগুলি আবদ্ধ করার কোন প্রয়োজন নেই, তাই এখানে, ডিস্ক পৃষ্ঠা সংকোচন পদ্ধতির বিপরীতে, আমাদের স্পার্স ফাইলগুলির প্রয়োজন নেই সমস্ত; সেই অনুযায়ী, এই প্রক্রিয়াটি কেবল ওএস লিনাক্সেই কাজ করবে না। উপরন্তু, আমরা পৃষ্ঠাটি কতটা সংকুচিত করতে পেরেছি তা আমাদের কাছে আর গুরুত্বপূর্ণ নয়। এমনকি যদি আমরা 1 বাইট মুক্ত করি, এটি ইতিমধ্যেই একটি ইতিবাচক ফলাফল এবং আমরা WAL-এ সংকুচিত ডেটা সংরক্ষণ করতে পারি, ডিস্ক পৃষ্ঠা কম্প্রেশনের বিপরীতে, যেখানে আমরা 1টির বেশি ফাইল সিস্টেম ব্লক মুক্ত করলেই সংকুচিত পৃষ্ঠাটি সংরক্ষণ করি।

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

ডিস্ক পৃষ্ঠা কম্প্রেশনের মতো, WAL পৃষ্ঠা স্ন্যাপশট কম্প্রেশন ZSTD, LZ4, Snappy কম্প্রেশন অ্যালগরিদম, সেইসাথে SKIP_GARBAGE মোড ব্যবহার করতে পারে।

কর্মক্ষমতা প্রভাব

এটা লক্ষ্য করা কঠিন নয় যে সরাসরি WAL পৃষ্ঠা স্ন্যাপশট কম্প্রেশন সক্রিয় করা শুধুমাত্র সেই থ্রেডগুলিকে প্রভাবিত করে যা পৃষ্ঠা মেমরিতে ডেটা লেখে, অর্থাৎ সেই থ্রেডগুলি যা ক্যাশে ডেটা পরিবর্তন করে। WAL থেকে ফিজিক্যাল রেকর্ড পড়া শুধুমাত্র একবারই ঘটে, এই মুহূর্তে নোডটি পতনের পরে উত্থাপিত হয় (এবং শুধুমাত্র যদি এটি একটি চেকপয়েন্টের সময় পড়ে)।

এটি থ্রেডগুলিকে প্রভাবিত করে যা নিম্নলিখিত উপায়ে ডেটা পরিবর্তন করে: আমরা প্রতিবার ডিস্কে লেখার আগে পৃষ্ঠাটি সংকুচিত করার প্রয়োজনের কারণে একটি নেতিবাচক প্রভাব (CPU) পাই এবং এর পরিমাণ হ্রাসের কারণে একটি ইতিবাচক প্রভাব (ডিস্ক IO) তথ্য লিখিত। তদনুসারে, এখানে সবকিছু সহজ: যদি সিস্টেমের কার্যকারিতা CPU দ্বারা সীমিত হয়, আমরা একটি সামান্য অবনতি পাই, যদি এটি ডিস্ক I/O দ্বারা সীমিত হয়, আমরা বৃদ্ধি পাই।

পরোক্ষভাবে, WAL আকার হ্রাস করা স্ট্রীমগুলিকেও (ইতিবাচকভাবে) প্রভাবিত করে যা WAL বিভাগগুলিকে সংরক্ষণাগার এবং WAL কমপ্যাকশন স্ট্রিমগুলিতে ফেলে দেয়।

সিন্থেটিক ডেটা ব্যবহার করে আমাদের পরিবেশে বাস্তব কর্মক্ষমতা পরীক্ষায় সামান্য বৃদ্ধি দেখা গেছে (থ্রুপুট 10%-15% বৃদ্ধি পেয়েছে, 10%-15% লেটেন্সি কমেছে)।

কিভাবে সক্রিয় এবং কনফিগার করবেন

ন্যূনতম Apache Ignite সংস্করণ: 2.8. নিম্নলিখিত হিসাবে সক্ষম এবং কনফিগার করুন:

• ক্লাস-পাথের মধ্যে অবশ্যই একটি ইগনিট-কম্প্রেশন মডিউল থাকতে হবে। ডিফল্টরূপে, এটি libs/ঐচ্ছিক ডিরেক্টরির Apache Ignite ডিস্ট্রিবিউশনে অবস্থিত এবং ক্লাস-পাথের মধ্যে অন্তর্ভুক্ত নয়। আপনি ডাইরেক্টরীটিকে একটি স্তরের উপরে libs-এ নিয়ে যেতে পারেন এবং তারপর আপনি যখন ignite.sh এর মাধ্যমে চালাবেন তখন এটি স্বয়ংক্রিয়ভাবে সক্রিয় হয়ে যাবে।
• অধ্যবসায় সক্রিয় করা আবশ্যক (এর মাধ্যমে সক্ষম DataRegionConfiguration.setPersistenceEnabled(true)).
• কম্প্রেশন মোড পদ্ধতি ব্যবহার করে সেট করা আবশ্যক DataStorageConfiguration.setWalPageCompression(), কম্প্রেশন ডিফল্টরূপে অক্ষম (অক্ষম মোড)।
• ঐচ্ছিকভাবে, আপনি পদ্ধতি ব্যবহার করে কম্প্রেশন স্তর সেট করতে পারেন DataStorageConfiguration.setWalPageCompression(), প্রতিটি মোডের জন্য বৈধ মানের জন্য পদ্ধতির জন্য javadoc দেখুন।

উপসংহার

Apache Ignite-এ বিবেচিত ডেটা কম্প্রেশন মেকানিজম একে অপরের থেকে স্বাধীনভাবে ব্যবহার করা যেতে পারে, তবে তাদের যেকোনো সমন্বয়ও গ্রহণযোগ্য। তারা কীভাবে কাজ করে তা বোঝার ফলে আপনার পরিবেশে আপনার কাজের জন্য তারা কতটা উপযুক্ত এবং সেগুলি ব্যবহার করার সময় আপনাকে কী উৎসর্গ করতে হবে তা নির্ধারণ করতে আপনাকে অনুমতি দেবে। ডিস্ক পৃষ্ঠা কম্প্রেশন প্রধান স্টোরেজ সংকুচিত করার জন্য ডিজাইন করা হয়েছে এবং একটি মাঝারি কম্প্রেশন অনুপাত দিতে পারে। WAL পৃষ্ঠার স্ন্যাপশট কম্প্রেশন WAL ফাইলগুলির জন্য একটি গড় ডিগ্রী কম্প্রেশন দেবে এবং সম্ভবত কর্মক্ষমতা উন্নত করবে। WAL কমপ্যাকশন কর্মক্ষমতার উপর ইতিবাচক প্রভাব ফেলবে না, তবে শারীরিক রেকর্ডগুলি সরিয়ে WAL ফাইলের আকার যতটা সম্ভব কমিয়ে দেবে।

উত্স: www.habr.com