Opcje klastrowania Lucene.NET?

Question

Jestem zainteresowany uruchomieniem Lucene.NET dla aplikacji działającej w klastrach Windows. Sam problem wyszukiwania jest dość mały, ale problem z statystyką/klastrem wciąż musi zostać rozwiązany.

Rozumiem, że SOLR obsługuje mój scenariusz (i więcej), ale wymaganie kontenera serwletów (i Java) stwarza dla mnie pewne problemy. W zależności od złożoności podejścia opartego na Lucene.NET nadal może to być opcja z fiolką.

Moje pytanie brzmi, jakie opcje mam dla obchodzenia problemu działa na wielu hostach:

• Utrzymują się na wspólnej pamięci, wspólne dla wszystkich węzłów? Czy kontroler Lucene.NET będzie obsługiwał współbieżność w sposób przejrzysty? Czy serwery używają pamięci RAM do buforowania, a jeśli tak, to czy Lucene.NET unieważnia to w oparciu o zaktualizowane pliki w przejrzysty sposób?

• Replikacja? Każdy serwer ma własną kopię wszystkiego, czego potrzebuje. Przy każdej aktualizacji wszystkie serwery otrzymują nową replikę (lub różnicę, jeśli jest to stosunkowo proste). Istniejące narzędzia do tego, lub do mnie do obsługi?

• Podział/podział obciążenia pracą? Każdy serwer obsługuje tylko własne dane, zarówno dla odczytów, jak i aktualizacji. Narzędzia do obsługi tego, łączenia częściowych wyników itp.?

• Inne opcje, które mogłem pominąć podczas mojego wstępnego dochodzenia?

Podczas eksperymentów z lokalną wersją, mój katalog Lucene był w porządku kilkuset megs. Na dłuższą metę widzę prawdopodobnie 1-5 GB. Jeśli częstotliwość aktualizacji jest trudna, mogę to dość elastycznie kontrolować. Przewiduje się, że jednoczesne obciążenia odczytu/wyszukiwania będą bardzo umiarkowane.

Answer 1

Możesz użyć lucene.net z wieloma serwerami, ale musisz zaimplementować serwer indeksujący.

Wszystkie wprowadzone zmiany powinny znajdować się w kolejce i co jakiś czas indeksować oczekujące dokumenty. Powinieneś również natychmiast zaindeksować, czy x elementów jest w kolejce (x zależy od tego, czy twoja dokumentacja scalania ustawiła dla mnie 25 000).

Uzasadnieniem powyższego jest uniknięcie dokonywania niewielkich zmian w indeksie, ponieważ pogorszy to nadgodziny wydajności spowodowane utworzeniem wielu małych plików. Możesz uruchomić 2 serwery indeksujące, ale tylko 1 będzie indeksować na raz ze względu na blokowanie indeksu, jedynym powodem, dla którego to zrobisz, jest to, że w przypadku niepowodzenia pierwsze rozwiązanie zależy od Twoich potrzeb.

Użyłem indeksu 15 GB z 30 milionami rekordów. Scenariusz, który miałem z tym był pod lazurem.

• 1 pracownik rola wskaźnika zmienia

• 2 - 20 ról internetowych obsługujących treść każdego gospodarstwa indeksu.

Zmiany były przesyłane co 15 minut, a indeks został scalony po 25 000 zmianach, a każdy połączony indeks zawierał 250 000 dokumentów. Każdy serwer sieciowy sprawdzał przechowywanie obiektów typu blob w poszukiwaniu zmian co 15 minut i blokował czytnik indeksu, który został unieważniony po pobraniu zmian. Maksymalna liczba dokumentów w pliku to po prostu zatrzymanie pobierania przez serwery internetowe wielu wcześniejszych zmian.

Na początku korzystałem z Lucene.AzureDirectory, ale nie był on niezawodny w wykrywaniu zmienionych obiektów typu blob w pamięci typu blob, dlatego wykonałem iterację obiektów typu blob i porównano je lokalnie i pobrałem w razie potrzeby.

Czy mogę teraz zaimplementować coś takiego? odpowiedź jest duża nie. Zamiast tego użyłbym elasticsearch lub solr, kiedy wymyślasz koło.