মঙ্গোডিবি বিএসন ডকুমেন্ট আকারের সীমা বোঝা যাচ্ছে

Question

মঙ্গোডিবির সংজ্ঞা নির্দেশিকা থেকে:

4MB (যখন BSON এ রূপান্তরিত হয়) এর চেয়ে বড় ডকুমেন্টগুলি ডাটাবেসে সংরক্ষণ করা যায় না। এটি কিছুটা স্বেচ্ছাচারী সীমা (এবং ভবিষ্যতে উত্থাপিত হতে পারে); এটি বেশিরভাগই খারাপ স্কিমা নকশা রোধ এবং ধারাবাহিক কর্মক্ষমতা নিশ্চিত করার জন্য।

আমি এই সীমাটি বুঝতে পারি না, এর অর্থ কি এই যে 4MB এর চেয়ে বড় বলে মনে হয় এমন অনেক মন্তব্য সহ একটি ব্লগ পোস্টযুক্ত একটি দস্তাবেজ একটি একক দস্তাবেজ হিসাবে সংরক্ষণ করা যায় না?

এছাড়াও এটি নেস্টেড ডকুমেন্টগুলিও গণনা করে?

আমি যদি এমন কোনও দস্তাবেজ চাইতাম যা মানটিতে পরিবর্তনগুলি নিরীক্ষণ করে। (অবশেষে এটি 4MB সীমা ছাড়িয়ে বাড়তে পারে))

আশা করি কেউ এটি সঠিকভাবে ব্যাখ্যা করেছেন।

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

ধন্যবাদ.

Comments

আমি মনে করি যে প্রশ্নটি স্পষ্ট করে দেওয়া উচিত যে এটি মঙ্গোডিবি সঞ্চিত নথি আকারের সীমাবদ্ধতা, বিএসওএন ফর্ম্যাটের নয়।

— অ্যালেক্সোপেস্কু

যদিও, আমি কেবল একটি বিশাল নথি সংরক্ষণের চেষ্টা করেছি যা অবশ্যই "BSON :: অবৈধ ডকুমেন্ট: নথিটি খুব বড়: বার্তাটি 4194304 বাইটে সীমাবদ্ধ রয়েছে" বার্তাটি পেতে 4MB ছাড়িয়েছে " যদি এটি হয় তবে এটি কি সতর্কতা / ত্রুটি বার্তায় বিভ্রান্তিকর নয়?

— নিক তাই

শেল db.isMaster().maxBsonObjectSize/(1024*1024)+' MB'কমান্ডের সাহায্যে আপনি আপনার সর্বোচ্চ BSON ডকুমেন্ট আকারটি সহজেই খুঁজে পেতে পারেন mongo।

— আহমেটবি - গুগল

স্কিমহীন নোসকিএল এর উদ্দেশ্য কী যেখানে আপনি 16 এমবি রেকর্ডের বেশি রেকর্ড ডাম্প করতে পারবেন না এবং এর উপরে ক্রড অপারেশন তৈরি করতে পারবেন!

— রিজওয়ান প্যাটেল

আমি মনে করি প্রাথমিক উক্তিটি সব বলেছে ... খারাপ স্কিমা নকশা রোধ করার জন্য সীমাটি রয়েছে। উদাহরণস্বরূপ, আপনার অনেক মন্তব্য সহ একটি পোস্ট রয়েছে, আপনি একটি ব্লগ এন্ট্রি সংগ্রহ এবং একটি মন্তব্য সংগ্রহ, বা একটি পরিবর্তন সংগ্রহ চান। মঙ্গো / নোসকিএল ডিজাইনটি নথির নেটওয়ার্ক হিসাবে বৃহত্তর আকারের জিনিসগুলিকে মঞ্জুরি দেয় তবে বিকাশকারীকে সেগুলি এমন অংশে ভেঙে ফেলা দরকার যা বোঝায়। যদি কোনও আকারের সীমা নির্ধারণ না করা হয়, তবে অন্যান্য সমস্যাগুলি ঘটবে। আমি মনে করি 4 এমবি সীমা ঠিক ছিল। 16 এমবি, দুর্দান্ত! তবে আমি যদি ১mb এমবি ডকুমেন্টটি লিখছি তবে এটির একটি সূত্র যে ডিজাইনের সাথে অন্য কিছু ভুল।

— আইল্যাশ

Answer 1

প্রথমত, এটি প্রকৃতপক্ষে পরবর্তী সংস্করণে উত্থাপিত হচ্ছে 8MBবা 16MB... তবে আমি এটিকে দৃষ্টিকোণে রাখার কথা ভাবছি, 10gen থেকে এলিয়ট (যিনি মোংগোডিবি বিকাশ করেছেন) এটিকে সর্বোত্তমভাবে বলেছেন:

সম্পাদনা: আকারটি সরকারীভাবে ' বাড়ানো ' হয়েছে16MB

সুতরাং, আপনার ব্লগের উদাহরণে, 4 এমবি আসলে একটি সম্পূর্ণ লট .. উদাহরণস্বরূপ, "ওয়ার্ল্ডস ওয়ার্ল্ড" এর সম্পূর্ণ অসম্পূর্ণ পাঠ্যটি কেবল 364 কে (এইচটিএমএল): http://www.gutenberg.org/etext/36

যদি আপনার ব্লগ পোস্টটি দীর্ঘ মন্তব্যগুলির সাথে দীর্ঘ হয় তবে আমি তার জন্য এটি পড়ব না :)

ট্র্যাকব্যাকগুলির জন্য, আপনি যদি তাদের 1MB উত্সর্গ করেন তবে আপনার কাছে সহজেই 10 কে-র বেশি (সম্ভবত 20k এর কাছাকাছি) থাকতে পারে

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

-Eliot

আমি মনে করি আপনি সীমাতে পৌঁছানোর জন্য বেশ চাপ দিয়েছিলেন ... এবং সময়ের সাথে সাথে, আপনি আপগ্রেড করলে ... আপনাকে কম এবং কম চিন্তা করতে হবে।

সীমাটির মূল বিষয়টি হ'ল আপনি নিজের সার্ভারে থাকা সমস্ত র‌্যাম ব্যবহার করবেন না (যেমন আপনি MBযখন জিজ্ঞাসা করছেন তখন আপনাকে সমস্ত নথিকে র্যামে লোড করতে হবে need )

সুতরাং সীমাটি হ'ল একটি সাধারণ সিস্টেমে সাধারণ ব্যবহারযোগ্য র্যামের কিছু% ... যা বছরের পর বছর বাড়তে থাকবে।

মংগোডিবিতে ফাইল সংরক্ষণের বিষয়ে নোট

আপনার যদি গ্রিডএফএস এপিআই16MB ব্যবহার করতে পারে তার চেয়ে বড় ডকুমেন্টগুলি (বা ফাইলগুলি) সঞ্চয় করতে হবে যা স্বয়ংক্রিয়ভাবে ডেটাগুলিকে সেগমেন্টে বিভক্ত করবে এবং এগুলি আপনার কাছে আবার প্রবাহিত করবে (এভাবে আকারের সীমা / র‌্যামের সমস্যাটি এড়ানো হবে))

একক নথিতে কোনও ফাইল সঞ্চয় করার পরিবর্তে গ্রিডেফএস ফাইলটি অংশগুলিতে বা অংশগুলিতে বিভক্ত করে এবং প্রতিটি খণ্ডকে পৃথক নথি হিসাবে সংরক্ষণ করে।

গ্রিডএফএস ফাইল সংরক্ষণের জন্য দুটি সংগ্রহ ব্যবহার করে। একটি সংগ্রহ ফাইল খণ্ডগুলি সঞ্চয় করে, এবং অন্যান্য স্টোরগুলিতে মেটাডেটা ফাইল করে।

কোনও এসকিউএল ডাটাবেসে আপনি যতটা সম্ভব চিত্র, ফাইল, ভিডিও ইত্যাদি সঞ্চয় করতে আপনি এই পদ্ধতিটি ব্যবহার করতে পারেন। আমি এটি বহু গিগাবাইট ভিডিও ফাইল সঞ্চয় করতেও ব্যবহার করেছি।

Comments

আপনার দুর্দান্ত ডাটাবেসের জন্য আপনার যথেষ্ট পরিমাণে র‌্যাম রয়েছে ... এটি দুর্দান্ত ... সাধারণত "ওয়ার্কিং সেট" র‌্যামে থাকে, পুরো ডাটাবেস নয় (যেমন আমার ক্ষেত্রে আমার কাছে এক x জিবিএসের বেশি ডাটাবেস রয়েছে যেখানে সমস্ত যোগ করা আমার র‌্যাম ছাড়িয়ে গেলে, তবে এটি ঠিক আছে কারণ কার্যকারী সেটটি অনেক বেশি, অনেক ছোট)) এছাড়াও, যদি কোনও সীমা না থাকে তবে আপনি কোনও র‌্যাম ডাব্লু / একটি ক্যোয়ারিতে একটি 800 এমবি ডক এবং অন্যটির সাথে একটি 400 কে ডক লোড করতে পারেন, আপনার র‌্যামকে সামান্য ভারসাম্য তৈরি করা ইত্যাদি etc । সুতরাং "সীমা" সাধারণত সার্ভার RAM এর কিছু% এর (সুতরাং এটা সময়ের সাথে বৃদ্ধি।) mongodb.org/display/DOCS/Checking+Server+Memory+Usage

— জাস্টিন জেনকিন্স

এটি দুর্দান্ত যে আপনি সমস্ত কিছু র‍্যামে সঞ্চয় করতে পারবেন তবে দক্ষতা এবং ব্লগ পোস্টের আইডিয়ামটি বিবেচনা করুন। আপনি অবশ্যই স্পষ্টভাবে চান যে কোনও পোস্ট যদি এটি পড়ে থাকে memory তবে বেশিরভাগ লোকেরা কখনই প্রথম পৃষ্ঠার পাতায় পড়বে না, আপনি কি সত্যিই কোনও ব্লগ পোস্টের জন্য 10 পৃষ্ঠার মন্তব্যে স্মরণে রাখতে চান? অবশ্যই, আপনি এটি করতে পারেন এবং যদি আপনার ডাটাবেসটি যথেষ্ট ছোট যে এটি সমস্ত স্মৃতিতে ফিট করতে পারে তবে কোনও সমস্যা নেই। তবে খাঁটি দক্ষতার দিক থেকে আপনি যদি এড়াতে পারেন তবে অকার্যকর বিটগুলি মেমরির জায়গা নিতে চান না (এবং এটি আরডিবিএমএসের ক্ষেত্রেও যায়)।

— অ্যালেক্সগ্যাড

মিষ্টি জেসুস, সুতরাং মঙ্গোর যুক্তি "16 এমবি কারও পক্ষে যথেষ্ট হওয়া উচিত"? এটি এর আগে অতীতে কখনও ভুল প্রমাণিত হয়নি।

— রবার্ট খ্রিস্ট

এটি আমার পক্ষে খুব খারাপ লাগছে। মঙ্গো বড় ডেটার জন্য দরকারী বলে মনে করা হয়, এরকম সীমাবদ্ধতা নেই। আমার প্রকল্পে, আমার সমষ্টি এবং গ্রুপের টুইটগুলি একই ট্রেন্ডিং বিষয়ের সাথে সম্পর্কিত হওয়া দরকার এবং এটি 20 ঘন্টা সময়ের জন্য 20000 এরও বেশি টুইটের মধ্যে শেষ হতে পারে (এবং এটির পক্ষে যথেষ্ট সম্ভাবনা রয়েছে যে ট্রেন্ডগুলি আরও বেশি স্থায়ী হবে) আমার ডিবিতে 20 ঘন্টা) অনেকগুলি টুইট থাকা এবং তাদের পাঠ্য একই সাথে সঞ্চয় করা ধ্বংসাত্মক এবং কয়েকটি ছোট ট্রেন্ডের গোষ্ঠীভুক্ত হওয়ার পরে এটি একটি বড় ট্রেন্ড ব্যতীত শেষ হয়।

— সাবভাস পারস্তাদিদিস

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

— schmidlop

Answer 2

সম্প্রদায়ের অনেকেই পারফরম্যান্স সম্পর্কে সতর্কবার্তা নিয়ে সীমাবদ্ধতা পছন্দ করবেন না, যুক্তিযুক্ত যুক্তির জন্য এই মন্তব্যটি দেখুন: https://jira.mongodb.org/browse/SERVER-431?focusedCommentId=22283&page=com.atlassian.jira.plugin। system.issuetabpanels: মন্তব্য-tabpanel # টি মন্তব্য-22283

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

Comments

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

— শারজিল আহমেদ

@ মারআর 75 এটি এখন ঠিক করে দিয়েছে, এটি কি ঠিক করা হয়েছে?

— মাফাই

মানে, সীমাটি 16MB এ বাড়ানো হয়েছিল, এটি "ইস্যু" দীর্ঘমেয়াদী স্থির করে না; আইএমও সীমা সরিয়ে নেওয়া উচিত।

— 75

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

— 75

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

— mar7575

Answer 3

গুগল যারা এখানে নির্দেশ পেয়েছেন তাদের জন্য এখানে একটি স্পষ্টীকরণের উত্তর পোস্ট করতে।

দস্তাবেজের আকারে ডকুমেন্টের সমস্ত বিষয় অন্তর্ভুক্ত রয়েছে সাব-ডকুমেন্টস, নেস্টেড অবজেক্টস ইত্যাদি including

সুতরাং এর একটি নথি:

{
    _id:{},
    na: [1,2,3],
    naa: [
        {w:1,v:2,b:[1,2,3]},
        {w:5,b:2,h:[{d:5,g:7},{}]}
    ]
}

সর্বাধিক আকার 16 ম্যাগ আছে।

Sbudocuments এবং নেস্টেড অবজেক্টস সমস্ত নথির আকারের জন্য গণনা করা হয়।

Comments

বিএসওএন-তে প্রতিনিধিত্ব করতে সক্ষম একক বৃহত্তম সম্ভাব্য কাঠামোটি হ'ল বিদ্রূপজনকভাবে, সবচেয়ে কমপ্যাক্ট। size_tমঙ্গোডিবি অভ্যন্তরীণভাবে ( -৪ -বিট) অ্যারে সূচকগুলি ব্যবহার করে সত্ত্বেও , ১M এমবি নথির আকারের সীমাটি সর্বোপরি দুই মিলিয়ন ন্যূনসামগ্রীযুক্ত একটি একক অ্যারে সম্বলিত একটি নথি উপস্থাপন করতে সক্ষম হবে।

— amcgregor

ক্ষমা প্রার্থনা, ঠিকানার জন্য দ্বিতীয় মন্তব্য যুক্ত করা / আরও একটি গুরুত্বপূর্ণ বিবরণ স্পষ্ট করে: আপনি যখন বলেন নথির আকারে নথির সমস্ত কিছু অন্তর্ভুক্ত থাকে, এতে কীগুলিও অন্তর্ভুক্ত থাকে । উদাহরণস্বরূপ এর {"f": 1}চেয়ে দুটি বাইট ছোট {"foo": 1}। আপনি যদি সাবধান না হন তবে এটি দ্রুত সংযোজন করতে পারে, যদিও আধুনিক অন ডিস্ক সংক্ষেপণ সাহায্য করে।

— amcgregor

Answer 4

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

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

বাইনারি ফাইল <> জেএসএন (এনকোডড) <> বিএসওএন (এনকোডড)

আপনার ডকুমেন্টের ডেটা ফাইলে পাথ (ইউআরএল) রাখার এবং ডেটা বাইনারি করে রাখাই আরও দক্ষ হবে।

আপনি যদি সত্যিই এই অজানা দৈর্ঘ্যের এই ফাইলগুলি আপনার ডিবিতে রাখতে চান তবে বড় ফাইলগুলি অ্যাক্সেস করার পরে আপনি সম্ভবত এগুলি গ্রিডএফএসে রেখে দেওয়া এবং আপনার সম্মতিটি হুমকির ঝুঁকি না নেওয়াই ভাল।

Comments

"ইতিমধ্যে বিভিন্ন ডাটাবেস রয়েছে যা বড় ফাইলগুলি সংরক্ষণ / পুনরুদ্ধারে খুব দক্ষ; সেগুলিকে অপারেটিং সিস্টেম বলা হয়।"; ব্লগ.মোংডব.অর্গ

— পোস্ট /

Answer 5

বিএসওএন নথিগুলির জন্য নেস্টেড গভীরতা: মঙ্গোডিবি BSON নথিগুলির জন্য নীড়ের 100 টিরও বেশি সমর্থন করে না।

আরও তথ্য ভিস্ট

Answer 6

সম্ভবত একটি ব্লগ পোস্ট সংরক্ষণ করে -> একটি সম্পর্কহীন ডাটাবেসে মন্তব্য সম্পর্কিত সম্পর্কটি সত্যই সেরা নকশা নয়।

আপনার সম্ভবত ব্লগ পোস্টগুলিতে পৃথক সংগ্রহে মন্তব্যগুলি সংরক্ষণ করা উচিত।

[সম্পাদনা]

আরও আলোচনার জন্য নীচে মন্তব্য দেখুন।

Comments

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

— জাস্টিন জেনকিনস

আমি আমার উত্তর সম্ভবত অত্যধিক কঠোর ছিল। মঙ্গোডিবি বা অনুরূপ ডাটাবেসে ব্লগ পোস্টগুলি এবং সম্পর্কিত মন্তব্যগুলি সংরক্ষণ করার ক্ষেত্রে কোনও ভুল নেই। এটি আরও বেশি যে লোকেরা দক্ষতার

— নথিভিত্তিক ডেটাবেসগুলিকে

@ মিশেল: "ব্লগ" ভাল না, তবে পৃথক সংগ্রহে মন্তব্যগুলি সংরক্ষণ করা ঠিক একই কারণে খারাপ is কমেন্টস অ্যারে সহ পোস্টগুলি হ'ল ডকুমেন্টের ড্যানিবল উদাহরণ।

— ম্যাট ব্রিগেস

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

— গেটস ভিপি

@ গেটস ভিপি, আমি পৃথক পূর্ণ পাঠ্য ইঞ্জিন ব্যবহারের বিষয়ে একমত। আমি একটি মেটাডেটা অনুসন্ধানের বিষয়ে ভাবছিলাম। আপনার যদি বুক ডকুমেন্টগুলির একটি সেট থাকে এবং আপনি 1982 সালে প্রকাশিত সমস্ত বই সন্ধান করতে চান? যদি প্রতিটি বইয়ের + 100kb পাঠ্য থাকে তবে আপনি প্রথম 20 টি বইয়ের শিরোনাম প্রদর্শন করতে কয়েকটি মেগাবাইট স্থানান্তর করতে চান না।

— মিকেরোবি

Answer 7

Https://www.mongodb.com/blog/post/6-rules-of-thumb-for-mongodb-schema-design-part-1 অনুসারে

আপনি যদি আশা করেন যে কোনও ব্লগ পোস্ট 16Mb নথির সীমা অতিক্রম করতে পারে, আপনার মন্তব্যগুলি একটি পৃথক সংগ্রহের মধ্যে নিয়ে যাওয়া উচিত এবং মন্তব্য থেকে ব্লগ পোস্টটি উল্লেখ করা উচিত এবং একটি অ্যাপ্লিকেশন-স্তরে যোগদান করা উচিত।

// posts
[
  {
    _id: ObjectID('AAAA'),
    text: 'a post',
    ...
  }
]

// comments
[
  {
    text: 'a comment'
    post: ObjectID('AAAA')
  },
  {
    text: 'another comment'
    post: ObjectID('AAAA')
  }
]