HBase ব্যবহারের তত্ত্ব এবং অনুশীলন

শুভ অপরাহ্ন আমার নাম ড্যানিল লিপোভয়, Sbertech-এ আমাদের টিম HBase কে অপারেশনাল ডেটার স্টোরেজ হিসেবে ব্যবহার করা শুরু করেছে। এটি অধ্যয়নের সময়, অভিজ্ঞতা সঞ্চিত হয়েছে যে আমি পদ্ধতিগত এবং বর্ণনা করতে চেয়েছিলাম (আমরা আশা করি এটি অনেকের জন্য কার্যকর হবে)। নীচের সমস্ত পরীক্ষাগুলি HBase সংস্করণ 1.2.0-cdh5.14.2 এবং 2.0.0-cdh6.0.0-beta1 দিয়ে সম্পাদিত হয়েছিল।

1. সাধারণ স্থাপত্য
2. HBASE-তে ডেটা লেখা
3. HBASE থেকে ডেটা পড়া
4. ডেটা ক্যাশিং
5. ব্যাচ ডেটা প্রসেসিং মাল্টিগেট/মাল্টিপুট
6. অঞ্চলে টেবিল বিভক্ত করার কৌশল (বিভক্ত করা)
7. ফল্ট টলারেন্স, কমপ্যাক্টিফিকেশন এবং ডেটা লোকেলিটি
8. সেটিংস এবং কর্মক্ষমতা
9. চাপ পরীক্ষা
10. তথ্যও

1. সাধারণ স্থাপত্য

ব্যাকআপ মাস্টার ZooKeeper নোডে সক্রিয় একজনের হার্টবিট শোনেন এবং অদৃশ্য হয়ে গেলে, মাস্টারের কার্যভার গ্রহণ করেন।

2. HBASE-তে ডেটা লিখুন

প্রথমে, আসুন সবচেয়ে সহজ কেসটি দেখি - put(rowkey) ব্যবহার করে একটি টেবিলে একটি কী-মানের বস্তু লেখা। ক্লায়েন্টকে প্রথমে খুঁজে বের করতে হবে যে রুট রিজিয়ন সার্ভার (RRS), যেটি hbase:meta টেবিল সংরক্ষণ করে, কোথায় অবস্থিত। তিনি ZooKeeper থেকে এই তথ্য পান। এর পরে এটি RRS-এ অ্যাক্সেস করে এবং hbase:meta টেবিলটি পড়ে, যেখান থেকে এটি কোন RegionServer (RS) আগ্রহের টেবিলে প্রদত্ত রোকির জন্য ডেটা সংরক্ষণের জন্য দায়ী সে সম্পর্কে তথ্য বের করে। ভবিষ্যতে ব্যবহারের জন্য, মেটা টেবিলটি ক্লায়েন্ট দ্বারা ক্যাশে করা হয় এবং সেইজন্য পরবর্তী কলগুলি দ্রুত RS-এ চলে যায়।

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

মেমস্টোরে একটি এন্ট্রি রাখার পরে, ক্লায়েন্টকে একটি প্রতিক্রিয়া ফেরত দেওয়া হয় যে এন্ট্রিটি সফলভাবে সংরক্ষিত হয়েছে। যাইহোক, বাস্তবে এটি শুধুমাত্র একটি বাফারে সংরক্ষণ করা হয় এবং একটি নির্দিষ্ট সময় অতিক্রান্ত হওয়ার পরে বা যখন এটি নতুন ডেটা দিয়ে পূর্ণ হয় তখনই ডিস্কে যায়।

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

HFile ফরম্যাটে ফাইলগুলি HDFS-এ জমা করা হয় এবং সময়ে সময়ে ছোটখাটো কমপ্যাক্ট প্রক্রিয়া চালু করা হয়, যা কিছু মুছে না দিয়েই ছোট ফাইলগুলিকে বড় ফাইলগুলিতে মার্জ করে। সময়ের সাথে সাথে, এটি একটি সমস্যায় পরিণত হয় যা শুধুমাত্র ডেটা পড়ার সময় উপস্থিত হয় (আমরা একটু পরে এটিতে ফিরে আসব)।

উপরে বর্ণিত লোডিং প্রক্রিয়া ছাড়াও, আরও অনেক কার্যকর পদ্ধতি রয়েছে, যা সম্ভবত এই ডাটাবেসের সবচেয়ে শক্তিশালী দিক - বাল্কলোড। এটি সত্য যে আমরা স্বাধীনভাবে HFiles গঠন করি এবং সেগুলিকে ডিস্কে রাখি, যা আমাদেরকে নিখুঁতভাবে স্কেল করতে এবং খুব শালীন গতি অর্জন করতে দেয়। আসলে, এখানে সীমাবদ্ধতা HBase নয়, কিন্তু হার্ডওয়্যারের ক্ষমতা। নীচে 16টি অঞ্চল সার্ভার এবং 16 নোডম্যানেজার ইয়ারন (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 থ্রেড), HBase সংস্করণ 1.2.0-cdh5.14.2 সমন্বিত একটি ক্লাস্টারে বুট ফলাফল রয়েছে৷

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

আপনি একই সময়ে দুটি টেবিলে লোড করা শুরু করতে পারেন এবং দ্বিগুণ গতি পেতে পারেন। নীচে আপনি দেখতে পাচ্ছেন যে দুটি টেবিলে একবারে 10 কেবি ব্লক লেখা প্রতিটিতে প্রায় 600 এমবি/সেকেন্ড গতিতে ঘটে (মোট 1275 এমবি/সেকেন্ড), যা একটি টেবিলে লেখার গতি 623 এমবি/সেকেন্ডের সাথে মিলে যায় (দেখুন উপরে নং 11)

কিন্তু 50 KB এর রেকর্ড সহ দ্বিতীয় রান দেখায় যে ডাউনলোডের গতি সামান্য বাড়ছে, যা ইঙ্গিত দেয় যে এটি সীমা মানগুলির কাছে পৌঁছেছে। একই সময়ে, আপনাকে মনে রাখতে হবে যে HBASE তে কার্যত কোনও লোড তৈরি হয়নি, এর জন্য যা প্রয়োজন তা হল প্রথমে hbase:meta থেকে ডেটা দেওয়া এবং HFiles লাইনিং করার পরে, ব্লকক্যাচে ডেটা রিসেট করুন এবং সংরক্ষণ করুন। মেমস্টোর ডিস্কে বাফার, যদি এটি খালি না থাকে।

3. HBASE থেকে ডেটা পড়া

যদি আমরা ধরে নিই যে ক্লায়েন্টের কাছে ইতিমধ্যেই hbase:meta থেকে সমস্ত তথ্য রয়েছে (বিন্দু 2 দেখুন), তাহলে অনুরোধটি সরাসরি RS-এ যায় যেখানে প্রয়োজনীয় কী সংরক্ষণ করা হয়। প্রথমত, অনুসন্ধানটি মেমক্যাশে সঞ্চালিত হয়। সেখানে ডেটা আছে কি না তা নির্বিশেষে, ব্লকক্যাশে বাফারে এবং প্রয়োজনে HFiles-এ অনুসন্ধান করা হয়। ফাইলে ডেটা পাওয়া গেলে, এটি ব্লকক্যাশে রাখা হয় এবং পরবর্তী অনুরোধে দ্রুত ফেরত দেওয়া হবে। ব্লুম ফিল্টার ব্যবহার করার জন্য HFile-এ অনুসন্ধান করা তুলনামূলকভাবে দ্রুত। অল্প পরিমাণ ডেটা পড়ার পরে, এটি অবিলম্বে নির্ধারণ করে যে এই ফাইলটিতে প্রয়োজনীয় কী রয়েছে কিনা এবং যদি না থাকে তবে পরবর্তীটিতে চলে যায়।

এই তিনটি উত্স থেকে ডেটা প্রাপ্ত করার পরে, আরএস একটি প্রতিক্রিয়া তৈরি করে। বিশেষ করে, ক্লায়েন্ট সংস্করণের অনুরোধ করলে এটি একবারে একটি বস্তুর একাধিক পাওয়া সংস্করণ স্থানান্তর করতে পারে।

4. ডেটা ক্যাশিং

MemStore এবং BlockCache বাফারগুলি বরাদ্দকৃত অন-হিপ RS মেমরির 80% পর্যন্ত দখল করে (বাকিটি RS পরিষেবা কাজের জন্য সংরক্ষিত)। যদি সাধারণ ব্যবহারের মোডটি এমন হয় যে প্রক্রিয়াগুলি একই ডেটা লিখতে এবং পড়ে অবিলম্বে, তাহলে ব্লকক্যাশ হ্রাস করা এবং মেমস্টোর বৃদ্ধি করা অর্থপূর্ণ, কারণ যখন লেখার ডেটা পড়ার জন্য ক্যাশে আসে না, তখন ব্লকক্যাচ কম ঘন ঘন ব্যবহার করা হবে। BlockCache বাফার দুটি অংশ নিয়ে গঠিত: LruBlockCache (সর্বদা অন-হিপ) এবং BucketCache (সাধারণত অফ-হিপ বা SSD-এ)। BucketCache ব্যবহার করা উচিত যখন প্রচুর পড়ার অনুরোধ থাকে এবং সেগুলি LruBlockCache-এর সাথে খাপ খায় না, যা গারবেজ কালেক্টরের সক্রিয় কাজ করে। একই সময়ে, আপনার রিড ক্যাশে ব্যবহার করে কর্মক্ষমতায় আমূল বৃদ্ধি আশা করা উচিত নয়, তবে আমরা অনুচ্ছেদ 8 এ ফিরে আসব

সমগ্র RS-এর জন্য একটি BlockCache আছে, এবং প্রতিটি টেবিলের জন্য একটি MemStore আছে (প্রতিটি কলাম পরিবারের জন্য একটি)।

কিভাবে বর্ণিত তাত্ত্বিকভাবে, লেখার সময়, ডেটা ক্যাশে যায় না এবং প্রকৃতপক্ষে, টেবিলের জন্য এই ধরনের প্যারামিটার CACHE_DATA_ON_WRITE এবং RS-এর জন্য "লিখতে ক্যাশে ডেটা" মিথ্যা সেট করা হয়। যাইহোক, অনুশীলনে, যদি আমরা মেমস্টোরে ডেটা লিখি, তারপর এটিকে ডিস্কে ফ্লাশ করি (এভাবে এটি পরিষ্কার করা হয়), তারপর ফলাফল ফাইলটি মুছে ফেলুন, তারপর একটি get অনুরোধ কার্যকর করার মাধ্যমে আমরা সফলভাবে ডেটা গ্রহণ করব। তাছাড়া, এমনকি যদি আপনি BlockCache সম্পূর্ণরূপে নিষ্ক্রিয় করেন এবং নতুন ডেটা দিয়ে টেবিলটি পূরণ করেন, তারপর মেমস্টোরকে ডিস্কে রিসেট করেন, সেগুলি মুছে দেন এবং অন্য সেশন থেকে অনুরোধ করেন, সেগুলি এখনও কোথাও থেকে পুনরুদ্ধার করা হবে। তাই HBase শুধু তথ্যই নয়, রহস্যময় রহস্যও সংরক্ষণ করে।

hbase(main):001:0> create 'ns:magic', 'cf'
Created table ns:magic
Took 1.1533 seconds
hbase(main):002:0> put 'ns:magic', 'key1', 'cf:c', 'try_to_delete_me'
Took 0.2610 seconds
hbase(main):003:0> flush 'ns:magic'
Took 0.6161 seconds
hdfs dfs -mv /data/hbase/data/ns/magic/* /tmp/trash
hbase(main):002:0> get 'ns:magic', 'key1'
 cf:c      timestamp=1534440690218, value=try_to_delete_me

"পঠিত ক্যাশে ডেটা" প্যারামিটারটি মিথ্যাতে সেট করা হয়েছে৷ আপনার যদি কোন ধারনা থাকে, মন্তব্যে এটি আলোচনা করতে স্বাগত জানাই।

5. ব্যাচ ডেটা প্রসেসিং মাল্টিগেট/মাল্টিপুট

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

একটি ভার্চুয়াল মেশিনে পরীক্ষা করা হয়েছিল, 8 কোর, সংস্করণ HBase 2.0.0-cdh6.0.0-beta1।

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

খণ্ড আকার বাড়ানোর পাশাপাশি, অঞ্চল অনুসারে ডেটা বিভক্ত করা সাহায্য করে, যেমন টেবিল বিভাজন। এর ফলে প্রতিটি অঞ্চলে কম অনুরোধ আসে এবং সেগুলি একটি কক্ষে ফিট হলে, প্রতিক্রিয়া ভাল থাকে৷

6. অঞ্চলে টেবিল বিভক্ত করার কৌশল (বিভক্ত করা)

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

এটি ঘটে যে এটি একটি তীক্ষ্ণ ধীরগতির দিকে নিয়ে যায় যদি পরে লোড করা ডেটার মতো দেখায়, উদাহরণস্বরূপ, দীর্ঘ মান, যার বেশিরভাগ একই অঙ্ক দিয়ে শুরু হয়, উদাহরণস্বরূপ:

1000001
1000002
...
1100003

যেহেতু কীগুলি একটি বাইট অ্যারে হিসাবে সংরক্ষণ করা হয়, সেগুলি সব একইভাবে শুরু হবে এবং এই রেঞ্জের কীগুলি সংরক্ষণ করে একই অঞ্চল #1 এর অন্তর্গত। বিভিন্ন বিভাজন কৌশল রয়েছে:

HexStringSplit - "00000000" => "FFFFFFFF" পরিসরে একটি হেক্সাডেসিমেল এনকোড করা স্ট্রিং-এ কীটিকে পরিণত করে এবং বামদিকে শূন্য সহ প্যাডিং।

ইউনিফর্ম স্প্লিট - "00" => "FF" রেঞ্জে হেক্সাডেসিমেল এনকোডিং এবং শূন্য সহ ডানদিকে প্যাডিং সহ কীটিকে একটি বাইট অ্যারেতে পরিণত করে।

উপরন্তু, আপনি বিভক্ত করার জন্য যেকোনো পরিসর বা কীগুলির সেট নির্দিষ্ট করতে পারেন এবং স্বয়ংক্রিয়-বিভক্তকরণ কনফিগার করতে পারেন। যাইহোক, সবচেয়ে সহজ এবং সবচেয়ে কার্যকর পদ্ধতির মধ্যে একটি হল UniformSplit এবং হ্যাশ কনক্যাটেনেশনের ব্যবহার, উদাহরণস্বরূপ CRC32(rowkey) ফাংশন এবং rowkey-এর মাধ্যমে কী চালানো থেকে সবচেয়ে উল্লেখযোগ্য জোড়া বাইট:

হ্যাশ + রোকি

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

7. ত্রুটি সহনশীলতা এবং ডেটা স্থানীয়তা

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

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

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

পরীক্ষাটি 3টি DataNodes এবং 4 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 থ্রেড) এ সম্পাদিত হয়েছিল। HBase সংস্করণ 1.2.0-cdh5.14.2

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

এছাড়াও, বড় কমপ্যাকশন মেমস্টোরের অবস্থাকে প্রভাবিত করে না; এটিকে ডিস্কে ফ্লাশ করতে এবং এটিকে কমপ্যাক্ট করতে, আপনাকে ফ্লাশ ব্যবহার করতে হবে (connection.getAdmin().flush(TableName.valueOf(tblName)))।

8. সেটিংস এবং কর্মক্ষমতা

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

• 10টি থ্রেড একই সাথে 3 বার একটি সারিতে চালু করা হয়েছিল (আসুন এটিকে থ্রেডের একটি ব্লক বলি)।
• একটি ব্লকের সমস্ত থ্রেডের অপারেটিং সময় গড় করা হয়েছিল এবং ব্লকের অপারেশনের চূড়ান্ত ফলাফল ছিল।
• সমস্ত থ্রেড একই টেবিলের সাথে কাজ করে।
• থ্রেড ব্লকের প্রতিটি শুরুর আগে, একটি বড় কম্প্যাকশন সঞ্চালিত হয়েছিল।
• প্রতিটি ব্লক নিম্নলিখিত ক্রিয়াকলাপগুলির মধ্যে শুধুমাত্র একটি সম্পাদন করেছে:

- রাখো
-পাওয়া
-পান+পুট

• প্রতিটি ব্লক তার অপারেশনের 50টি পুনরাবৃত্তি করেছে।
• একটি রেকর্ডের ব্লকের আকার হল 100 বাইট, 1000 বাইট বা 10000 বাইট (এলোমেলো)।
• ব্লকগুলি বিভিন্ন সংখ্যক অনুরোধ করা কীগুলির সাথে চালু করা হয়েছিল (একটি কী বা 10টি)।
• ব্লকগুলি বিভিন্ন টেবিল সেটিংসের অধীনে চালানো হয়েছিল। পরামিতি পরিবর্তিত:

— BlockCache = চালু বা বন্ধ
— ব্লক সাইজ = 65 KB বা 16 KB
— পার্টিশন = 1, 5 বা 30
— MSLAB = সক্ষম বা নিষ্ক্রিয়

সুতরাং ব্লক এই মত দেখায়:

ক MSLAB মোড চালু/বন্ধ করা হয়েছে।
খ. একটি টেবিল তৈরি করা হয়েছিল যার জন্য নিম্নলিখিত পরামিতিগুলি সেট করা হয়েছিল: ব্লকক্যাচে = সত্য/কোনটি নয়, ব্লক সাইজ = 65/16 কেবি, পার্টিশন = 1/5/30।
গ. কম্প্রেশন GZ এ সেট করা হয়েছে।
d 10টি থ্রেড একই সাথে চালু করা হয়েছিল 1/10 পুট/গেট/গেট+পুট অপারেশন করে এই টেবিলে 100/1000/10000 বাইটের রেকর্ড সহ, এক সারিতে 50টি প্রশ্ন সম্পাদন করে (এলোমেলো কী)।
e পয়েন্ট d তিনবার পুনরাবৃত্তি হয়েছিল।
চ সমস্ত থ্রেডের অপারেটিং সময় গড় ছিল।

সমস্ত সম্ভাব্য সংমিশ্রণ পরীক্ষা করা হয়েছিল। এটা অনুমান করা যায় যে রেকর্ড আকার বৃদ্ধির সাথে সাথে গতি কমে যাবে, অথবা ক্যাশিং অক্ষম করার ফলে মন্থরতা ঘটবে। যাইহোক, লক্ষ্য ছিল প্রতিটি প্যারামিটারের প্রভাবের মাত্রা এবং তাৎপর্য বোঝা, তাই সংগৃহীত ডেটা একটি রৈখিক রিগ্রেশন ফাংশনের ইনপুটে দেওয়া হয়েছিল, যা টি-পরিসংখ্যান ব্যবহার করে তাত্পর্য মূল্যায়ন করা সম্ভব করে। নীচে পুট অপারেশন সঞ্চালন ব্লক ফলাফল আছে. কম্বিনেশনের সম্পূর্ণ সেট 2*2*3*2*3 = 144 অপশন + 72 টাকা। কিছু দুবার করা হয়েছিল। সুতরাং, মোট 216 রান আছে:

3টি ডেটানোড এবং 4টি RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 থ্রেড) সমন্বিত একটি মিনি-ক্লাস্টারে পরীক্ষা করা হয়েছিল। HBase সংস্করণ 1.2.0-cdh5.14.2।

3.7 সেকেন্ডের সর্বোচ্চ সন্নিবেশ গতি প্রাপ্ত হয়েছিল MSLAB মোড বন্ধ করে, একটি পার্টিশন সহ একটি টেবিলে, ব্লকক্যাচে সক্ষম সহ, ব্লক সাইজ = 16, 100 বাইটের রেকর্ড, প্রতি প্যাকে 10 টুকরা।
82.8 সেকেন্ডের সর্বনিম্ন সন্নিবেশ গতি MSLAB মোড সক্ষম করা হয়েছে, একটি বিভাজন সহ একটি টেবিলে, ব্লকক্যাচে সক্ষম সহ, ব্লক সাইজ = 16, 10000 বাইটের রেকর্ড, প্রতিটি 1টি।

এখন মডেল তাকান. আমরা R2 এর উপর ভিত্তি করে মডেলের ভাল মানের দেখতে, কিন্তু এটা একেবারে পরিষ্কার যে এক্সট্রাপোলেশন এখানে contraindicated হয়. সিস্টেমের প্রকৃত আচরণ যখন প্যারামিটার পরিবর্তন হয় তখন রৈখিক হবে না; এই মডেলটি ভবিষ্যদ্বাণীর জন্য নয়, প্রদত্ত প্যারামিটারের মধ্যে কী ঘটেছে তা বোঝার জন্য প্রয়োজন। উদাহরণ স্বরূপ, এখানে আমরা ছাত্রের মাপকাঠি থেকে দেখতে পাচ্ছি যে BlockSize এবং BlockCache প্যারামিটার পুট অপারেশনের জন্য কোন ব্যাপার নয় (যা সাধারণত বেশ অনুমান করা যায়):

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

এখন আসুন Get blocks কার্যকর করার ফলাফল মূল্যায়ন করা যাক:

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

ঠিক আছে, অবশেষে, আসুন ব্লকের মডেলটি দেখি যা প্রথমে পারফর্ম করেছে এবং তারপরে রাখছে:

সমস্ত পরামিতি এখানে উল্লেখযোগ্য। এবং নেতাদের ফলাফল:

9. লোড টেস্টিং

ঠিক আছে, অবশেষে আমরা একটি কম বা কম শালীন লোড চালু করব, কিন্তু যখন আপনার সাথে তুলনা করার কিছু থাকে তখন এটি সর্বদা আরও আকর্ষণীয় হয়। ডাটাস্ট্যাক্সের ওয়েবসাইটে, ক্যাসান্দ্রার মূল বিকাশকারী, সেখানে রয়েছে ফলাফল HBase সংস্করণ 0.98.6-1 সহ বেশ কয়েকটি NoSQL স্টোরেজের NT। লোডিং 40টি থ্রেড, ডেটা সাইজ 100 বাইট, এসএসডি ডিস্ক দ্বারা সম্পাদিত হয়েছিল। রিড-মডিফাই-রাইট অপারেশন পরীক্ষার ফলাফল নিম্নলিখিত ফলাফল দেখিয়েছে।

যতদূর আমি বুঝতে পেরেছি, 100টি রেকর্ডের ব্লকে পঠন করা হয়েছিল এবং 16টি HBase নোডের জন্য, DataStax পরীক্ষা প্রতি সেকেন্ডে 10 হাজার অপারেশনের পারফরম্যান্স দেখায়।

এটা ভাগ্যের বিষয় যে আমাদের ক্লাস্টারে 16টি নোডও রয়েছে, কিন্তু এটা খুব "ভাগ্যবান" নয় যে প্রতিটিতে 64টি কোর (থ্রেড) আছে, যখন DataStax পরীক্ষায় আছে মাত্র 4টি। অন্যদিকে, তাদের SSD ড্রাইভ রয়েছে, আমাদের HDD আছে। লোডের সময় HBase এবং CPU-এর নতুন সংস্করণের ব্যবহার কার্যত উল্লেখযোগ্যভাবে বৃদ্ধি পায়নি (দৃশ্যত 5-10 শতাংশ)। যাইহোক, আসুন এই কনফিগারেশন ব্যবহার শুরু করার চেষ্টা করা যাক। ডিফল্ট টেবিল সেটিংস, রিডিং 0 থেকে 50 মিলিয়ন এলোমেলোভাবে কী পরিসরে সঞ্চালিত হয় (অর্থাৎ, প্রতিবার নতুন)। টেবিলটিতে 50 মিলিয়ন রেকর্ড রয়েছে, 64টি পার্টিশনে বিভক্ত। কীগুলি crc32 ব্যবহার করে হ্যাশ করা হয়। টেবিল সেটিংস ডিফল্ট, MSLAB সক্ষম। 40টি থ্রেড চালু করে, প্রতিটি থ্রেড 100টি র্যান্ডম কীগুলির একটি সেট পড়ে এবং অবিলম্বে জেনারেট করা 100 বাইটগুলিকে এই কীগুলিতে ফিরিয়ে দেয়।

স্ট্যান্ড: 16 DataNode এবং 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 থ্রেড)। HBase সংস্করণ 1.2.0-cdh5.14.2।

গড় ফলাফল প্রতি সেকেন্ডে 40 হাজার অপারেশনের কাছাকাছি, যা DataStax পরীক্ষার তুলনায় উল্লেখযোগ্যভাবে ভালো। যাইহোক, পরীক্ষামূলক উদ্দেশ্যে, আপনি সামান্য শর্ত পরিবর্তন করতে পারেন. এটি খুব অসম্ভাব্য যে সমস্ত কাজ একচেটিয়াভাবে একটি টেবিলে এবং শুধুমাত্র অনন্য কীগুলিতে পরিচালিত হবে। আসুন ধরে নিই যে একটি নির্দিষ্ট "হট" কীগুলির সেট রয়েছে যা মূল লোড তৈরি করে। অতএব, আসুন বড় রেকর্ড (10 KB) সহ একটি লোড তৈরি করার চেষ্টা করি, এছাড়াও 100 এর ব্যাচে, 4টি ভিন্ন টেবিলে এবং অনুরোধ করা কীগুলির পরিসর 50 হাজারে সীমাবদ্ধ করে। নীচের গ্রাফটি 40টি থ্রেডের লঞ্চ দেখায়, প্রতিটি থ্রেড পড়ে 100 কীগুলির একটি সেট এবং অবিলম্বে এই কীগুলির পিছনে 10 KB এলোমেলো করে লিখে।

স্ট্যান্ড: 16 DataNode এবং 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 থ্রেড)। HBase সংস্করণ 1.2.0-cdh5.14.2।

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

পড়া এবং অবিলম্বে লেখা HBase-এর জন্য সবচেয়ে কঠিন কাজের পরিস্থিতিগুলির মধ্যে একটি। আপনি যদি শুধুমাত্র ছোট পুট অনুরোধ করেন, উদাহরণস্বরূপ 100 বাইট, সেগুলিকে 10-50 হাজার টুকরার প্যাকে একত্রিত করে, আপনি প্রতি সেকেন্ডে কয়েক হাজার অপারেশন পেতে পারেন, এবং পরিস্থিতি শুধুমাত্র পঠনযোগ্য অনুরোধগুলির সাথে একই রকম। এটি লক্ষণীয় যে ফলাফলগুলি DataStax দ্বারা প্রাপ্ত ফলাফলের চেয়ে আমূল ভাল, সর্বাধিক 50 হাজার ব্লকের অনুরোধের কারণে।

স্ট্যান্ড: 16 DataNode এবং 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 থ্রেড)। HBase সংস্করণ 1.2.0-cdh5.14.2।

10। উপসংহার

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

যদি আপনার মতামতে এমন কিছু থাকে যা যথেষ্ট প্রকাশ না করা হয় তবে আমি আপনাকে আরও বিশদে বলতে প্রস্তুত। আমরা আপনাকে আপনার অভিজ্ঞতা শেয়ার করার জন্য আমন্ত্রণ জানাই বা আপনি যদি কিছুর সাথে একমত না হন তবে আলোচনা করতে।

উত্স: www.habr.com