মঙ্গো সংগ্রহ `আকার`` স্টোরেজ সাইজ` এর চেয়ে * বড় *?

Question

কমান্ডটি ব্যবহার করে আমি সম্প্রতি আমার সংগ্রহটি সংযোগ করেছি:

 db.<collectionName>.runCommand( "compact" )

এবং এখন আমার সংগ্রহের আকারটি ডিস্কের আকারের চেয়ে বড় বলে মনে হচ্ছে!

SECONDARY> db.<collectionName>.stats()
{
"ns" : "<databaseName>.<collectionName>",
"count" : 2937359,
"size" : 5681676492,                   # 5.6 GB
"avgObjSize" : 1934.2805874256433,
"storageSize" : 4292853728,            # 4.2 GB
"numExtents" : 2,
"nindexes" : 2,
"lastExtentSize" : 2146426864,
"paddingFactor" : 1.669999999836597,
"flags" : 1,
"totalIndexSize" : 220735648,
"indexSizes" : {
    "_id_" : 162326304,
    "e_1_" : 58409344
},
"ok" : 1

}

আমি বুঝতে পারি না কীভাবে এটি সম্ভব। সমস্ত মঙ্গোদব সংগ্রহগুলি কি সব সময় ব্যাক-ডিস্ক-ব্যাক-ডিস্ক নয়?

কেউ কি এই ফলাফল ব্যাখ্যা করতে পারেন?

Comments

আমি এর আগেও পরিসংখ্যান দেখেছি, তবে এর ব্যাখ্যা নেই। একটি চালানোর চেষ্টা করবেন validate?

— ইভ ফ্রিম্যান

Answer 1

storageSize সূচকগুলি বাদ দিয়ে সেই ডেটার জন্য সমস্ত এক্সেটেন্টের যোগফল।

সুতরাং যে সংগ্রহটি 2 টি এক্সটেন্ট নেয়, সেগুলি প্রতি 2 গিগাবাইট, অতএব 4 গিগাবাইট। sizeসূচীগুলি অন্তর্ভুক্ত করে এবং আমি বিশ্বাস করি যে সংখ্যাটি আরও বাড়িয়ে দেয় other উভয়ই সত্যই সঠিক অনস্ক্রিয় আকারের প্রতিনিধিত্ব করে না। ডিস্ক আকারের জন্য, db.stats()একটি ফাইলের আকারের ক্ষেত্র রয়েছে যা আপনি যা চাইছেন তার কাছাকাছি যা আমি মনে করি যে আপনি খুঁজছেন।

বিভিন্ন ক্ষেত্রের অর্থ কী তা রূপরেখায় ম্যানুয়ালটি কিছুটা ভাল, সংগ্রহের জন্য এখানে দেখুন:

http://docs.mongodb.org/manual/reference/collection-statistics/

এবং এখানে ডাটাবেস পরিসংখ্যান জন্য:

http://docs.mongodb.org/manual/reference/database-statistics/

---

কিছু অন্যান্য সম্ভাব্য প্রাসঙ্গিক তথ্য:

কমপ্যাক্ট কমান্ড কোনও ডেটা ফাইলগুলি সঙ্কুচিত করে না; এটি কেবল স্থান মুছে ফেলা হয়েছে যাতে বৃহত্তর অবজেক্টগুলি এটি পুনরায় ব্যবহার করতে পারে। কমপ্যাক্ট কমান্ডটি কখনই ডাটাবেস ফাইলগুলি মুছতে বা সঙ্কুচিত করতে পারে না এবং সাধারণত এটির কাজ করতে অতিরিক্ত স্থানের প্রয়োজন হয়, সাধারণত সর্বনিম্ন এক অতিরিক্ত পরিমাণে।

আপনি যদি ডাটাবেসটি মেরামত করেন তবে এটি প্রাথমিকভাবে স্ক্র্যাচ থেকে ডেটা ফাইলগুলি পুনরায় লিখন করবে, যা প্যাডিং সরিয়ে ফেলবে এবং এগুলি আপনি যতটা দক্ষতার সাথে যাচ্ছেন তেমন দক্ষতার সাথে ডিস্কে সংরক্ষণ করবে। তবে এটি করতে আপনার ডিস্কে আকারের 2x ডলার প্রয়োজন (আসলে কম, তবে এটি একটি শালীন গাইড)।

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

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

http://www.mongodb.org/display/DOCS/Padding+Factor

Comments

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

— ক্রিস ডাব্লু।

৪.২ গিগাবাইটের ডিস্কটি কেবলমাত্র ডেটা, ৫. is জিবি হ'ল ডাটা প্লাস সূচক এবং তারপরে প্রকৃত ডিস্ক আকারের জন্য আপনাকে সম্ভবত এর পরিবর্তে ডাটাবেস স্তরের পরিসংখ্যানগুলি দেখতে হবে

— অ্যাডাম সি

আমি দৌড়ে একই জিনিস! আশ্চর্যের বিষয়টি হ'ল তাদের দস্তাবেজে এটি বলে যে আকার সূচকগুলির জন্য হিসাব করে না: "অতিরিক্ত আকারে সংগ্রহের সাথে সম্পর্কিত কোনও সূচকের আকার অন্তর্ভুক্ত নয়, যা টোটাল ইন্ডেক্সসাইজ ফিল্ড রিপোর্ট করে" "

— মাতিজাশ

কারণটি হ'ল আকারটি সংকুচিত ডেটা আকার প্রদর্শন করে, যখন স্টোরেজ আকার অ্যাকাউন্টে সংকোচনে লাগে। এটি ডিবি স্তরে এখানে বর্ণিত হয়েছে, তবে সংগ্রহের জন্য এটি প্রযোজ্য বলে মনে হচ্ছে: ডকস.মোংডব.ম্যানুয়াল

— রেফারেন্স

Answer 2

মংডোব> 3.x এর জন্য

For MMAPv1: 
datasize < storageSize

but For wiredTiger
datasize > storageSize (most cases due to compression but may be
                        storageSize greater, it varies on condition like
                        compression technique, whether compact/repair 
                        command run or not)

Db.get Colલેક્શન ('নাম') এর জন্য st

size = total size in memory of all records in a collection + padding (excluded index size + record header which is 16 byte per header, header means  = field name)        
avgObjSize = avg size of obj + padding
storageSize =  total amount of storage allocated to this collection for document storage. (totalIndex size excluded)
totalIndexSize : totalIndexSize (compressed in case of wiredTiger)

Db.stats এর জন্য ()

dataSize = document + padding
storageSize = document + padding + deleted space
fileSize = document + padding extents +  index extents + yet-unused space

আমরা এর দ্বারা অব্যবহৃত স্থান বা গর্তটি মুছতে পারি

db.getCollection('name').runCommand( "compact" )

কমপ্যাক্ট বা মেরামত কমান্ড চালানোর পরে আমরা সঠিক স্টোরেজ আকার এবং ডেটা আকারের পার্থক্য পেতে পারি।

মোংডব ওয়্যারড টাইগারে সংক্ষেপণ প্রযুক্তি:

- snappy : good compression, low overhead
- zlib: better compression, more CPU
- none (we can disable compression, by default its enable in WT)