როდის არ გამოდგება Elasticsearch ძირითად მონაცემთა ბაზად?

Question

IT Interview Practice · Accepted Answer

Elasticsearch-ს მონაცემების ხანგრძლივად შენახვა შეუძლია. მთავარ ბაზად არჩევამდე იკითხეთ: **რომელი ბიზნესწესები უნდა დარჩეს მართებული ჩაწერის ჩავარდნის ან პარალელური შესრულების დროს**.

შეკვეთების სისტემაში პროდუქტის პოვნა და შესყიდვის დადასტურება სხვადასხვა ამოცანაა. პირველში ძიების შესაბამისობაა მნიშვნელოვანი, მეორეში — გადახდისა და მარაგის ცვლილებების სისწორე.

## 1. დაიწყეთ ცვლილებებით, რომლებიც ერთად უნდა შესრულდეს

დავუშვათ, შესყიდვას შეკვეთის ჩანაწერი და მარაგის შემცირება სჭირდება. ბიზნესმა უნდა განსაზღვროს, რა მოხდება, თუ მხოლოდ ერთი წარმატებით შესრულდება.

```text
[Create order] ---- must coordinate ---- [Reduce stock]
      |                                      |
   success                                failure?
```

Elasticsearch-ის Bulk API რამდენიმე დოკუმენტის ოპერაციას ერთად აგზავნის, მაგრამ ერთი შეიძლება ჩავარდეს, მეორე კი შესრულდეს. ის ოპერაციებს ერთიან, სრულად წარმატებულ ან სრულად გაუქმებულ ტრანზაქციად არ აქცევს. აპლიკაციამ თითოეული შედეგი უნდა შეამოწმოს. [Bulk API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-bulk).

თუ მოთხოვნა რამდენიმე ჩანაწერის ატომური ცვლილებაა, ტრანზაქციული ბაზა ჩვეულებრივ უფრო პირდაპირ საფუძველს იძლევა. კოორდინაციის თვითონ აგება მარცხის შემთხვევებსა და აღდგენის სამუშაოს ამატებს.

## 2. გაარჩიეთ დოკუმენტის დაცვა და ბიზნესგარანტიები

ოპტიმისტური კონკურენტულობის კონტროლი ამოწმებს, შეიცვალა თუ არა დოკუმენტი წაკითხული ვერსიის შემდეგ. მას შეუძლია მოძველებული განახლების უარყოფა, რათა ერთმა კლიენტმა მეორის სამუშაო შეუმჩნევლად არ გადაწეროს. [კონკურენტულობის კონტროლი](https://www.elastic.co/docs/reference/elasticsearch/rest-apis/optimistic-concurrency-control).

დაცვა ეხება განახლებად დოკუმენტს. ის ავტომატურად არ ათანხმებს მარაგისა და შეკვეთის დოკუმენტებს, არ ქმნის რელაციურ გარე გასაღებებს და არ იცავს ნებისმიერ უნიკალურობის წესს ბიზნესველებს შორის.

საცავის არჩევამდე ჩამოწერეთ აპლიკაციის წესები. გადაწყვეტილება კონკრეტული გახდება და მხოლოდ „საძიებო ძრავის“ ან „ბაზის“ სახელზე აღარ იქნება დამოკიდებული.

## 3. შეამოწმეთ, როდის ხდება ჩაწერა საძიებო

წარმატებული ჩაწერა და ძიებაში ხილული შედეგი ცალკე მოვლენებია:

```text
[Write accepted] -> [Refresh] -> [Search can see the change]
```

Refresh ახალ ცვლილებებს ძიებისთვის ხილულს ხდის. ამიტომ ID-ით რეალურ დროში მიღება ძიების მოთხოვნისგან განსხვავდება. refresh=wait_for ძიებაში გამოჩენას შეიძლება დაელოდოს, მაგრამ მრავალდოკუმენტიან ტრანზაქციას არ ქმნის. [Refresh-ის ქცევა](https://www.elastic.co/docs/reference/elasticsearch/rest-apis/refresh-parameter).

პროდუქტის ძიების გვერდზე მცირე დაყოვნება შეიძლება მისაღები იყოს. საბოლოო გადახდის ან უფლებამოსილების გადაწყვეტილებისთვის ზუსტად განსაზღვრეთ საჭირო თანმიმდევრულობა და შესაბამისი წყარო წაიკითხეთ. Refresh და მონაცემების გამძლე შენახვაც სხვადასხვა საკითხია.

## 4. აირჩიეთ Elasticsearch-ის როლი

| მოთხოვნა | შესაფასებელი მიმართულება | მიზეზი |
| --- | --- | --- |
| შეკვეთა და დაკავშირებული ჩანაწერები ატომურად უნდა შეიცვალოს | ტრანზაქციული მთავარი ბაზა | სისწორის წესები ავტორიტეტულ ჩანაწერებთან ახლოს უნდა იყოს. |
| მომხმარებლებს მოქნილი სრული ტექსტის ძიება სჭირდებათ | Elasticsearch საძიებო ასლად | საძიებო მონაცემების დამოუკიდებლად ფორმირება და ხელახლა აგება შეიძლება. |
| დამოუკიდებელი დოკუმენტები თავსებადი თანმიმდევრულობის მოთხოვნებით | Elasticsearch შეიძლება მთავარ საცავად გამოდგეს | მეორე ბაზას დადასტურებული დანიშნულება უნდა ჰქონდეს. |

შეკვეთების სისტემის გავრცელებული დიზაინია:

```text
[Transactional DB] -> [CDC / outbox] -> [Indexer] -> [Elasticsearch]
 authoritative data                               search copy
```

CDC დადასტურებულ ცვლილებებს იღებს; outbox მოვლენას ბიზნესგანახლებასთან იმავე ტრანზაქციაში წერს. ცალკე პროცესი ცვლილებებს ინდექსში აგზავნის. ასე ორი დამოუკიდებელი აპლიკაციური ჩაწერის ერთდროულ წარმატებაზე დამოკიდებულება მცირდება.

ინდექსირების გზას მაინც სჭირდება სტაბილური ID-ები, ვერსიები, წაშლა, გამეორება და ჩამორჩენის მონიტორინგი. გამოცადეთ ინდექსის წყაროდან ხელახლა აგება. წინააღმდეგ შემთხვევაში საძიებო ასლი მეორე, არათანმიმდევრულ ჭეშმარიტების წყაროდ შეიძლება იქცეს.

## 5. არჩევამდე აღდგენის მოდელი დაადასტურეთ

ნებისმიერი როლისას დაგეგმეთ სარეზერვო ასლები და გამოცადეთ აღდგენა. რეპლიკები ხელმისაწვდომობას ეხმარება, მაგრამ სარეზერვო ასლებს არ ცვლის. რეალური კონფიგურაციისთვის განსაზღვრეთ მისაღები მონაცემთა დანაკარგი და აღდგენის დრო.

შეკვეთების მაგალითში ტრანზაქციულ ჩანაწერებს მათი წესების მხარდამჭერ ბაზაში შევინახავდი და Elasticsearch-ს ძიების საჭიროების მიხედვით დავამატებდი. დამოუკიდებელი საძიებო დოკუმენტებისთვის შევაფასებდი, აკმაყოფილებს თუ არა მარტო Elasticsearch შენახვის, თანმიმდევრულობისა და აღდგენის მოთხოვნებს.

**დაიმახსოვრეთ:** აირჩიეთ დატვირთვისთვის საჭირო გარანტიებით და შემდეგ შეამოწმეთ მარცხისა და აღდგენის ქცევა. ძიების სიჩქარე გადაწყვეტილების მხოლოდ ნაწილია.

მოთხოვნა	შესაფასებელი მიმართულება	მიზეზი
შეკვეთა და დაკავშირებული ჩანაწერები ატომურად უნდა შეიცვალოს	ტრანზაქციული მთავარი ბაზა	სისწორის წესები ავტორიტეტულ ჩანაწერებთან ახლოს უნდა იყოს.
მომხმარებლებს მოქნილი სრული ტექსტის ძიება სჭირდებათ	Elasticsearch საძიებო ასლად	საძიებო მონაცემების დამოუკიდებლად ფორმირება და ხელახლა აგება შეიძლება.
დამოუკიდებელი დოკუმენტები თავსებადი თანმიმდევრულობის მოთხოვნებით	Elasticsearch შეიძლება მთავარ საცავად გამოდგეს	მეორე ბაზას დადასტურებული დანიშნულება უნდა ჰქონდეს.

1. დაიწყეთ ცვლილებებით, რომლებიც ერთად უნდა შესრულდეს

2. გაარჩიეთ დოკუმენტის დაცვა და ბიზნესგარანტიები

3. შეამოწმეთ, როდის ხდება ჩაწერა საძიებო

4. აირჩიეთ Elasticsearch-ის როლი

5. არჩევამდე აღდგენის მოდელი დაადასტურეთ

დაკავშირებული კითხვები