Elasticsearch मुख्य database म्हणून कधी अयोग्य ठरतो?

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).

अनेक रेकॉर्डचा atomic बदल हवा असेल तर ट्रान्झॅक्शनल डेटाबेस सामान्यतः सरळ आधार देतो. समन्वय स्वतः बांधल्यास अपयशाचे प्रसंग आणि पुनर्प्राप्तीचे काम वाढते.

## 2. दस्तऐवज संरक्षण आणि व्यवसाय हमी वेगळी ओळखा

Optimistic concurrency control वाचलेल्या आवृत्तीनंतर दस्तऐवज बदलला का ते तपासतो. जुना अपडेट नाकारून एका क्लायंटने दुसऱ्याचे काम नकळत पुसणे रोखू शकतो. [Concurrency control](https://www.elastic.co/docs/reference/elasticsearch/rest-apis/optimistic-concurrency-control).

हे संरक्षण अद्ययावत होणाऱ्या दस्तऐवजापुरते असते. ते साठा आणि ऑर्डर दस्तऐवज आपोआप समन्वित करत नाही, relational foreign keys देत नाही किंवा व्यवसाय फील्डमधील कोणतेही uniqueness नियम आपोआप लावत नाही.

साठवण निवडण्याआधी अॅपचे नियम लिहा. त्यामुळे निर्णय ‘सर्च इंजिन’ किंवा ‘डेटाबेस’ या नावांऐवजी ठोस गरजांवर होतो.

## 3. लेखन शोधात कधी दिसते ते तपासा

लेखन यशस्वी होणे आणि शोधात निकाल दिसणे वेगवेगळे क्षण आहेत:

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

Refresh अलीकडचे बदल शोधाला दिसू देतो. म्हणून ID ने real-time दस्तऐवज मिळवणे आणि search query वेगळे आहेत. refresh=wait_for शोधात दिसेपर्यंत थांबू शकतो, पण अनेक दस्तऐवजांची ट्रान्झॅक्शन तयार करत नाही. [Refresh वर्तन](https://www.elastic.co/docs/reference/elasticsearch/rest-apis/refresh-parameter).

उत्पादन शोध पानाला छोटा विलंब चालू शकतो. अंतिम पेमेंट किंवा परवानगी निर्णयासाठी आवश्यक consistency स्पष्ट करा आणि ती देणारा स्रोत वाचा. Refresh आणि टिकाऊ साठवणही वेगळे विषय आहेत.

## 4. Elasticsearch ची भूमिका निवडा

| गरज | तपासायची दिशा | कारण |
| --- | --- | --- |
| ऑर्डर आणि संबंधित रेकॉर्ड atomic बदलले पाहिजेत | ट्रान्झॅक्शनल मुख्य डेटाबेस | अचूकतेचे नियम अधिकृत रेकॉर्डजवळ हवेत. |
| लवचिक पूर्ण मजकूर शोध हवा | शोधाची प्रत म्हणून Elasticsearch | शोध डेटा स्वतंत्र बनवता आणि पुन्हा उभारता येतो. |
| स्वतंत्र दस्तऐवज आणि योग्य consistency गरजा | Elasticsearch मुख्य साठा होऊ शकतो | दुसऱ्या डेटाबेसचे कारण सिद्ध असावे. |

ऑर्डर प्रणालीची सामान्य रचना:

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

CDC commit झालेले बदल पकडतो; outbox व्यवसाय अपडेटसोबत त्याच ट्रान्झॅक्शनमध्ये event लिहितो. वेगळी प्रक्रिया ते इंडेक्सला पोहोचवते. त्यामुळे दोन स्वतंत्र अॅप लेखन नेहमी एकत्र यशस्वी होतील या गृहितावर अवलंबून राहावे लागत नाही.

इंडेक्सिंगला तरीही स्थिर ID, आवृत्ती हाताळणी, हटवणे, पुनर्प्रयत्न आणि विलंब निरीक्षण लागते. स्रोतापासून इंडेक्स पुन्हा बांधण्याची चाचणी करा. नाहीतर शोध प्रत दुसरा विसंगत अधिकृत स्रोत बनू शकते.

## 5. निर्णयाआधी पुनर्प्राप्ती तपासा

भूमिका कोणतीही असो, backup नियोजित करा आणि restore तपासा. Replica उपलब्धता वाढवतात पण backup ची जागा घेत नाहीत. प्रत्यक्ष संरचनेसाठी स्वीकार्य डेटा हानी आणि पुनर्प्राप्ती वेळ ठरवा.

ऑर्डर उदाहरणात मी ट्रान्झॅक्शनल रेकॉर्ड त्यांच्या नियमांना आधार देणाऱ्या डेटाबेसमध्ये ठेवेन आणि शोध गरज योग्य ठरवेल तेव्हा Elasticsearch जोडेन. स्वतंत्र शोधकेंद्रित दस्तऐवजांसाठी Elasticsearch एकटाच साठवण, consistency आणि पुनर्प्राप्ती पूर्ण करतो का पाहीन.

**लक्षात ठेवा:** कामाला आवश्यक हमीनुसार निवडा, मग अपयश आणि पुनर्प्राप्ती तपासा. शोधाचा वेग हा निर्णयाचा फक्त एक भाग आहे.

गरज	तपासायची दिशा	कारण
ऑर्डर आणि संबंधित रेकॉर्ड atomic बदलले पाहिजेत	ट्रान्झॅक्शनल मुख्य डेटाबेस	अचूकतेचे नियम अधिकृत रेकॉर्डजवळ हवेत.
लवचिक पूर्ण मजकूर शोध हवा	शोधाची प्रत म्हणून Elasticsearch	शोध डेटा स्वतंत्र बनवता आणि पुन्हा उभारता येतो.
स्वतंत्र दस्तऐवज आणि योग्य consistency गरजा	Elasticsearch मुख्य साठा होऊ शकतो	दुसऱ्या डेटाबेसचे कारण सिद्ध असावे.

1. एकत्र यशस्वी होणाऱ्या बदलांपासून सुरुवात करा

2. दस्तऐवज संरक्षण आणि व्यवसाय हमी वेगळी ओळखा

3. लेखन शोधात कधी दिसते ते तपासा

4. Elasticsearch ची भूमिका निवडा

5. निर्णयाआधी पुनर्प्राप्ती तपासा

संबंधित प्रश्न