როგორ მოქმედებს write concern და read concern თანმიმდევრობაზე?

Question

Accepted Answer

**Write concern** და **read concern** აკონტროლებენ თანმიმდევრობის და დამტკიცების გარანტიებს MongoDB-ში (replica set-ებში) — **შედეგობის** და **უსაფრთხოების/თანმიმდევრობის** შორის ვაჭრობით. ისინი საშუალებას გაძლევთ დააკონკრეტოთ, რამდენად ძლიერად დამტკიცდებიან write-ები და რამდენად თანმიმდევრი იყოს read-ები, მონაცემების მოთხოვნების საფუძველზე.

## Write concern — write-ების დამტკიცება

```js
// write concern: how many nodes must acknowledge a write
db.orders.insertOne(doc, { writeConcern: { w: 1 } });           // primary only — fast
db.orders.insertOne(doc, { writeConcern: { w: "majority" } });   // majority of nodes — safe
db.orders.insertOne(doc, { writeConcern: { w: "majority", j: true } }); // + journaled to disk
```

```text
w: 1          → only the PRIMARY acknowledges (fast, but a write could be LOST on failover)
w: "majority" → a majority of nodes acknowledge → the write SURVIVES primary failover
               (no data loss) — safer but slower (waits for replication)
j: true       → also wait for the write to be written to the JOURNAL (disk durability)
```

**Write concern** აკონტროლებს დამტკიცებას: `w: "majority"` უზრუნველყოფს, რომ write აკრეფილია უმრავლესობამდე (failover გადარჩება ზარალის გარეშე), მაგრამ უფრო ნელია; `w: 1` უფრო სწრაფია, მაგრამ write შეიძლება დაკარგდეს, თუ primary ვერ დაამტკიცა დანაბარი.

## Read concern — read-ების თანმიმდევრობა

```js
db.orders.find().readConcern("majority");   // read data acknowledged by a majority
```

```text
local        → returns the most recent data on the node (may not be majority-committed,
               could be rolled back) — default, fast
majority     → returns only data acknowledged by a majority (won't be rolled back) — consistent
linearizable → strongest (reflects all prior majority writes) — slowest
```

**Read concern** აკონტროლებს რა მონაცემებს ხედავენ read-ები: `majority` აბრუნებს მხოლოდ უმრავლესობის მიერ დამტკიცებულ მონაცემებს (rollback არ იქნება — თანმიმდევრი), ხოლო `local` (უახლესი ლოკალური მონაცემი, შესაძლოა ჯერ არ დამტკიცებული უმრავლესობის მიერ).

## თანმიმდევრობა და შედეგობის ვაჭრობა

```text
Stronger guarantees (w: majority, readConcern: majority) → safer, consistent, but SLOWER
Weaker guarantees (w: 1, readConcern: local) → faster, but risk of data loss on failover
  or reading not-yet-durable data
→ Choose based on the data: critical data (payments) → strong; less critical → faster.
→ Reading from secondaries adds eventual-consistency considerations (stale reads).
```

## რატომ არის ეს მნიშვნელოვანი

Write concern და read concern-ის გაგება მნიშვნელოვანია **MongoDB replica set-ებში თანმიმდევრობა-შედეგობის ვაჭრობის აღმეზობლობის მისაღებად**, ამიტომ ეს ღირებული უფროსი დონის ცოდნაა სწორი, სათანადოდ დაკომპილირებული განაწილებული MongoDB აპლიკაციების აგებისთვის.

ეს პარამეტრები აკონტროლებენ MongoDB-ის თანმიმდევრობის და დამტკიცების გარანტიებს, და მათი გაგება აუცილებელია იმისთვის, რომ მონაცემი ჩაიბარდეს უსაფრთხოების სათანადო დონით მისი მნიშვნელობის თანახმად. **Write concern** განსაკუთრებით მნიშვნელოვანია **დამტკიცებისთვის**: `w: "majority"` უზრუნველყოფს, რომ write აკრეფილია უმრავლესობის ნოდებამდე (primary failover გადარჩება მონაცემის დაკარგვის გარეშე — კრიტიკულია მნიშვნელოვანი მონაცემებისთვის, როგორც გადახდები ან შეკვეთები), ხოლო `w: 1` უფრო სწრაფია, მაგრამ რისკავს write-ის დაკარგვას, თუ primary ვერ დაამტკიცა დანაბარი — კონსეკვენციური ვაჭრობა, სადაც არასწორი არჩევანი შეიძლება ნიშნავდეს silent მონაცემის დაკარგვას failover-ზე. **Read concern** აკონტროლებს **read თანმიმდევრობას**: `majority` აბრუნებს მხოლოდ უმრავლესობის მიერ დამტკიცებულ მონაცემებს (თანმიმდევრი, rollback არ იქნება) ხოლო `local` (უახლესი მონაცემი, შესაძლოა არ დამტკიცებული და ექვემდებარება rollback-ს) — გავლენა აქვს იმაზე, კითხავს თუ არა მონაცემი, რომელიც მოგვიანებით ქრება.

გარანტიების გაგება — ძლიერი გარანტიები (უმრავლესობა) უფრო უსაფრთხო და თანმიმდევრია, მაგრამ უფრო ნელი, ხოლო სუსტი უფრო სწრაფია, მაგრამ რისკავს მონაცემის დაკარგვას ან არათანმიმდევრი read-ებს — და არჩევა მონაცემის კრიტიკალურობის საფუძველზე (ძლიერი მნიშვნელოვანი მონაცემებისთვის, უფრო სწრაფი ნაკლებად კრიტიკულთათვის) — ეს არის ძირითადი სამსჯელო.

ასევე შესაბამისი არის ის, რომ read secondary-დან დამატებითი eventual-consistency განხილვებს ამატებს (მოძველებული read-ები).
achel მონაცემის თანმიმდევრობა და დამტკიცება კრიტიკულია (და სათანადო დონე დამოკიდებული მონაცემზე), და write/read concern ის გამო, რომ ეს აკეთებს MongoDB-ის განაწილებული (replica set) არქიტექტურაში ამ გარანტიებს შედეგობის წინააღმდეგ, მათი გაგება — დამტკიცება/თანმიმდევრობის დონეები, შედეგობის ვაჭრობა, და სათანადოდ არჩევანი — მნიშვნელოვანია უფროსი დონის ცოდნა სწორი განაწილებული MongoDB აპლიკაციების აგებისთვის, ტემა, რომელიც გვიჩვენებს განაწილებული სისტემების თანმიმდევრობის ვაჭრობის გაგებას, რომელიც განსაკუთრებით მნიშვნელოვანია აპლიკაციებისთვის, სადაც მონაცემის დაკარგვა ან არათანმიმდევრობა ხარჯოვანი იქნებოდა.