Skalowanie ElasticSearch

Question

Szukam informacji na temat tego, jak ElasticSearch będzie skalował się z ilością danych w indeksach i jestem zaskoczony, jak mało mogę znaleźć na ten temat. Może jakieś doświadczenie z tłumu tutaj może mi pomóc.

Obecnie korzystamy z CloudSearch do indeksowania ≈ 7 milionów dokumentów; w CloudSearch powoduje to 2 wystąpienia typu m2.xlarge. Zamiast tego rozważamy przejście na ElasticSearch w celu obniżenia kosztów. Ale wszystko, co znajduję na skalowaniu ElasticSearch, to to, że skaluje się dobrze, może być rozłożony w kilku instancjach itd.

Ale jakiego rodzaju urządzenie (pamięć, dysk) potrzebowałbym dla tego rodzaju danych?

Jak by to zmienić, gdybym zwiększył ilość danych o współczynnik 12 (≈ 80 milionów dokumentów)?

Answer 1

Ostatnio przełączyłem się z CloudSearch na hostowaną usługę ElasticSearch w firmie, w której pracuję. Nasza specyficzna aplikacja ma niewiele ponad 100 milionów dokumentów i rośnie każdego dnia. Jak dotąd nasze doświadczenie z ElasticSearch było absolutnie cudowne. Średnia wydajność wyszukiwania wynosi ~ 250ms, nawet przy sortowaniu, filtrowaniu i facetingowaniu. Dokumenty indeksujące są również stosunkowo szybkie, pomimo kilku MB obciążenia, które przechodzimy przez HTTP z masowym API co kilka godzin. Częstotliwość odświeżania również wydaje się bliska natychmiastowej reakcji.

Dla naszego indeksu ~ 100M doc/12GB użyliśmy 4 replik/2 repliki (powstaną 3 repliki, jeśli wydajność spadnie) rozłożone na 4 węzły. Przed skonfigurowaniem indeksu nasz zespół spędził kilka dni na badaniu wdrożenia/konserwacji klastra ElasticSearch i zdecydował się na użycie http://qbox.io, aby zaoszczędzić pieniądze i czas. Paraliżująco obawialiśmy się problemów z wydajnością i skalowaniem, decydując się na hosting naszego indeksu na dedykowanym klastrze, takim jak Qbox, ale do tej pory doświadczenie było naprawdę fantastyczne.

Ponieważ nasz indeks znajduje się w dedykowanym klastrze, nie mamy dostępu do konfiguracji konfiguracji na poziomie węzłów, więc moja wiedza techniczna z wdrożeniem ES jest nadal dość ograniczona. Biorąc to pod uwagę, nie jestem pewien, jakie dokładnie wydajności są potrzebne dla wydajności, której doświadczyliśmy w naszym indeksie. Wiem jednak, że klaster Qboksa używa SSD ... tak, że z pewnością może mieć znaczący wpływ.

Sytuacja w przypadku, ElasticSearch ma skalowane bezproblemowo. Wysoce, bardzo polecam przełącznik (nawet jeśli to tylko zaoszczędzić $$, CloudSearch jest szalenie drogi). Mam nadzieję, że te informacje pomogą!

Answer 2

Jako Javanna said, to zależy. Głównie na: (1) wskaźnik indeksowania; (2) rozmiar dokumentów; (3) wymagania dotyczące częstości i opóźnień w wyszukiwaniu; i (4) rodzaj wyszukiwań.

Biorąc to pod uwagę, najlepiej możemy pomóc podając przykłady. Na our site (monitoring aktualności) mamy:

1. Index ponad 100 docs na minutę. Mamy obecnie około 50 milionów dokumentów. Słyszałem także o indeksach ES z setkami milionów dokumentów.
2. Dokumenty to artykuły z niektórymi metadanymi, nie krótkie, ale nie takie duże.
3. Nasze opóźnienie wyszukiwania wynosi od ~ 50 ms (dla normalnych i rzadkich terminów) do 800 ms dla wspólnych haseł (stopwords, indeksujemy je). Ta odmiana jest w dużej mierze spowodowana naszą niestandardową punktacją (dzięki obsłudze Lucene/ES w celu jej dostosowania) oraz faktem, że zestaw danych (odwrócone listy) nie mieści się całkowicie w pamięci (pamięć podręczna systemu operacyjnego). Więc kiedy trafi na buforowaną odwróconą listę, jest szybszy.
4. Wykonujemy zapytania OR z wieloma terminami, które są jednym z najtrudniejszych. Wykonujemy również faceting na dwóch polach o pojedynczej wartości. I trochę eksperymentów z aspektem daty (aby pokazać tempo publikacji w czasie).

Robimy to wszystko przy 4 instancjach EC2 z m1.large. A teraz planujemy przejść na ES, just released, 0.9 version, aby uzyskać wszystkie bonusy i ulepszenia wydajności Lucene 4.0.

Teraz pozostawiając przykłady na bok. ElasticSearch jest dość skalowalny. Utworzenie indeksu za pomocą N shards i M replicas jest bardzo proste, a następnie utworzenie maszyn X z ES. Rozprowadzi on odpowiednio wszystkie odłamki i repliki. Możesz zmienić liczbę replik w dowolnym momencie (dla każdego indeksu).

Jedną z wad jest to, że nie można zmienić liczby odłamków po utworzeniu indeksu. Ale wciąż możesz "przesłonić" go wcześniej, aby w razie potrzeby zostawić miejsce na skalowanie. Lub utwórz nowy indeks z odpowiednią liczbą odłamków i ponownie zindeksuj wszystko (robimy to).

Wreszcie, ElasticSearch (a także) używa pod maską biblioteki Lucene Search, która jest bardzo dojrzałą i dobrze znaną biblioteką.

Answer 3

CloudSearch niedawno spadły ceny i może teraz być tańsze rozwiązanie niż utrzymywanie własnego Search infrastrcuture na EC2 - http://aws.amazon.com/blogs/aws/cloudsearch-price-reduction-plus-features/