Πότε δεν ενδείκνυται το Elasticsearch ως κύρια βάση δεδομένων;

Question

IT Interview Practice · Accepted Answer

Το Elasticsearch μπορεί να αποθηκεύει δεδομένα μόνιμα. Για να αποφασίσετε αν πρέπει να είναι η κύρια βάση, ρωτήστε **ποιοι επιχειρησιακοί κανόνες πρέπει να ισχύουν όταν οι εγγραφές αποτυγχάνουν ή εκτελούνται ταυτόχρονα**.

Σε σύστημα παραγγελιών, η εύρεση προϊόντων και η επιβεβαίωση αγοράς είναι διαφορετικές εργασίες. Στην πρώτη μετρά η συνάφεια αναζήτησης, στη δεύτερη οι σωστές αλλαγές πληρωμής και αποθέματος.

## 1. Ξεκινήστε από αλλαγές που πρέπει να πετύχουν μαζί

Ας υποθέσουμε ότι η αγορά χρειάζεται παραγγελία και μείωση αποθέματος. Πρέπει να οριστεί τι γίνεται αν πετύχει μόνο μία ενέργεια.

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

Το bulk API υποβάλλει πολλές λειτουργίες εγγράφων μαζί, αλλά μία μπορεί να αποτύχει και άλλη να πετύχει. Δεν τις κάνει συναλλαγή «όλα ή τίποτα». Η εφαρμογή πρέπει να εξετάζει κάθε αποτέλεσμα. [Bulk API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-bulk).

Για ατομική αλλαγή πολλών εγγραφών, μια συναλλακτική βάση συνήθως δίνει πιο άμεση βάση σχεδιασμού. Ο δικός σας συντονισμός προσθέτει περιπτώσεις αποτυχίας και αποκατάστασης.

## 2. Ξεχωρίστε προστασία εγγράφου και επιχειρησιακές εγγυήσεις

Ο αισιόδοξος έλεγχος ταυτόχρονης πρόσβασης ελέγχει αν το έγγραφο άλλαξε από την έκδοση που διαβάσατε. Μπορεί να απορρίψει παλιά ενημέρωση, αποτρέποντας σιωπηρή αντικατάσταση της δουλειάς άλλου πελάτη. [Έλεγχος ταυτόχρονης πρόσβασης](https://www.elastic.co/docs/reference/elasticsearch/rest-apis/optimistic-concurrency-control).

Η προστασία αφορά το συγκεκριμένο έγγραφο. Δεν συντονίζει αυτόματα απόθεμα και παραγγελία, δεν δίνει σχεσιακά ξένα κλειδιά ούτε επιβάλλει αυθαίρετη μοναδικότητα επιχειρησιακών πεδίων.

Γράψτε τους απαιτούμενους κανόνες πριν επιλέξετε αποθήκευση. Έτσι η απόφαση γίνεται συγκεκριμένη αντί να βασίζεται στην ονομασία «μηχανή αναζήτησης» ή «βάση δεδομένων».

## 3. Ελέγξτε πότε μια εγγραφή εμφανίζεται στην αναζήτηση

Η επιτυχής εγγραφή και το ορατό αποτέλεσμα αναζήτησης είναι διαφορετικά γεγονότα:

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

Το refresh κάνει πρόσφατες αλλαγές ορατές στην αναζήτηση. Συνεπώς η άμεση ανάκτηση με ID διαφέρει από ερώτημα αναζήτησης. Το refresh=wait_for μπορεί να περιμένει την ορατότητα, αλλά δεν δημιουργεί συναλλαγή πολλών εγγράφων. [Συμπεριφορά refresh](https://www.elastic.co/docs/reference/elasticsearch/rest-apis/refresh-parameter).

Στη σελίδα προϊόντων μικρή καθυστέρηση ίσως είναι αποδεκτή. Για τελική πληρωμή ή άδεια πρόσβασης, ορίστε ρητά τη συνέπεια και διαβάστε πηγή που την παρέχει. Refresh και μόνιμη αποθήκευση είναι επίσης διαφορετικά ζητήματα.

## 4. Επιλέξτε τον ρόλο του Elasticsearch

| Απαίτηση | Κατεύθυνση αξιολόγησης | Αιτία |
| --- | --- | --- |
| Παραγγελίες και σχετικές εγγραφές αλλάζουν ατομικά | Συναλλακτική κύρια βάση | Οι κανόνες ορθότητας ανήκουν κοντά στις έγκυρες εγγραφές. |
| Ευέλικτη αναζήτηση πλήρους κειμένου | Elasticsearch ως αντίγραφο αναζήτησης | Τα δεδομένα αναζήτησης διαμορφώνονται και ανακατασκευάζονται ανεξάρτητα. |
| Ανεξάρτητα έγγραφα με συμβατές ανάγκες συνέπειας | Ίσως ταιριάζει ως κύρια αποθήκη | Μια δεύτερη βάση χρειάζεται αποδεδειγμένο σκοπό. |

Συνηθισμένη σχεδίαση παραγγελιών είναι:

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

Το CDC καταγράφει δεσμευμένες αλλαγές, ενώ το outbox αποθηκεύει συμβάν μαζί με την επιχειρησιακή ενημέρωση στην ίδια συναλλαγή. Άλλη διεργασία τα μεταφέρει στο index. Έτσι δεν εξαρτάστε από δύο ανεξάρτητες εγγραφές που πρέπει πάντα να πετυχαίνουν μαζί.

Η διαδρομή indexing χρειάζεται σταθερά ID, εκδόσεις, διαγραφές, επαναλήψεις και παρακολούθηση καθυστέρησης. Δοκιμάστε ανακατασκευή από την πηγή, αλλιώς το αντίγραφο μπορεί να γίνει δεύτερη ασυνεπής πηγή αλήθειας.

## 5. Επιβεβαιώστε αποκατάσταση πριν δεσμευτείτε

Σε κάθε ρόλο σχεδιάστε αντίγραφα ασφαλείας και δοκιμάστε επαναφορά. Τα replicas βοηθούν διαθεσιμότητα, αλλά δεν αντικαθιστούν backups. Ορίστε ανεκτή απώλεια και χρόνο αποκατάστασης για την πραγματική ρύθμιση.

Στις παραγγελίες θα κρατούσα συναλλακτικά δεδομένα σε βάση που υποστηρίζει τους κανόνες τους, προσθέτοντας Elasticsearch αν δικαιολογείται από την αναζήτηση. Για ανεξάρτητα έγγραφα αναζήτησης θα εξέταζα αν αρκεί μόνο του για αποθήκευση, συνέπεια και αποκατάσταση.

**Θυμηθείτε:** επιλέξτε βάσει απαιτούμενων εγγυήσεων και επαληθεύστε αποτυχίες και επαναφορά. Η ταχύτητα αναζήτησης είναι μόνο μέρος της απόφασης.

Απαίτηση	Κατεύθυνση αξιολόγησης	Αιτία
Παραγγελίες και σχετικές εγγραφές αλλάζουν ατομικά	Συναλλακτική κύρια βάση	Οι κανόνες ορθότητας ανήκουν κοντά στις έγκυρες εγγραφές.
Ευέλικτη αναζήτηση πλήρους κειμένου	Elasticsearch ως αντίγραφο αναζήτησης	Τα δεδομένα αναζήτησης διαμορφώνονται και ανακατασκευάζονται ανεξάρτητα.
Ανεξάρτητα έγγραφα με συμβατές ανάγκες συνέπειας	Ίσως ταιριάζει ως κύρια αποθήκη	Μια δεύτερη βάση χρειάζεται αποδεδειγμένο σκοπό.

1. Ξεκινήστε από αλλαγές που πρέπει να πετύχουν μαζί

2. Ξεχωρίστε προστασία εγγράφου και επιχειρησιακές εγγυήσεις

3. Ελέγξτε πότε μια εγγραφή εμφανίζεται στην αναζήτηση

4. Επιλέξτε τον ρόλο του Elasticsearch

5. Επιβεβαιώστε αποκατάσταση πριν δεσμευτείτε

Σχετικές ερωτήσεις