Elasticsearch vs Cassandra vs Elasticsearch z Cassandrą

110

Uczę się NoSQL i szukam różnych opcji dla jednego z wymagań mojego klienta. Przeszedłem przez różne źródła, zanim postawiłem to pytanie (osoba z niewielką wiedzą w NoSQL)

  • Muszę szybciej przechowywać dane i je czytać.
  • W pełni bezpieczny i łatwo skalowalny.
  • Potrafi przeszukiwać dane dla Analytics.

Skończyło się na krótkiej liście: Cassandra and Elasticsearch

Rozumiem, że Cassandra jest dla mnie idealnym rozwiązaniem pamięci masowej NoSQL, ponieważ mogę zapisywać i odczytywać dane za pomocą indeksów. Jeśli zawiedzie lub może się nie powieść, znajdziesz w Analytics. W przyszłości, jeśli chcę uzyskać dane z from_date to to_datelub więcej sposobów na uzyskanie danych do analityki, jeśli nie zaprojektuję odpowiednio modelu danych lub nie zachowam długoterminowej obserwacji, co może być dość trudne w ciągle zmieniającym się świecie.

Chociaż Elastic Searchjest najlepszy w indeksowaniu (wspierany przez Lucene) i może wyszukiwać dane losowo, rzucając losowy tekst. Ale czy to działa tak samo, nawet jeśli chcę odzyskać dane from_date to to_date(spodziewam się, że tak może być). Ale prawdziwe pytanie brzmi: czy jest to wyszukiwarka, czy doskonały magazyn danych NoSQL, taki jak Cassandra? Jeśli tak, dlaczego nadal potrzebujemy Cassandry?

Jeśli oba są w innym świecie, wyjaśnij to! Jak je połączyć, aby uzyskać bardziej efektywne rozwiązanie?

Reddy
źródło
2
Należy również wziąć pod uwagę DSE Search = Cassandra + solr Integrated = najlepsze z obu światów: skalowalna baza danych dla pamięci masowej napędzana mocą wyszukiwania Solr.
Bereng
1
@Bereng, myślę, że DSE jest komercyjne i nie zajmujemy się komercyjnym oprogramowaniem.
Reddy
3
Jeśli jesteś startupem z przychodami netto <2 mln USD (USA), pozwolą Ci korzystać z DSE bezpłatnie (przez co najmniej rok lub dwa).
Aaron

Odpowiedzi:

150

Jedna z naszych aplikacji wykorzystuje dane przechowywane zarówno w Cassandrze, jak i ElasticSearch. Używamy Cassandry, aby uzyskać dostęp do tych rekordów, kiedy tylko jest to możliwe, i powielać dane w tabelach zapytań zaprojektowanych tak, aby były zgodne z określonymi żądaniami po stronie aplikacji. Aby uzyskać bardziej liberalne wyszukiwanie, niż pozwalają na to nasze tabele zapytań, ElasticSearch dobrze wykonuje tę funkcję.

Zadaliśmy to samo pytanie (sobie)… „Dlaczego nie weźmiemy wszystkiego z ElastsicSearch?”

Odpowiedź jest taka, że ​​ElasticSearch został zaprojektowany jako wyszukiwarka, a nie trwały magazyn danych. Czasami ElasticSearch traci zapisy. Zmiany schematu są trudne w ElasticSearch bez odrzucania wszystkiego i ponownego ładowania. W tym celu napisałem zadania, które mają na celu utrzymanie synchronizacji ElasticSearch z naszym klastrem Cassandra. Na Quorze odbyła się również stosunkowo niedawna dyskusja na ten temat , która przyniosła podobne wnioski.

Biorąc to pod uwagę, ElasticSearch działa świetnie jako wyszukiwarka. A Cassandra świetnie sprawdza się jako skalowalny magazyn danych o wysokiej wydajności. Jednak wysyłanie zapytań do danych różni się od wyszukiwania danych. Są chwile, kiedy potrzebujemy jednego lub drugiego, a połączenie tych dwóch działa dobrze w naszej aplikacji. Może (ale nie musi) działać dobrze dla twojego.

Jeśli chodzi o analitykę, odniosłem pewien sukces w używaniu łącznika Cassandra Spark do obsługi bardziej złożonych zapytań OLAP. Mam nadzieję, że to pomoże.

Edytuj 20200421

Napisałem nowszą odpowiedź na podobne pytanie:

ElasticSearch a ElasticSearch + Cassandra

Aaron
źródło
24
Czy ktoś może wyjaśnić różnicę między odpytywaniem a wyszukiwaniem danych?
Dror
21
@dror na przykład, jeśli znasz identyfikator (y) swoich danych, po prostu o nie prosisz (cassandra), a jeśli nie znasz identyfikatora (-ów) swoich danych, wyszukujesz je / je (wyszukiwanie elastyczne).
arsenik
2
@Gladwell wszystko zależy od rozmiaru Twoich danych i złożoności zapytań. Teoretycznie Elastic może wszystko. Jednak ufam, że Cassandra wykona lepszą pracę skalowania do obsługi dużego zestawu danych (dla zapytań) niż Elastic, zwłaszcza jeśli obsługujesz wiele regionów / DC.
Aaron
1
@Aaron ... skalowanie w celu obsługi dużego zbioru danych jest tym, co dobrze robią oba te silniki. Nasza organizacja używa elastycznego wyszukiwania jako podstawowej bazy danych, mechanizmu ostrzegania, narzędzia analitycznego, a teraz, gdy xpack obsługuje uczenie maszynowe; zapewnia również statystyki biznesowe wokół naszej krawędzi IOT.
AnthonyJClink
1
@Dror Zadawanie prawdziwego pytania!
Mike Ezzati
32

Cassandra + Lucene to świetna opcja. Istnieją różne inicjatywy w tej sprawie, na przykład:

Alvaro Agea
źródło
Należy pamiętać o jednej rzeczy, w 2.1 możesz teraz "upuścić" niestandardowy indeksator ... więc na przykład możesz naśladować to, co robi Statio z ich rozwidleniem C *, ale poza głównym wierszem C *. Nie jestem świadomy jakichkolwiek szeroko zakrojonych wysiłków, aby to zrobić, ale sam w ten sposób planuję obniżyć indeksy Lucene do C *. Więcej informacji: Issues.apache.org/jira/browse/CASSANDRA-8717
evanv.
8

Po samodzielnej pracy nad tym problemem zdałem sobie sprawę, że bazy danych NoSQL, takie jak casandra, są dobre, gdy chcesz mieć pewność, że zachowujesz schemat danych z niezawodną operacją zapisu, i nie chcesz korzystać z operacji indeksowania oferowanych przez elastyczne wyszukiwanie. Jeśli chcesz zachować niektóre dane indeksów, elastyczne wyszukiwanie jest dobre, jeśli ufasz swojemu schematowi i zamierzasz wykonać znacznie więcej odczytów niż zapisów.

Mój przypadek dotyczył analityki danych. Tak więc zachowałem wiele moich Lateksów w wyszukiwaniu elastycznym, ponieważ później chciałem dużo przejrzeć dane, aby zobaczyć, jaki powinien być mój następny krok. Użyłbym casandra, gdybym chciał wprowadzić wiele zmian w schemacie danych w moich pilotażach analitycznych.

Istnieje również wiele fajnych narzędzi do reprezentacji, takich jak kibana, których możesz użyć do zaprezentowania danych z dobrą grafiką. Może jestem leniwy, ale wyglądają bardzo dobrze i pomogli mi.

M.Rez
źródło
4

Przechowywanie danych w połączeniu Cassandry i ElasticSearch zapewnia największą funkcjonalność. Umożliwia wyszukiwanie tabel klucz-wartość, a także umożliwia wyszukiwanie danych w indeksach.

To połączenie zapewnia dużą elastyczność, idealną do Twojego zastosowania.


źródło
4

Elassandra to połączone rozwiązanie Cassandra + Elastic search, wykorzystuje Elastic search do indeksowania danych i Cassandra jako magazyn danych, nie jestem pewien co do wydajności, ale zgodnie z tym artykułem jej wydajność jest dobra.
Jeśli Twoja aplikacja wymaga funkcji wyszukiwania, Elassandra jest najlepszą opcją open source. Wyszukiwanie DSE jest dostępne, ale jest drogie.

anavaras lamurep
źródło
1

Stworzyliśmy aplikację, w której wykorzystaliśmy Elasticsearch i Cassandra. Podobne dane zostały zapisane w Cassandrze i zindeksowane w Elasticsearch.

Interfejs użytkownika naszej aplikacji zawierał funkcje takie jak wyszukiwanie, agregacje, eksport danych itp. Mikroserwisy zaplecza nieustannie pobierały ogromne dane (dotyczące tematów Kafki) i zapisywały je w Cassandrze. Gdy dane zostaną zapisane w Cassandrze, usługi upewnią się, że dane są indeksowane w Elasticsearch.

Cassandra działała jako „źródło prawdy” dla Elasticsearch. W przypadkach, gdy wymagane było ponowne zindeksowanie indeksu ES, odpytaliśmy Cassandrę i ponownie zindeksowaliśmy dane do ES.

To rozwiązanie pomogło nam, ponieważ było bardzo łatwe do skalowania, a wyszukiwania i agregacje były znacznie szybsze.

Sumit A
źródło
0
  • Ponieważ elastyczne wyszukiwanie jest oparte na indeksie Lucene i jeśli chcesz przechowywać indeksowanie w elastyku, działa najlepiej w porównaniu z indeksowaniem w samej Cassandrze w celu pobrania danych.
  • Jeśli Twoje wymagania nie są związane z pobieraniem w czasie rzeczywistym, możesz również użyć elastycznego wyszukiwania jako bazy danych NoSQL, istnieją myśli, że ElasticSearch traci zapisy, a zmiany schematu są trudne, ale jeśli ilość danych nie jest zbyt duża. Możesz łatwo osiągnąć elastyczne wyszukiwanie jako wyszukiwarkę z najlepszym indeksowaniem wraz z elastycznym wyszukiwaniem jako bazą danych NoSQL. Istnieje kilka sposobów, aby temu zapobiec. Pracowałem nad zmianami schematu w elasticsearch, jeśli struktura danych jest spójna, spowoduje to jakiekolwiek problemy.
  • Bycie zwolennikiem ElasticSearch lub SOlr. Pracowałem nad obydwoma wyszukiwarkami i doświadczyłem, że obie wyszukiwarki mogą być używane płynnie, jeśli skonfigurujesz je poprawnie.
  • Jedyne minusy, o których mogę pomyśleć, jeśli celujesz w wynik w czasie rzeczywistym i nie możesz skracać milisekund opóźnienia w swojej odpowiedzi. W takim razie lepiej skorzystać z pomocy innych baz danych NoSQL, takich jak Cassandra lub Couchbase.
  • Cassandra z solr, działa lepiej niż Cassandra z elastyczną wyszukiwarką.
vishal yadav
źródło
0

Cassandra świetnie radzi sobie z pobieraniem danych przez ID . Nie wiem zbyt wiele o wydajności indeksu drugorzędnego, ale wątpię, czy jest tak szybki, jak Elasticsearch. Z pewnością Elasticsearch wygrywa, jeśli chodzi o funkcję wyszukiwania pełnotekstowego ( analiza tekstu , ocena trafności) itp.).

Cassandra również wygrywa pod względem wydajności aktualizacji . Elasticsearch obsługuje aktualizacje, ale aktualizacja to tak naprawdę reindeksowanie + nietrwałe usuwanie w niepodzielnej operacji.

Cassandra ma bardzo ładny model replikacji (jeśli chcesz być wyjątkowo bezpieczny). Elasticsearch też jest w porządku, nie jestem w obozie, który mówi, że ES jest szczególnie zawodny (czasami ma problemy, jak każde oprogramowanie).

Elasticsearch udostępnia również agregacje do analiz w czasie rzeczywistym. A ponieważ wyszukiwania są tak szybkie, analizy podzbioru danych będą szybkie .

Jeśli twoje wymagania są wystarczająco dobrze spełnione przez jeden z nich (tak jak tutaj wygląda na to, że ES będzie działał dobrze), użyłbym tylko jednego. Jeśli masz wymagania z obu światów, możesz:

  • użyj jednego z nich i obejdź wady. Na przykład możesz być w stanie obsłużyć wiele aktualizacji za pomocą Elasticsearch, ale z większą liczbą fragmentów i większym sprzętem
  • użyj obu i upewnij się, że są zsynchronizowane
Radu Gheorghe
źródło