Elasticsearch replikacja innych danych systemowych?

Question

Załóżmy, że chcę użyć elasticsearch do wdrożenia wyszukiwania ogólnego na stronie internetowej. Górny pasek wyszukiwania powinien znajdować zasoby różnych typów w całej witrynie. Dokumenty na pewno (przesłane/zindeksowane za pośrednictwem tika), ale także takie rzeczy jak klienci, konta, inne osoby itp.

Ze względów architektonicznych większość dokumentów innych niż dokumenty (klienci, konta) będzie istniała w relacyjnej bazie danych.

Wdrażając to wyszukiwanie, opcją # 1 byłoby tworzenie wersji dokumentów wszystkiego, a następnie użycie elastycznego przeszukiwania, aby uruchomić wszystkie aspekty wyszukiwania, polegając w ogóle na relacyjnej bazie danych w celu znalezienia różnych typów obiektów.

Opcja nr 2 polega na użyciu elastycznego wyszukiwania tylko do indeksowania dokumentów, co oznaczałoby dla ogólnej funkcji "wyszukiwania w witrynie", musisz wydzielić wiele wyszukiwań do wielu systemów, a następnie zebrać wyniki przed ich zwrotem .

Opcja nr 1 wydaje się o wiele lepsza, ale wadą jest to, że wymaga ona, aby wyszukiwanie elastyczne miało w istocie kopię bardzo wielu różnych rzeczy w relacyjnej bazie danych produkcji, a także, że kopie te zachowają świeżość po zmianie.

Jaki jest najlepszy sposób na utrzymanie synchronizacji tych sklepów i czy mam rację, sądząc, że w przypadku wyszukiwania ogólnego opcja nr 1 jest lepsza? Czy istnieje opcja # 3?

Answer 1

Na liście znajdują się dwie główne opcje wyszukiwania w wielu magazynach danych, np. Wyszukiwanie w jednym centralnym magazynie danych (opcja nr 1) lub wyszukiwanie we wszystkich magazynach danych i łączenie wyników (opcja # 2).

Obie opcje będą pracować, choć opcja nr 2 ma dwie główne wady:

1. będzie wymagać znacznej ilości logiki, które zostaną opracowane w aplikacji w celu „oddziału” do wyszukiwania wielokrotności Przechowuj dane i zbieraj wyniki, które otrzymujesz.
2. Czas odpowiedzi może być różny dla każdej składnicy danych, w związku z czym należy poczekać, aż najwolniejsza składnica danych odpowie, aby przedstawić wyniki wyszukiwania użytkownikowi (chyba że obejdzie się to przy użyciu różnych technologii asynchronicznych, takie jak Ajax, websocket, itp.)

Jeśli chcesz zapewnić lepsze i bardziej niezawodne wyszukiwanie, opcja nr 1 wyraźnie dostałaby mój głos (tak naprawdę to robię w większości przypadków). Jak poprawnie stwierdzono, główną "wadą" tej opcji jest konieczność zachowania synchronizacji Elasticsearch ze zmianami w innych głównych magazynach danych.

Ponieważ Twoje inne magazyny danych będzie relacyjnych baz danych, masz kilka różnych opcji, aby utrzymać je w synchronizacji z Elasticsearch, a mianowicie:

• pomocą Logstash JDBC input
• pomocą funkcji

JDBC importer

Te dwie pierwsze opcje działają świetnie, ale mają jedną główną wadę, tzn. Nie przechwytują DELETE na stole, przechwytują tylko INSERT i UPDATE. Oznacza to, że jeśli kiedykolwiek usuniesz użytkownika, konto itp., Nie będziesz wiedział, że musisz usunąć odpowiedni dokument w Elasticsearch. O ile oczywiście nie zdecydujesz się usunąć indeks Elasticsearch przed każdą sesją importowania.

Aby to zlikwidować, możesz użyć innego narzędzia, które opiera się na binlogu MySQL i dzięki temu będzie mogło przechwytywać każde zdarzenie. Jest napisane w Go, jedno w Java i jedno w Python.