কখন Elasticsearch প্রধান database হিসেবে উপযুক্ত নয়?

Question

IT Interview Practice · Accepted Answer

Elasticsearch স্থায়ীভাবে তথ্য সংরক্ষণ করতে পারে। একে primary database করবেন কি না ঠিক করতে জিজ্ঞেস করুন **লেখা ব্যর্থ হলে বা একসঙ্গে চললে কোন ব্যবসায়িক নিয়মগুলো অবশ্যই সঠিক থাকতে হবে**।

অর্ডার সিস্টেমে পণ্য খোঁজা ও কেনা নিশ্চিত করা আলাদা কাজ। প্রথমটিতে অনুসন্ধানের প্রাসঙ্গিকতা গুরুত্বপূর্ণ; দ্বিতীয়টিতে payment ও inventory-র সঠিক পরিবর্তন গুরুত্বপূর্ণ।

## 1. যে পরিবর্তনগুলো একসঙ্গে সফল হওয়া দরকার সেখান থেকে শুরু করুন

ধরুন কেনাকাটায় একটি order record তৈরি এবং stock কমানো লাগে। শুধু একটি সফল হলে কী হবে তা ব্যবসাকে নির্ধারণ করতে হবে।

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

Elasticsearch-এর bulk API একসঙ্গে একাধিক document operation পাঠায়, কিন্তু একটি ব্যর্থ হলেও অন্যটি সফল হতে পারে। এটি সবগুলো সফল অথবা সবগুলো ব্যর্থ এমন transaction বানায় না। Application-কে আলাদা ফল পরীক্ষা করতে হবে। [Bulk API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-bulk)।

একাধিক record-এ atomic পরিবর্তন দরকার হলে transactional database সাধারণত সরাসরি ভিত্তি দেয়। নিজে এই coordination বানালে failure case ও recovery কাজ বাড়ে।

## 2. Document সুরক্ষা ও ব্যবসায়িক নিশ্চয়তা আলাদা করুন

Optimistic concurrency control দেখে আপনার পড়া version-এর পর document বদলেছে কি না। এটি পুরোনো update প্রত্যাখ্যান করে এক client-এর কাজ অন্য client নীরবে মুছে দেওয়া আটকাতে পারে। [Concurrency control](https://www.elastic.co/docs/reference/elasticsearch/rest-apis/optimistic-concurrency-control)।

এই সুরক্ষা যে document update হচ্ছে তার জন্য। এটি স্বয়ংক্রিয়ভাবে stock document ও order document সমন্বয় করে না, relational foreign key দেয় না বা business field জুড়ে যেকোনো uniqueness rule কার্যকর করে না।

Storage বাছার আগে application-এর প্রয়োজনীয় নিয়ম লিখুন। এতে “search engine” বা “database” নামের ওপর নির্ভর না করে সিদ্ধান্ত স্পষ্ট হয়।

## 3. কখন লেখা 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-এ সামান্য দেরি গ্রহণযোগ্য হতে পারে। চূড়ান্ত payment বা permission সিদ্ধান্তের জন্য consistency স্পষ্টভাবে নির্ধারণ করে তা দেয় এমন source পড়ুন। Refresh ও durable storage-ও আলাদা বিষয়।

## 4. Elasticsearch-এর ভূমিকা বেছে নিন

| চাহিদা | বিবেচনার দিক | কারণ |
| --- | --- | --- |
| Order ও সম্পর্কিত record একসঙ্গে atomically বদলাতে হবে | Transactional primary database | সঠিকতার নিয়ম authoritative record-এর কাছাকাছি থাকা উচিত। |
| নমনীয় full-text search দরকার | Search copy হিসেবে Elasticsearch | Search data আলাদাভাবে সাজানো ও পুনর্গঠন করা যায়। |
| স্বাধীন document ও উপযুক্ত consistency চাহিদা | Elasticsearch মূল store হিসেবে মানানসই হতে পারে | দ্বিতীয় database-এর প্রমাণযোগ্য উদ্দেশ্য থাকা উচিত। |

অর্ডার সিস্টেমের একটি প্রচলিত নকশা:

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

CDC committed পরিবর্তন ধরে; outbox business update-এর একই transaction-এ event রাখে। আলাদা process সেই পরিবর্তন index-এ পৌঁছায়। এতে application-এর সম্পর্কহীন দুটি write সবসময় একসঙ্গে সফল হবে, এই নির্ভরতা এড়ানো যায়।

Indexing path-এ এখনও stable ID, version handling, delete, retry ও lag monitoring লাগে। Source থেকে index পুনর্গঠন পরীক্ষা করুন। নইলে search copy দ্বিতীয় অসামঞ্জস্যপূর্ণ source of truth হতে পারে।

## 5. সিদ্ধান্ত চূড়ান্ত করার আগে recovery model নিশ্চিত করুন

যে ভূমিকাই নিন, backup পরিকল্পনা ও restore পরীক্ষা করুন। Replica availability বাড়ায়, backup-এর বিকল্প নয়। বাস্তব configuration-এর জন্য গ্রহণযোগ্য data loss ও recovery time নির্ধারণ করুন।

অর্ডারের উদাহরণে আমি transactional record তার নিয়ম সমর্থনকারী database-এ রাখব এবং search চাহিদা যুক্তি দিলে Elasticsearch যোগ করব। স্বাধীন search-কেন্দ্রিক document হলে শুধু Elasticsearch storage, consistency ও recovery চাহিদা মেটায় কি না দেখব।

**মনে রাখুন:** কাজের প্রয়োজনীয় guarantee অনুযায়ী বাছুন, তারপর failure ও recovery যাচাই করুন। Search speed সেই সিদ্ধান্তের মাত্র একটি অংশ।

চাহিদা	বিবেচনার দিক	কারণ
Order ও সম্পর্কিত record একসঙ্গে atomically বদলাতে হবে	Transactional primary database	সঠিকতার নিয়ম authoritative record-এর কাছাকাছি থাকা উচিত।
নমনীয় full-text search দরকার	Search copy হিসেবে Elasticsearch	Search data আলাদাভাবে সাজানো ও পুনর্গঠন করা যায়।
স্বাধীন document ও উপযুক্ত consistency চাহিদা	Elasticsearch মূল store হিসেবে মানানসই হতে পারে	দ্বিতীয় database-এর প্রমাণযোগ্য উদ্দেশ্য থাকা উচিত।

1. যে পরিবর্তনগুলো একসঙ্গে সফল হওয়া দরকার সেখান থেকে শুরু করুন

2. Document সুরক্ষা ও ব্যবসায়িক নিশ্চয়তা আলাদা করুন

3. কখন লেখা search-এ দেখা যায় পরীক্ষা করুন

4. Elasticsearch-এর ভূমিকা বেছে নিন

5. সিদ্ধান্ত চূড়ান্ত করার আগে recovery model নিশ্চিত করুন

সম্পর্কিত প্রশ্ন