Konfiguracja

Po pierwsze – konfiguracja. W tym wypadku sprawa jest całkiem prosta. W pliku solrconfig.xml musimy skonfigurować odpowiednią implementację Directory. Wygląda to mniej, więcej tak:

<directoryFactory name="DirectoryFactory" class="solr.ByteBuffersDirectoryFactory" />

Należy pamiętać o jednej rzeczy. W przypadku ByteBuffersDirectory jedyną możliwą implementacją lockType jest simple. Inne nie są wspierane.

Możliwe wykorzystanie

Nowa implementacja Directory wprowadzona wraz z Solr 8.0 w przyszłości może zastąpić RAMDirectory obecne w Lucene i Solr już od długiego czasu, aczkolwiek nie polecane ze względu na swoje bolączki i potencjalnie występujące problemy.

Teoretyczne wykorzystanie tego typu implementacji Directory sprowadza się do małych, krótko żyjących indeksów Lucene, które trzymane tylko i wyłącznie w pamięci powodują brak zapisu/odczytu z dysku, a tym samym brak wykorzystania I/O i potencjalnie szybsze operacje indeksowania i wyszukiwania.

Przykładem takich rozwiązań mogą być dane wymagające ciągłych aktualizacji, na przykład stany magazynowe, dane które potrzebne są tylko i wyłączenie raz, itp.

Należy jednak pamiętać, iż podobnie do RAMDirectory, tak samo ByteBuffersDirectory nie zapisuje danych na dysku. Oznacza to konieczność ponownej indeksacji danych na przykład po ponownych uruchomieniu Solr.

Zalety

Podstawowa zaleta to ta, iż dane zaindeksowane do kolekcji/rdzenia, który oparty jest o ByteBuffersDirectory, nie będą wykorzystywać zasobów dyskowych. Oznacza to bardzo szybki zapis i odczyt danych, co może skutkować wzrostem wydajności indeksowania i zmniejszeniem czasu odpowiedzi na zapytania. Należy jednak pamiętać, iż podobne zachowanie możliwe jest w przypadku zastosowania implementacji Directory opartych o dostęp do danych za pomocą mmap, takich jak MMapDirectory, która to współdzieli cache I/O systemu operacyjnego. Dodatkowo ByteBuffersDirectory w pełni wspiera wielowątkowość, co jest znaczącą poprawą w stosunku do RAMDirectory.

Wady

Jeżeli mówimy o wadach, to warto wspomnieć o trzech rzeczach. Po pierwsze brak trwałości danych, a co za tym idzie konieczność ich odtwarzania po każdym restarcie. Oczywiście, jest to założenie tej implementacji, ale warto o tym pamiętać. Druga rzecz to śmieci w pamięci. Nawet krótko żyjące kolekcje będą tworzyć dane na stosie, a tym samym garbage collector będzie musiał je posprzątać. Ostatnia – jesteśmy ograniczeni fizyczną pojemnością pamięci, a dokładniej wielkością pamięci przydzielonej dla wirtualnej maszyny Java i dobrymi praktykami odnośnie wykorzystania pamięci, należy o tym pamiętać.