আমি সম্প্রতি তা জানতে পেরেছি Red Hat Satellite থেকে MongoDB সমর্থন সরিয়ে দেয় (তারা লাইসেন্স পরিবর্তনের কারণে বলে)। এটি আমাকে ভাবতে বাধ্য করেছে কারণ গত কয়েক বছরে আমি মঙ্গোডিবি কতটা ভয়ানক এবং কীভাবে কারও এটি ব্যবহার করা উচিত নয় সে সম্পর্কে প্রচুর নিবন্ধ দেখেছি। কিন্তু এই সময়ে, MongoDB অনেক বেশি পরিণত পণ্য হয়ে উঠেছে। কি হলো? সমস্ত ঘৃণা কি আসলেই একটি নতুন ডিবিএমএসের প্রাথমিক বিপণনে ভুলের কারণে? নাকি লোকেরা শুধু ভুল জায়গায় MongoDB ব্যবহার করছে?

আপনি যদি মনে করেন আমি MongoDB রক্ষা করছি, অনুগ্রহ করে পড়ুন দাবিত্যাগ নিবন্ধের শেষে।

নতুন রীতি

আমি বলতে পারি তার চেয়ে বেশি বছর ধরে আমি সফ্টওয়্যার শিল্পে কাজ করছি, তবে আমি এখনও আমাদের শিল্পকে আঘাত করেছে এমন প্রবণতার একটি ছোট অংশের কাছে উন্মুক্ত হয়েছি। আমি 4GL, AOP, Agile, SOA, Web 2.0, AJAX, Blockchain-এর উত্থান প্রত্যক্ষ করেছি... তালিকাটি অন্তহীন। প্রতি বছর নতুন প্রবণতা প্রদর্শিত হয়। কিছু দ্রুত বিবর্ণ হয়ে যায়, অন্যরা মৌলিকভাবে সফ্টওয়্যার তৈরির উপায় পরিবর্তন করে।

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

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

দ্রষ্টব্য: আপনি মনে করতে পারেন যে আমি নথির ডেটাবেসগুলিকে কলামার ডেটাবেস, কী/মান স্টোর, বা সাধারণ NoSQL সংজ্ঞার আওতায় পড়ে এমন অন্যান্য অসংখ্য ডেটা স্টোরের সাথে বিভ্রান্ত করছি। এবং আপনি ঠিক আছেন. কিন্তু সেই সময় বিশৃঙ্খলা রাজত্ব করে। সবাই NoSQL নিয়ে আচ্ছন্ন, এটা সবাই হয়ে গেছে একেবারে প্রয়োজনীয়, যদিও অনেকেই বিভিন্ন প্রযুক্তির পার্থক্য দেখতে পাননি। অনেকের জন্য, MongoDB হয়ে গেছে সমার্থকের সাথে NoSQL

এবং ডেভেলপাররা এটি নিয়ে ঝাঁপিয়ে পড়ে। একটি স্কিমলেস ডাটাবেসের ধারণা যা যাদুকরীভাবে যেকোনো সমস্যা সমাধানের জন্য স্কেল করে তা বেশ লোভনীয় ছিল। 2014 সালের দিকে, মনে হচ্ছিল যে এক বছর আগে মাইএসকিউএল, পোস্টগ্রেস বা এসকিউএল সার্ভারের মতো রিলেশনাল ডাটাবেস ব্যবহার করা হয়েছে এমন সব জায়গায় মঙ্গোডিবি ডাটাবেস স্থাপন করা শুরু করেছে। কেন জিজ্ঞাসা করা হলে, আপনি সাধারণ "এটি ওয়েবের স্কেল" থেকে আরও চিন্তাশীল "আমার ডেটা খুব ঢিলেঢালাভাবে কাঠামোগত এবং কোনও স্কিমা ছাড়াই ডাটাবেসে ভালভাবে ফিট করে" এর উত্তর পেতে পারেন৷

এটা মনে রাখা গুরুত্বপূর্ণ যে MongoDB, এবং সাধারণভাবে ডকুমেন্ট ডাটাবেস, ঐতিহ্যগত রিলেশনাল ডাটাবেসের সাথে বেশ কয়েকটি সমস্যার সমাধান করে:

• কঠোর পরিকল্পনা: একটি রিলেশনাল ডাটাবেসের সাহায্যে, আপনার যদি গতিশীলভাবে ডেটা জেনারেট করা থাকে, তাহলে আপনাকে হয় একগুচ্ছ ডেটার এলোমেলো "বিবিধ" কলাম তৈরি করতে বাধ্য করা হবে, সেখানে ডেটার ব্লবগুলি ঠেলে দিতে হবে, অথবা কনফিগারেশন ব্যবহার করতে হবে। ইএভি...এই সবগুলির উল্লেখযোগ্য ত্রুটি রয়েছে৷
• অসুবিধা স্কেলিং: যদি এত বেশি ডেটা থাকে যে এটি একটি সার্ভারে মাপসই না হয়, তাহলে MongoDB এটিকে একাধিক মেশিনে স্কেল করার অনুমতি দেওয়ার জন্য ব্যবস্থা অফার করে।
• জটিল সার্কিট পরিবর্তন: কোন মাইগ্রেশন নেই! একটি রিলেশনাল ডাটাবেসে, ডাটাবেস কাঠামো পরিবর্তন করা একটি বিশাল সমস্যা হতে পারে (বিশেষ করে যখন প্রচুর ডেটা থাকে)। মঙ্গোডিবি প্রক্রিয়াটিকে ব্যাপকভাবে সহজ করতে সক্ষম হয়েছিল। এবং এটি এত সহজ করে দিয়েছে যে আপনি যেতে এবং খুব দ্রুত এগিয়ে যাওয়ার সাথে সাথে সার্কিট আপডেট করতে পারেন।
• রেকর্ডিং কর্মক্ষমতা: MongoDB কর্মক্ষমতা ভাল ছিল, বিশেষ করে যখন সঠিকভাবে কনফিগার করা হয়। এমনকি MongoDB-এর আউট-অফ-দ্য-বক্স কনফিগারেশন, যার জন্য এটি প্রায়শই সমালোচিত হত, কিছু চিত্তাকর্ষক কর্মক্ষমতা সংখ্যা দেখিয়েছিল।

সমস্ত ঝুঁকি আপনার উপর

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

ন্যায্যভাবে, 10gen/MongoDB Inc-এ কেউ নেই। বলব না যে নিম্নলিখিতগুলি সত্য নয়, এগুলি কেবল আপস।

• লেনদেন হারিয়েছে: লেনদেন অনেক রিলেশনাল ডাটাবেসের একটি মূল বৈশিষ্ট্য (সকল নয়, তবে বেশিরভাগ)। লেনদেনের অর্থ হল আপনি পারমাণবিকভাবে একাধিক ক্রিয়াকলাপ সম্পাদন করতে পারেন এবং নিশ্চিত করতে পারেন যে ডেটা সামঞ্জস্যপূর্ণ থাকে। অবশ্যই, একটি NoSQL ডাটাবেসের সাথে, লেনদেন একটি একক নথির মধ্যে হতে পারে, অথবা আপনি লেনদেনের শব্দার্থবিদ্যা পেতে দ্বি-পর্যায়ের প্রতিশ্রুতি ব্যবহার করতে পারেন। কিন্তু আপনাকে এই কার্যকারিতা নিজেই বাস্তবায়ন করতে হবে... যা একটি কঠিন এবং সময়সাপেক্ষ কাজ হতে পারে। প্রায়শই আপনি বুঝতে পারেন না যে একটি সমস্যা আছে যতক্ষণ না আপনি ডাটাবেসের ডেটা অবৈধ অবস্থায় শেষ হয় কারণ অপারেশনের পারমাণবিকতা নিশ্চিত করা যায় না। দ্রষ্টব্য: অনেকেই আমাকে বলেছেন যে MongoDB 4.0 গত বছর লেনদেন চালু করেছে, কিন্তু কিছু সীমাবদ্ধতা সহ। নিবন্ধ থেকে টেকওয়ে একই রয়ে গেছে: প্রযুক্তিটি কতটা ভালোভাবে আপনার চাহিদা পূরণ করে তা মূল্যায়ন করুন।
• সম্পর্কগত অখণ্ডতা হারানো (বিদেশী কী): যদি আপনার ডেটার মধ্যে সম্পর্ক থাকে, তাহলে আপনাকে সেগুলি অ্যাপ্লিকেশনে প্রয়োগ করতে হবে। এই সম্পর্কগুলিকে সম্মান করে এমন একটি ডাটাবেস থাকলে অ্যাপ্লিকেশনটির অনেক কাজ বন্ধ হয়ে যাবে এবং সেইজন্য আপনার প্রোগ্রামাররা।
• ডেটা কাঠামো প্রয়োগ করার ক্ষমতার অভাব: কঠোর স্কিমাগুলি কখনও কখনও একটি বড় সমস্যা হতে পারে, তবে তারা যদি বুদ্ধিমানের সাথে ব্যবহার করা হয় তবে ভাল ডেটা স্ট্রাকচারিংয়ের জন্য একটি শক্তিশালী প্রক্রিয়া। মঙ্গোডিবি-র মতো নথি ডেটাবেসগুলি অবিশ্বাস্য স্কিমা নমনীয়তা প্রদান করে, কিন্তু এই নমনীয়তা ডেটা পরিষ্কার রাখার দায়িত্ব সরিয়ে দেয়। আপনি যদি তাদের যত্ন না নেন, তাহলে আপনি আপনার প্রত্যাশিত ফর্মে সংরক্ষণ করা হয়নি এমন ডেটার জন্য অ্যাকাউন্টে আপনার অ্যাপ্লিকেশনে প্রচুর কোড লিখবেন। যেমনটি আমরা প্রায়শই আমাদের কোম্পানিতে বলে থাকি সিম্পল থ্রেড... অ্যাপ্লিকেশনটি কোনো দিন আবার লেখা হবে, কিন্তু ডেটা চিরকাল বেঁচে থাকবে। দ্রষ্টব্য: MongoDB স্কিমা চেকিং সমর্থন করে: এটি দরকারী, কিন্তু রিলেশনাল ডাটাবেসের মতো একই গ্যারান্টি প্রদান করে না। প্রথমত, স্কিমা চেক যোগ করা বা পরিবর্তন করা সংগ্রহে বিদ্যমান ডেটাকে প্রভাবিত করে না। আপনি নতুন স্কিমা অনুযায়ী ডেটা আপডেট করেছেন তা নিশ্চিত করা আপনার উপর নির্ভর করে। এটি আপনার প্রয়োজনের জন্য যথেষ্ট কিনা তা নিজের জন্য সিদ্ধান্ত নিন।
• নেটিভ কোয়েরি ভাষা / টুল ইকোসিস্টেমের ক্ষতি: এসকিউএল এর আবির্ভাব একটি পরম বিপ্লব ছিল এবং তারপর থেকে কিছুই পরিবর্তন হয়নি। এটি একটি অবিশ্বাস্যভাবে শক্তিশালী ভাষা, কিন্তু বেশ জটিল। JSON টুকরা সমন্বিত একটি নতুন ভাষায় ডাটাবেস কোয়েরি তৈরি করার প্রয়োজনীয়তাকে এসকিউএল-এর সাথে কাজ করার অভিজ্ঞতা আছে এমন লোকেরা পিছনের দিকে একটি বড় পদক্ষেপ হিসাবে বিবেচনা করে। আইডিই থেকে রিপোর্টিং টুলস পর্যন্ত এসকিউএল ডাটাবেসের সাথে ইন্টারঅ্যাক্ট করে এমন সরঞ্জামগুলির একটি সম্পূর্ণ মহাবিশ্ব রয়েছে। এসকিউএল সমর্থন করে না এমন একটি ডাটাবেসে যাওয়ার মানে হল আপনি এই টুলগুলির বেশিরভাগ ব্যবহার করতে পারবেন না বা সেগুলি ব্যবহার করার জন্য আপনাকে ডেটা এসকিউএল-এ অনুবাদ করতে হবে, যা আপনার ধারণার চেয়ে বেশি কঠিন হতে পারে।

অনেক ডেভেলপার যারা মঙ্গোডিবিতে পরিণত হয়েছে তারা আসলেই ট্রেড-অফ বুঝতে পারেনি এবং প্রায়শই তাদের প্রাথমিক ডেটা স্টোর হিসাবে এটি ইনস্টল করার জন্য প্রথমে ডুব দেয়। এর পরে ফিরে আসা প্রায়শই অবিশ্বাস্যভাবে কঠিন ছিল।

ভিন্নভাবে কি করা যেত?

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

কিভাবে সঠিক প্রযুক্তি নির্বাচন করবেন? প্রযুক্তি মূল্যায়নের জন্য একটি পদ্ধতিগত কাঠামো তৈরি করার জন্য বেশ কয়েকটি প্রচেষ্টা করা হয়েছে, যেমন "সফ্টওয়্যার সংস্থাগুলিতে প্রযুক্তি প্রবর্তনের জন্য কাঠামো" и "সফ্টওয়্যার প্রযুক্তি মূল্যায়নের জন্য কাঠামো", কিন্তু এটা আমার মনে হয় যে এটি অপ্রয়োজনীয় জটিলতা।

শুধুমাত্র দুটি মৌলিক প্রশ্ন জিজ্ঞাসা করে অনেক প্রযুক্তি বুদ্ধিমত্তার সাথে মূল্যায়ন করা যেতে পারে। সমস্যা হল এমন লোকদের খুঁজে বের করা যারা দায়িত্বের সাথে তাদের উত্তর দিতে পারে, উত্তর খুঁজে পেতে সময় নেয় এবং পক্ষপাত ছাড়াই।

আপনি যদি কোন সমস্যার সম্মুখীন না হন, তাহলে আপনার নতুন টুলের প্রয়োজন নেই। ডট

প্রশ্ন 1: আমি কোন সমস্যা সমাধান করার চেষ্টা করছি?

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

প্রশ্ন 2: আমি কি অনুপস্থিত?

এটি অবশ্যই একটি আরও কঠিন প্রশ্ন কারণ আপনাকে খনন করতে হবে এবং পুরানো এবং নতুন উভয় প্রযুক্তিরই ভাল ধারণা থাকতে হবে। কখনও কখনও আপনি সত্যিই একটি নতুন বুঝতে পারবেন না যতক্ষণ না আপনি এটির সাথে কিছু তৈরি করেন বা সেই অভিজ্ঞতার সাথে কাউকে না পান।

যদি আপনার কোনটিই না থাকে, তাহলে এই যন্ত্রের মূল্য নির্ধারণের জন্য ন্যূনতম সম্ভাব্য বিনিয়োগ সম্পর্কে চিন্তা করা বোধগম্য। এবং আপনি একবার বিনিয়োগ করলে, সিদ্ধান্তটি ফিরিয়ে আনা কতটা কঠিন হবে?

মানুষ সব সময় সব নষ্ট করে

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

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

উদ্দেশ্যমূলক মূল্যায়ন সহজ নয়, তবে অন্তর্নিহিত জ্ঞানীয় পক্ষপাতগুলি বোঝা আপনাকে আরও যুক্তিসঙ্গত সিদ্ধান্ত নিতে সাহায্য করবে।

সারাংশ

যখনই একটি উদ্ভাবন প্রদর্শিত হয়, দুটি প্রশ্নের উত্তর অবশ্যই অত্যন্ত যত্ন সহকারে দিতে হবে:

• এই টুল একটি বাস্তব সমস্যা সমাধান করে?
• আমরা কি ট্রেড-অফ ভাল বুঝি?

আপনি যদি আত্মবিশ্বাসের সাথে এই দুটি প্রশ্নের উত্তর দিতে না পারেন তবে কয়েক ধাপ পিছনে যান এবং চিন্তা করুন।

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

দাবিত্যাগ

আমি এটা পরিষ্কার করতে চাই যে MongoDB-এর সাথে আমার প্রেম বা ঘৃণার সম্পর্ক নেই। মোঙ্গোডিবি সমাধানের জন্য সবচেয়ে উপযুক্ত যে ধরনের সমস্যা আমাদের ছিল না। আমি জানি যে 10gen/MongoDB Inc. প্রথমে খুব সাহসী ছিল, অনিরাপদ ডিফল্ট সেট করা এবং যেকোন ডেটা নিয়ে কাজ করার জন্য সর্বত্র (বিশেষ করে হ্যাকাথনে) MongoDB প্রচার করা। এটি সম্ভবত একটি খারাপ সিদ্ধান্ত ছিল। কিন্তু এটি এখানে বর্ণিত পদ্ধতির বিষয়টি নিশ্চিত করে: প্রযুক্তির উপরিভাগের মূল্যায়নের সাথেও এই সমস্যাগুলি খুব দ্রুত সনাক্ত করা যেতে পারে।

উত্স: www.habr.com