তিন স্তরের স্থাপত্যের ভূমিকা
থ্রি-টায়ার আর্কিটেকচার হল ইন্টারনেটে সবচেয়ে সাধারণ ইন্টারঅ্যাকশন আর্কিটেকচার। এটি উপস্থিত হয়েছিল যখন দ্বি-স্তরের সার্ভার অংশটি দুটি অংশে বিভক্ত ছিল: একটি লজিক স্তর এবং একটি ডেটা স্তর ।
এটি এই মত কিছু দেখাচ্ছিল:
ক্লায়েন্ট লেয়ার হল "ডিস্ট্রিবিউটেড অ্যাপ্লিকেশানের" অংশ যা ব্যবহারকারীর মিথস্ক্রিয়ার জন্য দায়ী। এই স্তরটিতে ব্যবসায়িক যুক্তি থাকা উচিত নয় এবং সমালোচনামূলক ডেটা সংরক্ষণ করা উচিত নয়। এছাড়াও, এটি সরাসরি ডাটাবেস স্তরের সাথে যোগাযোগ করা উচিত নয়, তবে শুধুমাত্র ব্যবসায়িক যুক্তি স্তরের মাধ্যমে।
যাইহোক, এখানে এখনও কিছু যুক্তি আছে। প্রথমত, এটি ইন্টারফেসের মাধ্যমে ব্যবহারকারীর সাথে মিথস্ক্রিয়া, তার দ্বারা প্রবেশ করা ডেটার বৈধতা, স্থানীয় ফাইলগুলির সাথে কাজ। এটি সার্ভারের সাথে কাজ করার সময় ব্যবহারকারীর অনুমোদন এবং ডেটা এনক্রিপশন সম্পর্কিত সবকিছু অন্তর্ভুক্ত করে।
দ্বিতীয়ত, এটি একটি সহজ ব্যবসায়িক যুক্তি। উদাহরণস্বরূপ, যদি একটি অনলাইন স্টোর পণ্যগুলির একটি তালিকা পাঠায়, আমরা সেগুলিকে ক্লায়েন্টের দিকে সাজাতে এবং ফিল্টার করতে পারি। এবং আদিম ডেটা সঞ্চয়স্থানও এখানে রয়েছে: ক্যাশিং, লগ-ইন ব্যবহারকারী কুকিজ এবং এর মতো।
ব্যবসায়িক যুক্তি স্তরটি দ্বিতীয় স্তরে অবস্থিত, বেশিরভাগ ব্যবসায়িক যুক্তি এটিতে কেন্দ্রীভূত। এর বাইরে, ক্লায়েন্টে রপ্তানি করা হয় এমন টুকরোগুলি, সেইসাথে ডাটাবেসে নিমজ্জিত লজিক উপাদান (সঞ্চিত পদ্ধতি এবং ট্রিগার) অবশিষ্ট থাকে।
ব্যবসায়িক লজিক সার্ভারের একটি খুব অংশে শুধুমাত্র এই একই যুক্তি থাকে না, তবে স্কেলিং সমস্যাগুলিও সমাধান করে: কোডটি অংশে বিভক্ত এবং বিভিন্ন সার্ভারে বিতরণ করা হয়। কিছু উচ্চ চাহিদাযুক্ত পরিষেবা কয়েক ডজন সার্ভারে চলতে পারে। তাদের মধ্যে লোড লোড ব্যালেন্সার দ্বারা পরিচালিত হয়।
সার্ভার অ্যাপ্লিকেশনগুলি সাধারণত এমনভাবে ডিজাইন করা হয় যাতে সার্ভারের অন্য একটি অনুলিপি সহজেই চালু করা যায় এবং এটির অন্যান্য অনুলিপিগুলির সাথে সহযোগিতায় কাজ শুরু করা যায়। অর্থাৎ, এমনকি সার্ভার কোড লেখার প্রক্রিয়ার মধ্যেও, আপনি কখনই গ্যারান্টি পাবেন না যে আপনার স্ট্যাটিক ক্লাস একটি একক উদাহরণে চালু হয়েছে।
ডেটা স্তরটি ডেটা সঞ্চয়স্থান সরবরাহ করে এবং একটি পৃথক স্তরে স্থাপন করা হয়, একটি নিয়ম হিসাবে, ডাটাবেস ম্যানেজমেন্ট সিস্টেম (DBMS) এর মাধ্যমে প্রয়োগ করা হয়, শুধুমাত্র অ্যাপ্লিকেশন সার্ভার স্তর থেকে এই উপাদানটির সাথে সংযোগ প্রদান করা হয়।
ডেটা স্তর আলাদা করার কারণ
একটি পূর্ণাঙ্গ তৃতীয় স্তরে ডেটা স্তরের বিভাজন অনেক কারণে ঘটেছে, তবে প্রধানটি হল সার্ভারে বর্ধিত লোড।
প্রথমত, ডেটাবেসগুলি ডেটা প্রক্রিয়াকরণের জন্য প্রচুর মেমরি এবং প্রসেসরের সময় প্রয়োজন হতে শুরু করে। অতএব, তারা আলাদা সার্ভারে সর্বত্র স্থাপন করা শুরু করে।
বর্ধিত লোডের সাথে, ব্যাকএন্ড সহজেই সদৃশ হতে পারে এবং একটি সার্ভারের দশটি কপি উত্থাপন করা যেতে পারে, তবে ডাটাবেসটি নকল করা অসম্ভব - ডাটাবেসটি এখনও সিস্টেমের একটি একক এবং অবিভাজ্য উপাদান রয়ে গেছে।
দ্বিতীয়ত, ডেটাবেসগুলি স্মার্ট হয়ে উঠেছে - তাদের নিজস্ব ব্যবসায়িক যুক্তি রয়েছে। তারা সঞ্চিত পদ্ধতি, ট্রিগার, তাদের নিজস্ব ভাষা যেমন PLSQL সমর্থন করতে শুরু করে। এমনকি প্রোগ্রামাররা হাজির যারা কোড লিখতে শুরু করে যা ডিবিএমএসের ভিতরে চলে।
সমস্ত যুক্তি যা ডেটার সাথে আবদ্ধ ছিল না তা ব্যাকএন্ডে নিয়ে যাওয়া হয়েছিল এবং কয়েক ডজন সার্ভারে সমান্তরালভাবে চালু করা হয়েছিল। ডেটার সাথে সমালোচনামূলকভাবে আবদ্ধ সমস্ত কিছুই DBMS-এর অভ্যন্তরে রয়ে গেছে এবং সেখানে ইতিমধ্যে বর্ধিত লোডের সমস্যাগুলি আমাদের নিজস্ব পদ্ধতি ব্যবহার করে সমাধান করতে হয়েছিল:
- একটি ডাটাবেস ক্লাস্টার হল ডাটাবেস সার্ভারের একটি গ্রুপ যা একই ডেটা সঞ্চয় করে এবং একটি নির্দিষ্ট প্রোটোকল ব্যবহার করে সিঙ্ক্রোনাইজ করে।
- শেয়ারিং - ডেটা লজিক্যাল ব্লকে বিভক্ত এবং বিভিন্ন ডাটাবেস সার্ভারে বিতরণ করা হয়। এই পদ্ধতির সাথে ডাটাবেস পরিবর্তনগুলি বজায় রাখা খুব কঠিন।
- NoSQL পদ্ধতি হল ডাটাবেসগুলিতে ডেটা সংরক্ষণ করা যা বিপুল পরিমাণ ডেটা সঞ্চয় করার জন্য তৈরি করা হয়েছে। এগুলি প্রায়শই এমনকি ডাটাবেস নয়, তবে নির্দিষ্ট ফাইল স্টোরেজ। রিলেশনাল ডাটাবেসের তুলনায় খুব খারাপ কার্যকারিতা।
- ডেটা ক্যাশিং। ডাটাবেস স্তরে একটি সাধারণ ক্যাশের পরিবর্তে, সম্পূর্ণ ক্যাশিং ডিবিএমএস উপস্থিত হয়েছিল, যা ফলাফলটি কেবল মেমরিতে সংরক্ষণ করে।
এটা স্পষ্ট যে সার্ভার প্রযুক্তির এই চিড়িয়াখানা পরিচালনা করার জন্য পৃথক লোক এবং/অথবা সম্পূর্ণ দল প্রয়োজন ছিল, যার ফলে ডেটা স্তরটিকে একটি পৃথক স্তরে সরিয়ে দেওয়া হয়েছিল।
গুরুত্বপূর্ণ ! সমস্ত উন্নত প্রযুক্তির জন্ম হয় বৃহৎ আইটি কর্পোরেশনের গভীরতায়, যখন পুরানো পন্থা আর নতুন চ্যালেঞ্জ মোকাবেলা করে না। ডাটাবেসগুলিকে একটি পৃথক স্তরে তৈরি করা কোনও প্রোগ্রামার দ্বারা উদ্ভাবিত হয়নি, তবে ওরাকল বা আইবিএম-এর গভীরতায় কোথাও একদল প্রকৌশলী দ্বারা উদ্ভাবিত হয়েছিল।
মজাদার! জুকারবার্গ যখন ফেসবুক লিখতে শুরু করেন, তখন তিনি কেবল পিএইচপি + মাইএসকিউএল-এ কাজ করতেন। যখন লক্ষ লক্ষ ব্যবহারকারী ছিল, তারা একটি বিশেষ অনুবাদক লিখেছিল যেটি সমস্ত পিএইচপি কোড C++-এ অনুবাদ করেছিল এবং এটিকে নেটিভ মেশিন কোডে কম্পাইল করেছিল।
এছাড়াও, MySQL কোটি কোটি ব্যবহারকারীর ডেটা সংরক্ষণ করতে সক্ষম নয়, তাই Facebook NoSQL ডাটাবেসের ধারণা তৈরি করেছে এবং একটি শক্তিশালী সার্ভার-সাইড NoSQL DBMS - Cassandra লিখেছে। যাইহোক, এটি সম্পূর্ণরূপে জাভাতে লেখা।
অ্যাপ্লিকেশন যুক্তি অবস্থান অস্পষ্টতা
এবং যদিও একটি তিন-স্তরের স্থাপত্য প্রায় দ্ব্যর্থহীনভাবে এর অংশগুলির মধ্যে ভূমিকাগুলি বন্টন করে, তবে সিস্টেমে ব্যবসায়িক যুক্তির একটি নতুন অংশ (নতুন কোড) যোগ করা দরকার ঠিক কোথায় তা সঠিকভাবে নির্ধারণ করা সবসময় সম্ভব নয়।
এই ধরনের অস্পষ্টতার একটি উদাহরণ নীচের ছবিতে দেখানো হয়েছে:
সার্ভারের অংশটি একটি ধূসর পটভূমিতে পূর্ণ, ক্লায়েন্ট অংশটি সাদা দিয়ে পূর্ণ। পরবর্তী পদ্ধতির একটি ভাল উদাহরণ (অনেক ডানে) আধুনিক মোবাইল অ্যাপস। ক্লায়েন্ট সাইডে (ফোনে) ভিউ (ডিসপ্লে), লজিক এবং ডেটা থাকে। এবং শুধুমাত্র কখনও কখনও এই ডেটা সার্ভারের সাথে সিঙ্ক্রোনাইজ করা হয়।
বামদিকের বিকল্পের একটি উদাহরণ হল একটি সাধারণ পিএইচপি সার্ভার, যার সার্ভারে সমস্ত যুক্তি রয়েছে এবং এটি ক্লায়েন্টকে ইতিমধ্যেই স্ট্যাটিক HTML দেয়। এই দুটি চরমের মধ্যে কোথাও, আপনার প্রকল্পটি অবস্থিত হবে।
কাজের শুরুতে, আপনি প্রকল্পের সাথে পরিচিত হওয়ার পরে, আপনাকে এটিতে কাজ করা প্রোগ্রামারদের সাথে পরামর্শ করতে হবে, সেই জায়গাগুলি সম্পর্কে যেখানে পরবর্তী কাজের যুক্তি প্রয়োগ করা আপনার পক্ষে ভাল।
তা করতে নির্দ্বিধায়। প্রথমত, তারা তাদের সনদ নিয়ে অন্য কারও মঠে আরোহণ করে না। দ্বিতীয়ত, প্রত্যেকের জন্য (এবং আপনারও) আপনার প্রয়োজনীয় কোডটি খুঁজে পাওয়া সহজ হবে যেখানে আপনি এটি খুঁজে পাওয়ার আশা করছেন৷