Elasticsearch بنیادی ڈیٹابیس کے طور پر کب مناسب نہیں ہوتی؟

Question

IT Interview Practice · Accepted Answer

Elasticsearch ڈیٹا مستقل محفوظ کر سکتا ہے۔ اسے بنیادی database چننے سے پہلے پوچھیں کہ **writes ناکام یا بیک وقت ہوں تو کون سے کاروباری اصول درست رہنے چاہییں**۔

آرڈر سسٹم میں مصنوعات تلاش کرنا اور خریداری کی تصدیق الگ کام ہیں۔ پہلے میں متعلقہ نتائج، دوسرے میں درست payment اور stock تبدیلی اہم ہے۔

## 1. ساتھ کامیاب ہونے والی تبدیلیوں سے شروع کریں

فرض کریں خریداری میں آرڈر ریکارڈ اور stock کم کرنا ضروری ہے۔ کاروبار کو طے کرنا ہوگا کہ صرف ایک کامیاب ہو تو کیا ہو۔

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

Elasticsearch کا bulk API کئی document operations ساتھ بھیجتا ہے، مگر ایک ناکام اور دوسری کامیاب ہو سکتی ہے۔ یہ سب یا کچھ نہیں والی 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 کی حفاظت اور کاروباری ضمانت الگ رکھیں

Optimistic concurrency control دیکھتا ہے کہ پڑھے گئے ورژن کے بعد document نہیں بدلا۔ یہ پرانا update رد کرکے ایک client کو دوسرے کا کام خاموشی سے بدلنے سے روک سکتا ہے۔ [Concurrency control](https://www.elastic.co/docs/reference/elasticsearch/rest-apis/optimistic-concurrency-control)۔

یہ حفاظت اسی document کی ہے۔ Stock اور order documents خودکار طور پر مربوط نہیں ہوتے، relational foreign keys نہیں ملتیں اور کاروباری fields کی ہر ممکن uniqueness شرط نافذ نہیں ہوتی۔

Storage چننے سے پہلے application کے اصول لکھیں۔ اس سے فیصلہ “search engine” یا “database” کے نام کے بجائے ٹھوس ضرورت پر ہوتا ہے۔

## 3. دیکھیں write کب تلاش میں آتی ہے

کامیاب write اور دکھائی دینے والا search result الگ واقعات ہیں:

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

Refresh حالیہ تبدیلیاں search کو دکھاتا ہے۔ اس لیے document ID سے real-time lookup، search query سے مختلف ہے۔ refresh=wait_for تلاش میں نظر آنے کا انتظار کرتا ہے مگر multi-document transaction نہیں بناتا۔ [Refresh کا رویہ](https://www.elastic.co/docs/reference/elasticsearch/rest-apis/refresh-parameter)۔

مصنوعات کی تلاش میں معمولی تاخیر قابلِ قبول ہو سکتی ہے۔ آخری payment یا permission فیصلے کے لیے مطلوبہ consistency واضح کریں اور ایسا source پڑھیں جو اسے دیتا ہو۔ Refresh اور پائیدار storage بھی الگ مسائل ہیں۔

## 4. Elasticsearch کا کردار چنیں

| ضرورت | زیرِ غور راستہ | وجہ |
| --- | --- | --- |
| Orders اور متعلقہ records ایک ساتھ بدلیں | Transactional بنیادی database | درستگی کے اصول مستند records کے قریب ہوں۔ |
| لچک دار full-text search چاہیے | Elasticsearch بطور search copy | Search data آزادانہ بنایا اور دوبارہ تعمیر ہو سکتا ہے۔ |
| موزوں consistency والے آزاد documents | Elasticsearch مرکزی store ہو سکتا ہے | دوسرے database کا ثابت مقصد ہونا چاہیے۔ |

آرڈر سسٹم کا عام design:

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

CDC committed تبدیلیاں لیتا ہے؛ outbox کاروباری update کے ساتھ اسی transaction میں event رکھتا ہے۔ الگ process تبدیلیاں index تک پہنچاتا ہے۔ یوں دو غیر متعلق writes کے ہمیشہ ساتھ کامیاب ہونے پر انحصار نہیں رہتا۔

Indexing کو پھر بھی مستحکم IDs، versions، deletes، retries اور lag نگرانی چاہیے۔ Source سے index دوبارہ بنا کر آزمائیں۔ ورنہ search copy دوسری، متضاد حقیقت کا ذریعہ بن سکتی ہے۔

## 5. فیصلہ کرنے سے پہلے recovery model کی تصدیق کریں

کردار جو بھی ہو، backups بنائیں اور restore آزمائیں۔ Replicas دستیابی میں مدد دیتی ہیں مگر backup کا بدل نہیں۔ اصل configuration کے لیے قابلِ قبول data loss اور recovery time طے کریں۔

آرڈر مثال میں transactional records ایسے database میں رکھوں گا جو ان کے اصول سنبھالتا ہو، اور search ضرورت جواز دے تو Elasticsearch شامل کروں گا۔ آزاد search-oriented documents میں دیکھوں گا کہ Elasticsearch اکیلا storage، consistency اور recovery پوری کرتا ہے یا نہیں۔

**یاد رکھیں:** کام کی مطلوبہ ضمانتوں کے مطابق چنیں، پھر failure اور recovery جانچیں۔ Search کی رفتار فیصلے کا صرف ایک حصہ ہے۔

ضرورت	زیرِ غور راستہ	وجہ
Orders اور متعلقہ records ایک ساتھ بدلیں	Transactional بنیادی database	درستگی کے اصول مستند records کے قریب ہوں۔
لچک دار full-text search چاہیے	Elasticsearch بطور search copy	Search data آزادانہ بنایا اور دوبارہ تعمیر ہو سکتا ہے۔
موزوں consistency والے آزاد documents	Elasticsearch مرکزی store ہو سکتا ہے	دوسرے database کا ثابت مقصد ہونا چاہیے۔

1. ساتھ کامیاب ہونے والی تبدیلیوں سے شروع کریں

2. Document کی حفاظت اور کاروباری ضمانت الگ رکھیں

3. دیکھیں write کب تلاش میں آتی ہے

4. Elasticsearch کا کردار چنیں

5. فیصلہ کرنے سے پہلے recovery model کی تصدیق کریں

متعلقہ سوالات