আমাদের কখন মঙ্গোডিবি ব্যবহার করা উচিত?


17

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

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

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

সেক্ষেত্রে আমরা কখন রিলেশনাল ডাটাবেসের পরিবর্তে মঙ্গোডিবি ব্যবহার করতে পারি? মঙ্গোডিবি সম্পর্কে এমন কোনও ট্রুলি বড় সতর্কতা রয়েছে যা এটি কিছু পরিস্থিতিতে অনুচিত করে তোলে?


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


2
পছন্দ করেছেন এই প্রসঙ্গে, "সরল এবং ব্যবহার করা সহজ" এর অর্থ "বাগ লেখার সময় এবং ডেটা ক্ষতিগ্রস্থ করার সময় ব্যবহার করা সহজ";)
আন্দ্রে এফ

উত্তর:


17

মূলত:

  • আপনি যদি একগুচ্ছ দলিলগুলির আকারে আপনার ডেটা উপস্থাপন করতে পারেন তবে মঙ্গোডিবি ভাল পছন্দ হতে পারে।

  • আপনি যদি নিজের ডেটাটিকে আন্তঃসংযুক্ত টেবিলগুলির একগুচ্ছ হিসাবে কল্পনা করতে চান তবে মঙ্গোডিবি ভাল পছন্দ নাও করতে পারে।

এখানে দুটি উদাহরণ যা আমি উদাহরণস্বরূপ পাই:

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

    এটি একগুচ্ছ টেবিল হিসাবে সংরক্ষণ করা যেতে পারে, তবে একটি মডেল তৈরি করার চেষ্টা করার সময়, এটি খুব বেশি না হলে, কয়েক ডজন টেবিলে খুব দ্রুত বৃদ্ধি পায় grows কিছু এসকিউএল ক্যোয়ারী প্রচুর পরিমাণে কুৎসিত হতে পারে joinএবং ... ভাল, আপনি ছবিটি পান।

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

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

    একটি নথিভিত্তিক পদ্ধতির সাথে, দস্তাবেজটি কী হবে তা খুঁজে পাওয়া শক্ত difficult একজন ব্যবহারকারী হয়তো? ভাল, এটি একটি ভাল শুরু। একজন ব্যবহারকারী নথিতে এই ব্যবহারকারীর লেখা সমস্ত কিছুই থাকবে। তবে সে কী ভাগ করে নিয়েছে?

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

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

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

    এখন, আপনি যদি কোনও রিলেশনাল ডাটাবেস ব্যবহার করে থাকেন তবে আপনার কত টেবিলের প্রয়োজন হবে? ঠিক, তিন। এটি মডেলটির জন্য সোজাসাপ্টা এবং ব্যবহারের জন্যও সহজ।


৪.০ সংস্করণটি এসিডি
কার্মাইন

@ কারমাইন: আপডেট উত্তর দেওয়ার মতো পর্যাপ্ত জ্ঞান আমার কাছে নেই। আপনি দয়া করে (1) নীচের উত্তর হিসাবে আপনার পোস্ট করতে পারেন এবং (২) একবার আপনি এখানে মন্তব্য করার জন্য যোগ করতে পারেন, তাই আমি আপনার উত্তরটির সাথে একটি লিঙ্ক যুক্ত করে এই দাবিটি অস্বীকার করি যে মোংগোডিবি 4 থেকে আর এটি বৈধ নয়?
আর্সেনী মরজেনকো

9

প্রতিটি প্রযুক্তির এর সুবিধা রয়েছে।

রিলেশনাল ডাটাবেসের সুবিধাগুলি হ'ল আরডিবিএমএস আপনার জন্য কিছু কাজ করে, যেমন:

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

যে সমস্ত যে নিচে boils আপনি কম কোড লিখতে হবে কারণ RDBMS তোমাদের জন্য এমন জিনিস enforces।

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

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


5
মংগোডিবি লেনদেনের অভাব একটি বিশাল অসুবিধা। সারাক্ষণ রেস-কন্ডিশন নিয়ে চিন্তা করা পাছায় এমন ব্যথা in
কোডসইনচাউস

1
দ্রষ্টব্য: মঙ্গোডিবি এখন এসিডি লেনদেনকে সমর্থন করে।
মিলান Velebit

5

আপনার বিশেষ ক্ষেত্রে, মঙ্গোডিবি একটি ভাল পছন্দ বলে মনে হচ্ছে, তবে প্রচুর পরিস্থিতি রয়েছে (সম্ভবত তাদের বেশিরভাগের) যেখানে এটি সেরা পছন্দ নয়।

MongoDB আরো পরিস্থিতিতে উপযুক্ত যে পড়া / লেখার জন্য আহবান অনেক লেনদেন নিরাপত্তা ডেটা, অনেক জোর ছাড়া (কিছু তথ্য মাঝেমধ্যে এমন একটি সার্ভার দুর্ঘটনায় হারিয়ে পরার যদি, এটি একটি বড় চুক্তি না), স্কেল বড় আশা, এবং ডন ' সত্যিই একটি স্থিতিশীল স্কিমা আছে।

মোংগোডিবি প্রয়োজনীয় পরিস্থিতিতেগুলির জন্য উপযুক্ত নয় :

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

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

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


3

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

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


2

কোনও ওয়েব পৃষ্ঠার প্রদত্ত উদাহরণ তৈরি করতে প্রয়োজনীয় পুরো কাঠামোগত ডেটা সংরক্ষণ করার জন্য মঙ্গোডিবি দরকারী is আপনি প্রদত্ত পৃষ্ঠার জন্য ডেটা পুনরুদ্ধার করতে পারেন, এটি আপনার ক্লায়েন্ট অ্যাপ্লিকেশনটিতে দিন যা এটি সরবরাহ করতে পারে।

এরকম প্রসঙ্গে মঙ্গোডিবি খুব দ্রুত এবং নির্ভরযোগ্য। তবে কখনই ভুলে যাবেন না যে আপনার ডাটাবেসে আপনার সম্পর্কিত সম্পর্ক নেই। যার অর্থ আপনি যদি নিজের ওয়েবপৃষ্ঠার কাঠামোতে কিছু পরিবর্তন করেন তবে আপনি ইতিমধ্যে সঞ্চিত পৃষ্ঠাগুলির গর্তগুলি পূরণ করতে পারবেন না কারণ আপনার এটি করার জন্য প্রয়োজনীয় ডেটা নেই। এটি সম্পর্কে এখানে আরও: http://www.sarahmei.com/blog/2013/11/11/why-you-should-never-use-mongodb/

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