কোনটি ভাল - ওরাকল বা রেডিস বা কীভাবে প্ল্যাটফর্মের পছন্দকে সমর্থন করা যায়

কাউকে সম্বোধন না করে সে জোরে জোরে বলল, "এটা দরকার।" - এটা প্রয়োজন! এটি ঠিক যা বলে: একটি কোম্পানির প্রধান কাজ হল শেয়ারহোল্ডারদের স্বার্থে লাভ করা। ভাল, এটা সম্পর্কে চিন্তা করুন! তারা কিছুতেই ভয় পায় না!

ইউলি দুবভ, "লেসার ইভিল"

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

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

প্রেরণা

আপনি যখন একটি শিক্ষামূলক প্রকল্প বা শখের প্রকল্প শুরু করেন, তখন একটি প্ল্যাটফর্ম বেছে নেওয়ার অনুপ্রেরণা খুব বৈচিত্র্যময় হতে পারে: "এটি এমন একটি প্ল্যাটফর্ম যা আমি সবচেয়ে ভাল জানি", "আমি এটি বুঝতে আগ্রহী", "এখানে সেরা ডকুমেন্টেশন রয়েছে" ... একটি বাণিজ্যিক কোম্পানির ক্ষেত্রে, নির্বাচনের মানদণ্ড একই: আমাকে কত টাকা দিতে হবে এবং এই অর্থের জন্য আমি কী পাব।

স্বাভাবিকভাবেই, আপনি কম দিতে চান এবং আরও পেতে চান। যাইহোক, আপনাকে সিদ্ধান্ত নিতে হবে কোনটি বেশি গুরুত্বপূর্ণ - কম অর্থ প্রদান বা বেশি পাওয়া এবং প্রতিটি নোডের জন্য একটি ওজন নির্ধারণ করুন। আসুন ধরে নিই যে একটি সস্তার চেয়ে একটি উচ্চ-মানের সমাধান আমাদের কাছে বেশি গুরুত্বপূর্ণ, এবং আমরা "কস্ট" নোডে 40% এবং "সুযোগ" নোডে 60% ওজন নির্ধারণ করি।

বড় কর্পোরেশনগুলিতে, বিপরীতটি সাধারণত সত্য - খরচের ওজন 50% এর নীচে পড়ে না এবং সম্ভবত 60% এরও বেশি। মডেল উদাহরণে, যা গুরুত্বপূর্ণ তা হল যে কোনও প্যারেন্ট নোডের চাইল্ড নোডের মোট ওজন 100% হতে হবে।

কাট-অফ শর্ত

সাইট db-engines.com প্রায় 500 ডাটাবেস ম্যানেজমেন্ট সিস্টেম পরিচিত। স্বাভাবিকভাবেই, আপনি যদি অনেকগুলি বিকল্প থেকে একটি লক্ষ্য প্ল্যাটফর্ম বেছে নেন, তাহলে আপনি একটি পর্যালোচনা নিবন্ধ দিয়ে শেষ করতে পারেন, কিন্তু একটি বাণিজ্যিক প্রকল্প নয়। পছন্দের স্থান হ্রাস করার জন্য, কাট-অফ মানদণ্ড প্রণয়ন করা হয় এবং যদি প্ল্যাটফর্ম এই মানদণ্ডগুলি পূরণ না করে, তবে এটি বিবেচনা করা হয় না।

কাট-অফ মানদণ্ড প্রযুক্তিগত বৈশিষ্ট্যগুলির সাথে সম্পর্কিত হতে পারে, উদাহরণস্বরূপ:

• ACID গ্যারান্টি দেয়;
• রিলেশনাল ডেটা মডেল;
• SQL ভাষা সমর্থন (দ্রষ্টব্য, এটি "রিলেশনাল মডেল" এর মতো নয়);
• অনুভূমিক স্কেলিং সম্ভাবনা।

সাধারণ মানদণ্ড থাকতে পারে:

• রাশিয়ায় বাণিজ্যিক সহায়তার প্রাপ্যতা;
• মুক্ত উৎস;
• টেলিকম এবং গণযোগাযোগ মন্ত্রকের রেজিস্টারে প্ল্যাটফর্মের প্রাপ্যতা;
• কিছু রেটিংয়ে প্ল্যাটফর্মের উপস্থিতি (উদাহরণস্বরূপ, db-engines.com রেটিং-এর প্রথম শতকে);
• বাজারে বিশেষজ্ঞদের উপস্থিতি (উদাহরণস্বরূপ, hh.ru ওয়েবসাইটে একটি জীবনবৃত্তান্তে প্ল্যাটফর্মের নাম অনুসন্ধানের ফলাফলের ভিত্তিতে)।

সর্বোপরি, এন্টারপ্রাইজ-নির্দিষ্ট মানদণ্ড থাকতে পারে:

• কর্মীদের উপর বিশেষজ্ঞদের প্রাপ্যতা;
• মনিটরিং সিস্টেম X বা ব্যাকআপ সিস্টেম Y এর সাথে সামঞ্জস্য, যার উপর ভিত্তি করে সমস্ত সমর্থন...

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

খরচ অনুমান

সমাধানের খরচ স্পষ্টতই লাইসেন্সের খরচ, সমর্থনের খরচ এবং সরঞ্জামের খরচ নিয়ে গঠিত।

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

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

বিভিন্ন বিক্রেতার বিভিন্ন লাইসেন্সিং মেট্রিক থাকতে পারে: কোরের সংখ্যা, ডেটা ভলিউম বা নোডের সংখ্যা অনুসারে। স্ট্যান্ডবাই বেস বিনামূল্যে হতে পারে, বা এটি প্রধান এক হিসাবে একই ভাবে লাইসেন্স করা যেতে পারে. মেট্রিক্সে কোনো পার্থক্য আবিষ্কৃত হলে, আপনাকে মডেল স্ট্যান্ডের বিস্তারিত বর্ণনা করতে হবে এবং স্ট্যান্ডের লাইসেন্সের খরচ গণনা করতে হবে।

একটি সঠিক তুলনার জন্য একটি গুরুত্বপূর্ণ বিষয় হল একই সমর্থন শর্ত। উদাহরণ স্বরূপ, ওরাকল সাপোর্টের জন্য প্রতি বছর লাইসেন্স মূল্যের 22% খরচ হয়, কিন্তু আপনাকে PostgreSQL সমর্থনের জন্য অর্থ প্রদান করতে হবে না। এভাবে তুলনা করা কি ঠিক? না, কারণ একটি ত্রুটি যা আপনার নিজের থেকে ঠিক করা যায় না তার সম্পূর্ণ ভিন্ন পরিণতি রয়েছে: প্রথম ক্ষেত্রে, সহায়তা বিশেষজ্ঞরা আপনাকে দ্রুত এটি ঠিক করতে সহায়তা করবে, তবে দ্বিতীয় ক্ষেত্রে, প্রকল্পটি বিলম্বিত হওয়ার বা সমাপ্তির ডাউনটাইম হওয়ার ঝুঁকি রয়েছে। একটি অনির্দিষ্ট সময়ের জন্য সিস্টেম।

আপনি তিনটি উপায়ে গণনার শর্ত সমান করতে পারেন:

1. সমর্থন ছাড়া ওরাকল ব্যবহার করুন (বাস্তবে এটি ঘটে না)।
2. PostgreSQL-এর জন্য সমর্থন কিনুন - উদাহরণস্বরূপ, Postgres Professional থেকে।
3. সহায়তার অভাবের সাথে সম্পর্কিত ঝুঁকিগুলি বিবেচনা করুন।

উদাহরণস্বরূপ, একটি ঝুঁকি গণনা এইরকম দেখতে পারে: একটি মারাত্মক ডাটাবেস ব্যর্থতার ক্ষেত্রে, সিস্টেম ডাউনটাইম হবে 1 ব্যবসায়িক দিন। সিস্টেম ব্যবহার করে অনুমানকৃত মুনাফা প্রতি বছর 40 বিলিয়ন MNT, দুর্ঘটনার হার 1/400 অনুমান করা হয়, এইভাবে সমর্থনের অভাবের ঝুঁকি প্রতি বছর আনুমানিক 100 মিলিয়ন MNT অনুমান করা হয়। স্পষ্টতই, "পরিকল্পিত লাভ" এবং "আনুমানিক দুর্ঘটনা ফ্রিকোয়েন্সি" হল ভার্চুয়াল মান, কিন্তু এই ধরনের মডেল না থাকার চেয়ে অনেক ভালো।

বাস্তবে, দীর্ঘমেয়াদী ডাউনটাইমের সম্মানজনক খরচ অগ্রহণযোগ্য হওয়ার জন্য সিস্টেমটি খুব গুরুত্বপূর্ণ হতে পারে, তাই সমর্থন প্রয়োজন হবে। যদি ডাউনটাইম অনুমোদিত হয়, তবে সমর্থন প্রত্যাখ্যান করা কখনও কখনও অর্থ সঞ্চয় করার একটি ভাল উপায় হতে পারে।

আসুন আমরা ধরে নিই যে 5 বছরের জন্য অপারেটিং প্ল্যাটফর্ম A এর খরচ 800 মিলিয়ন MNT, অপারেটিং প্ল্যাটফর্ম B এর খরচ 650 মিলিয়ন MNT, এবং অপারেটিং প্ল্যাটফর্ম C এর খরচ 600 মিলিয়ন MNT। প্ল্যাটফর্ম সি, বিজয়ী হিসাবে, মূল্যের জন্য একটি সম্পূর্ণ পয়েন্ট পায়, যখন প্ল্যাটফর্ম A এবং B একটু কম পায়, সেগুলি কতবার বেশি ব্যয়বহুল তার অনুপাতে। এই ক্ষেত্রে - যথাক্রমে 0.75 এবং 0.92 পয়েন্ট।

সুযোগ মূল্যায়ন

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

উন্নয়ন ফাংশন অন্তর্ভুক্ত:

• ডেটা ম্যানিপুলেশন সহজতর;
• স্কেলিং;
• সেকেন্ডারি ইনডেক্সের উপস্থিতি।

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

প্রশাসনিক কার্যাবলী অন্তর্ভুক্ত:

• ব্যাকআপ সিস্টেম ক্ষমতা;
• নিরীক্ষণের সহজতা;
• ক্ষমতা পরিচালনার সহজতা - ডিস্ক এবং নোড;
• তথ্য প্রতিলিপি ক্ষমতা.

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

টুল
মন্তব্য
মূল্যায়ন

imp/exp
ডেটা আপলোড এবং লোড হচ্ছে
0.1

ব্যাকআপ শুরু/শেষ
ফাইল কপি করা হচ্ছে
0.3

আরএমএএন
ক্রমবর্ধমান অনুলিপি ক্ষমতা
0.7

জেডডিএলআরএ
শুধুমাত্র ক্রমবর্ধমান অনুলিপি, পয়েন্টে দ্রুততম পুনরুদ্ধার
1.0

যদি কোনও স্পষ্ট মূল্যায়নের মানদণ্ড না থাকে, তবে বেশ কিছু বিশেষজ্ঞকে রেটিং দিতে এবং তারপরে তাদের গড় করতে বলাটা বোধগম্য।

অবশেষে, আমরা কেবল তথ্য সুরক্ষা ফাংশন তালিকাভুক্ত করি:

• পাসওয়ার্ড ব্যবস্থাপনা নীতির প্রাপ্যতা;
• বহিরাগত প্রমাণীকরণ সরঞ্জাম (LDAP, Kerberos) সংযোগ করার ক্ষমতা;
• অ্যাক্সেসের রোল মডেল;
• অডিট ক্ষমতা;
• ডিস্কে ডেটা এনক্রিপশন;
• নেটওয়ার্কের মাধ্যমে সংক্রমণের সময় এনক্রিপশন (TLS);
• অ্যাডমিনিস্ট্রেটরের কাছ থেকে ডেটা সুরক্ষা।

কর্মক্ষমতা পরীক্ষা

আলাদাভাবে, আমি কোনো লোড পরীক্ষার ফলাফল ব্যবহার করার বিরুদ্ধে সতর্ক করতে চাই যা আপনার দ্বারা যুক্তি হিসাবে তৈরি করা হয়নি।

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

দ্বিতীয়ত, সিস্টেমের কর্মক্ষমতা বেশ দৃঢ়ভাবে নির্ভর করে কোন প্ল্যাটফর্মের জন্য কোডটি মূলত লেখা হয়েছিল এবং কোন সরঞ্জামের উপর পরীক্ষাটি করা হয়েছিল। আমি অনেক পরীক্ষা দেখেছি যেখানে ওরাকলকে PostgreSQL এর সাথে তুলনা করা হয়েছিল। ফলাফলগুলি একটি সিস্টেমের শর্তহীন শ্রেষ্ঠত্ব থেকে অন্যটির সমান শর্তহীন শ্রেষ্ঠত্ব পর্যন্ত বিস্তৃত।

এবং পরিশেষে, তৃতীয়ত, কে পরীক্ষা করেছে সে সম্পর্কে আপনি কিছুই জানেন না। উভয় যোগ্যতাই গুরুত্বপূর্ণ, OS এবং প্ল্যাটফর্ম সেট আপ করার গুণমানকে প্রভাবিত করে, সেইসাথে অনুপ্রেরণা, যা অন্যান্য সমস্ত কারণের মিলিত হওয়ার চেয়ে পরীক্ষার ফলাফলকে বেশি প্রভাবিত করে।

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

ফল

অবশেষে, সমস্ত কাজের ফলাফল একটি স্প্রেডশীট হওয়া উচিত যেখানে সমস্ত অনুমান একত্রিত, গুণিত এবং সংক্ষিপ্ত করা হয়:

আপনি যেমন বুঝতে পেরেছেন, স্কেল পরিবর্তন করে এবং রেটিংগুলি সামঞ্জস্য করে আপনি যে কোনও পছন্দসই ফলাফল অর্জন করতে পারেন, তবে এটি একটি সম্পূর্ণ ভিন্ন গল্প...

উত্স: www.habr.com