Kiedy używać Cassandra vs Solr w DSE?

Question

Używam DSE do integracji Cassandra/Solr, aby dane były przechowywane w Cassandrze i indeksowane w Solr. To bardzo naturalne, że używa Cassandry do obsługi operacji CRUD i używa Solr do pełnego wyszukiwania tekstowego, a DSE może naprawdę uprościć synchronizację danych między Cassandrą i Solr.

Jeśli chodzi o zapytanie, istnieją dwa sposoby przejścia: Cassandra pomocniczy/ręczny skonfigurowany indeks vs. Solr. Chcę wiedzieć, kiedy stosować tę metodę i jaka jest różnica w wydajności, zwłaszcza w konfiguracji DSE.

Oto jeden przykład użycia w moim projekcie. Mam tabelę Cassandry przechowującą pewne dane jednostki towaru. Poza podstawową operacją CRUD, muszę również pobrać elementy według równości na pewnym polu (np. Kategoria), a następnie sortować według pewnego porządku (w moim przypadku tutaj pole like_count).

mogę myśleć o trzech różnych sposobów, aby sobie z tym poradzić:

1. Declare „indeksowane = true” w schemacie Solr dla obu kategorii i pola like_count i kwerendy w Solr
2. Tworzenie nieznormalizowane tabeli w Cassandry z klucz podstawowy (kategoria, like_count, id)
3. Tworzenie nieznormalizowane tabeli w Cassandry z klucza podstawowego (kategoria, klasa, id) i użyć zewnętrznego urządzenia, takiego jak Spark/Storm, aby posortować elementy według like_count

Pierwsza metoda wydaje się być najprostsza w implementacji i utrzymaniu. Po prostu napiszę trochę trywialnego kodu dostępu do Solr, a pozostałe podnoszenie ciężkie obsługiwane jest przez Solr/DSE search.

Druga metoda wymaga ręcznej denormalizacji przy tworzeniu i aktualizacji. Muszę również zachować oddzielną tabelę. Istnieje również problem z grobowcem, ponieważ wartość like_count może być często aktualizowana. Dobrą stroną jest to, że odczyt może być szybszy (jeśli nie ma nadmiernych nagrobków).

Trzecia metoda może złagodzić problem nagrobka kosztem jednego dodatkowego komponentu do sortowania.

Która metoda jest według ciebie najlepszą opcją? Jaka jest różnica w wydajności?

Answer 1

Cassandra indeksy wtórne mają ograniczone przypadki użycia:

1. Nie więcej niż kilka kolumn indeksowanych.
2. Tylko jedna indeksowana kolumna w zapytaniu.
3. zbyt dużego ruchu między węzłami danych wysokiej liczby elementów (relatywnie unikatowe wartości kolumna)
4. zbyt dużego ruchu między węzłami dla niskich danych liczby elementów (wysoki procent rzędów pasuje)
5. zapytania muszą być znane z góry więc model danych można zoptymalizować wokół nich.

Z powodu tych ograniczeń aplikacje często tworzą "tabele indeksów" indeksowane przez dowolną kolumnę. Wymaga to, aby dane były duplikowane z głównej tabeli do każdej tabeli indeksów, lub dodatkowe zapytanie będzie potrzebne do odczytania tabeli indeksów, a następnie odczytanie rzeczywistego wiersza z głównej tabeli po przeczytaniu głównego klucza z tabeli indeksów. Zapytania dotyczące wielu kolumn będą musiały być wcześniej ręcznie indeksowane, co sprawia, że ​​zapytania ad hoc są problematyczne. Wszelkie duplikaty będą musiały być ręcznie aktualizowane przez aplikację w każdej tabeli indeksów.

Poza tym ... będą działały poprawnie w przypadkach, w których "skromna" liczba wierszy zostanie wybrana spośród niewielkiej liczby węzłów, a zapytania są dobrze określone wcześniej, a nie ad hoc.

DSE/Solr jest lepsze dla:

1. Umiarkowany liczba kolumn są indeksowane.
2. Złożone kwerendy z pewną liczbą kolumn/pól, do których się odwołuje - Lucene dopasowuje wszystkie określone pola w zapytaniu równolegle. Lucene indeksuje dane w każdym węźle, więc węzły kwerendy równolegle.
3. Zapytania ad hoc ogólnie, gdzie dokładne zapytania nie są z góry znane.
4. Zapytania w postaci tekstu sformatowanego, takie jak wyszukiwanie słów kluczowych, symbole wieloznaczne, fuzzy/like, zakres, nierówność.

Jest wydajność i pojemność koszt korzystania Solr indeksowanie, a więc dowód wykonania koncepcji zaleca się ocenić, jak bardzo potrzebne są dodatkowe RAM, przechowywania i węzły, które zależy od liczby kolumn wy wskaźnik, tym ilość indeksowanych tekstów i dowolna złożoność filtrowania tekstu (np. n-gramy potrzebują więcej.) Może wynosić od 25% wzrostu w przypadku relatywnie małej liczby indeksowanych kolumn do 100%, jeśli wszystkie kolumny są indeksowane. Ponadto musisz mieć wystarczającą liczbę węzłów, aby indeks Solr na węzeł mieścił się w pamięci RAM lub przeważnie w pamięci RAM, jeśli używasz dysku SSD. I vnodes nie są obecnie zalecane dla centrów danych Solr.