SOLR autoCommit vs autoSoftCommit

Myślę, że ten Artykuł będzie dla Ciebie przydatny. Wyjaśnia on szczegółowo, jak działają twarde i miękkie commity, a także kompromisy, które powinny być brane pod uwagę podczas strojenia systemu.

Zawsze drżę z tego powodu, ponieważ każda rekomendacja w niektórych przypadkach będzie błędna. Moim pierwszym zaleceniem byłoby, aby nie zastanawiać się nad problemem. Niektórzy bardzo mądrzy ludzie starali się, aby cały proces był solidny. Najpierw wypróbuj proste rzeczy i dostosuj je tylko w razie potrzeby. W w szczególności, spójrz na rozmiar dzienników transakcji i dostosuj swoje twarde przedziały commitów, aby utrzymać te "rozsądne rozmiary". Pamiętaj, że karą jest głównie czas powtórki, jeśli ponownie uruchomisz się po awarii JVM. Czy 15 sekund jest dopuszczalne? Więc po co się zmniejszać?

Widzieliśmy sytuacje, w których twardy interwał zatwierdzania jest znacznie krótszy niż miękki interwał zatwierdzania, patrz bit indeksowania zbiorczego poniżej.

To są miejsca na początek.

HEAVY (BULK) Indeksowanie

Założenie tutaj jest takie, że jesteś zainteresowany dostarczeniem wielu danych do indeksu tak szybko, jak to możliwe do wyszukiwania w przyszłości. Myślę o oryginalnych źródłach danych itp.

Ustaw swój miękki interwał commit dość długo. Jak za 10 minut. Soft commit dotyczy widoczności, a moim założeniem jest to, że indeksowanie zbiorcze nie polega na wyszukiwaniu w czasie zbliżonym do rzeczywistego, więc nie wykonuj dodatkowej pracy, otwierając jakikolwiek rodzaj wyszukiwarki. Ustaw swoje twarde przedziały commitów do 15 sekund, openSearcher = false. Ponownie zakłada się, że będziesz po prostu wysadzać dane w Solr. Najgorszy przypadek polega na tym, że restartujesz system i musisz odtworzyć 15 sekund lub więcej danych z tlog. Jeśli Twój system częściej odbija się w górę i w dół, najpierw ustal przyczynę. Dopiero po wypróbowaniu prostych rzeczy należy rozważyć udoskonalenia, są one zwykle wymagane tylko w nietypowych okolicznościach. Ale obejmują one: Wyłączanie tlog całkowicie do pracy przy dużym obciążeniu Indeksowanie w trybie offline za pomocą jakiejś mapy-zmniejsz proces Tylko posiadanie przyponu na odłamek, brak replik na obciążenie, potem włączanie replik i pozwalanie im na replikację w starym stylu, aby nadrobić zaległości. Zauważ, że jest to automatyczne, jeśli węzeł wykryje, że jest "za daleko" poza synchronizacją z liderem, inicjuje replikację w starym stylu. Po dogonić, dostanie dokumenty, ponieważ są one indeksowane do lidera i zachować własny tlog. itd.

INDEX-HEAVY, QUERY-LIGHT

Mam na myśli, powiedzmy, przeszukiwanie plików dziennika. Jest to przypadek, w którym masz dużo danych pochodzących z systemu prawie cały czas. Ale Ładowanie zapytań jest dość lekkie, często w celu rozwiązywania problemów lub analizy użycia.

Ustaw swój miękki przedział zatwierdzania dość długo, aż do maksymalnego opóźnienia, jakie można uzyskać, aby dokumenty były widoczne. To może potrwać kilka minut lub znacznie dłużej. Może nawet godziny z możliwością wydania twardego commita (opensearcher = true) lub Soft commit na żądanie. Ustaw swój twardy commit na 15 sekund, openSearcher = false INDEX-LIGHT, QUERY-LIGHT OR HEAVY

Jest to stosunkowo statyczny indeks, który czasami dostaje mały impuls indeksowania. Powiedz, że co 5-10 minut (lub dłużej) robisz aktualizację

O ile nie jest wymagana funkcjonalność NRT, pominąłbym w tej sytuacji miękkie commity i robił twarde commity co 5-10 minut z opensearcher = true. Jest to sytuacja, w której, jeśli indeksujesz z pojedynczy zewnętrzny proces indeksowania, może mieć sens, aby Klient wydał twardy commit.

INDEX-HEAVY, QUERY-HEAVY

Jest to przypadek prawie w czasie rzeczywistym (NRT)i jest naprawdę najtrudniejszy z wielu. Ten będzie wymagał eksperymentów, ale od tego bym zaczął

Ustaw interwał commit soft na tak długo, jak możesz wytrzymać. Nie słuchaj swojego menedżera produktu, który mówi "potrzebujemy nie więcej niż 1 sekundy opóźnienia". Naprawdę. Odepchnij mocno i zobacz, czy użytkownik jest najlepiej obsługiwany lub nawet zauważy. Soft commity i NRT są całkiem niesamowite, ale nie są wolne. Ustaw interwał zatwierdzania na 15 sekund.

W moim przypadku (index heavy, query heavy) replikacja master-slave trwała zbyt długo, spowalniając wysyłanie zapytań do slave. Zwiększając softCommit do 15min i zwiększając hardCommit do 1min, poprawa wydajności była świetna. Teraz replikacja działa bez problemów, a serwery mogą obsłużyć znacznie więcej żądań na sekundę.

To jest mój przypadek użycia, zdałem sobie sprawę, że naprawdę nie potrzebuję elementów, aby były dostępne na master w czasie rzeczywistym, ponieważ master jest używany tylko do indeksowania elementów, a nowe elementy są dostępne w niewolnikach w każdym cyklu replikacji (5min), co jest całkowicie ok dla mojego przypadku. powinieneś dostosować te parametry do swojego przypadku.

Miękkie commity dotyczą widoczności. twardość to trwałość. optymalizacja to wydajność.

Soft commity są bardzo szybkie, zmiany są widoczne, ale te zmiany nie są utrzymywane (są tylko w pamięci). więc podczas crashu te zmiany mogą być ostatnie.
Twarde zmiany commity są trwałe na dysku.
Optymalizacja jest jak hard commit, ale łączy również segmenty indeksu solr w jeden segment w celu poprawy wydajności .Ale to bardzo kosztowne.

A operacja commit (hard commit) sprawia, że zmiany indeksu są widoczne dla nowych żądań wyszukiwania. Twardy commit wykorzystuje transakcję log, aby uzyskać identyfikator najnowszych zmian dokumentu, a także wywołuje fsync na plikach indeksu, aby upewnić się, że mają został przepłukany do stabilnej pamięci masowej, a utrata danych nie będzie spowodowana awarią zasilania.

Miękki commit jest znacznie szybszy, ponieważ sprawia, że tylko zmiany indeksu są widoczne i nie indeksuje plików fsync ani nie zapisuje nowy deskryptor indeksu. W przypadku awarii JVM lub utraty mocy, zmiany, które nastąpiły po ostatnim twardym commit zostanie utracony. Wyszukiwanie kolekcji, które mają wymagania NRT (które chcą, aby zmiany indeksu były szybkie widoczne dla wyszukiwań) będzie chciał miękkiego commit często, ale twardego commit rzadziej. SoftCommit może być " mniej drogie " pod względem czasu, ale nie za darmo, ponieważ może spowolnić przepustowość.

Optymalizacja jest jak twardy commit, z wyjątkiem tego, że zmusza wszystkie segmenty indeksu do połączenia w jeden segment pierwszy. W zależności od zastosowania, operacja ta powinna być wykonywana rzadko (np. wieczorem), jeśli w ogóle, ponieważ polega na odczytaniu i przepisaniu całego indeksu. Segmenty są zwykle łączone w czasie i tak (jak określone przez politykę scalania), a optymalizacja wymusza natychmiastowe połączenie.

auto commit properties we can manage from sorlconfig.xml files.
<autoCommit>
       <maxTime>1000</maxTime>
  </autoCommit>


    <!-- SoftAutoCommit

         Perform a 'soft' commit automatically under certain conditions.
         This commit avoids ensuring that data is synched to disk.

         maxDocs - Maximum number of documents to add since the last
                   soft commit before automaticly triggering a new soft commit.

         maxTime - Maximum amount of time in ms that is allowed to pass
                   since a document was added before automaticly
                   triggering a new soft commit.
      -->

     <autoSoftCommit>
       <maxTime>1000</maxTime>
     </autoSoftCommit>

Bibliografia:

Https://wiki.apache.org/solr/SolrConfigXml

Https://lucene.apache.org/solr/guide/6_6/index.html