Aby przetestować to samodzielnie, zindeksowałem wszystkie angielskie artykuły w Wikipedii (bez żadnych informacji historycznych) w pojedynczym odłamku elastycznym. Folder danych elasticsearch wzrósł do ~ 42 GB na końcu testu. Wyciągnięte wnioski są następujące:
- wielkość odłamki nie ma wpływu na szybkość indeksowania. Pamiętaj, że nie próbowałem indeksować więcej niż jednym wątkiem naraz, ale szybkość indeksowania pojedynczych nici była mniej więcej stała przez cały czas trwania testu, z drugiej strony drastycznie wpływało na wielkość odłamków. Zwłaszcza gdy próbujesz wysłać zapytanie do więcej niż jednego użytkownika naraz. Dokładne liczby będą zależały głównie od mocy twojej maszyny, struktury danych i liczby wątków. Aby dać ci pewien pomysł, dzięki elastycznemu wyszukiwaniu uruchomionemu na mojej maszynie programistycznej, wysłanie zapytania do odłamka Wikipedii z 25 równoczesnymi użytkownikami skutkowało średnim czasem odpowiedzi wynoszącym 3,5 sekundy (z maksimum w ciągu pół minuty).
Mój wniosek jest taki, że odłamek zbyt duży nie sprawi, że analiza elastyczna zawodzi tylko z powodu indeksowania. Zapytanie o duży fragment może być zbyt wolne dla twoich potrzeb, lub, w pewnych sytuacjach, nawet złamać elastyczne wyszukiwanie z OutOfMemoryException (na przykład duże fasetowane zapytanie).
Ta odpowiedź jest oparta na moim własnym śledztwie. Pełna historia można przeczytać na moim blogu:
http://blog.trifork.com/2013/09/26/maximum-shard-size-in-elasticsearch/
http://blog.trifork.com/2013/11/05/maximum-shard-size-in-elasticsearch-revisited/
Chociaż linki mogą odpowiedzieć na pytanie, lepiej jest to tutaj zasadnicze części odpowiedzi i podać link do odniesienia. Odpowiedzi dotyczące linków mogą stać się nieprawidłowe, jeśli strona z linkami się zmieni. – SysDragon
@SysDragon Edytowałem moją odpowiedź. –
Całkiem fajnie, +1 – SysDragon