Ni lini Elasticsearch haifai kuwa hifadhidata kuu?

Question

IT Interview Practice · Accepted Answer

Elasticsearch inaweza kuhifadhi data kwa kudumu. Ili kuamua ikiwa iwe database kuu, uliza **ni kanuni zipi za biashara lazima ziendelee kuwa kweli uandishi unaposhindwa au unapofanyika kwa wakati mmoja**.

Katika mfumo wa oda, kutafuta bidhaa na kuthibitisha ununuzi ni kazi tofauti. Umuhimu wa matokeo ya utafutaji unahusika na ya kwanza; malipo sahihi na mabadiliko sahihi ya stock yanahusika na ya pili.

## 1. Anza na mabadiliko yanayopaswa kufanikiwa pamoja

Tuseme ununuzi unahitaji rekodi ya oda na kupunguza stock. Biashara lazima iamue nini kifanyike ikiwa moja tu imefanikiwa.

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

Bulk API ya Elasticsearch hutuma operations kadhaa za nyaraka pamoja, lakini moja inaweza kushindwa huku nyingine ikifanikiwa. Haizifanyi kuwa transaction ya yote-au-hakuna. Programu lazima ichunguze matokeo ya kila moja. [Bulk API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-bulk).

Ikiwa hitaji ni mabadiliko ya atomiki katika rekodi kadhaa, database yenye transactions kwa kawaida hutoa msingi wa moja kwa moja zaidi. Kujenga uratibu huo mwenyewe huongeza hali za kushindwa na kazi ya urejeshaji.

## 2. Tofautisha ulinzi wa nyaraka na dhamana za biashara

Optimistic concurrency control hukagua kwamba nyaraka haijabadilika tangu toleo ulilosoma. Inaweza kukataa update iliyopitwa na wakati, kuzuia client kufuta kazi ya client mwingine kimya kimya. [Udhibiti wa concurrency](https://www.elastic.co/docs/reference/elasticsearch/rest-apis/optimistic-concurrency-control).

Ulinzi huo unatumika kwa nyaraka inayosasishwa. Hauunganishi moja kwa moja nyaraka ya stock na ya oda, hautoi foreign keys za mahusiano wala kutekeleza kanuni zozote za uniqueness katika fields za biashara.

Andika kanuni ambazo programu inahitaji kabla ya kuchagua hifadhi. Hii hufanya uamuzi uwe mahususi badala ya kutegemea lebo “search engine” au “database”.

## 3. Angalia uandishi unakuwa wa kutafutwa lini

Uandishi kufanikiwa na matokeo kuonekana kwenye search ni matukio tofauti:

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

Refresh hufanya mabadiliko ya karibuni yaonekane kwenye search. Kutafuta kwa document ID kwa wakati halisi kwa hiyo hutofautiana na search query. Chaguo la refresh=wait_for linaweza kusubiri kuonekana kwenye search, lakini halijengi transaction ya nyaraka nyingi. [Tabia ya refresh](https://www.elastic.co/docs/reference/elasticsearch/rest-apis/refresh-parameter).

Kwa ukurasa wa kutafuta bidhaa, kuchelewa kidogo kuonekana kunaweza kukubalika. Kwa uamuzi wa mwisho wa malipo au ruhusa, fafanua uthabiti unaohitajika wazi na soma chanzo kinachoutoa. Refresh na uhifadhi wa kudumu pia ni masuala tofauti.

## 4. Chagua jukumu la Elasticsearch

| Hitaji | Mwelekeo wa kutathmini | Sababu |
| --- | --- | --- |
| Oda na rekodi zinazohusiana lazima zibadilike atomiki | Database kuu ya transactions | Kanuni za usahihi zinapaswa kuwa karibu na rekodi zenye mamlaka. |
| Watumiaji wanahitaji full-text search inayonyumbulika | Elasticsearch kama nakala ya search | Data ya search inaweza kutengenezwa na kujengwa upya kwa kujitegemea. |
| Nyaraka zinazojitegemea zenye mahitaji yanayolingana ya uthabiti | Elasticsearch inaweza kufaa kuwa hifadhi kuu | Database ya pili inapaswa kuwa na kusudi lililothibitishwa. |

Muundo wa kawaida wa mfumo wa oda ni:

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

CDC hunasa mabadiliko yaliyocommitiwa; outbox hurekodi tukio pamoja na update ya biashara katika transaction ileile. Process tofauti hupeleka mabadiliko kwenye index. Hii huepusha kutegemea uandishi mbili zisizohusiana za programu kufanikiwa pamoja kila wakati.

Njia ya indexing bado inahitaji ID thabiti, usimamizi wa versions, deletes, retries na ufuatiliaji wa lag. Jaribu kujenga index upya kutoka chanzo. Vinginevyo, nakala ya search inaweza kuwa chanzo cha pili cha ukweli kisicholingana.

## 5. Thibitisha modeli ya urejeshaji kabla ya kuamua

Bila kujali jukumu lililochaguliwa, panga backups na ujaribu kurejesha. Replicas husaidia upatikanaji lakini si mbadala wa backups. Bainisha upotevu wa data unaokubalika na muda wa kurejesha kwa configuration halisi.

Kwa mfano wa oda, ningehifadhi rekodi za transactions katika database inayounga mkono kanuni zake na kuongeza Elasticsearch ikiwa mahitaji ya search yanahalalisha. Kwa nyaraka zinazojitegemea zinazolenga search, ningetathmini ikiwa Elasticsearch peke yake inatimiza mahitaji ya hifadhi, uthabiti na urejeshaji.

**Kumbuka:** chagua kwa dhamana zinazohitajika na mzigo wa kazi, kisha hakiki tabia wakati wa hitilafu na urejeshaji. Kasi ya search ni sehemu moja tu ya uamuzi.

Hitaji	Mwelekeo wa kutathmini	Sababu
Oda na rekodi zinazohusiana lazima zibadilike atomiki	Database kuu ya transactions	Kanuni za usahihi zinapaswa kuwa karibu na rekodi zenye mamlaka.
Watumiaji wanahitaji full-text search inayonyumbulika	Elasticsearch kama nakala ya search	Data ya search inaweza kutengenezwa na kujengwa upya kwa kujitegemea.
Nyaraka zinazojitegemea zenye mahitaji yanayolingana ya uthabiti	Elasticsearch inaweza kufaa kuwa hifadhi kuu	Database ya pili inapaswa kuwa na kusudi lililothibitishwa.

1. Anza na mabadiliko yanayopaswa kufanikiwa pamoja

2. Tofautisha ulinzi wa nyaraka na dhamana za biashara

3. Angalia uandishi unakuwa wa kutafutwa lini

4. Chagua jukumu la Elasticsearch

5. Thibitisha modeli ya urejeshaji kabla ya kuamua

Maswali yanayohusiana