মেমক্যাচ ব্যবহার: ডাটাবেস আপডেট করার সময় ক্যাশে আপডেট করা কি ভাল অনুশীলন?


13

এই প্রশ্নটি স্থাপত্যের সেরা অভ্যাসগুলি সম্পর্কে।

আমাদের বর্তমান আর্কিটেকচার

আমার একটি পিএইচপি ক্লাস রয়েছে যা ব্যবহারকারীর তথ্যের জন্য মাইএসকিউএল অ্যাক্সেস করে। এটি কল করুন UserUserবহুবার অ্যাক্সেস করা হয়েছে, তাই আমরা লোড হ্রাস করতে ক্যাশে স্তরগুলি প্রয়োগ করেছি।

প্রথম স্তরটি আমরা "প্রতি অনুরোধ" ক্যাশে বলি। মাইএসকিউএল থেকে ডেটা পুনরুদ্ধার করার পরে, আমরা একটি ব্যক্তিগত সম্পত্তিতে ডেটা সংরক্ষণ করি User। তথ্যের জন্য পরবর্তী কোনও অনুরোধ মাইএসকিউএল থেকে ডেটা পুনরায় অনুরোধ করার পরিবর্তে সম্পত্তিটি ফেরত দেয়।

যেহেতু ওয়েব অনুরোধটি প্রতি অনুরোধের ভিত্তিতে বেঁচে থাকে এবং মারা যায়, এই ক্যাশেটি কেবলমাত্র একক অনুরোধে অ্যাপ্লিকেশনটিকে মাইএসকিউএল অ্যাক্সেস করতে বাধা দেয়।

আমাদের দ্বিতীয় স্তরটি মেমক্যাচড। যখন ব্যক্তিগত সম্পত্তি খালি থাকে, আমরা প্রথমে ডেটার জন্য মেমক্যাচড চেক করি। মেমক্যাচড ফাঁকা থাকলে আমরা ডেটাগুলির জন্য মাইএসকিউএলকে জিজ্ঞাসা করি, মেমক্যাচ আপডেট করি এবং এর ব্যক্তিগত সম্পত্তি আপডেট করি User

প্রশ্নটি

আমাদের অ্যাপ্লিকেশনটি একটি গেম, এবং কখনও কখনও এটি আবশ্যক হয় যে কিছু ডেটা যতটা সম্ভব আপ টু ডেট। প্রায় পাঁচ মিনিটের ব্যবধানে, ব্যবহারকারীর ডেটা পড়ার অনুরোধটি 10 ​​বা 11 বার হতে পারে; তারপরে একটি আপডেট হতে পারে। পরবর্তী পড়ার অনুরোধগুলি আপ টু ডেট হওয়া বা গেম মেকানিক্স ব্যর্থ হওয়া দরকার।

সুতরাং, আমরা যা করেছি তা হ'ল একটি টুকরো কোড প্রয়োগ করে যা এক্সপ্লোর করা হয় যখন একটি ডাটাবেস আপডেট ঘটে। এই কোডটি আপডেট হওয়া ডেটা সহ মেমচেডে কীটি সেট করে, তাই মেমকেচেড পরবর্তী সমস্ত অনুরোধগুলি আপ টু ডেট।

এটি কি সর্বোত্তম? এই জাতীয় "লিভিং ক্যাশে" বাছাই করার চেষ্টা করার সময় কি কোনও পারফরম্যান্স উদ্বেগ বা অন্যান্য "গোটচস" রয়েছে সে সম্পর্কে আমাদের সচেতন হওয়া উচিত?


এটি মুছে ফেলার এবং ডেটা পুনরায় যুক্ত করার সাথে কী করার আছে?
মাইক নাকিস

প্রশ্নের শিরোনাম স্পষ্ট করে দিয়েছি।
স্টিফেন

কেন কেবল ক্যাশেড ডেটা শেষ হবে না? এটি আপডেট করার অর্থ হ'ল আপনাকে আপডেটটি বজায় রাখা নিশ্চিত করা দরকার (যাতে নতুন উপায়ে যদি এভাবে আপডেট করা দরকার হয় তবে আপনাকে আপডেটটি পরিবর্তন করতে হবে)। ক্যাশে মেয়াদ শেষ হওয়ার অর্থ হ'ল ডেটাবেস থেকে নতুন কিছু টানা হয় --- এবং কোনও নতুন আপডেটের আপডেটিং কোডে নতুন পরিবর্তন দরকার হয় না। নেতিবাচক দিকটি হ'ল ডেটাবেস লোড বেশি হতে পারে।
পিটার কে।

@ পিটার হ্যাঁ, আমরা সে সম্পর্কেও ভেবেছিলাম। যদি আমাদের বর্তমান পদ্ধতির সাথে অন্য কোনও সমস্যা না আসে তবে আমরা এটির সাথে থাকব। অন্যথায় আমরা আপনার বর্ণনার সাথে যেতে পারি।
স্টিফেন

1
@ স্টেফেন আপনি যে পদ্ধতির বর্ণনা করেছেন তাকে "লিখনের মাধ্যমে ক্যাচ" বলা হয় এবং এটি মোটামুটি সাধারণ পদ্ধতি।
শ্রীপাঠি কৃষ্ণন

উত্তর:


10

আমার প্রস্তাবনাটি হ'ল আপনার ব্যবহারের প্রোফাইল এবং ক্যাশের জন্য আপনার প্রয়োজনীয়তাগুলি দেখুন।

আপনি বাসী ডেটা মেমচেডে রেখে যাবেন এমন কোনও কারণ আমি দেখতে পাচ্ছি না। আমি মনে করি আপনি সঠিক পন্থাটি বেছে নিয়েছেন যেমন: ডিবি আপডেট করুন।

যাই হোক না কেন, আপনার আপনার ডিবি আপডেটে একটি মোড়কের দরকার হবে (যা আপনি করেছেন)। ডিবি এবং ইন-র‍্যামে ব্যবহারকারী আপডেট করার জন্য আপনার কোডটি ম্যাকাকেচেড, বা ম্যাকচেডের একটি মেয়াদ শেষ হওয়া উচিত।

উদাহরণস্বরূপ - যদি আপনার ব্যবহারকারীরা লগ অফের অংশ হিসাবে সাধারণত প্রতি সেশনে একবার আপডেট করে থাকেন তবে ক্যাশে ডেটা আপডেট করার মতো কোনও পয়েন্ট নেই (যেমন উচ্চ স্কোর মোট) - আপনার সরাসরি এটির মেয়াদ শেষ হয়ে যাবে।

তবে তারা যদি ডেটা আপডেট করতে চলেছে (যেমন বর্তমান গেমের অবস্থা) এবং তার পরে 0.2 সেকেন্ড পরে আপনার কাছে একটি তাত্ক্ষণিক পিএইচপি পৃষ্ঠা হিট হবে যা ডেটা অনুরোধ করতে চলেছে, আপনি এটি ক্যাশে তাজা চাইবেন।


3

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

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

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

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

আমি যা করব না, কোনও পরিস্থিতিতে ক্যাশে পূরণ করার জন্য একটি অতিরিক্ত পদ্ধতি যুক্ত করা হয়েছে, তারপরে আপনাকে দুটি জায়গায় কল (এবং এপিআই হুক ইত্যাদি) বজায় রাখতে হবে।

গ্যাটাচাসের ক্ষেত্রে, আপনি সরাসরি ক্যাশে লিখছেন কিনা সে সম্পর্কে আপনাকে অবশ্যই যত্নবান হওয়া দরকার is আপনার নীরব আপডেট করার সময় যদি অনেক থ্রেড পড়ার চেষ্টা করে তবে আপনার কিছু গুরুতর অবৈধ ডেটা সমস্যা হতে পারে, যা ডেটাটিকে প্রথম স্থানে রাখার চেষ্টা করার পয়েন্টকে পরাস্ত করবে।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.