Elasticsearch कब मुख्य डेटाबेस के लिए उपयुक्त नहीं है?

Question

IT Interview Practice · Accepted Answer

Elasticsearch डेटा को टिकाऊ तरीके से रख सकता है। उसे primary database बनाना चाहिए या नहीं, इसके लिए पूछें कि **writes fail हों या साथ चलें तो कौन-से business rules हमेशा सही रहने चाहिए**।

ऑर्डर सिस्टम में products खोजना और purchase पक्का करना अलग काम हैं। पहले में search relevance महत्वपूर्ण है; दूसरे में payment और inventory के बदलाव सही होने चाहिए।

## 1. उन बदलावों से शुरू करें जिन्हें साथ सफल होना चाहिए

मान लें purchase के लिए order record बनाना और stock घटाना जरूरी है। केवल एक सफल हो तो क्या होगा, business को यह तय करना होगा।

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

Elasticsearch का bulk API कई document operations साथ भेजता है, लेकिन एक item fail और दूसरा सफल हो सकता है। वह उन्हें all-or-nothing transaction नहीं बनाता। Application को हर परिणाम देखना होगा। [Bulk API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-bulk)।

Records के बीच atomic बदलाव चाहिए तो transactional database सामान्यतः ज्यादा सीधा आधार देता है। यह coordination खुद बनाने से failure cases और recovery का काम बढ़ता है।

## 2. Document की सुरक्षा और business guarantees अलग समझें

Optimistic concurrency control जांचता है कि आपके पढ़े version के बाद document बदला तो नहीं। वह पुराने आधार वाला update रोक सकता है, ताकि एक client चुपचाप दूसरे का काम overwrite न करे। [Concurrency control](https://www.elastic.co/docs/reference/elasticsearch/rest-apis/optimistic-concurrency-control)।

यह सुरक्षा update होने वाले document पर लागू है। यह stock और order documents को अपने-आप coordinate नहीं करती, relational foreign keys नहीं देती और अलग business fields पर मनचाहे uniqueness rules लागू नहीं करती।

Storage चुनने से पहले application के जरूरी नियम लिखें। इससे निर्णय “search engine” या “database” नाम के बजाय ठोस जरूरत पर आधारित होगा।

## 3. देखें कि write कब search में दिखता है

Write सफल होना और search result में दिखना अलग घटनाएं हैं:

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

Refresh हाल के बदलाव search में दिखाता है। इसलिए document ID से real-time lookup और search query अलग हैं। refresh=wait_for search visibility तक रुक सकता है, लेकिन multi-document transaction नहीं बनाता। [Refresh का व्यवहार](https://www.elastic.co/docs/reference/elasticsearch/rest-apis/refresh-parameter)।

Product search page में छोटा delay स्वीकार हो सकता है। Final payment या permission decision के लिए consistency स्पष्ट तय करें और उसे देने वाला source पढ़ें। Refresh और durable storage भी अलग चिंताएं हैं।

## 4. Elasticsearch की भूमिका चुनें

| जरूरत | परखने की दिशा | कारण |
| --- | --- | --- |
| Orders और संबंधित records atomically बदलें | Transactional primary database | Correctness के नियम authoritative records के पास होने चाहिए। |
| Flexible full-text search चाहिए | Elasticsearch को search copy रखें | Search data स्वतंत्र रूप से ढाला और दोबारा बनाया जा सकता है। |
| Independent documents और अनुकूल consistency जरूरतें | Elasticsearch main store हो सकता है | दूसरे database का स्पष्ट उद्देश्य होना चाहिए। |

Order system का सामान्य design है:

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

CDC committed changes पकड़ता है; outbox business update के साथ उसी transaction में event रखता है। अलग process बदलाव index तक पहुंचाता है। इससे दो असंबंधित application writes हमेशा साथ सफल हों, इस भरोसे पर निर्भर नहीं रहना पड़ता।

Indexing path में stable IDs, versions, deletes, retries और lag monitoring फिर भी जरूरी हैं। Source से index दोबारा बनाने की जांच करें। नहीं तो search copy दूसरा असंगत source of truth बन सकती है।

## 5. अंतिम चुनाव से पहले recovery model जांचें

भूमिका कोई भी हो, backups की योजना और restoration की जांच करें। Replicas availability बढ़ाते हैं, लेकिन backups की जगह नहीं लेते। वास्तविक configuration के लिए स्वीकार्य data loss और recovery time तय करें।

Order उदाहरण में मैं transactional records ऐसे database में रखूंगा जो उनके नियमों को समर्थन दे, और search जरूरत उचित ठहराए तो Elasticsearch जोड़ूंगा। Independent search-oriented documents के लिए जांचूंगा कि Elasticsearch अकेला storage, consistency और recovery की जरूरत पूरी करता है या नहीं।

**याद रखें:** workload की जरूरी guarantees से चुनें, फिर failure और recovery जांचें। Search speed इस निर्णय का सिर्फ एक हिस्सा है।

जरूरत	परखने की दिशा	कारण
Orders और संबंधित records atomically बदलें	Transactional primary database	Correctness के नियम authoritative records के पास होने चाहिए।
Flexible full-text search चाहिए	Elasticsearch को search copy रखें	Search data स्वतंत्र रूप से ढाला और दोबारा बनाया जा सकता है।
Independent documents और अनुकूल consistency जरूरतें	Elasticsearch main store हो सकता है	दूसरे database का स्पष्ट उद्देश्य होना चाहिए।

1. उन बदलावों से शुरू करें जिन्हें साथ सफल होना चाहिए

2. Document की सुरक्षा और business guarantees अलग समझें

3. देखें कि write कब search में दिखता है

4. Elasticsearch की भूमिका चुनें

5. अंतिम चुनाव से पहले recovery model जांचें

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