How to choose between cache-aside, read-through, write-through, client-side, and distributed caching strategies যেমনটি আমরা সাম্প্রতিক সময়ে উল্লেখ করেছি। পোস্ট, আমরা খুশি যে Pekka Enberg লিখতে সিদ্ধান্ত নিয়েছে আমরা গর্বিত যে আমরা তিনটি ক্যাপিটাল সমর্থন করেছি। কেন ডেটা ক্যাশ? ল্যাটিনির উপর একটি সম্পূর্ণ বই Get the Latency book excerpt পিডিএফ Get the Latency book excerpt পিডিএফ Get the Latency book excerpt পিডিএফ এছাড়াও, Pekka কেবলমাত্র সেই বই থেকে কীটনাশক শেয়ার করেছিলেন একটি (আমরা এখন অনুরোধ অনুযায়ী উপলব্ধ) নিম্ন দীর্ঘস্থায়ী অ্যাপ্লিকেশন নির্মাণ উপর masterclass চলুন আমাদের বইটির ক্যাশিং ক্যাপিটাল থেকে আরো কিছু অক্ষর রয়েছে. এটি প্রকাশকের অনুমতি নিয়ে এখানে পুনরায় প্রিন্ট করা হয়েছে। ল্যাটিন *আপনি আপনার অ্যাপ্লিকেশনে ক্যাশিং যোগ করার সময়, আপনাকে প্রথমে আপনার ক্যাশিং কৌশলটি বিবেচনা করতে হবে, যা নির্ধারণ করে কিভাবে ক্যাশ এবং একটি ডাটাবেস বা পরিষেবা হিসাবে ভিত্তিক ব্যাকআপ স্টোর থেকে পড়া এবং লিখা হয়। অন্য কথায়, যখন আপনার অ্যাপ্লিকেশন ক্যাশ থেকে একটি মান খুঁজছে, কিন্তু মূল্য সেখানে নেই বা শেষ হয়েছে, ক্যাশিং কৌশলটি আপনার অ্যাপ্লিকেশন বা ক্যাশ যা ব্যাকআপ স্টোর থেকে মূল্যটি পুনরুদ্ধার করে তা নির্ধারণ করে। পাশাপাশি ক্যাচিং ক্যাশ-সাইড ক্যাশিং সম্ভবত সবচেয়ে সাধারণ ক্যাশিং কৌশল আপনি সম্মুখীন হবে. যখন একটি ক্যাশ হিট হয়, ডেটা অ্যাক্সেস ল্যাটিনতা যোগাযোগের ল্যাটিনতা দ্বারা dominated হয়, যা সাধারণত ছোট, আপনি একটি ক্যাশ কাছাকাছি পেতে পারেন একটি ক্যাশ সার্ভার বা এমনকি আপনার অ্যাপ্লিকেশন মেমরি স্থান। যাইহোক, যখন একটি ক্যাশ মিস হয়, ক্যাশ-সাইড ক্যাশিংয়ের সাথে, ক্যাশটি অ্যাপ্লিকেশন দ্বারা আপডেট করা একটি প্যাসিভ স্টোর হয়. অর্থাৎ, ক্যাশটি কেবল একটি মিস রিপোর্ট করে এবং অ্যাপ্লিকেশন ব্যাকআপ স্টোর থেকে ডেটা সংগ্রহ এবং ক্যাশ আপডেট করার জন্য দায়ী। চিত্র 1 কার্যকলাপে ক্যাশ-সাইড ক্যাশিংয়ের একটি উদাহরণ দেখায়. An application looks up a value from a cache by a caching key, which determines the data the application is interested in. যদি চাবি ক্যাশে থাকে তবে ক্যাশটি চাবির সাথে সংযুক্ত মূল্য ফেরত দেয়, যা অ্যাপ্লিকেশন ব্যবহার করতে পারে. তবে, যদি চাবি অস্তিত্ব না থাকে বা ক্যাশে মেয়াদ শেষ হয়, তাহলে আমাদের একটি ক্যাশ মিস আছে, যা অ্যাপ্লিকেশনের পরিচালনা করতে হবে. অ্যাপ্লিকেশন ব্যাকিং স্টোর থেকে মূল্যটি অনুরোধ করে এবং মূল্যটি ক্যাশে সংরক্ষণ করে। ধারণা করা যাক আপনি ব্যবহারকারীর তথ্য ক্যাশিং করছেন এবং ব্যবহারকারীর আইডিটি অনুসন্ধান কী হিসাবে ব্যবহার করছেন। এই ক্ষেত্রে, অ্যাপ্লিকেশনটি ব্যবহারকারীর আইডি দ্বারা ব্যবহারকারীর তথ্যটি ডাটাবেস থেকে পড়ার জন্য একটি অনুসন্ধান পরিচালনা করে। ডাটাবেস থেকে ফেরত আসা ব্যবহারকারীর তথ্যটি তারপর একটি ফরম্যাটে রূপান্তরিত হয় যা আপনি ক্যাশে সংরক্ষণ করতে পারেন। ক্যাশ-সাইড ক্যাশিং জনপ্রিয় কারণ এটি রিডিসের মতো একটি ক্যাশ সার্ভার সেট আপ করা সহজ এবং এটি ডাটাবেস চাহিদা এবং পরিষেবা প্রতিক্রিয়া ক্যাশ করার জন্য ব্যবহার করা সহজ। ক্যাশ-সাইড ক্যাশিংয়ের সাথে, ক্যাশ সার্ভার প্যাসিভ হয় এবং আপনি কোন ডাটাবেসটি ব্যবহার করেন বা ফলাফলগুলি ক্যাশে ম্যাপ করা হয় তা জানতে হবে না। অনেক ক্ষেত্রে, ক্যাশ-সাইড ক্যাশিং অ্যাপ্লিকেশন ল্যাটিনতা হ্রাস করার একটি সহজ এবং কার্যকর উপায়। আপনি আপনার অ্যাপ্লিকেশনের কাছাকাছি একটি ক্যাশ সার্ভারে সবচেয়ে প্রাসঙ্গিক তথ্য থাকার দ্বারা ডাটাবেস অ্যাক্সেস ল্যাটিনতা লুকাতে পারেন। উদাহরণস্বরূপ, যদি আপনার একই সময়ে একাধিক পাঠক থাকে যা ক্যাশে একটি কী খুঁজছে, তবে আপনাকে আপনার অ্যাপ্লিকেশনে সমন্বয়যোগ্য ক্যাশ মিসগুলি কীভাবে পরিচালনা করবেন তা সমন্বয় করতে হবে; অন্যথায়, আপনি একাধিক ডাটাবেস অ্যাক্সেস এবং ক্যাশ আপডেটগুলি পেতে পারেন, যা পরবর্তী ক্যাশ অনুসন্ধানগুলি বিভিন্ন মান ফেরত দিতে পারে। যাইহোক, ক্যাশ-সাইড ক্যাশিংয়ের সাথে, আপনি লেনদেন সমর্থন হারাবেন কারণ ক্যাশ এবং ডাটাবেস একে অপরকে চিনতে না, এবং এটি অ্যাপ্লিকেশনের দায়িত্ব ডেটা আপডেট সমন্বয় করা. অবশেষে, ক্যাশ-সাইড ক্যাশিং গুরুত্বপূর্ণ ক্যাশ লেনদেন হতে পারে কারণ কিছু ক্যাশ অনুসন্ধান ক্যাশ হ্রাসে ডাটাবেসটি পড়ার লেনদেন অনুভব করে. যেটি হল, যদিও ক্যাশ হ্রাসের ক্ষেত্রে, অ্যাক্সেস লেনদেন দ্রুত হয় কারণ এটি কাছাকাছি ক্যাশ সার্ভার থেকে আসে; ক্যাশ অনুসন্ধান যা ক্যাশ হ্রাস Caching এর মাধ্যমে Read-through caching একটি কৌশল যেখানে, ক্যাশ-সাইড ক্যাশের বিপরীতে, ক্যাশ একটি সক্রিয় উপাদান যখন একটি ক্যাশ মিস হয়. যখন একটি ক্যাশ মিস হয়, একটি Read-through cache স্বয়ংক্রিয়ভাবে ব্যাকআপ স্টোর থেকে একটি মূল্য পড়ার চেষ্টা করে. ল্যাটেনশন ক্যাশ-সাইড ক্যাশের মত, যদিও ব্যাকআপ স্টোর পুনরুদ্ধার ল্যাটেনশন ক্যাশ থেকে ব্যাকআপ স্টোর থেকে নয়, অ্যাপ্লিকেশন থেকে ব্যাকআপ স্টোর থেকে, যা আপনার বিতরণ আর্কিটেকচার উপর নির্ভর করে ছোট হতে পারে। চিত্র 2 একটি কার্যকলাপে একটি পড়া-পরিবর্তন ক্যাশের উদাহরণ দেখায়. অ্যাপ্লিকেশনটি একটি ক্যাশ অনুসন্ধান করে এবং যদি একটি ক্যাশ মিস হয়, তাহলে ক্যাশটি ক্যাশের জন্য মূল্যটি পেতে ডাটাবেসে একটি পাঠ করে। Read-through caching আরো জটিলভাবে বাস্তবায়ন করা হয় কারণ একটি ক্যাশকে ব্যাকআপ স্টোর পড়তে সক্ষম হতে হবে, তবে এটি ব্যাকআপ স্টোরের জন্য একটি ফরম্যাটে ডাটাবেস ফলাফল রূপান্তর করতে হবে. উদাহরণস্বরূপ, যদি ব্যাকআপ স্টোর একটি এসকিউএল ডাটাবেস সার্ভার হয়, তাহলে আপনাকে ফলাফলগুলি একটি JSON বা অনুরূপ ফরম্যাটে রূপান্তর করতে হবে যাতে ফলাফলগুলি ক্যাশে সংরক্ষণ করা যায়। যাইহোক, কারণ ক্যাশ আপডেটগুলি সমন্বয় করে এবং ডাটাবেসটি পড়ার মাধ্যমে ক্যাশিং করে, এটি অ্যাপ্লিকেশনের জন্য লেনদেনের গ্যারান্টি প্রদান করতে পারে এবং একই সময়ে ক্যাশের অভাবগুলির উপর সামঞ্জস্য নিশ্চিত করতে পারে। অবশ্যই, রেকর্ড দীর্ঘস্থায়ীতার একই সতর্কবাণীটি পড়ার মাধ্যমে ক্যাশগুলির ক্ষেত্রে প্রযোজ্য, যেমন তারা ক্যাশ-সাইড ক্যাশিংয়ের ক্ষেত্রে প্রযোজ্য। একটি ব্যতিক্রম: সক্রিয় উপাদান হিসাবে, পড়ার মাধ্যমে ক্যাশগুলি দীর্ঘস্থায়ীতাকে ভালভাবে লুকিয়ে রাখতে পারে, উদাহরণস্বরূপ, আপগ্রেড-পরিবর্তন ক্যাশিংয়ের সাথে। ক্যাশিং এর মাধ্যমে Cache-side এবং read-through caching ক্যাশিং পড়ার চারপাশে ক্যাশিং ক্যাশিং কৌশল, কিন্তু কখনও কখনও, আপনি ক্যাশিং লিখার সমর্থন করতে চান। এই ক্ষেত্রে, ক্যাশিং একটি অ্যাপ্লিকেশনের আবেদন করতে পারে যে একটি কী মান আপডেট করার জন্য একটি ইন্টারফেস সরবরাহ করে। ক্যাশিং-side caching ক্ষেত্রে, অ্যাপ্লিকেশন একমাত্র ব্যক্তি ব্যাকিং স্টোর সঙ্গে যোগাযোগ করে এবং, এইভাবে, ক্যাশ আপডেট করে। যাইহোক, read-through caching এর সাথে কাজ করার জন্য দুটি বিকল্প রয়েছে: write-through এবং write-behind caching। লেখার মাধ্যমে ক্যাশিং এমন একটি কৌশল যেখানে ক্যাশে একটি আপডেট অবিলম্বে ব্যাকআপ স্টোরে প্রচারিত হয়। যখনই একটি ক্যাশ আপডেট করা হয়, ক্যাশটি সিন্কেলভাবে ক্যাশে মূল্যের সাথে ব্যাকআপ স্টোর আপডেট করে। লেখার মাধ্যমে ক্যাশের লেখার দীর্ঘস্থায়ীতা ব্যাকআপ স্টোরে লেখার দীর্ঘস্থায়ী দ্বারা নিয়ন্ত্রিত হয়, যা উল্লেখযোগ্য হতে পারে। চিত্র 3 এ দেখানো হিসাবে, একটি অ্যাপ্লিকেশন একটি ক্যাশকে একটি কী এবং একটি মান জুড়ির সাথে ক্যাশ দ্বারা সরবরাহ করা ইন্টারফেস ব্যবহার করে আপডেট করে। ক্যাশ নতুন মানের সাথে তার অবস্থা আপডেট করে, নতুন মানের সাথে লেখার মাধ্যমে ক্যাশিংটি ক্যাশ এবং ব্যাকআপিং স্টোরেজকে সমন্বিত রাখার উদ্দেশ্য করে। যাইহোক, অ-ট্রান্সেকশনাল ক্যাশের জন্য, ক্যাশ এবং ব্যাকআপিং স্টোরেজগুলি ত্রুটিগুলির উপস্থিতিতে সমন্বিত হতে পারে। উদাহরণস্বরূপ, যদি লেখার জন্য ক্যাশে সফল হয় তবে লেখার জন্য ব্যাকআপিং স্টোরেজে ব্যর্থ হয়, দুটিই সমন্বিত হবে। একটি পড়ার মাধ্যমে ক্যাশের মতো, লেখার মাধ্যমে ক্যাশিং অনুমান করে যে ক্যাশটি ডাটাবেসের সাথে সংযুক্ত হতে পারে এবং একটি ক্যাশ মানকে একটি ডাটাবেস অনুরোধে রূপান্তর করতে পারে. উদাহরণস্বরূপ, যদি আপনি ব্যবহারকারীর ডেটা ক্যাশ করছেন যেখানে ব্যবহারকারীর আইডি কী হিসাবে কাজ করে এবং একটি JSON ডকুমেন্ট মূল্যকে প্রতিনিধিত্ব করে, তাহলে ক্যাশটি ব্যবহারকারীর তথ্যের JSON প্রতিনিধিত্বকে একটি ডাটাবেস আপডেটে রূপান্তর করতে সক্ষম হতে হবে. লেখার মাধ্যমে ক্যাশিংয়ের সাথে, সবচেয়ে সহজ সমাধানটি প্রায়ই ডাটাবেসে JSON সংরক্ষণ করা হয়. লেখার মাধ্যমে ক্যাশিংয়ের প্রধান অসুবিধাটি ক্যাশ আপডেটগুলির সাথে সংযুক্ত ল্যাটেনশন, যা মূলত ডাটাবেস কম্পম ল্যাটেনশন সমান। ক্যাচিং এর পেছনে লেখার পেছনে ক্যাশিং কৌশল অবিলম্বে ক্যাশ আপডেট করে, লেখার পেছনে ক্যাশিং এর বিপরীতে, যা ডাটাবেস আপডেটগুলি অতিক্রম করে। একটি লেখার পেছনে ক্যাশের লেখার দীর্ঘতা লেখার পেছনে ক্যাশের তুলনায় কম কারণ ব্যাকিং স্টোর অ্যাসিন্রোনালভাবে আপডেট করা হয়। অর্থাৎ, ক্যাশটি অ্যাপ্লিকেশনের সাথে অবিলম্বে লেখার স্বীকৃতি করতে পারে, যাতে কম দীর্ঘায়িত লেখার ফলাফল হয়, এবং তারপর ব্যাকিং স্টোর আপডেটটি ব্যাকিং স্টোরে সম্পন্ন করে। যাইহোক, লেখার পেছনে ক্যাশিংয়ের অসুবিধা হল আপনি ট্রান্সান্সমিশন সমর্থন হারাচ্ছেন কারণ ক্যাশটি আর ক্যাশ এবং ডাটাবেসের সমন্বয় নিশ্চিত করতে পারবে না। এছাড়াও, লেখার পেছনে ক্যাশিং গ্রাহক সাইড ক্যাশিং একটি ক্লায়েন্ট সাইড ক্যাশিং কৌশল মানে আপনার অ্যাপ্লিকেশনের মধ্যে ক্লায়েন্ট স্তরের ক্যাশিং আছে. যদিও Redis যেমন ক্যাশিং সার্ভার ইন্ড মেমরি ক্যাশিং ব্যবহার করে, অ্যাপ্লিকেশনটি Redis প্রোটোকল মাধ্যমে ক্যাশ অ্যাক্সেস করার জন্য নেটওয়ার্কে যোগাযোগ করতে হবে. যদি অ্যাপ্লিকেশন একটি ডাটা সেন্টারে চলমান একটি পরিষেবা হয়, তাহলে একটি ক্যাশ সার্ভার ক্যাশিংয়ের জন্য চমৎকার কারণ একটি ডাটা সেন্টারে নেটওয়ার্ক ঘূর্ণন দ্রুত, এবং ক্যাশের জটিলতা ক্যাশ নিজেই। ক্লায়েন্ট পক্ষের ক্যাশিংয়ের সাথে, পড়া-পরিবর্তন এবং লিখা-পরিবর্তন ক্যাশিংয়ের একটি সংমিশ্রণ দীর্ঘমেয়াদি দৃষ্টিভঙ্গি থেকে অপ্টিমাইজড হয় কারণ উভয়ই পড়া এবং লিখা দ্রুত হয়. অবশ্যই, আপনার ক্লায়েন্ট সাধারণত ডাটাবেসের সাথে সরাসরি সংযোগ করতে সক্ষম হবে না, কিন্তু পরিবর্তে একটি প্রক্সি বা API সার্ভারের মাধ্যমে বহিরাগতভাবে ডাটাবেস অ্যাক্সেসের স্তর এবং দীর্ঘমেয়াদি কারণে ক্যাশিং ক্লায়েন্ট পক্ষের লেনদেন নিশ্চিত করা কঠিন করে তোলে। অনেক অ্যাপ্লিকেশনের জন্য যারা কম দীর্ঘস্থায়ী ক্লায়েন্ট-সাইড ক্যাশিং প্রয়োজন, রিপ্লিকেশনের জন্য স্থানীয়-প্রথম পদ্ধতিটি আরো কার্যকরী হতে পারে। কিন্তু সহজ পড়া ক্যাশিংয়ের জন্য, ক্লায়েন্ট-সাইড ক্যাশিং কম দীর্ঘস্থায়ী অর্জন করার জন্য একটি ভাল সমাধান হতে পারে। বিতরণ ক্যাশিং ইতিমধ্যে, আমরা শুধুমাত্র ক্যাশিং সম্পর্কে আলোচনা করেছি যেন একটি একক ক্যাশ ইন্সটিউট থাকে। উদাহরণস্বরূপ, আপনি একটি অ্যাপ্লিকেশন ক্যাশ বা একটি একক Redis সার্ভার ব্যবহার করে একটি PostgreSQL ডাটাবেস থেকে চাহিদাগুলি ক্যাশ করতে পারেন। এই ধরনের বিতরণকৃত ক্যাশিংয়ের সাথে, আপনার অনেকগুলি ক্যাশের উদাহরণ রয়েছে যা স্বাধীনভাবে বা একটি ক্যাশ গ্রুপে কাজ করে। বিতরণকৃত ক্যাশিংয়ের সাথে, আপনাকে একই জটিলতা এবং বিবেচনাগুলির অনেকগুলি রয়েছে যেমনটি পুনরাবৃত্তি এবং পার্টিশনিং সম্পর্কে চাবিকাঠি 5 এ আলোচনা করা হয়েছে। বিতরণকৃত ক্যাশিংয়ের সাথে, আপনি প্রতিটি উদাহরণে সমস্ত ক্যাশড ডেটা রাখতে চান না, বরং নোডগুলির মধ্যে বিভক্ত ক্যাশড ডেটা রাখতে চান। একইভাবে, আপনি উচ্চ উপলব্ধতা এবং কম অ্যাক্সেস ল্যাটিনেশনের জন্য একাধিক উদাহরণে পার্টিশনগুলি পুন মোটামুটি, বিতরণকৃত ক্যাশিং ক্যাশিং, পার্টিশন এবং পুনর্গঠনের সুবিধা এবং সমস্যাগুলির একটি সীমানা, তাই আপনি যদি এর সাথে যাচ্ছেন তবে সাবধান থাকুন। *আপনি পড়াশোনা চালিয়ে যাওয়ার জন্য, ScyllaDB থেকে বা . বিনামূল্যে ডাউনলোড 3 Chapter Latency Excerpt ম্যানিং এর সম্পূর্ণ বই কিনুন সিনথিয়া ডানলপ Cynthia ScyllaDB এর সামগ্রী কৌশল সিনিয়র ডিরেক্টর এবং 20+ বছর ধরে সফটওয়্যার ডেভেলপমেন্ট এবং গুণমান প্রকৌশল সম্পর্কে লিখেছেন।
