Wraz z Solr 7.0 i wprowadzeniem nowych typów replik, oprócz standardowego typu NRT, pojawiło się naturalne pytanie – czy możemy kontrolować wykonywanie zapytań? Czy możemy powiedzieć Solr, że chcielibyśmy, aby zapytania były wykonywane na replikach typu PULL lub te repliki były priorytetowe. Przyjrzyjmy się zatem możliwościom.
Parametr shards
Jedną z pierwszych możliwości kontroli zapytań jeżeli chodzi o SolrCloud jest parametr shards. Pozwala on na dokładne określenie, które z shardów mają uczestniczyć w wykonywaniu zapytania. Jako wartości parametru możemy przekazywać zarówno nazwy logiczne, jak również nazwy replik, np:
http://localhost:8983/solr/test/select?q=*:*&shards=shard1http://localhost:8983/solr/test/select?q=*:*&shards=shard1,shard2,shard3http://localhost:8983/solr/test/select?q=*:*&shards=localhost:6683/solr/testPierwsze z powyższych zapytań zostanie przekazane do shardów zgrupowanych pod logiczną nazwą shard1, drugie z zapytań zostanie wykonane na shardach z logicznymi nazwami shard1, shard2 oraz shard3. Ostatnie zapytanie zostanie natomiast wykonane na replikach znajdujących się na instancji Solr o adresie localhost:6683 na kolekcji test.
Istnieje takie możliwość wskazania alternatywy, tak aby możliwy był load balancing pomiędzy instancjami, np:
http://localhost:8983/solr/test/select?q=*:*&shards=localhost:6683/solr/test|localhost:7783/solr/testPowyższe zapytanie zostanie wykonane na instancji działającej na porcie 6683 lub na instancji działającej na porcie 7783.
Parametr shards.preference
Parametr shards daje nam pewne możliwości kontroli, gdzie wykonane zostanie nasze zapytanie. Jednak, aby wykorzystać repliki danego rodzaju musielibyśmy sami pobierać informacje na temat ich lokalizacji, a następnie zadawać odpowiednie zapytanie. Parametr shards.preference wyręcza nas udostępniając możliwość zdefiniowania typu repliki jaki ma mieć priorytet podczas wykonywania zapytania lub/oraz lokalizacji repliki.
Na przykład, aby Solr preferował repliki typu PULL podczas wykonywania zapytania wystarczy, abyśmy dodali do naszego zapytania parametr shards.preference z wartością replica.type:PULL:
http://localhost:8983/solr/test/select?q=*:*&shards.preference=replica.type:PULLOczywiście możemy powiedzieć, aby Solr wykorzystywał najpierw repliki typu PULL, a następnie repliki typu TLOG jeżeli te pierwsze nie są dostępne. Nasze zapytanie wyglądałoby wtedy następująco:
http://localhost:8983/solr/test/select?q=*:*&shards.preference=replica.type:PULL,replica.type:TLOGMożemy także powiedzieć, aby Solr najpierw preferował repliki typu PULL, a jak takich nie ma, to te dostępne lokalnie:
http://localhost:8983/solr/test/select?q=*:*&shards.preference=replica.type:PULL,replica.location:localWprowadziliśmy tutaj nową wartość parametru shards.preference, czyli replica.location:local. Określa on preferowaną lokalizację replik i w tym wypadku mówi, aby preferował te znajdujące się lokalnie.
Oczywiście nie jest to jedyna możliwość, jeżeli chodzi o lokalizację replik. Podobnie jak w przypadku parametru shards mamy możliwość wskazania danej instancji Solr, która ma być tą preferowaną. Na przykład, jeżeli chcemy, aby preferowaną maszyną był serwer o adresie 192.168.1.1 wystarczy zadać następujące zapytanie:
http://localhost:8983/solr/test/select?q=*:*&shards.preference=replica.type:PULL,replica.location:http://192.168.1.1Podsumowanie
Omówione parametry, a szczególnie shards.preference ze swoją wartością replica.type może być szczególnie przydatny w tych przypadkach kiedy w SolrCloud korzystamy z różnego typu replik. Mówiąc Solr, iż do wyszukiwania preferujemy repliki typu PULL lub TLOG możemy zmniejszyć lub wyeliminować obciążenie zapytaniami replik typu NRT, a tym samym zbliżyć się do tego co oferuje Solr w architekturze master – slave – podział ról replik. Wszystko to dalej korzystając z SolrCloud i wszystkich udogodnień, które za tym idą.