سوالات مصاحبه NoSQL و MongoDB سطح سینیور (50 سوال)

Question 1

چرا shard key با cardinality پایین مثل `country` (حدود ۲۰۰ مقدار) برای یک collection بزرگ مشکل‌ساز است؟

Accepted Answer

تعداد chunkهای قابل‌تقسیم محدود می‌شود و chunkهای پرحجم به jumbo chunk غیرقابل‌انتقال تبدیل می‌شوند

Answer

MongoDB shard key رشته‌ای را نمی‌پذیرد

Answer

کوئری‌ها روی این فیلد همیشه scatter-gather می‌شوند

Answer

replication بین shardها متوقف می‌شود

Question 2

استفاده از `{ createdAt: 1 }` یا `_id` از نوع ObjectId به‌عنوان ranged shard key چه مشکلی ایجاد می‌کند؟

Accepted Answer

همه insertها به chunk انتهایی (maxKey) روی یک shard می‌روند و آن shard به hotspot نوشتن تبدیل می‌شود

Answer

documentها به‌صورت تصادفی بین shardها پخش می‌شوند و range query ممکن نیست

Answer

ObjectId به‌عنوان shard key مجاز نیست

Answer

balancer همه chunkها را مدام جابه‌جا می‌کند ولی بار نوشتن پخش می‌شود

Question 3

trade-off اصلی hashed sharding در مقایسه با ranged sharding چیست؟

Accepted Answer

نوشتن‌ها یکنواخت پخش می‌شوند، اما range queryها روی shard key به scatter-gather روی همه shardها تبدیل می‌شوند

Answer

range queryها سریع‌تر می‌شوند ولی نوشتن‌ها روی یک shard متمرکز می‌شوند

Answer

hashed sharding فقط برای فیلدهای عددی کار می‌کند

Answer

hashed sharding نیاز به config server را حذف می‌کند

Question 4

در یک cluster با shard key `{ userId: 1 }`، کوئری `find({ email: 'x@y.com' })` چگونه اجرا می‌شود؟

Accepted Answer

`mongos` آن را به همه shardها ارسال (broadcast) و نتایج را ادغام می‌کند

Answer

فقط به shard primary database ارسال می‌شود

Answer

کوئری با خطا رد می‌شود چون shard key ندارد

Answer

`mongos` با hash ایمیل shard درست را پیدا می‌کند

Question 5

در یک SaaS چندمستأجری، چرا shard key `{ tenantId: 1, _id: 1 }` اغلب بهتر از `{ tenantId: 1 }` به‌تنهایی است؟

Accepted Answer

کوئری‌های هر tenant هدفمند می‌مانند و داده tenantهای بزرگ همچنان قابل تقسیم به چند chunk است

Answer

چون MongoDB فقط shard keyهای دو فیلدی را می‌پذیرد

Answer

چون `_id` داده را رمزنگاری می‌کند

Answer

چون همه tenantها را روی یک shard نگه می‌دارد

Question 6

jumbo chunk در MongoDB چیست و علت اصلی آن چیست؟

Accepted Answer

chunkی بزرگ‌تر از اندازه مجاز که چون همه documentها مقدار shard key یکسان دارند قابل تقسیم نیست

Answer

chunkی که شامل documentهای بیش از ۱۶MB است

Answer

chunkی که روی config server ذخیره شده است

Answer

chunkی که عمداً برای backup ساخته شده است

Question 7

در MongoDB مدرن (5.0+)، اگر shard key اشتباه انتخاب شده باشد چه گزینه‌ای وجود دارد؟

Accepted Answer

`reshardCollection` که داده را به‌صورت آنلاین با shard key جدید بازتوزیع می‌کند

Answer

هیچ راهی جز dump و restore کامل با downtime وجود ندارد

Answer

تغییر مستقیم فیلد `key` در config database

Answer

حذف همه indexها تا MongoDB خودش shard key جدید انتخاب کند

Question 8

zone sharding در MongoDB برای چه سناریویی مناسب است؟

Accepted Answer

نگه‌داشتن داده کاربران اروپایی روی shardهای مستقر در اروپا برای رعایت مقررات و latency

Answer

فشرده‌سازی داده‌های قدیمی

Answer

اجرای election سریع‌تر

Answer

حذف نیاز به shard key

Question 9

هنگام network partition، primary یک replica set که در سمت اقلیت قرار گرفته چه می‌کند؟

Accepted Answer

step down می‌کند و نوشتن نمی‌پذیرد؛ سمت اکثریت primary جدید انتخاب می‌کند

Answer

به پذیرش نوشتن ادامه می‌دهد و بعداً conflictها merge می‌شوند

Answer

کل cluster را خاموش می‌کند

Answer

به arbiter تبدیل می‌شود

Question 10

قضیه PACELC چه چیزی را به CAP اضافه می‌کند؟

Accepted Answer

حتی بدون partition (Else)، سیستم باید بین Latency و Consistency یکی را ترجیح دهد

Answer

اینکه partition tolerance اختیاری است

Answer

اینکه می‌توان هم‌زمان هر سه ویژگی CAP را داشت

Answer

معیاری برای اندازه‌گیری throughput دیسک

Question 11

در Cassandra با replication factor برابر ۳، کدام ترکیب consistency level خواندن قوی (read-your-writes) را تضمین می‌کند؟

Accepted Answer

نوشتن با `QUORUM` و خواندن با `QUORUM`، چون 2 + 2 > 3

Answer

نوشتن با `ONE` و خواندن با `ONE`

Answer

نوشتن با `ONE` و خواندن با `QUORUM`

Answer

نوشتن با `ANY` و خواندن با `TWO`

Question 12

در یک cluster چند دیتاسنتری Cassandra، چرا `LOCAL_QUORUM` معمولاً به `QUORUM` ترجیح داده می‌شود؟

Accepted Answer

فقط quorum در دیتاسنتر محلی را منتظر می‌ماند و از latency بین دیتاسنترها و وابستگی به دسترس‌پذیری آن‌ها جلوگیری می‌کند

Answer

داده را در همه دیتاسنترها هم‌زمان تأیید می‌کند

Answer

consistency قوی‌تری از `ALL` می‌دهد

Answer

replication به دیتاسنترهای دیگر را غیرفعال می‌کند

Question 13

چرا الگوی «صف» با insert و delete زیاد در یک partition در Cassandra عملکرد خواندن را خراب می‌کند؟

Accepted Answer

delete یک tombstone می‌نویسد و خواندن‌ها باید تا compaction پس از `gc_grace_seconds` از روی هزاران tombstone عبور کنند

Answer

delete در Cassandra کل partition را قفل می‌کند

Answer

Cassandra از delete پشتیبانی نمی‌کند و داده فقط با TTL حذف می‌شود

Answer

هر delete باعث rebuild کامل index می‌شود

Question 14

Cassandra هنگام وجود دو نوشتن هم‌زمان روی یک ستون در replicaهای مختلف، چگونه conflict را حل می‌کند؟

Accepted Answer

last-write-wins بر اساس timestamp هر سلول، که در برابر clock skew آسیب‌پذیر است

Answer

با vector clock و برگرداندن همه نسخه‌ها به client

Answer

با قفل توزیع‌شده قبل از هر نوشتن

Answer

نوشتن دوم همیشه رد می‌شود

Question 15

چرا نوشتن در Cassandra (موتور مبتنی بر LSM-tree) بسیار سریع است؟

Accepted Answer

نوشتن فقط به commit log به‌صورت ترتیبی append و در memtable حافظه ثبت می‌شود؛ SSTableها بعداً flush و compact می‌شوند

Answer

نوشتن‌ها مستقیماً در جای خود روی B-tree دیسک به‌روزرسانی می‌شوند

Answer

نوشتن‌ها تا تأیید همه replicaها در حافظه client می‌مانند

Answer

Cassandra داده را هرگز روی دیسک نمی‌نویسد

Question 16

کدام مکانیزم در Cassandra replicaهای ناسازگار را با مقایسه Merkle tree همگام می‌کند؟

Accepted Answer

anti-entropy repair (`nodetool repair`)

Answer

hinted handoff

Answer

read repair

Answer

gossip protocol

Question 17

برای ذخیره میلیاردها اندازه‌گیری سنسور در Cassandra، چرا partition key را `((sensor_id, day))` قرار می‌دهند نه فقط `sensor_id`؟

Accepted Answer

تا partitionها بی‌نهایت رشد نکنند و اندازه آن‌ها محدود و قابل مدیریت بماند

Answer

چون Cassandra فقط partition key دو ستونی را می‌پذیرد

Answer

تا داده همه سنسورها روی یک node قرار گیرد

Answer

تا نیاز به clustering key از بین برود

Question 18

مزیت consistent hashing با virtual nodes (vnodes) در سیستم‌هایی مثل Cassandra چیست؟

Accepted Answer

افزودن یا حذف یک node فقط بخش کوچکی از داده را جابه‌جا می‌کند و بار به‌طور یکنواخت‌تر بین nodeها پخش می‌شود

Answer

همه داده‌ها روی همه nodeها کپی می‌شوند

Answer

نیاز به replication را حذف می‌کند

Answer

کوئری‌های range روی partition key را کارآمد می‌کند

Question 19

هزینه lightweight transaction در Cassandra مثل `INSERT ... IF NOT EXISTS` چیست؟

Accepted Answer

از Paxos استفاده می‌کند و چند round-trip بین replicaها دارد، پس latency بسیار بیشتری از نوشتن معمولی دارد

Answer

هیچ هزینه اضافه‌ای ندارد

Answer

کل cluster را تا پایان قفل می‌کند

Answer

فقط روی یک node بدون replication اجرا می‌شود

Question 20

برای جدولی که همه رأی‌ها با partition key `candidateId` نوشته می‌شود و یک نامزد بسیار محبوب است، راه‌حل رایج hot partition چیست؟

Accepted Answer

write sharding: افزودن suffix تصادفی مثل `candidateId#7` و جمع زدن نتایج هنگام خواندن

Answer

افزایش provisioned capacity کل جدول به‌تنهایی همیشه کافی است

Answer

تبدیل همه نوشتن‌ها به `Scan`

Answer

افزودن یک LSI روی `candidateId`

Question 21

سقف throughput یک partition فیزیکی در DynamoDB تقریباً چقدر است؟

Accepted Answer

۳۰۰۰ RCU و ۱۰۰۰ WCU در ثانیه

Answer

۴۰۰۰۰ RCU و ۴۰۰۰۰ WCU در ثانیه

Answer

۱۰۰ RCU و ۱۰ WCU در ثانیه

Answer

محدودیتی ندارد

Question 22

ایده اصلی single-table design در DynamoDB چیست؟

Accepted Answer

نگه‌داشتن چند نوع entity در یک جدول با کلیدهای عمومی مثل `PK = USER#123` و `SK = ORDER#456` تا داده مرتبط با یک `Query` خوانده شود

Answer

هر جدول فقط یک item داشته باشد

Answer

همه داده در یک attribute JSON بزرگ ذخیره شود

Answer

استفاده از یک جدول برای همه محیط‌های dev و prod

Question 23

sparse GSI در DynamoDB چگونه کار می‌کند؟

Accepted Answer

فقط itemهایی که attribute کلید GSI را دارند وارد index می‌شوند، پس می‌توان با آن زیرمجموعه کوچکی را مستقیم کوئری کرد

Answer

GSI فقط هر چند item یکی را نمونه‌برداری می‌کند

Answer

GSI بدون partition key تعریف می‌شود

Answer

itemها پس از مدتی از GSI حذف می‌شوند

Question 24

چگونه در DynamoDB از lost update بین دو client هم‌زمان جلوگیری می‌شود؟

Accepted Answer

optimistic locking با attribute `version` و `ConditionExpression: 'version = :expected'` در هر update

Answer

با strongly consistent read به‌تنهایی

Answer

با `Scan` قبل از هر نوشتن

Answer

DynamoDB به‌طور خودکار همه updateها را merge می‌کند

Question 25

کدام جمله درباره `TransactWriteItems` در DynamoDB درست است؟

Accepted Answer

تا ۱۰۰ item را به‌صورت اتمیک می‌نویسد و تقریباً دو برابر capacity نوشتن معمولی مصرف می‌کند

Answer

تعداد itemها نامحدود است و هزینه اضافه‌ای ندارد

Answer

فقط داخل یک partition کار می‌کند

Answer

isolation ندارد و نتایج میانی قابل مشاهده است

Question 26

در protocol election مونگو (pv1، مبتنی بر Raft) کدام secondary احتمال بیشتری برای primary شدن دارد؟

Accepted Answer

عضوی با oplog به‌روزتر که رأی اکثریت را در یک term جدید بگیرد؛ priority بالاتر هم ترجیح داده می‌شود

Answer

عضوی که بیشترین فضای دیسک را دارد

Answer

عضوی که اول به cluster اضافه شده است

Answer

arbiter، چون داده ندارد و سریع‌تر است

Question 27

وقتی primary قدیمی پس از failover به replica set برمی‌گردد و نوشتن‌هایی دارد که به اکثریت نرسیده بودند، چه می‌شود؟

Accepted Answer

آن نوشتن‌ها rollback می‌شوند و در فایل‌های rollback ذخیره می‌شوند تا به‌صورت دستی بررسی شوند

Answer

آن نوشتن‌ها به‌طور خودکار با primary جدید merge می‌شوند

Answer

primary قدیمی دوباره primary می‌شود و داده جدید را دور می‌ریزد

Answer

کل replica set متوقف می‌شود

Question 28

causally consistent session در MongoDB چه تضمینی برای خواندن از secondaryها می‌دهد؟

Accepted Answer

read-your-writes و monotonic reads، با منتظر ماندن secondary تا رسیدن به `operationTime` session

Answer

همه secondaryها هم‌زمان با primary به‌روز می‌شوند

Answer

خواندن همیشه به primary هدایت می‌شود

Answer

هیچ تضمینی؛ فقط latency را کم می‌کند

Question 29

read concern `'linearizable'` در MongoDB چه ویژگی‌ها و محدودیت‌هایی دارد؟

Accepted Answer

فقط روی primary و برای کوئری‌هایی که یک document را برمی‌گردانند، و تضمین می‌کند همه نوشتن‌های majority قبلی دیده شوند

Answer

روی هر secondary کار می‌کند و سریع‌ترین read concern است

Answer

فقط داخل multi-document transaction قابل استفاده است

Answer

داده تأییدنشده را هم برمی‌گرداند

Question 30

در یک multi-document transaction با `readConcern: 'snapshot'`، خواندن‌ها چه رفتاری دارند؟

Accepted Answer

همه خواندن‌ها یک snapshot ثابت از داده majority-committed در زمان شروع را می‌بینند

Answer

هر خواندن جدیدترین داده، حتی uncommitted، را می‌بیند

Answer

خواندن‌ها قفل exclusive روی collection می‌گیرند

Answer

خواندن‌ها فقط از secondary انجام می‌شوند

Question 31

وقتی یک transaction در MongoDB با خطای دارای label `TransientTransactionError` (مثلاً write conflict) شکست می‌خورد، رفتار درست چیست؟

Accepted Answer

کل transaction از ابتدا دوباره اجرا شود؛ helper `withTransaction()` این کار را خودکار انجام می‌دهد

Answer

فقط آخرین عملیات دوباره اجرا شود

Answer

خطا را نادیده گرفته و commit کنید

Answer

read concern را به `'local'` تغییر دهید

Question 32

چرا transactionهایی که چند shard را درگیر می‌کنند گران‌تر از transactionهای تک‌shard هستند؟

Accepted Answer

به two-phase commit با هماهنگ‌کننده بین shardها نیاز دارند که round-tripها و latency را افزایش می‌دهد

Answer

MongoDB transactionهای چند shardی را پشتیبانی نمی‌کند

Answer

کل cluster در طول transaction فقط‌خواندنی می‌شود

Answer

داده‌ها قبل از commit به یک shard منتقل می‌شوند

Question 33

اگر consumer یک change stream چند ساعت خاموش باشد و resume token آن از oplog خارج شده باشد، چه اتفاقی می‌افتد؟

Accepted Answer

resume شکست می‌خورد و باید یک بازسازی کامل (full resync) انجام داد یا از نقطه جدید شروع کرد

Answer

MongoDB رویدادهای از دست رفته را از backup بازسازی می‌کند

Answer

change stream به‌طور خودکار از ابتدای collection شروع می‌کند

Answer

رویدادها در صف `mongos` ذخیره شده‌اند

Question 34

چرا الگوی «ذخیره در MongoDB و سپس publish در Kafka» در کد application قابل اعتماد نیست و جایگزین آن چیست؟

Accepted Answer

crash بین دو عملیات باعث ناسازگاری می‌شود؛ باید رویداد را در همان نوشتن (outbox) ذخیره و با change stream/CDC منتشر کرد

Answer

Kafka با MongoDB سازگار نیست

Answer

باید ابتدا publish و سپس ذخیره کرد تا مشکل حل شود

Answer

استفاده از `w: 0` این مشکل را حل می‌کند

Question 35

WiredTiger کنترل هم‌زمانی نوشتن‌ها را در چه سطحی انجام می‌دهد؟

Accepted Answer

در سطح document با optimistic concurrency و MVCC؛ conflictها به‌صورت داخلی retry می‌شوند

Answer

یک قفل سراسری برای کل database

Answer

قفل در سطح collection برای هر نوشتن

Answer

قفل در سطح فایل سیستم‌عامل

Question 36

وقتی working set (داده و indexهای پرکاربرد) از اندازه WiredTiger cache بزرگ‌تر شود چه علامتی ظاهر می‌شود؟

Accepted Answer

افزایش شدید page fault و I/O دیسک، و جهش latency کوئری‌ها

Answer

کوئری‌ها خطای out-of-memory می‌دهند و داده حذف می‌شود

Answer

MongoDB به‌طور خودکار shard جدید می‌سازد

Answer

هیچ اثری ندارد چون همه چیز روی دیسک است

Question 37

query planner مونگو وقتی چند index کاندیدا وجود دارد چگونه انتخاب می‌کند؟

Accepted Answer

planهای کاندیدا را به‌صورت آزمایشی رقابت می‌دهد، برنده را برای آن query shape در plan cache نگه می‌دارد

Answer

همیشه index با کمترین اندازه را انتخاب می‌کند

Answer

همیشه جدیدترین index ساخته‌شده را انتخاب می‌کند

Answer

به‌صورت تصادفی یک index انتخاب می‌کند

Question 38

چرا برای کوئری پرتکرار روی `{ a, b }` یک compound index معمولاً از دو single-field index جداگانه بهتر است؟

Accepted Answer

planner به‌ندرت index intersection را انتخاب می‌کند و compound index مستقیماً به کلیدهای منطبق می‌رسد و sort را هم پشتیبانی می‌کند

Answer

MongoDB نمی‌تواند بیش از یک single-field index در هر collection داشته باشد

Answer

single-field indexها روی دیسک ذخیره نمی‌شوند

Answer

compound index هیچ هزینه نوشتنی ندارد

Question 39

کاربرد hidden index در MongoDB (4.4+) چیست؟

Accepted Answer

ارزیابی اثر حذف یک index بدون drop واقعی، چون planner آن را نادیده می‌گیرد ولی index همچنان نگهداری می‌شود

Answer

پنهان کردن داده حساس از کاربران

Answer

ساخت index فقط روی secondaryها

Answer

index که در `explain()` نمایش داده نمی‌شود ولی استفاده می‌شود

Question 40

برای ساخت یک index بزرگ روی replica set پرترافیک با کمترین اثر روی primary، چه رویکردی رایج است؟

Accepted Answer

rolling index build: ساخت روی هر secondary به‌صورت standalone، سپس step down کردن primary و ساخت روی آن

Answer

drop کردن همه indexها و ساخت دوباره در ساعت اوج

Answer

تبدیل موقت replica set به standalone

Answer

ساخت index فقط روی arbiter

Question 41

stage `$merge` در انتهای aggregation برای چه سناریویی مفید است؟

Accepted Answer

ساخت on-demand materialized view که نتایج را به‌صورت افزایشی در یک collection upsert می‌کند

Answer

ادغام دو replica set در یکی

Answer

ترکیب دو index در یک index

Answer

merge کردن conflictهای نوشتن هم‌زمان

Question 42

time-series collection در MongoDB (5.0+) چگونه داده را بهینه ذخیره می‌کند؟

Accepted Answer

اندازه‌گیری‌ها را بر اساس `metaField` و بازه زمانی به‌طور داخلی در bucketهای ستونی فشرده گروه‌بندی می‌کند

Answer

هر اندازه‌گیری را در یک shard جدا قرار می‌دهد

Answer

داده را فقط در حافظه نگه می‌دارد

Answer

indexها را غیرفعال می‌کند

Question 43

چرا documentی که تازه در Elasticsearch index شده ممکن است بلافاصله در نتایج جستجو ظاهر نشود؟

Accepted Answer

Elasticsearch near real-time است و document فقط پس از refresh (پیش‌فرض هر ۱ ثانیه) برای جستجو قابل مشاهده می‌شود

Answer

indexing همیشه چند دقیقه طول می‌کشد

Answer

document فقط پس از restart نود قابل جستجو است

Answer

جستجو همیشه از replica قدیمی روزانه انجام می‌شود

Question 44

چرا انتخاب تعداد primary shardهای یک index در Elasticsearch تصمیم مهمی است؟

Accepted Answer

پس از ساخت index به‌راحتی تغییر نمی‌کند و نیاز به reindex یا split/shrink دارد؛ shardهای زیاد هم overhead دارند

Answer

تعداد shardها هر زمان بدون هزینه قابل تغییر است

Answer

تعداد shard فقط روی امنیت اثر دارد

Answer

Elasticsearch همیشه فقط یک shard دارد

Question 45

بهترین روش رایج برای همگام نگه‌داشتن Elasticsearch با داده اصلی در MongoDB چیست؟

Accepted Answer

MongoDB منبع حقیقت بماند و تغییرات از طریق CDC (change streams یا Debezium) به Elasticsearch منتقل شود

Answer

Elasticsearch به‌عنوان تنها پایگاه‌داده transactional استفاده شود

Answer

application در هر درخواست به هر دو بنویسد و خطاها را نادیده بگیرد

Answer

هر شب کل داده را دستی کپی کنید و جستجوی real-time نداشته باشید

Question 46

چرا پیمایش‌های عمیق (مثلاً ۵ hop) در Neo4j سریع‌تر از joinهای بازگشتی در SQL هستند؟

Accepted Answer

index-free adjacency: هر node اشاره‌گر مستقیم به relationshipهایش دارد، پس هزینه هر hop به اندازه کل داده بستگی ندارد

Answer

Neo4j همه داده را در یک جدول بزرگ نگه می‌دارد

Answer

Neo4j نتایج همه پیمایش‌ها را از قبل محاسبه می‌کند

Answer

Neo4j از B-tree برای هر hop استفاده می‌کند که سریع‌تر از SQL است

Question 47

در سیستم‌های Dynamo-style مثل Riak، vector clock چه مزیتی نسبت به last-write-wins دارد؟

Accepted Answer

نوشتن‌های واقعاً هم‌زمان را تشخیص می‌دهد و نسخه‌های متضاد (siblings) را برای merge نگه می‌دارد، به‌جای حذف بی‌صدای یکی

Answer

نیاز به replication را حذف می‌کند

Answer

ساعت‌های همه nodeها را دقیقاً همگام می‌کند

Answer

حجم داده را فشرده می‌کند

Question 48

retryable writes در MongoDB چگونه از اعمال دوباره یک `insertOne` پس از خطای شبکه جلوگیری می‌کند؟

Accepted Answer

driver یک session id و transaction number به نوشتن می‌دهد و سرور تکرار با همان شناسه را تشخیص داده و نتیجه قبلی را برمی‌گرداند

Answer

driver قبل از retry کل collection را scan می‌کند

Answer

سرور همه نوشتن‌های تکراری را با unique index روی همه فیلدها رد می‌کند

Answer

retryable writes فقط درخواست را بدون هیچ تضمینی دوباره می‌فرستد

Question 49

در document versioning pattern برای نگه‌داشتن تاریخچه قراردادها، طراحی رایج چیست؟

Accepted Answer

نسخه جاری در collection اصلی با فیلد `revision` و نسخه‌های قبلی در یک collection تاریخچه جدا ذخیره می‌شوند

Answer

همه نسخه‌ها در یک آرایه بی‌کران داخل document اصلی

Answer

هر نسخه به‌عنوان یک database جدا

Answer

MongoDB به‌طور خودکار همه نسخه‌ها را نگه می‌دارد

Question 50

اگر `username` در میلیون‌ها کامنت denormalize شده باشد، هزینه اصلی تغییر نام کاربری چیست و چه زمانی این طراحی قابل قبول است؟

Accepted Answer

write amplification و ناسازگاری موقت؛ قابل قبول است وقتی تغییر نادر و خواندن بسیار پرتکرار باشد و به‌روزرسانی async تحمل شود

Answer

هیچ هزینه‌ای ندارد چون MongoDB خودکار همه کپی‌ها را به‌روز می‌کند

Answer

denormalization همیشه anti-pattern است و هرگز قابل قبول نیست

Answer

فقط فضای دیسک بیشتری مصرف می‌کند و روی نوشتن اثری ندارد