Solr caching z EHCache/BigMemory

Question

Wdrażamy dużą konfigurację Lucene/Solr z dokumentami przekraczającymi 150 milionów. Będziemy także aktualizować dokumenty o umiarkowanej ilości każdego dnia.

Moje pytanie jest naprawdę jeden z dwóch części:

Jakie są konsekwencje wdrożenia buforowania przy użyciu innego ciągu Solr, czyli ehcache zamiast natywnej Solr LRUCache/FastLRUCache?

Terakota ogłosiła BigMemory, która ma być używana w połączeniu z EHCache jako wewnątrzprocesowy bufor podręczny. Zgodnie z TC, pozwala to na przechowywanie dużych ilości danych bez obciążenia GC JVM. Czy jest to dobry pomysł, aby korzystać z Solr? Czy to naprawdę pomoże?

Chciałbym esp. Chciałbym usłyszeć od ludzi z prawdziwym doświadczeniem w produkcji z EHCache/BigMemory i/lub Solr Cache Tuning.

Answer 1

Nie jestem pewien, czy ktoś próbował tego jeszcze. Na pewno chcielibyśmy nawiązać współpracę z ludźmi z Solr, aby przekonać się, jak przydatne byłoby to. Możemy nawet zoptymalizować go pod kątem użycia.

Answer 2

Wiele myśli na ten temat. Chociaż moja odpowiedź nie wpływa w żaden sposób na EhCache.

Po pierwsze, nie wierzę, że dokumenty powinny być przechowywane w indeksie wyszukiwania. Zawartość wyszukiwania powinna być tam przechowywana, a nie cały dokument. Mam na myśli to, że to, co powróciło z twojego zapytania, powinno być identyfikatorem dokumentu. Nie treść samych dokumentów. Same dokumenty powinny być przechowywane i pobierane z drugiego systemu, prawdopodobnie oryginalnego magazynu plików, od którego są indeksowane. Zmniejszy to rozmiar indeksu, zmniejszy rozmiar pamięci podręcznej dokumentu, zmniejszy czas replikacji master slave (może to stać się wąskim gardłem, jeśli często aktualizujesz) i zmniejszy narzut podczas pisania odpowiedzi wyszukiwania.

Następnie rozważ wprowadzenie wstecznego proxy HTTP przed Solr. Chociaż pamięci podręczne zapytań umożliwiają Solr szybką reakcję, pamięć podręczna, taka jak lakier, znajdująca się przed Solr, jest jeszcze szybsza. To zwalnia Solr, pozwalając mu spędzać czas reagując na zapytania, których jeszcze nie widział. Drugim efektem jest to, że możesz teraz wrzucić większość pamięci do pamięci podręcznej dokumentów zamiast do pamięci podręcznej zapytań. Jeśli zastosujesz się do mojej pierwszej sugestii, twoje dokumenty będą niewiarygodnie małe, pozwalając zachować większość, jeśli nie wszystkie, w pamięci.

Szybkie obliczanie obwiedni dla wielkości dokumentów. Mogę łatwo dostarczyć 32-bitowy int jako identyfikator dla 150 milionów dokumentów. Nadal mam 10x miejsca na wzrost dokumentów. 150 milionów identyfikatorów zajmuje 600 MB. Dodaj współczynnik kłamstwa dla dokumentów zawijających Solr, a prawdopodobnie będziesz mógł łatwo przechowywać wszystkie dokumenty Solr w pamięci podręcznej w rozmiarze 1-2 GB. Biorąc pod uwagę, że uzyskanie 12 GB-24 GB lub pamięci RAM jest teraz łatwe, powiedziałbym, że można zrobić to wszystko na 1 pudełku i uzyskać niesamowitą wydajność. Nie potrzeba niczego innego, jak EhCache. Tylko upewnij się, że wykorzystujesz swój indeks wyszukiwania tak skutecznie, jak to tylko możliwe.

Jeśli chodzi o GC: Nie widziałem zbyt dużo czasu GC na serwerach Solr. Większość z tego, co należało zebrać, to bardzo krótkotrwałe obiekty związane z żądaniem HTTP i cyklem reakcji, które nigdy nie wychodzi z przestrzeni eden. Pamięć podręczna nie osiągnęła dużych obrotów po prawidłowym dostrojeniu. Jedyne duże zmiany nastąpiły po załadowaniu nowego indeksu, a pamięci podręczne zostały spłukane, ale nie działo się to ciągle.

EDYCJA: Dla tła, spędziłem trochę czasu, dostosowując buforowanie Solr dla dużej firmy, która sprzedaje konsole i obsługuje miliony wyszukiwań dziennie z serwerów Solr.