Elasticsearch hangi durumlarda birincil veritabanı olarak uygun değildir?

Question

IT Interview Practice · Accepted Answer

Elasticsearch veriyi kalıcı biçimde saklayabilir. Birincil veritabanı olup olmamasına karar vermek için **yazmalar başarısız olduğunda veya eşzamanlı çalıştığında hangi iş kurallarının geçerli kalması gerektiğini** sorun.

Bir sipariş sisteminde ürün bulmak ve satın almayı onaylamak farklı işlerdir. İlki için arama uygunluğu, ikincisi için doğru ödeme ve stok değişiklikleri önemlidir.

## 1. Birlikte başarılı olması gereken değişikliklerden başlayın

Bir satın almanın sipariş kaydı oluşturmayı ve stok azaltmayı gerektirdiğini varsayalım. İşletme, yalnızca biri başarılı olursa ne olması gerektiğini tanımlamalıdır.

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

Elasticsearch bulk API, birden fazla belge işlemini birlikte gönderir; ancak bir öğe başarısız olurken diğeri başarılı olabilir. Bu işlemleri ya hep ya hiç türünde bir transaction yapmaz. Uygulama tek tek sonuçları incelemelidir. [Bulk API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-bulk).

Gereksinim, kayıtlar arasında atomik değişiklikse işlemsel bir veritabanı genellikle daha doğrudan bir temel sunar. Bu koordinasyonu kendiniz uygulamak hata senaryolarını ve kurtarma işini artırır.

## 2. Belge korumasını iş garantilerinden ayırın

İyimser eşzamanlılık kontrolü, belgenin okuduğunuz sürümden beri değişmediğini kontrol eder. Eski bir güncellemeyi reddederek bir istemcinin diğerinin işini sessizce ezmesini önleyebilir. [Eşzamanlılık kontrolü](https://www.elastic.co/docs/reference/elasticsearch/rest-apis/optimistic-concurrency-control).

Bu koruma güncellenen belgeye uygulanır. Stok belgesini sipariş belgesiyle otomatik olarak koordine etmez, ilişkisel foreign key sağlamaz veya iş alanları arasında her tür benzersizlik kuralını uygulamaz.

Depolama seçmeden önce uygulamanın ihtiyaç duyduğu kuralları yazın. Böylece karar, “arama motoru” veya “veritabanı” etiketine dayanmak yerine somutlaşır.

## 3. Bir yazmanın ne zaman aranabilir olduğunu kontrol edin

Başarılı yazma ile görünür arama sonucu ayrı olaylardır:

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

Refresh, son değişiklikleri aramaya görünür kılar. Dolayısıyla belge kimliğiyle gerçek zamanlı okuma, arama sorgusundan farklıdır. refresh=wait_for seçeneği arama görünürlüğünü bekleyebilir ancak çok belgeli transaction oluşturmaz. [Refresh davranışı](https://www.elastic.co/docs/reference/elasticsearch/rest-apis/refresh-parameter).

Ürün arama sayfasında kısa bir görünürlük gecikmesi kabul edilebilir. Son ödeme veya yetki kararı için gerekli tutarlılığı açıkça tanımlayın ve bunu sağlayan bir kaynaktan okuyun. Refresh ile kalıcı depolama da ayrı konulardır.

## 4. Elasticsearch'ün rolünü seçin

| Gereksinim | Değerlendirilecek yön | Neden |
| --- | --- | --- |
| Siparişler ve ilişkili kayıtlar atomik değişmeli | İşlemsel birincil veritabanı | Gerekli doğruluk kuralları yetkili kayıtların yakınında olmalıdır. |
| Kullanıcıların esnek tam metin araması gerekiyor | Arama kopyası olarak Elasticsearch | Arama verisi bağımsız şekillendirilebilir ve yeniden oluşturulabilir. |
| Uyumlu tutarlılık ihtiyaçları olan bağımsız belgeler | Ana depo olarak Elasticsearch uygun olabilir | İkinci veritabanının kanıtlanmış bir amacı olmalıdır. |

Yaygın bir sipariş sistemi tasarımı şöyledir:

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

CDC, commit edilmiş değişiklikleri yakalar; outbox, iş güncellemesinin yanında aynı transaction içinde olay kaydeder. Ayrı bir süreç bu değişiklikleri indekse iletir. Böylece uygulamadaki bağımsız iki yazmanın her zaman birlikte başarılı olmasına güvenilmez.

İndeksleme yolu yine de sabit kimlikler, sürüm yönetimi, silmeler, yeniden denemeler ve gecikme izlemesi gerektirir. İndeksi kaynaktan yeniden oluşturmayı test edin. Aksi halde arama kopyası ikinci ve tutarsız bir doğruluk kaynağına dönüşebilir.

## 5. Karar vermeden önce kurtarma modelini doğrulayın

Hangi rol seçilirse seçilsin yedeklemeyi planlayın ve geri yüklemeyi test edin. Replikalar erişilebilirliğe yardımcı olur ancak yedeklerin yerini tutmaz. Gerçek yapılandırma için kabul edilebilir veri kaybını ve kurtarma süresini tanımlayın.

Sipariş örneğinde işlemsel kayıtları kurallarını destekleyen bir veritabanında tutar, arama gereksinimleri haklı çıkarıyorsa Elasticsearch eklerdim. Bağımsız, arama odaklı belgelerde Elasticsearch'ün tek başına depolama, tutarlılık ve kurtarma ihtiyaçlarını karşılayıp karşılamadığını değerlendirirdim.

**Unutmayın:** iş yükünün ihtiyaç duyduğu garantilere göre seçin, ardından hata ve kurtarma davranışını doğrulayın. Arama hızı bu kararın yalnızca bir parçasıdır.

Gereksinim	Değerlendirilecek yön	Neden
Siparişler ve ilişkili kayıtlar atomik değişmeli	İşlemsel birincil veritabanı	Gerekli doğruluk kuralları yetkili kayıtların yakınında olmalıdır.
Kullanıcıların esnek tam metin araması gerekiyor	Arama kopyası olarak Elasticsearch	Arama verisi bağımsız şekillendirilebilir ve yeniden oluşturulabilir.
Uyumlu tutarlılık ihtiyaçları olan bağımsız belgeler	Ana depo olarak Elasticsearch uygun olabilir	İkinci veritabanının kanıtlanmış bir amacı olmalıdır.

1. Birlikte başarılı olması gereken değişikliklerden başlayın

2. Belge korumasını iş garantilerinden ayırın

3. Bir yazmanın ne zaman aranabilir olduğunu kontrol edin

4. Elasticsearch'ün rolünü seçin

5. Karar vermeden önce kurtarma modelini doğrulayın

İlgili sorular