Autoscaling API w Solr

Jeżeli nie wiesz co to jest Autoscaling API Solr pozwolę sobię na szybkie wprowadzenie. Jest to API pozwalające na ustawianie reguł dla klastra lub kolekcji, które mówią Solr jak mają być alokowane repliki w Solr. Chcemy wziąć pod uwagę wykorzystanie procesora danej instancji Solr – możemy to zrobić. Chcemy wziąć pod uwagę wyjorzystanie dysku na danej instancji – oczywiście możemy to zrobić. Najfajniejsze jest to, iż reguły mogą być definiowane zarówno dla całego klastra, jak również dla pojedynczych kolekcji w klastrze. Daje nam to całkiem dużą swobodę jeżeli chodzi o konfigurację.

Aczkolwiek, zdefiniowane reguły używane są tylko podczas przypisywania replik do instancji Solr. Oznacza to, że w momencie kiedy kolekcja została już stworzona Solr nie będzie korzystał z tych informacji podczas dodawania replik. Zmieniło się to wraz z wprowadzeniem Solr 7.2, gdzie dostaliśmy do dyspozycji komendę UTILIZENODE.

Środowisko testowe

Aby umożliwić proste odtworzenie testu zdecydowałem się na urucomienie banalnego środowiska testowego opartego o Solr 7.2 składającego się z dwóch instancji Solr. Pierwsza z nich uruchomiona została następującym poleceniem:

$ bin/solr start -c

Drugą instancję Solr uruchamiamy następującym poleceniem:

$ bin/solr start -z localhost:9983 -p 6683

Po uruchomieniu obu instancji tworzymy pojedynczą kolekcję nazwaną test zbudowaną z jednego lidera i trzech replik, wszystkie stworzone na pojedynczej instancji Solr. Nasz widok kolekcji wygląda następująco:

A sam stan opisany odpowiednim plikiem JSON wygląda następująco:

{"test":{
    "pullReplicas":"0",
    "replicationFactor":"1",
    "router":{"name":"compositeId"},
    "maxShardsPerNode":"1",
    "autoAddReplicas":"false",
    "nrtReplicas":"1",
    "tlogReplicas":"0",
    "shards":{"shard1":{
        "range":"80000000-7fffffff",
        "state":"active",
        "replicas":{
          "core_node2":{
            "core":"test_shard1_replica_n1",
            "base_url":"http://192.168.1.15:8983/solr",
            "node_name":"192.168.1.15:8983_solr",
            "state":"active",
            "type":"NRT",
            "leader":"true"},
          "core_node4":{
            "core":"test_shard1_replica_n3",
            "base_url":"http://192.168.1.15:8983/solr",
            "node_name":"192.168.1.15:8983_solr",
            "state":"active",
            "type":"NRT"},
          "core_node6":{
            "core":"test_shard1_replica_n5",
            "base_url":"http://192.168.1.15:8983/solr",
            "node_name":"192.168.1.15:8983_solr",
            "state":"active",
            "type":"NRT"},
          "core_node8":{
            "core":"test_shard1_replica_n7",
            "base_url":"http://192.168.1.15:8983/solr",
            "node_name":"192.168.1.15:8983_solr",
            "state":"active",
            "type":"NRT"}}}}}}

Jak widać mamy potwierdzenie tego, iż wszystkie shardy zostały przypisane do tego samej instancji Solr – tej z base_url równą http://192.168.1.15:8983/solr.

Mamy zatem następującą sytuację:

• Mamy klaster Solr, który stowrzony jest z dwóch instancji Solr
• W ramach klastra stworzona jest pojedyncza kolekcja
• Nasza kolekcja zbudowana jest z czterech shardów – jednego lidera oraz trzech replik
• Wszystkie shardy przypisane są do pojedynczej instancji Solr

Podsumowując – nie korzystamy z wszystkich instancji Solr. Spróbujmy to zmienić korzystając z komendy UTILIZENODE wprowadzonej w Collections API w Solr 7.2.

Korzystanie z UTILIZENODE w API kolekcji

Aby zilustrować działanie Autoscaling API oraz UTILIZENODE w Collections API ustawimy pewne preferencje alokacji replik dla całego klastra. Przy pomocy następującego polecenia powiemy Solr, aby starał się minimalizować liczbę coreów na każdej instancji Solr dostępnej w klastrze:

$ curl -XPOST 'localhost:8983/api/cluster/autoscaling' -H 'Content-Type:application/json' -d '{
 "set-cluster-preferences" : [
  {"minimize": "cores"}
 ]
}'

Powyższe polecenie ustawia właściwości dla klastra dotyczące preferencji umieszczania shardów. Mówi, że Solr ma minimalizować liczbę coreów na każdej instancji, a zatem dążyć do jak największego rozproszenia kolekcji. Zatem teraz, korzystając z polecenia UTILIZENODE z Collections API możemy zmusić Solr, aby druga, nieużywana instancja Solr zaczęła być wykorzystywana. Robimy to następującym poleceniem:

$ curl -XGET 'localhost:8983/solr/admin/collections?action=UTILIZENODE&node=192.168.1.15:6683_solr'

Parametr node jest konieczny ponieważ musimy powiedziec Solr, która instancja Solr powinna być brana pod uwagę podczas alokacji. Przetwarzanie polecenia, w zależności od wielkości replik może zająć dość długo, a w związku z tym, w systemie produkcyjnym sugerowane jest uruchamianie tej komendy w asynchronicznie. W naszym przypadku wykonanie będzie dość szybkie i skutkuje takimi zmianami w klastrze:

Plik JSON opisujący stan kolekcji, po zmianach, wygląda następująco:

{"test":{
    "pullReplicas":"0",
    "replicationFactor":"1",
    "shards":{"shard1":{
        "range":"80000000-7fffffff",
        "state":"active",
        "replicas":{
          "core_node6":{
            "core":"test_shard1_replica_n5",
            "base_url":"http://192.168.1.15:8983/solr",
            "node_name":"192.168.1.15:8983_solr",
            "state":"active",
            "type":"NRT",
            "leader":"true"},
          "core_node8":{
            "core":"test_shard1_replica_n7",
            "base_url":"http://192.168.1.15:8983/solr",
            "node_name":"192.168.1.15:8983_solr",
            "state":"active",
            "type":"NRT"},
          "core_node10":{
            "core":"test_shard1_replica_n9",
            "base_url":"http://192.168.1.15:6683/solr",
            "node_name":"192.168.1.15:6683_solr",
            "state":"active",
            "type":"NRT"},
          "core_node12":{
            "core":"test_shard1_replica_n11",
            "base_url":"http://192.168.1.15:6683/solr",
            "node_name":"192.168.1.15:6683_solr",
            "state":"active",
            "type":"NRT"}}}},
    "router":{"name":"compositeId"},
    "maxShardsPerNode":"1",
    "autoAddReplicas":"false",
    "nrtReplicas":"1",
    "tlogReplicas":"0"}}

Jak widać dwie repliki zostały przesunięte z instancji 192.168.1.15:8983_solr do instancji 192.168.1.15:6683_solr, czyli Solr zrobił dokładnie to co chcieliśmy.

Podsumowanie

Komenda UTILIZENODE z API kolekcji jest pewną formą automatyzacji zarządzania klastrem. Oczywiście podobny efekt uzyskamy korzystając z poleceń ADDREPLICA oraz DELETEREPLICA ale będzie to zarządzanie manualne i nie będzie brało pod uwagę ustawień klastra i kolekcji. Komenda UTILIZENODE daje nam pewność, iż wszystkie ustawienia, zarówno te dotyczące klastra, jak i te dotyczące kolekcji będą zachowane.

Zadawanie zapytań

Jestem pewien, że wiesz jak zadaje się zapytania do Solr, tak jak jesteśmy przyzwyczajeni. Zatem, aby dostać dokumenty, które mają term solr w polu _text_ moglibyśmy użyć następującej komendy:

curl -XGET 'localhost:8983/solr/gettingstarted/select?q=_text_:solr&indent=true'

Gwoli wyjaśnienia – korzystam z jednego z przykładów dostarczonych wraz z Solr (schemaless), a zaindeksowane dane to dokumenty znajdujące się w katalogu docs dostarczanym razem z Solr.

Oczywiście, powyższe zapytanie można zadać także używając JSON API. Aby Solr zwrócił nam dokładnie te same wyniki wyszukiwania, które dostaliśmy w przypadku zapytania powyżej, skorzystalibyśmy z następującej komendy:

curl -XGET 'localhost:8983/solr/gettingstarted/query' -d '{
 "query":"_text_:solr"
}'

Przyjemne i proste – jak widać, wszystko co musimy zrobić, to przekazać obiekt JSON jako payload żądania, który będzie posiadał pole query, za pomocą którego przekazujemy nasze zapytanie. Taki obiekt wysłaliśmy do handlera /query ze względu, że skonfigurowany jest, aby domyślnie odpowiadać w formacie JSON. Oczywiście moglibyśmy skorzystać z handlera /select, ale wtedy odpowiedź zwrócona zostałaby w formacie XML.

Jeżeli chodzi o zadawanie zapytań, to zamiast przekazywania obiektu JSON, możemy przekazać standardowe parametry. Dokładnie tak, nie musimy przekazywać ich jako parametrów URI, ale w ciele żądania:

curl -XGET 'localhost:8983/solr/gettingstarted/query' -d 'q=_text_:solr'

Tym razem, nie mamy obiektu JSON. Standardowy parametr q został przekazany w ciele żądania i przesłany do handlera /query. Jeżeli chcemy przekazać więcej parametrów oddzielamy je znakiem &.

Stronnicowanie

Oczywiście, korzystając z JSON API możemy także kontrolować stronicowanie. W tym celu korzystamy z dwóch parametrów – limit oraz offset. Pierwszy z nich, limit definiuje maksymalną liczbę dokumentów jaką Solr może zwrócić. Parametr offset odpowiedzialny jest za określenie od którego dokumentu wyniki wyszukiwania mają być pokazywane. Na przykład, aby dostać maksymalnie 20 dokumentów zaczynając od jedenastego wykorzystalibyśmy następujące zapytanie:

curl -XGET 'localhost:8983/solr/gettingstarted/query' -d '{
 "query":"_text_:solr",
 "limit":20,
 "offset":10
}'

Sortowanie

Kolejna rzecz to możliwość sortowania wyników wyszukiwania – oczywiście, także dostępna. Aby posortować nasze wyniki wyszukiwania na podstawie pola o nazwie id malejąco użylibyśmy następującego zapytania:

curl -XGET 'localhost:8983/solr/gettingstarted/query' -d '{
 "query":"_text_:solr",
 "sort":"id desc"
}'

Jak widać definicja sortowania jest taka sama, jak w przypadku sortowania w kiedy korzystamy z parametrów URI i parametru sort.

Filtrowanie

Na koniec zostawiliśmy sobie filtrowanie. Do filtrowania wykorzystujemy właściwość filter obiekty JSON przesyłanego w ciele żądania. Na przykład zapytanie zawężąjące wyniki wyszukiwania tylko do tych dokumentów, które mają wartość text/html w polu content_type wyglądałoby następująco:

curl -XGET 'localhost:8983/solr/gettingstarted/query' -d '{
 "query":"_text_:solr",
 "filter":"content_type:text/html"
}'

Co dalej?

Jak widać, JSON API w Solr jest bardzo przyjemne i proste w wykorzystaniu pozwalając nam na definiowanie zapytań z pewną strukturą. W następnym wpisie postaramy się przybliżyć kolejną możliwość JSON API, czyli faceting. Postaramy się pokazać różnice pomiędzy starą implementacją obecną w Solr już od bardzo dawna, a nową, wprowadzoną stosunkowo niedawno.

Możliwości

Przyjrzymy się zatem nowemu API.

Zwracanie informacji w formacie XML

Bardzo dużo użytkowników Solr przyzwyczajonych jest do tego, iż dane z Solr zwracane są domyślnie w formacie XML, co nie jest prawdą w przypadku opisywanego API, którego domyślny format zwracanych danych to JSON. Jeżeli chcemy, aby powyżej opisane informacje zwracane były w formacie XML należy do każdego z wymienionych zapytań dodać parametr wt=xml, na przykład:

$curl 'http://localhost:8983/solr/collection1/schema/fieldtypes?wt=xml'

Pobieranie zdefiniowanych pól

Zacznijmy od pobierania informacji na temat pól zdefiniowanych w indeksie. W tym celu udostępnione zostały dwie możliwości:

1. Pobieranie informacji na temat wszystkich pól
2. Pobieranie informacji na temat konkretnego pola

W pierwszym wypadku należy zadać następujące zapytanie:

$curl 'http://localhost:8983/solr/collection1/schema/fields'

W drugim przypadku wystarczy do powyższego zapytania dodać znak / oraz nazwę pola. Na przykład, aby pobrać dane na temat pola author należałoby wysłać następujące zapytanie:

$curl 'http://localhost:8983/solr/collection1/schema/fields/author'

Odpowiedź Solr na pierwsze zapytanie wygląda następująco:

{
  "responseHeader":{
    "status":0,
    "QTime":1},
  "fields":[{
      "name":"_version_",
      "type":"long",
      "indexed":true,
      "stored":true},
    {
      "name":"author",
      "type":"text_general",
      "indexed":true,
      "stored":true},
    {
      "name":"cat",
      "type":"string",
      "multiValued":true,
      "indexed":true,
      "stored":true},
    {
      "name":"category",
      "type":"text_general",
      "indexed":true,
      "stored":true},
    {
      "name":"id",
      "type":"string",
      "multiValued":false,
      "indexed":true,
      "required":true,
      "stored":true,
      "uniqueKey":true},
    {
      "name":"url",
      "type":"text_general",
      "indexed":true,
      "stored":true},
    {
      "name":"weight",
      "type":"float",
      "indexed":true,
      "stored":true}]}

Natomiast odpowiedź na zapytanie dotyczące pojedynczego pola wygląda następująco:

{
  "responseHeader":{
    "status":0,
    "QTime":0},
  "field":{
    "name":"author",
    "type":"text_general",
    "indexed":true,
    "stored":true}}

Pobieranie zdefiniowanych pól dynamicznych

Dokładnie tak samo, jak w powyższym przypadku wygląda sytuacja kiedy chcemy pobrać informacje na temat pól dynamicznych. Także i w tym przypadku mamy dwie możliwości:

1. Pobranie informacji na temat wszystkich pól dynamicznych
2. Pobranie informacji na temat konkretnego wzorca pola dynamicznego

W pierwszym wypadku należy zadać następujące zapytanie:

$curl 'http://localhost:8983/solr/collection1/schema/dynamicfields'

W drugim przypadku, podobnie jak wcześniej, dodajemy znak /, a następnie wzorzec:

$curl 'http://localhost:8983/solr/collection1/schema/dynamicfields/random_*'

Odpowiedź Solr na pierwsze zapytanie wygląda następująco:

{
  "responseHeader":{
    "status":0,
    "QTime":2},
  "dynamicfields":[{
      "name":"*_coordinate",
      "type":"tdouble",
      "indexed":true,
      "stored":false},
    {
      "name":"ignored_*",
      "type":"ignored",
      "multiValued":true},
    {
      "name":"random_*",
      "type":"random"},
    {
      "name":"*_p",
      "type":"location",
      "indexed":true,
      "stored":true},
    {
      "name":"*_c",
      "type":"currency",
      "indexed":true,
      "stored":true}]}

Natomiast odpowiedź na zapytanie dotyczące pojedynczego pola wygląda następująco:

{
  "responseHeader":{
    "status":0,
    "QTime":1},
  "dynamicfield":{
    "name":"random_*",
    "type":"random"}}

Pobieranie typów pól

Jak można się domyślać, podobnie jak w wyżej wymienionych przypadkach, tak samo w przypadku pobierania informacji na temat typów pól możemy dostać od Solr informacje na temat:

1. Wszystkich typów pól zdefiniowanych w pliku schema.xml
2. Pojedynczego zdefiniowanego typu

W pierwszym wypadku należy zadać następujące zapytanie:

$curl 'http://localhost:8983/solr/collection1/schema/fieldtypes'

W drugim przypadku, na dokładnie takiej samej zasadzie dodajemy znak /, a następnie nazwę typu:

$curl 'http://localhost:8983/solr/collection1/schema/fieldtypes/text_gl'

Odpowiedź Solr na pierwsze zapytanie wygląda następująco:

{
  "responseHeader":{
    "status":0,
    "QTime":3},
  "fieldTypes":[{
      "name":"alphaOnlySort",
      "class":"solr.TextField",
      "sortMissingLast":true,
      "omitNorms":true,
      "analyzer":{
        "class":"solr.TokenizerChain",
        "tokenizer":{
          "class":"solr.KeywordTokenizerFactory"},
        "filters":[{
            "class":"solr.LowerCaseFilterFactory"},
          {
            "class":"solr.TrimFilterFactory"},
          {
            "class":"solr.PatternReplaceFilterFactory",
            "replace":"all",
            "replacement":"",
            "pattern":"([^a-z])"}]},
      "fields":[],
      "dynamicFields":[]},
    {
      "name":"boolean",
      "class":"solr.BoolField",
      "sortMissingLast":true,
      "fields":["inStock"],
      "dynamicFields":["*_bs",
        "*_b"]},
    {
      "name":"text_gl",
      "class":"solr.TextField",
      "positionIncrementGap":"100",
      "analyzer":{
        "class":"solr.TokenizerChain",
        "tokenizer":{
          "class":"solr.StandardTokenizerFactory"},
        "filters":[{
            "class":"solr.LowerCaseFilterFactory"},
          {
            "class":"solr.StopFilterFactory",
            "words":"lang/stopwords_gl.txt",
            "ignoreCase":"true",
            "enablePositionIncrements":"true"},
          {
            "class":"solr.GalicianStemFilterFactory"}]},
      "fields":[],
      "dynamicFields":[]},
    {
      "name":"tlong",
      "class":"solr.TrieLongField",
      "precisionStep":"8",
      "positionIncrementGap":"0",
      "fields":[],
      "dynamicFields":["*_tl"]}]}

Natomiast odpowiedź na zapytanie dotyczące pojedynczego pola wygląda następująco:

{
  "responseHeader":{
    "status":0,
    "QTime":2},
  "fieldType":{
    "name":"text_gl",
    "class":"solr.TextField",
    "positionIncrementGap":"100",
    "analyzer":{
      "class":"solr.TokenizerChain",
      "tokenizer":{
        "class":"solr.StandardTokenizerFactory"},
      "filters":[{
          "class":"solr.LowerCaseFilterFactory"},
        {
          "class":"solr.StopFilterFactory",
          "words":"lang/stopwords_gl.txt",
          "ignoreCase":"true",
          "enablePositionIncrements":"true"},
        {
          "class":"solr.GalicianStemFilterFactory"}]},
    "fields":[],
    "dynamicFields":[]}}

Jak widać ilość zwracanych informacji jest dość duża

Pobieranie informacji na temat sekcji copyField

Dodatkowo za pomocą opisywanego API jesteśmy w stanie pobrać informacje na temat sekcji copyField poprzez wysłanie następującego zapytania:

$curl 'http://localhost:8983/solr/collection1/schema/copyfields'

Odpowiedź na powyższe zapytanie jest następująca:

{
  "responseHeader":{
    "status":0,
    "QTime":1},
  "copyfields":[{
      "source":"author",
      "dest":"text"},
    {
      "source":"cat",
      "dest":"text"},
    {
      "source":"content",
      "dest":"text"},
    {
      "source":"content_type",
      "dest":"text"},
    {
      "source":"description",
      "dest":"text"},
    {
      "source":"features",
      "dest":"text"},
    {
      "source":"author",
      "dest":"author_s",
      "destDynamicBase":"*_s"}]}

Przyszłość

W Solr 4.3 opisywane API zostało usprawnione oraz jest przygotowywane do umożliwienia zmian w strukturze indeksu za pomocą protokołu HTTP. Możemy zatem spodziewać się, iż w jednej z kolejnych wersji serwera wyszukiwania Solr otrzymamy możliwość łatwej zmiany struktury indeksu, przynajmniej takich, które nie będą powodować konfliktów z już zaindeksowanymi danymi.