আপনার ক্যাশিং সমাধান কখনও লিখবেন না

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

গুরুত্বপূর্ণ ! আপনার নিজের ক্যাশিং সমাধান কখনই লিখবেন না। এই টাস্কে এমন অনেক অসুবিধা রয়েছে যা আপনি স্বপ্নেও ভাবতে পারেননি।

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

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

এবং যেহেতু সবসময় মেমরির ঘাটতি থাকে, তাই ক্যাশে থেকে বস্তু মুছে ফেলার জন্য একটি কার্যকর কৌশল প্রয়োজন। এটি কিছুটা জাভাতে আবর্জনা সংগ্রহকারীর মতো। এবং যেমন আপনি মনে রাখবেন, কয়েক দশক ধরে সেরা মন প্রজন্মের দ্বারা বস্তু চিহ্নিত করার বিভিন্ন উপায় উদ্ভাবন করছে, ইত্যাদি।

সমস্যা 3 - বিভিন্ন কৌশল । অনুশীলন দেখায়, ক্যাশে সংরক্ষণ এবং আপডেট করার জন্য বিভিন্ন কৌশল বিভিন্ন বস্তুর জন্য কার্যকর। একটি দক্ষ ক্যাশিং সিস্টেম সমস্ত বস্তুর জন্য শুধুমাত্র একটি কৌশল করতে পারে না।

সমস্যা 4 - এর দক্ষ স্টোরেজ । আপনি শুধু ক্যাশে বস্তু সংরক্ষণ করতে পারবেন না. বস্তুতে প্রায়শই অন্যান্য বস্তুর উল্লেখ থাকে, ইত্যাদি।

অতএব, বস্তুগুলিকে নিজেরাই সংরক্ষণ করার পরিবর্তে, কখনও কখনও তাদের আদিম ক্ষেত্রগুলির মানগুলি সংরক্ষণ করা অনেক বেশি কার্যকর। এবং তাদের উপর ভিত্তি করে দ্রুত বস্তু নির্মাণের জন্য সিস্টেম।

ফলস্বরূপ, আপনি মেমরিতে একটি সম্পূর্ণ ভার্চুয়াল ডিবিএমএস পাবেন, যা দ্রুত কাজ করবে এবং সামান্য মেমরি ব্যবহার করবে।

ডাটাবেস ক্যাশিং

জাভা প্রোগ্রামে সরাসরি ক্যাশিং ছাড়াও, ক্যাশিং প্রায়ই ডাটাবেসে সরাসরি সংগঠিত হয়।

চারটি বড় পন্থা রয়েছে:

প্রথম পন্থা হল ডাটাবেসকে অস্বাভাবিক করা । এসকিউএল সার্ভার মেমরিতে ডেটা সঞ্চয় করে যেভাবে টেবিলে সংরক্ষণ করা হয় তার থেকে ভিন্নভাবে।

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

দ্বিতীয় পদ্ধতি হল ক্যোয়ারী ক্যাশিং । এবং অনুসন্ধান ফলাফল.

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

এই পদ্ধতিটি এমন একজন মানুষের সাথে খুব কার্যকর হতে পারে যিনি প্রশ্নগুলি বিশ্লেষণ করতে পারেন এবং ডিবিএমএসকে কীভাবে তাদের ক্যাশে করা যায় তা বের করতে সাহায্য করতে পারেন।

তৃতীয় পদ্ধতি হল একটি ইন-মেমরি ডাটাবেস

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

উদাহরণ:

এপ্রোচ 4 - ডাটাবেস ক্লাস্টার । বেশ কিছু পঠন-পাঠন ঘাঁটি।

আরেকটি সমাধান হল একটি ক্লাস্টার ব্যবহার করা: একই ধরণের বেশ কয়েকটি ডিবিএমএসে অভিন্ন ডেটা থাকে। একই সময়ে, আপনি সমস্ত ডেটাবেস থেকে ডেটা পড়তে পারেন এবং শুধুমাত্র একটিতে লিখতে পারেন। যা পরে বাকি ডাটাবেসের সাথে সিঙ্ক্রোনাইজ করা হয়।

এটি একটি খুব ভাল সমাধান কারণ এটি কনফিগার করা সহজ এবং অনুশীলনে কাজ করে। সাধারণত, ডাটা পরিবর্তনের জন্য ডাটাবেসের একটি অনুরোধের জন্য, ডেটা পড়ার জন্য 10-100টি অনুরোধ আসে।

হাইবারনেটে ক্যাশিংয়ের ধরন

হাইবারনেট ক্যাশিংয়ের তিনটি স্তর সমর্থন করে:

  • সেশন লেভেলে ক্যাশিং (সেশন)
  • সেশনফ্যাক্টরি স্তরে ক্যাশিং
  • ক্যাশিং অনুরোধ (এবং তাদের ফলাফল)

আপনি এই ধরনের চিত্রের আকারে এই সিস্টেমটি উপস্থাপন করার চেষ্টা করতে পারেন:

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

আসুন অবিলম্বে নিম্নলিখিত উদাহরণ বিবেচনা করা যাক:

Employee director1 = session.get(Employee.class, 4);
Employee director2 = session.get(Employee.class, 4);

assertTrue(director1 == director2);

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

একই বস্তু মানে এমনকি বস্তুর উল্লেখ অভিন্ন হবে। এটা সত্যিই একই বস্তু.

save() , update() , saveOrUpdate() , load() , get() , list() , iterate() , এবং scroll() পদ্ধতি সর্বদা প্রথম স্তরের ক্যাশে ব্যবহার করবে। আসলে, যোগ করার আর কিছুই নেই।

দ্বিতীয় স্তরের ক্যাশিং

যদি প্রথম স্তরের ক্যাশে সেশন অবজেক্টের সাথে আবদ্ধ হয়, তাহলে দ্বিতীয় স্তরের ক্যাশে সেশন অবজেক্টের সাথে আবদ্ধ হয়।সেশনফ্যাক্টরি. যার মানে এই ক্যাশে বস্তুর দৃশ্যমানতা প্রথম স্তরের ক্যাশের তুলনায় অনেক বেশি।

উদাহরণ:

Session session = factory.openSession();
Employee director1 = session.get(Employee.class, 4);
session.close();

Session session = factory.openSession();
Employee director2 = session.get(Employee.class, 4);
session.close();

assertTrue(director1 != director2);
assertTrue(director1.equals(director2));

এই উদাহরণে, ডাটাবেসে দুটি প্রশ্ন করা হবে। হাইবারনেট অভিন্ন বস্তু ফিরিয়ে দেবে, কিন্তু এটি একই বস্তু হবে না - তাদের আলাদা উল্লেখ থাকবে।

দ্বিতীয় স্তরের ক্যাশে ডিফল্টরূপে নিষ্ক্রিয় করা হয় । অতএব, আমাদের ডাটাবেসে একটির পরিবর্তে দুটি প্রশ্ন রয়েছে।

এটি সক্রিয় করতে, আপনাকে hibernate.cfg.xml ফাইলে নিম্নলিখিত লাইনগুলি লিখতে হবে:

<property name="hibernate.cache.provider_class" value="net.sf.ehcache.hibernate.SingletEhCacheProvider"/>
<property name="hibernate.cache.use_second_level_cache" value="true"/>

দ্বিতীয়-স্তরের ক্যাশে সক্ষম করার পরে, হাইবারনেট আচরণ কিছুটা পরিবর্তন হবে:

Session session = factory.openSession();
Employee director1 = session.get(Employee.class, 4);
session.close();

Session session = factory.openSession();
Employee director2 = session.get(Employee.class, 4);
session.close();

assertTrue(director1 == director2);

এই সমস্ত ম্যানিপুলেশনের পরেই দ্বিতীয়-স্তরের ক্যাশে সক্রিয় করা হবে এবং উপরের উদাহরণে, ডাটাবেসের জন্য শুধুমাত্র একটি ক্যোয়ারী কার্যকর করা হবে।