A wane hali Elasticsearch bai dace da zama babbar ma’ajiyar bayanai ba?

Question

IT Interview Practice · Accepted Answer

Elasticsearch na iya adana bayanai da ɗorewa. Don yanke ko ya zama babban database, tambayi **waɗanne ƙa’idojin kasuwanci dole su ci gaba da zama gaskiya idan writes sun gaza ko suka faru tare**.

A tsarin oda, gano kaya da tabbatar da sayayya ayyuka biyu ne. Dacewar sakamakon bincike tana da muhimmanci ga na farko; daidaiton biyan kuɗi da rage stock yana da muhimmanci ga na biyu.

## 1. Fara da canje-canjen da dole su yi nasara tare

A ce sayayya tana buƙatar rikodin oda da rage stock. Kasuwanci dole ya bayyana abin da za a yi idan ɗaya kawai ya yi nasara.

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

Bulk API na Elasticsearch yana aika ayyukan documents da yawa tare, amma ɗaya na iya gazawa wani kuma ya yi nasara. Ba ya mayar da su transaction na duka-ko-ba-komai. Application dole ya bincika sakamakon kowace aiki. [Bulk API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-bulk).

Idan canji dole ya zama atomic tsakanin records, transactional database yawanci yana ba da tushe mafi kai tsaye. Gina wannan haɗin da kanka yana ƙara yanayin gazawa da aikin recovery.

## 2. Bambanta kariyar document da tabbacin kasuwanci

Optimistic concurrency control yana duba ko document ya canza tun sigar da ka karanta. Yana iya ƙin tsohon update, yana hana client ɗaya share aikin wani a ɓoye. [Concurrency control](https://www.elastic.co/docs/reference/elasticsearch/rest-apis/optimistic-concurrency-control).

Wannan kariya tana kan document da ake sabuntawa. Ba ta haɗa document na stock da na oda kai tsaye, ba ta bayar da relational foreign keys, kuma ba ta tabbatar da kowace ƙa’idar uniqueness tsakanin filayen kasuwanci.

Rubuta ƙa’idojin da application yake buƙata kafin zaɓar storage. Hakan ya sa shawarar ta zama bayyananniya maimakon dogaro da sunan “search engine” ko “database”.

## 3. Duba lokacin da write zai bayyana ga search

Write mai nasara da sakamakon da ake iya gani a search abubuwa biyu ne:

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

Refresh yana sa sabbin canje-canje su bayyana ga search. Don haka real-time lookup da document ID ya bambanta da search query. refresh=wait_for zai iya jira har canjin ya bayyana, amma ba ya ƙirƙirar multi-document transaction. [Halin refresh](https://www.elastic.co/docs/reference/elasticsearch/rest-apis/refresh-parameter).

Ga shafin neman kaya, ɗan jinkiri na iya halatta. Ga shawarar biyan kuɗi ta ƙarshe ko izini, bayyana consistency da ake bukata kuma ka karanta tushen da yake bayar da ita. Refresh da durable storage ma batutuwa ne daban.

## 4. Zaɓi aikin da Elasticsearch zai yi

| Buƙata | Abin da za a tantance | Dalili |
| --- | --- | --- |
| Oda da records masu alaƙa dole su canza atomically | Transactional primary database | Ƙa’idojin daidaito su kasance kusa da bayanan hukuma. |
| Masu amfani suna buƙatar full-text search mai sassauci | Elasticsearch a matsayin kwafin search | Ana iya tsara da sake gina bayanan search daban. |
| Documents masu zaman kansu da consistency mai dacewa | Elasticsearch na iya zama babban store | Database na biyu ya kamata ya kasance da dalili bayyananne. |

Tsari na gama gari ga odar kaya shi ne:

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

CDC yana kama committed changes; outbox yana rubuta event tare da business update a transaction ɗaya. Wani process ya kai canjin zuwa index. Wannan yana kauce wa dogaro da writes biyu marasa haɗin transaction su yi nasara tare koyaushe.

Hanyar indexing har yanzu tana buƙatar stable IDs, kula da versions, deletes, retries da lura da lag. Gwada sake gina index daga source. In ba haka ba, kwafin search zai iya zama wata source of truth da ba ta dace da asalin ba.

## 5. Tabbatar da hanyar recovery kafin zaɓin ƙarshe

Ko wace rawa aka zaɓa, tsara backups kuma gwada restoration. Replicas suna taimakon availability amma ba su maye gurbin backups ba. Bayyana adadin data loss da lokacin recovery da aka yarda da su bisa configuration na gaske.

Ga misalin oda, zan riƙe transactional records a database da ke goyon bayan ƙa’idojinsu, sannan in ƙara Elasticsearch idan buƙatar search ta ba da hujja. Ga documents masu zaman kansu da aka fi nema ta search, zan tantance ko Elasticsearch shi kaɗai ya cika storage, consistency da recovery.

**Ka tuna:** zaɓi bisa tabbacin da workload yake bukata, sannan tabbatar da halin failure da recovery. Saurin search ɓangare ɗaya ne kawai na shawarar.

Buƙata	Abin da za a tantance	Dalili
Oda da records masu alaƙa dole su canza atomically	Transactional primary database	Ƙa’idojin daidaito su kasance kusa da bayanan hukuma.
Masu amfani suna buƙatar full-text search mai sassauci	Elasticsearch a matsayin kwafin search	Ana iya tsara da sake gina bayanan search daban.
Documents masu zaman kansu da consistency mai dacewa	Elasticsearch na iya zama babban store	Database na biyu ya kamata ya kasance da dalili bayyananne.

1. Fara da canje-canjen da dole su yi nasara tare

2. Bambanta kariyar document da tabbacin kasuwanci

3. Duba lokacin da write zai bayyana ga search

4. Zaɓi aikin da Elasticsearch zai yi

5. Tabbatar da hanyar recovery kafin zaɓin ƙarshe

Tambayoyi masu alaƙa