Redis জন্য 10 দ্রুত টিপস

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

1. কী ব্যবহার করা বন্ধ করুন *

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

for key in 'keys *':
  doAllTheThings()

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

একটি বিকল্প হিসাবে, SCAN পরীক্ষা করে দেখুন যা আপনাকে ভালভাবে করতে দেয়... পরিবর্তে বৃদ্ধিতে আপনার ডাটাবেসের মাধ্যমে স্ক্যান করুন। এটি একটি ইন্টারেটারে কাজ করে যাতে আপনি থেমে যেতে পারেন এবং আপনার উপযুক্ত মনে হলে যেতে পারেন।

2. রিডিস কি ধীর করছে তা খুঁজে বের করুন

যেহেতু রেডিস-এর লগগুলির সবচেয়ে বেশি শব্দ নেই, তাই আপনার উদাহরণের ভিতরে ঠিক কী ঘটছে তা ট্র্যাকডাউন করা প্রায়শই কঠিন। ভাগ্যক্রমে রেডিস আপনাকে এটি দেখানোর জন্য কমান্ডস্ট্যাট ইউটিলিটি সরবরাহ করে:

127.0.0.1:6379> INFO commandstats
# Commandstats
cmdstat_get:calls=78,usec=608,usec_per_call=7.79
cmdstat_setex:calls=5,usec=71,usec_per_call=14.20
cmdstat_keys:calls=2,usec=42,usec_per_call=21.00
cmdstat_info:calls=10,usec=1931,usec_per_call=193.10

এটি আপনাকে সমস্ত কমান্ডের একটি ব্রেকডাউন দেয়, সেগুলি কতবার চালানো হয়েছে, চালানোর জন্য কতগুলি মাইক্রোসেকেন্ড লেগেছে (প্রতি কলে মোট এবং গড়)

এটি রিসেট করতে কেবল কনফিগ রিসেটস্ট্যাট চালান, এবং আপনি একটি একেবারে নতুন স্লেট পেয়েছেন৷

3. একটি বেসলাইন হিসাবে Redis-বেঞ্চমার্ক ব্যবহার করুন, গসপেল সত্য নয়

রেডিস-এর স্রষ্টা সালভাতোর এটিকে আন্তরিকভাবে বলেছেন:"Redis GET/SET করে পরীক্ষা করা একটি ফেরারি পরীক্ষা করার মত যে বৃষ্টি হলে আয়না পরিষ্কার করা কতটা ভালো।" অনেক সময় লোকেরা আমার কাছে আশ্চর্য হয়ে আসে কেন তাদের রেডিস-বেঞ্চমার্ক ফলাফল সর্বোত্তম থেকে কম। কিন্তু আমাদের অনেকগুলি বিভিন্ন কারণ বিবেচনা করতে হবে, যেমন:

• ক্লায়েন্ট-সাইড সীমাবদ্ধতার মধ্যে আমরা কী করতে পারতাম?
• সংস্করণে কি কোনো পার্থক্য ছিল?
• অ্যাপ্লিকেশানটি কী করবে তার সাথে কি পরীক্ষা করা হচ্ছে তা কি প্রাসঙ্গিক?

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

4. হ্যাশগুলি আপনার সেরা বন্ধু

রাতের খাবারের জন্য হ্যাশকে আমন্ত্রণ জানান। ওয়াইন এবং ডাইন হ্যাশ। আপনি যদি তাদের সুযোগ দেন তবে তারা কী সুখ আনতে পারে তা দেখে আপনি অবাক হয়ে যাবেন। আমি এর আগে অনেকগুলি মূল কাঠামো দেখেছি:

foo:first_name
foo:last_name
foo:address

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

127.0.0.1:6379> HSET foo first_name "Joe"
(integer) 1
127.0.0.1:6379> HSET foo last_name "Engel"
(integer) 1
127.0.0.1:6379> HSET foo address "1 Fanatical Pl"
(integer) 1
127.0.0.1:6379> HGETALL foo
1) "first_name"
2) "Joe"
3) "last_name"
4) "Engel"
5) "address"
6) "1 Fanatical Pl"
127.0.0.1:6379> HGET foo first_name
"Joe"

5. সেই TTL সেট করুন!

যখনই সম্ভব, মেয়াদ শেষ হওয়া কীগুলির সুবিধা নিন। একটি নিখুঁত উদাহরণ হল অস্থায়ী প্রমাণীকরণ কীগুলির মতো কিছু সংরক্ষণ করা। আপনি যখন auth কী পুনরুদ্ধার করেন — আসুন একটি উদাহরণ হিসাবে OAUTH ব্যবহার করি — আপনাকে প্রায়শই মেয়াদ শেষ হওয়ার সময় দেওয়া হয়। আপনি যখন কী সেট করবেন, একই মেয়াদ শেষ হওয়ার সাথে এটি সেট করুন এবং রেডিস আপনার জন্য পরিষ্কার করবে! এই সমস্ত কীগুলির মাধ্যমে পুনরাবৃত্তি করার জন্য KEYS * এর আর প্রয়োজন নেই, তাই না?

6. সঠিক উচ্ছেদ নীতি নির্বাচন করা

যখন আমরা কীগুলি পরিষ্কার করার বিষয়ে আছি, আসুন উচ্ছেদের বিষয়ে স্পর্শ করি। যখন আপনার Redis দৃষ্টান্ত পূর্ণ হয়, Redis কীগুলি উচ্ছেদ করার চেষ্টা করবে। আপনার ব্যবহারের ক্ষেত্রে নির্ভর করে, আমি অত্যন্ত সুপারিশ করছি volatile-lru - ধরে নিচ্ছি আপনার মেয়াদ শেষ হয়ে যাওয়া কী আছে। আপনি যদি ক্যাশের মতো কিছু চালান এবং মেয়াদ শেষ হওয়ার সেট না থাকে তবে আপনি allkeys-lru বিবেচনা করতে পারেন। আমি এখানে উপলব্ধ বিকল্পগুলি চেক আউট করার সুপারিশ করব৷

7. যদি আপনার ডেটা গুরুত্বপূর্ণ হয়, চেষ্টা করুন/ব্যতীত

আপনার রেডিস উদাহরণে ডেটা তৈরি করা যদি এটি একেবারেই গুরুত্বপূর্ণ হয়, তবে আমি প্রচণ্ডভাবে একটি চেষ্টা/ব্যতীত রাখার পরামর্শ দিই। যেহেতু প্রায় সমস্ত রেডিস ক্লায়েন্টকে "ফায়ার-এন্ড-ফরগেট" করার জন্য কনফিগার করা হয়েছে, তাই কখন একটি কী আসলে ডাটাবেসে আসে না তার জন্য সর্বদা বিবেচনা করা উচিত। আপনার redis কলে যোগ করা জটিলতা এই ক্ষেত্রে কিছুই নয়, এবং আপনি নিশ্চিত করতে পারেন যে আপনার গুরুত্বপূর্ণ ডেটা যেখানে থাকা উচিত সেখানে পৌঁছেছে৷

8. এক দৃষ্টান্ত বন্যা করবেন না

যখনই সম্ভব, একাধিক Redis দৃষ্টান্তের মধ্যে কাজের চাপ ভাগ করুন। সংস্করণ 3.0.0 হিসাবে, Redis ক্লাস্টার এখন উপলব্ধ। রেডিস ক্লাস্টার আপনাকে কী রেঞ্জের উপর ভিত্তি করে প্রদত্ত প্রভু/দাসদের সেটগুলির মধ্যে কীগুলিকে আলাদা করতে দেয়। ক্লাস্টারের পিছনে যাদুটির একটি সম্পূর্ণ ভাঙ্গন এখানে পাওয়া যাবে। এবং আপনি যদি একটি টিউটোরিয়াল খুঁজছেন, তাহলে আর তাকাবেন না। যদি ক্লাস্টারিং একটি বিকল্প না হয়, তাহলে নেমস্পেসিং বিবেচনা করুন এবং একাধিক উদাহরণের মধ্যে আপনার কীগুলি বিতরণ করুন। আপনার ডেটা বিভাজন সম্পর্কে একটি আশ্চর্যজনক লেখা এখানে redis.io ওয়েবসাইটে পাওয়া যাবে।

9. আরও কোর =আরও ভাল, তাই না?!

ভুল. রেডিস হল একটি একক থ্রেডেড প্রক্রিয়া এবং আপনার যদি অধ্যবসায় সক্ষম থাকে তবে সর্বাধিক দুটি কোর ব্যবহার করবে। আপনি যদি একই হোস্টে একাধিক দৃষ্টান্ত চালানোর পরিকল্পনা না করেন—আশা করি শুধুমাত্র সেই ক্ষেত্রে ডেভ টেস্টিংয়ের জন্য!—একটি রেডিস উদাহরণের জন্য আপনার দুইটির বেশি কোরের প্রয়োজন হবে না৷

10. HA সব জিনিস!

রেডিস সেন্টিনেল এখন খুব ভালভাবে পরীক্ষা করা হয়েছে, এবং অনেক ব্যবহারকারীর এটি উৎপাদনে চলছে (অবজেক্ট রকেট অন্তর্ভুক্ত!) আপনি যদি আপনার আবেদনের জন্য রেডিসের উপর খুব বেশি নির্ভর করে থাকেন, তাহলে আপনাকে অনলাইনে রাখার জন্য একটি HA (উচ্চ প্রাপ্যতা) সমাধান বিবেচনা করতে হবে। অবশ্যই, আপনি যদি সেগুলি নিজেই পরিচালনা করতে না চান, তাহলে অবজেক্ট রকেট আমাদের HA প্ল্যাটফর্ম অফার করে 24×7 আপনার ব্যবহারের জন্য সমর্থন, এটি একটি শট দিন৷