ঘুম আসছে না, তাই লিখতে বসে পড়লাম।
আমার প্রফেশনাল এক্সপেরিয়েন্স ১ বছরের কাছাকাছি তাই ভুল ত্রুটির সম্ভাবনা অনেক বেশি। ভুল হলে অবশ্যই ফিডব্যাক দিবেন।
আগের আর্টিকেলগুলোর কন্টেন্ট এর উপরেই এই লিখাটা কন্টিনিউ করবো, আগের কন্টেন্ট গুলোর লিংক সবার শেষে দিয়ে দিবো।
অ্যাপ অনেক বড় হয়েছে মিলিওন ইউজার এর কাছা কাছি এখন। কনকারেন্ট ইউজার ৩ - ৪ লাখ।
আমরা ক্যশিং স্টিল ইউজ করছি যাতে ডাটাবেইজে ডাইরেক্ট হিট না পড়ে।
তাই ডাটাবেইজ নিয়ে আর চিন্তার কিছু নেই আপাতত। যত চিন্তা এই ক্যশিং নিয়ে।
প্রথম সমস্যা ক্যশ সাইজ নিয়ে এবং ডিস্ক এর অ্যালোকেট করা জায়গা নিয়ে। যদি একসাথে ৪ লাখ ইউজারের জন্য ভিডিও লিস্ট ক্যশ ডাটা স্টোর করি তাহলে ডিস্ক ব্যবহার হবে
৩৮ গিগাবাইটেরও বেশি যদি প্রতিটি ক্যশ সাইজ এভেরেজে ১০০kb হয়।
আমরা সোজাসুজি ভাবে সবচেয়ে অপ্টিমাল সমাধান এ যেতে পারবোনা, তাই একটু ধীরে ধীরে আগাই।
কেমন হয় যদি আমরা যে ডাটাকে ক্যাশ করবো, অর্থ্যাৎ সিরিয়ালাইজড ভিডিও লিস্ট টাকে কম্প্রেস করে দেন ক্যশ করি?
যদি ইনিশিয়াল সাইজ ১০০kb হয়, তাহলে কম্প্রেসড করা সাইজ হবে আনুমানিক ১০kb এর কাছা কাছি। সোজা ৯০% সাইজ রিডিউসড।
এখন ভাবতে পারেন যে কম্প্রেস করার জন্য কি রিকুয়েষ্ট বসিয়ে রাখতে হবে কিনা। আর হলেও কতক্ষন?
কম্প্রেস হতে টাইম নেয় আনুমানিক 1-10 microsecond. [ভুল হতে পারে]
আর আপনার ফ্রেমওয়ার্ক যদি Asynchronous Supported হয় তাহলে আর রিকুয়েষ্ট বসিয়ে রাখার নিয়ে চিন্তা করতে হবে না। যার জন্য ক্যশ হবে সে নাহয় একটু ধৈর্য ধরবে।
এই সিম্পল মেকানিজম এ আমরা কিন্তু ৯০% ক্যশ সাইজ কমিয়ে নিয়ে এসেছি। এর ফলে ডিস্ক এ চাপ একটু কম পড়বে।
এক্সাম্পল কম্প্রেশন এর প্রসিডিওর OrderDict ডাটার উপরে
# Compress Serialized data
json_str = json.dumps(serialized_data)
compressed_data = zlib.compress(json_str.encode('utf-8'))
cache.set(cache_key, compressed_data, expiration_time)
এখানে একটা নোটেবল প্রসেস হচ্ছে, যখন এই কম্প্রেসকৃত ডাটাকে ডিকম্প্রেস করে লোড করবেন তখন অবশ্যই যে ডাটাটাইপ ডাটা কম্প্রেস করেছেন তা উল্লেখ করতে হবে
# Decompress data
decompressed_data = zlib.decompress(compressed_data).decode('utf-8')
json_data = json.loads(decompressed_data, object_pairs_hook=lambda pairs: OrderedDict(pairs))
Django এর জন্য একটা ছোট্ট রিপো খুলে রেখেছি আমি, তা ব্যবহার করতে পারেন এই কম্প্রেস অ্যান্ড ডিকম্প্রেস প্রসিডিওর এর জন্য।
গিটহাব লিংক: Link
এটাতো গেলো ক্যশ সাইজ, এবার আসি ক্যশ রিনিউ নিয়ে। শেষবার আমি ক্যশ এক্সপাইরেশন টাইম None সেট করে দিয়েছলাম যাতে ক্যশ এক্সপায়ার না হয়। কিন্তু এখন আর তা করা সম্ভব না। কারন একসাথে এতো ইউজারের ক্যশ ধরেরাখলে অনেক অভারহেড কমপ্লেক্সিটির মুখোমুখি হতে হবে। তাই আমরা প্ল্যান করলাম ৩০ মিনিট এক্সপাইরেশন টাইম আবার আনবো৷
কিন্তু সমস্যা এইখানেও, যদি এমন হয় যে ১ লাখ ইউজারের ক্যশ একসাথে এক্সপায়ার হয়ে যায় এবং তারা একই সাথে এপিয়াই হিট দেয়?
এক্ষেত্রে আমাদের পুরনো সেই সাদামাটা ভিডিও লিস্টটা কে প্রি ক্যশ করে রাখতে পারি যা সেসকল ইউজারদেরকে দেখানো হবে যাদের ক্যশ এক্সপায়ারড হয়ে গিয়েছে। আর আমরা যখন দেখবো যে ইউজারের জন্য ক্যশ নেই, তখন একটা ব্যকগ্রাউন্ড টাস্ক এড করে দিতে পারি যাতে পরের রিকুয়েষ্ট পড়ার আগেই ইউজারের জন্য ইউজারের টেস্ট অনুযায়ী ক্যশ রেডি হয়ে যায়।
ক্যশ রেডি না হলেও, আমাদের কাছে কিন্তু স্টিল সেই সাদামাটা ক্যশড ভিডিও লিস্টটা আছে।
ব্যকগ্রাউন্ড টাস্কেও ঝামেলা আছে। একসাথে যদি ১ লাখ প্লাস ব্যকগ্রাউন্ড টাস্ক এসাইন হয় তাহলে রেডিস এর উপরে প্রেসার পড়বে অনেক বেশি, পাশা পাশি যদি Celery ব্যবহার করে থাকেন তাহলে Celery স্টাক হয়ে যাবে - যদি না আপনার ডাটাবেইজ অপটিমাইজড হয়, টাস্কের ভিতর ব্যবহার করা কুয়েরি গুলো অপ্টিমাইজড না হয়, সার্ভার রিসোর্স স্কেলেবল না হয় এবং Load Balancer না থাকে।
আরেকটা টপিকের লেজ গজিয়ে যাই:
কুয়েরি অপটিমাইজেশন হয়তো বুঝেছেন, কিন্তু ডাটাবেইজ অপটিমাইজেশন কী?
আগের লিখা গুলো :
ফার্স্ট: সার্ভার সাইড ক্যশিং কি, কেন ব্যবহার করা হয় এবং কেন গুরুত্বপূর্ণ?
সেকেন্ড : রাইট থ্রু ক্যশিং মেকানিজম!