MongoDB

01Գաղափարը՝ փաստաթղթեր տողերի փոխարեն

Պատկերացրեք ռելյացիոն բազան որպես աղյուսակների հավաքածու, որոնք միմյանց հետ join եք անում, իսկ MongoDB-ն՝ որպես թղթապանակների պահարան, որտեղ յուրաքանչյուր թղթապանակ պարունակում է ամեն ինչ մեկ բանի մասին։ Փաստաթուղթը BSON օբյեկտ է (երկուական JSON՝ լրացուցիչ տիպերով, ինչպիսիք են ամսաթվերը, decimal-ները և ObjectId-ն)։ Փաստաթղթերն ապրում են կոլեկցիաներում, իսկ կոլեկցիաները՝ բազայում։ Յուրաքանչյուր փաստաթուղթ ունի եզակի _id։ Մեկ կոլեկցիայի փաստաթղթերը պարտադիր չէ, որ նույն դաշտերն ունենան, բայց գործնականում պետք է ունենան, և դա ապահովում եք JSON Schema validator-ով։ Մեկ փաստաթղթի առավելագույն չափը 16 MB է, և դա ակնարկ է․ փաստաթղթերը սահմանափակ տվյալների համար են, ոչ թե անվերջ ցուցակների։

• BSON՝ երկուական ձևաչափը, որով MongoDB-ն պահում է տվյալները․ այն աջակցում է JSON-ում բացակայող տիպեր, ինչպիսիք են Date-ը և Decimal128-ը։
• Կոլեկցիա՝ փաստաթղթերի խումբ, մոտավորապես աղյուսակի նման։
• ObjectId՝ լռելյայն 12 բայթանոց _id, որը մոտավորապես դասավորված է ըստ ստեղծման ժամանակի։

02Մոդելավորում՝ ներդնել, թե հղել

Դիզայնի հիմնական հարցն այն է, թե կապված տվյալները գնում են ծնող փաստաթղթի ներսում (embed), թե իրենց սեփական կոլեկցիայում՝ id-ով, որը հղում է դրանց (reference)։ Ներդրեք, երբ զավակը պատկանում է ծնողին, կարդացվում է նրա հետ միասին և ունի սահմանափակ չափ՝ պատվերն ու դրա տողերը, օգտատերն ու նրա հասցեները։ Հղեք, երբ զավակը ընդհանուր է, աճում է առանց սահմանի կամ թարմացվում է անկախ՝ հանրաճանաչ գրառման մեկնաբանությունները, բազմաթիվ պատվերներում հղված ապրանքները։ MongoDB-ի սեփական ուղեցույցի հիմնական կանոնն է՝ «տվյալները, որոնց հասանելիությունը միասին է, պետք է միասին պահվեն»։ Նախագծեք հարցումներից դեպի հետ․ նախ թվարկեք էկրաններն ու API կանչերը, ապա ձևավորեք փաստաթղթերն այնպես, որ յուրաքանչյուրը սպասարկվի մեկ ընթերցմամբ։

1// One order document: line items embedded, customer referenced
2{
3  _id: ObjectId("665f1c2a9b1e8a0012345678"),
4  customerId: ObjectId("665f1b009b1e8a0011112222"),
5  status: "paid",
6  total: NumberDecimal("59.90"),
7  items: [
8    { sku: "TSHIRT-M", qty: 2, price: NumberDecimal("19.95") },
9    { sku: "CAP-01", qty: 1, price: NumberDecimal("20.00") }
10  ],
11  createdAt: ISODate("2026-11-05T10:00:00Z")
12}

03Հարցումներ, ինդեքսներ և ESR կանոնը

Հարցումներ եք անում filter փաստաթղթերով ({ status: "paid" }) և օպերատորներով, ինչպիսիք են $gt-ն, $in-ը և $elemMatch-ը։ Առանց ինդեքսի MongoDB-ն սկանավորում է բոլոր փաստաթղթերը (COLLSCAN)։ Ինդեքսները B-tree-ներ են, ճիշտ ինչպես SQL բազաներում, իսկ կոմպոզիտ ինդեքսները հետևում են ESR կանոնին․ նախ դրեք այն դաշտերը, որոնցով համընկնում եք Equality-ով (հավասարություն), ապա այն դաշտերը, որոնցով Sort եք անում, ապա այն դաշտերը, որոնցով ֆիլտրում եք Range-ով (միջակայք)։ { customerId: 1, createdAt: -1 } ինդեքսը կատարյալ սպասարկում է «այս հաճախորդի վերջին պատվերները» հարցումը։ Միշտ ստուգեք հարցումը explain("executionStats")-ով և համեմատեք totalDocsExamined-ը nReturned-ի հետ․ եթե առաջինը շատ ավելի մեծ է, ինդեքսը սխալ է կամ բացակայում է։

1db.orders.createIndex({ customerId: 1, status: 1, createdAt: -1 })
2 
3db.orders
4  .find({ customerId: id, status: "paid", createdAt: { $gte: since } })
5  .sort({ createdAt: -1 })
6  .limit(20)
7  .explain("executionStats")

04Aggregation pipeline-ը

Aggregation-ը MongoDB-ի պատասխանն է GROUP BY-ին և հաշվետվություններին։ Pipeline-ը փուլերի զանգված է, և յուրաքանչյուր փուլ ձևափոխում է փաստաթղթերի հոսքը և փոխանցում հաջորդին՝ հավաքման գծի պես։ $match-ը ֆիլտրում է (դրեք այն առաջինը, որ կարողանա ինդեքս օգտագործել), $group-ը հաշվում է գումարներ, $sort-ը դասավորում է, $project-ը վերաձևավորում է, $lookup-ը join է անում մեկ այլ կոլեկցիա, իսկ $unwind-ը զանգվածը վերածում է մեկ փաստաթղթի յուրաքանչյուր տարրի համար։ Pipeline-ները հզոր են, բայց կարող են ծանրանալ․ միլիոնավոր փաստաթղթերի վրա $group-ը հիշողություն է օգտագործում, իսկ 100 MB-ը գերազանցող փուլերը թափվում են սկավառակ։ $match-ը և $project-ը պահեք վաղ փուլերում, որպեսզի տվյալները փոքրացնեք թանկ փուլերից առաջ։

1db.orders.aggregate([
2  { $match: { status: "paid", createdAt: { $gte: ISODate("2026-10-01") } } },
3  { $unwind: "$items" },
4  { $group: {
5      _id: "$items.sku",
6      units: { $sum: "$items.qty" },
7      revenue: { $sum: { $multiply: ["$items.qty", "$items.price"] } }
8  } },
9  { $sort: { revenue: -1 } },
10  { $limit: 10 }
11])

05Replica set-եր, write concern և տրանզակցիաներ

Replica set-ը նույն տվյալները պահող mongod սերվերների խումբ է․ մեկ primary-ն ընդունում է գրառումները, secondary-ները պատճենում են նրա գործողությունների լոգը (oplog)։ Եթե primary-ն ընկնում է, մնացած անդամները վայրկյանների ընթացքում նորն են ընտրում։ Write concern-ը ցույց է տալիս, թե քանի անդամ պետք է հաստատի գրառումը․ MongoDB 5.0-ից ի վեր լռելյայնը «majority»-ն է, ինչը նշանակում է, որ հաստատված գրառումը վերապրում է failover-ը։ Read concern-ը և read preference-ը կառավարում են, թե ինչ եք կարդում և որտեղից։ Բազմափաստաթղթային ACID տրանզակցիաներ կան (replica set-երում՝ 4.0-ից, sharded կլաստերներում՝ 4.2-ից), բայց դրանք արտադրողականություն են արժենում․ լավ փաստաթղթային մոդելին դրանք հազվադեպ են պետք, քանի որ մեկ փաստաթղթի գրառումն արդեն ատոմար է։

• Պրոդակշնում օգտագործեք առնվազն երեք տվյալներ պահող անդամ՝ բաշխված տարբեր զոնաներում։
• Միացեք replica set-ի ամբողջական connection string-ով, որպեսզի դրայվերները failover-ի ժամանակ գտնեն նոր primary-ին։
• Secondary-ներից կարդալը կարող է վերադարձնել մի փոքր հնացած տվյալներ․ օգտագործեք դա միայն այնտեղ, որտեղ դա ընդունելի է։

06Օգտագործումը հավելվածից

Պաշտոնական դրայվերներ կան Node.js-ի, PHP-ի, Python-ի, Go-ի, Java-ի և այլնի համար։ Node.js-ում շատ թիմեր ավելացնում են Mongoose՝ սխեմաների և վալիդացիայի համար, բայց native դրայվերն էլ լավն է և ավելի բարակ։ Ստեղծեք մեկ client յուրաքանչյուր պրոցեսի համար և վերաօգտագործեք այն․ client-ը պահում է connection pool։ Վալիդացրեք մուտքը եզրին, գումարները պահեք Decimal128-ով (երբեք floating point-ով) և ամսաթվերը պահեք որպես իրական Date արժեքներ UTC-ով։ Միացրեք schema validation-ը կոլեկցիայի մակարդակում, որպեսզի սխալ deploy-ը չկարողանա աղբ գրել։

1import { MongoClient } from "mongodb";
2 
3const client = new MongoClient(process.env.MONGODB_URI!); // reuse per process
4const orders = client.db("shop").collection("orders");
5 
6export async function latestOrders(customerId: ObjectId) {
7  return orders
8    .find({ customerId }, { projection: { items: 0 } })
9    .sort({ createdAt: -1 })
10    .limit(20)
11    .toArray();
12}

07WiredTiger՝ ինչպես է իրականում աշխատում պահեստավորումը

WiredTiger-ը MongoDB-ի storage engine-ն է։ Այն օգտագործում է փաստաթղթի մակարդակի concurrency control, այնպես որ երկու գրող միմյանց արգելափակում են միայն այն ժամանակ, երբ դիպչում են նույն փաստաթղթին։ Տվյալներն ու ինդեքսները B-tree-ներ են՝ սեղմված սկավառակի վրա (լռելյայն snappy, ըստ ցանկության zstd)։ WiredTiger-ը RAM-ում պահում է cache՝ լռելյայն մոտավորապես (RAM-ը հանած 1 GB)-ի 50%-ը․ արտադրողականությունը կախված է նրանից, թե արդյոք working set-ը (հաճախ օգտագործվող փաստաթղթերը գումարած ինդեքսները) տեղավորվում է այնտեղ։ Գրառումները նախ գնում են journal, և պարբերաբար checkpoint են արվում տվյալների ֆայլերում, այնպես որ crash-ից հետո վերականգնումը կատարվում է վերջին checkpoint-ից գումարած journal-ը։ Երբ working set-ը չի տեղավորվում, տեսնում եք cache eviction-ի ճնշում, և սկավառակից ընթերցումները գերիշխում են latency-ում․ դա այն պահն է, երբ պետք է RAM ավելացնել, ինդեքսները կրճատել կամ shard անել։

• Հետևեք db.serverStatus().wiredTiger.cache-ին՝ dirty և evicted բայթերի համար։
• Արագ հարցումների համար ինդեքսները պետք է տեղավորվեն RAM-ում․ չափերը ստուգեք db.collection.stats()-ով։

08Sharding և shard key-ի ընտրություն

Sharding-ը կոլեկցիան բաժանում է մի քանի replica set-երի միջև։ Router-ը (mongos) յուրաքանչյուր հարցում ուղարկում է այն shard-երին, որոնց պատկանում են shard key-ի համապատասխան միջակայքերը։ Shard key-ն որոշում է ամեն ինչ․ այն պետք է ունենա բարձր cardinality, հավասարաչափ բաշխի գրառումները և առկա լինի հարցումների մեծ մասում։ Մոնոտոն աճող key-ը, ինչպիսին timestamp-ն է կամ ObjectId-ն, բոլոր insert-ներն ուղարկում է մեկ shard (hot shard)․ hashed sharding-ը շտկում է բաշխումը, բայց range հարցումները ցրում է բոլոր shard-երով։ Կոմպոզիտ key-ը, ինչպիսին { tenantId: 1, createdAt: 1 }-ն է, հաճախ լավ է աշխատում multi-tenant հավելվածների համար։ 5.0-ից ի վեր կարող եք կոլեկցիան reshard անել online, իսկ 6.0-ից balancer-ն աշխատում է տվյալների չափով, ոչ թե chunk-երի քանակով, բայց resharding-ը դեռևս թանկ է, այնպես որ ընտրեք ուշադիր։

1sh.enableSharding("shop")
2sh.shardCollection("shop.events", { tenantId: 1, createdAt: 1 })
3 
4// Queries that include tenantId are targeted to one shard
5db.events.find({ tenantId: "t_42", createdAt: { $gte: since } })

09Consistency-ի կարգավորիչներ՝ write concern, read concern, causal session-ներ

MongoDB-ն թույլ է տալիս consistency ընտրել յուրաքանչյուր գործողության համար։ Write concern w: "majority"-ն սպասում է, մինչև անդամների մեծամասնությունը ստանա գրառումը, այնպես որ այն վերապրում է failover-ը․ w: 1-ն ավելի արագ է, բայց գրառումը կարող է rollback արվել, եթե primary-ն ընկնի մինչև ռեպլիկացիան։ Read concern "majority"-ն վերադարձնում է միայն մեծամասնության կողմից հաստատված տվյալներ, "linearizable"-ը տալիս է ամենաուժեղ երաշխիքը մեկ փաստաթղթի ընթերցումների համար՝ ավելի բարձր գնով, իսկ "snapshot"-ն օգտագործվում է տրանզակցիաների ներսում։ Causally consistent session-ները երաշխավորում են, որ client-ը կարդում է իր սեփական գրառումները, նույնիսկ secondary-ներից կարդալիս։ Սխալն այն է, երբ կարգավորումները խառնում եք առանց մտածելու․ w: 1-ով գրելը և secondary-ներից կարդալը կարող է օգտատերերին ցույց տալ տվյալներ, որոնք հետո անհետանում են։

10Change stream-ներ, TTL և time series

Change stream-ները թույլ են տալիս հավելվածին բաժանորդագրվել insert-ներին, update-ներին և delete-ներին կոլեկցիայի, բազայի կամ կլաստերի վրա՝ oplog-ի հիման վրա։ Դրանք վերսկսելի են resume token-ով, ինչը դրանք դարձնում է հուսալի աղբյուր որոնման ինդեքսի կամ cache-ի սինքրոնիզացիայի կամ իրադարձությունների հրապարակման համար (հաճախ outbox պատերնի հետ համատեղ)։ TTL ինդեքսները ավտոմատ ջնջում են փաստաթղթերը որոշակի ժամանակ անց, ինչը օգտակար է session-ների և ժամանակավոր token-ների համար։ Time series կոլեկցիաները չափումները արդյունավետ պահում են bucket-ներում՝ ավտոմատ սեղմումով, ինչը հարմար է մետրիկների և IoT տվյալների համար։ Atlas-ը նաև ավելացնում է Atlas Search (Lucene-ի վրա հիմնված full text) և Vector Search, իսկ Community և Enterprise վերջին թողարկումները սկսել են search-ը և vector search-ը բերել նաև սեփական սերվերի վրա տեղակայումներին։

1// Expire sessions 24 hours after createdAt
2db.sessions.createIndex({ createdAt: 1 }, { expireAfterSeconds: 86400 })
3 
4// React to new paid orders
5const stream = db.orders.watch([{ $match: { "fullDocument.status": "paid" } }],
6  { fullDocument: "updateLookup" })