Aplikacja „sprzedaż samochodów” – projektowanie schema.xml dla naszych potrzeb (cz. 1)

Rafał Andrzejewski Solr , , 0 Comment

Podstawowym plikiem konfiguracyjnym solr, który jest niejako łącznikiem pomiędzy tym czego potrzebujemy, a tym co rozumie solr, jest plik schema.xml. Dobre zaprojektowanie schema.xml jest głównym czynnikiem warunkującym poprawne funkcjonowanie wyszukiwarki, która będzie w stanie zrealizować wszystkie wymagania, jakie przed nią stawiamy. Zacznijmy zatem kolejny cykl artykułów, poświęconych projektowaniu pliku schema.xml jak i również wszystkich składników wchodzących w skład zdefiniowanych przez nas typów pól.

Analiza wymagań

Wyobraźmy sobie, że chcemy wykorzystać silnik solr w celu dodania wyszukiwarki ogłoszeń samochodowych do naszego serwisu. Serwis nasz jest w tym momencie dosyć prymitywny i przetrzymuje podstawowe informacje opisujące właściwości każdego wystawionego na sprzedaż samochodu:

  • marka
  • model
  • rok produkcji
  • cena
  • pojemność
  • przebieg
  • kolor
  • czy uszkodzony

Chcielibyśmy w tym momencie zaprojektować najprostszy plik konfiguracyjny, który pomoże odpowiednio zaindeksować dane z powyższych pól. Zanim jednak przystąpimy do rzeźbienia pliku schema.xml, odpowiedzmy sobie na siedem podstawowych pytań, dotyczących każdego z tych pól:

1. Jaki typ ?

Ustalamy typ każdego pola:

  • marka – pole tekstowe
  • model – pole tekstowe
  • rok produkcji – pole liczbowe
  • cena – pole liczbowe, zmiennoprzecinkowe
  • pojemność – pole liczbowe
  • przebieg – pole liczbowe
  • kolor – pole tekstowe
  • czy uszkodzony – pole logiczne

Co nam to mówi ?

Będziemy potrzebowali definicji typów: string, boolean, int, float.

2. Czy po polu ma się odbywać wyszukiwanie ?

Ustalamy, z których pól będą wykorzystywane informacje, w celu znalezienia odpowiednich ogłoszeń samochodowych. W naszym serwisie będą to 3 pola: marka, model oraz rok produkcji.

Co nam to mówi ?

Pewnie będziemy potrzebowali kolejnego typu pola, który będzie poddawany działaniu różnych filtrów, zwiększających nasze szanse znalezienia interesującego nas dokumentu. Stworzymy sobie dodatkowe pole tego typu, po którym będziemy wyszukiwać i wrzucimy tam dane z wszystkich 3 powyższych pól.

3. Czy sortowalne lub grupowalne ?

Serwis nasz przewiduje sortowanie wyników wyszukiwania po polach: model, rok produkcji, cena oraz przebieg. Chcielibyśmy również móc grupować wyniki wyszukiwania (faceting) po polach marka, model, rok produkcji oraz kolor.

Co nam to mówi ?

Pola tekstowe, po których sortujemy lub grupujemy nie powinny być poddawane działaniu filtrów, które mogą nam rozdzielić na tokeny wartości w tych polach. Zależy nam jednak na tym, aby wszystkie wartości były zapisane małymi literami, tak aby wielkość liter nie wpływała na sortowanie czy też grupowanie. Będzie trzeba stworzyć nowy typ pola, który nam to umożliwi.

4. Czy wykorzystywane przy filtrowaniu ?

Na stronie wyszukiwania ogłoszeń chcemy mieć możliwość zawężenia wyników wyszukiwania, poprzez ustawianie zakresów na polach: rok produkcji, cena, pojemność oraz przebieg.

Co nam to mówi ?

Dobierzmy zatem takie typy dla tych pól, aby filtrowanie po zakresach było jak najbardziej wydajne.

5. Czy zostały mi pola, które nie zostały wymienione w punktach 2, 3 lub 4 ?

Okazuje się, że na polu „czy wymagane” nie będziemy przeprowadzać żadnych „operacji”.

Co nam to mówi ?

Ustawiamy atrybut „indexed” dla takiego pola na wartość false.

6.Czy wymagane ?

W naszym serwisie zakładamy, że polami wymaganymi dla każdego ogłoszenia będą pola marka, model oraz rok produkcji. Nie chcemy mieć dokumentów, które nie mają zdefiniowanych co najmniej tych trzech pól.

Co nam to mówi ?

Przy definiowaniu tych pól musimy pamiętać o ustawieniu wartości atrybutu „required” na true.

7. Czy wartości pól mają być pobierane z indeksu w oryginalnym stanie?

Informację ze wszystkich pól chcielibyśmy wyciągnąć bezpośrednio z wyników wyszukiwania i zaprezentować klientowi serwisu.

Co nam to mówi ?

Przy definiowaniu tych pól musimy pamiętać o ustawieniu wartości atrybutu „stored” na true.

Dodajmy definicje typów pól

Odpowiedzieliśmy już sobie na nasze niezbędne pytanie, wyciągnęliśmy wnioski, więc czas wprowadzić je w życie. Dodajmy do schemy typy pól:

Dodajemy zwykły typ string, który nie jest poddawany żadnej analizie, przyda się np. jako typ dla pola reprezentującego unikalny identyfikator dokumentu.

<fieldType name="string" sortMissingLast="true" omitNorms="true"/>

Dodajemy typ boolean.

<fieldType name="boolean" sortMissingLast="true" omitNorms="true"/>

Dodajemy typy dla pól liczbowych. Pamiętamy, że zależy nam na typach, które zagwarantują nam szybsze wykonywanie zapytań po zakresach. Skorzystajmy zatem z typów tint oraz tfloat:

<fieldType name="tint" precisionStep="8" omitNorms="true" positionIncrementGap="0"/>
<fieldType name="tfloat" precisionStep="8" omitNorms="true" positionIncrementGap="0"/>

Stwórzmy teraz typ tekstowy, który będzie wykorzystywany przez pole zbiorcze po którym będziemy wyszukiwać. Załóżmy prosty typ, który rozdzieli nam wszystkie tokeny po białych znakach, po czym zamieni wszystkie litery na małe.

<fieldType name="text" positionIncrementGap="100">
  <analyzer>
    <tokenizer class="solr.WhitespaceTokenizerFactory"/>
    <filter class="solr.LowerCaseFilterFactory"/>
  </analyzer>
</fieldType>

Potrzebujemy jeszcze typu dla pól, które będą sortowalne/grupowalne:

<fieldType name="lowercase" positionIncrementGap="100">
  <analyzer>
    <tokenizer class="solr.KeywordTokenizerFactory"/>
    <filter class="solr.LowerCaseFilterFactory" />
    <filter class="solr.TrimFilterFactory" />
  </analyzer>
</fieldType>

KeywordTokenizer tak naprawdę nie tokenizuje wartości którą dostaje na wejściu, czyli niezmieniona wartość zostanie poddana działaniu filtra LowerCaseFilterFactory po czym filtr TrimFilterFactory zadba o to, aby zostały usunięte wszelkie białe znaki, znajdujące się na początku lub na końcu wartości.

Dodajmy definicje pól

Identyfikator dokumentu: 

<field name="id" type="string" indexed="true" stored="true" required="true" />

Marka oraz model: 

<field name="make" type="text" indexed="false" stored="true" required="true" />
<field name="model" type="text" indexed="false" stored="true" required="true" />

Nasuwa się pytanie, dlaczego atrybuty indexed dla pól marka oraz model są ustawione na false? Przecież są to pola, które wykorzystywane są przy wyszukiwaniu, sortowaniu i grupowaniu. Zgadza się. Jednakże w celach wyszukiwania przekopiujemy wartości z tych pól do pola zbiorczego, a w celach sortowania/grupowania przekopiujemy wartości z tych pól do pól o typie „lowercase”.
Pola, do których będziemy kopiować wartości marek oraz modeli samochodów, a które to będą wykorzystywane do sortowania/grupowania po tych polach: 

<field name="make_sort" type="lowercase" indexed="true" stored="false" />
<field name="model_sort" type="lowercase" indexed="true" stored="false" />

Pole zbiorcze, do którego będą kopiowane wartości z pól, po których chcemy wyszukiwać. Jako że do tego pola kopiujemy wartości z więcej niż jednego pola, musimy ustawić wartość atrybutu „multiValued” na true: 

<field name="content" type="text" indexed="true" stored="false" multiValued="true"/>

Rok produkcji: 

<field name="year" type="tint" indexed="true" stored="true" required="true" />

Cena: 

<field name="price" type="tfloat" indexed="true" stored="true" />

Pojemność: 

<field name="engine_size" type="tint" indexed="true" stored="true" />

Przebieg: 

<field name="mileage" type="tint" indexed="true" stored="true" />

Kolor: 

<field name="colour" type="lowercase" indexed="true" stored="true" />

Pamiętamy o wartości false dla atrybutu „indexed” dla pola „Czy uszkodzony”: 

<field name="damaged" type="boolean" indexed="false" stored="true" />

Zostało nam przekopiować wartości z pól, po których wyszukujemy do jednego pola zbiorczego: 

<copyField source="make" dest="content"/>
<copyField source="model" dest="content"/>
<copyField source="year" dest="content"/>

… i ponownie pola marki i modelu do pól, po których będziemy sortować: 

<copyField source="make" dest="make_sort"/>
<copyField source="model" dest="model_sort"/>

Czy coś jeszcze do schemy?

Uzupełnijmy scheme jeszcze o 3 elementy:
Klucz unikalny dokumentu 

<uniqueKey>id</uniqueKey>

Domyślne pole, po którym wyszukujemy 

<defaultSearchField>content</defaultSearchField>

Domyślny operator, wykorzystywany przez parser zapytań do solr. Ustawmy go na wartość „AND”. 

<solrQueryParser defaultOperator="AND"/>

Mamy zatem gotowy plik konfiguracyjny schema.xml! Zobaczmy jak wygląda w całej okazałości: 

<?xml version="1.0" encoding="UTF-8" ?>
<schema name="carsale" version="1.2">
  <types>
   <fieldType name="string" sortMissingLast="true" omitNorms="true"/>
   <fieldType name="boolean" sortMissingLast="true" omitNorms="true"/>
   <fieldType name="tint" precisionStep="8" omitNorms="true" positionIncrementGap="0"/>
   <fieldType name="tfloat" precisionStep="8" omitNorms="true" positionIncrementGap="0"/>
   <fieldType name="text" positionIncrementGap="100">
     <analyzer>
       <tokenizer class="solr.WhitespaceTokenizerFactory"/>
       <filter class="solr.LowerCaseFilterFactory"/>
     </analyzer>
   </fieldType>
   <fieldType name="lowercase" positionIncrementGap="100">
     <analyzer>
       <tokenizer class="solr.KeywordTokenizerFactory"/>
       <filter class="solr.LowerCaseFilterFactory" />
       <filter class="solr.TrimFilterFactory" />
     </analyzer>
   </fieldType>
 </types>
 <fields>
   <field name="id" type="string" indexed="true" stored="true" required="true" />
   <field name="make" type="text" indexed="false" stored="true" required="true" />
   <field name="model" type="text" indexed="false" stored="true" required="true" />
   <field name="make_sort" type="lowercase" indexed="true" stored="false" />
   <field name="model_sort" type="lowercase" indexed="true" stored="false" />
   <field name="year" type="tint" indexed="true" stored="true" required="true" />
   <field name="price" type="tfloat" indexed="true" stored="true" />
   <field name="engine_size" type="tint" indexed="true" stored="true" />
   <field name="mileage" type="tint" indexed="true" stored="true" />
   <field name="colour" type="lowercase" indexed="true" stored="true" />
   <field name="damaged" type="boolean" indexed="false" stored="true" />
   <field name="content" type="text" indexed="true" stored="false" multiValued="true"/>
 </fields>
 <uniqueKey>id</uniqueKey>
 <defaultSearchField>content</defaultSearchField>
 <solrQueryParser defaultOperator="AND"/>
 <copyField source="make" dest="content"/>
 <copyField source="model" dest="content"/>
 <copyField source="make" dest="make_sort"/>
 <copyField source="model" dest="model_sort"/>
 <copyField source="year" dest="content"/>
</schema>

Podsumowując

W dzisiejszym wpisie udało nam się stworzyć plik schema.xml, który pomoże nam tak zaindeksować dane, abyśmy mogli zrealizować funkcjonalności wyszukiwania ogłoszeń naszego serwisu sprzedaży samochodów. Chcielibyśmy jednak rozwijać nasz serwis, co będzie się wiązało z dodatkowymi zmianami w pliku konfiguracyjnym … i nie tylko. W następnych artykułach z cyklu „sprzedaż samochodów” będziemy realizować nowe wymagania oraz wprowadzać kolejne modyfikacje.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Wymagane pola są oznaczone *

We use cookies to personalise content and ads, to provide social media features and to analyse our traffic. We also share information about your use of our site with our social media, advertising and analytics partners.
Cookies settings
Accept
Privacy & Cookie policy
Privacy & Cookies policy
Cookies list
Cookie name Active

Privacy Policy

What information do we collect?

We collect information from you when you register on our site or place an order. When ordering or registering on our site, as appropriate, you may be asked to enter your: name, e-mail address or mailing address.

What do we use your information for?

Any of the information we collect from you may be used in one of the following ways: To personalize your experience (your information helps us to better respond to your individual needs) To improve our website (we continually strive to improve our website offerings based on the information and feedback we receive from you) To improve customer service (your information helps us to more effectively respond to your customer service requests and support needs) To process transactions Your information, whether public or private, will not be sold, exchanged, transferred, or given to any other company for any reason whatsoever, without your consent, other than for the express purpose of delivering the purchased product or service requested. To administer a contest, promotion, survey or other site feature To send periodic emails The email address you provide for order processing, will only be used to send you information and updates pertaining to your order.

How do we protect your information?

We implement a variety of security measures to maintain the safety of your personal information when you place an order or enter, submit, or access your personal information. We offer the use of a secure server. All supplied sensitive/credit information is transmitted via Secure Socket Layer (SSL) technology and then encrypted into our Payment gateway providers database only to be accessible by those authorized with special access rights to such systems, and are required to?keep the information confidential. After a transaction, your private information (credit cards, social security numbers, financials, etc.) will not be kept on file for more than 60 days.

Do we use cookies?

Yes (Cookies are small files that a site or its service provider transfers to your computers hard drive through your Web browser (if you allow) that enables the sites or service providers systems to recognize your browser and capture and remember certain information We use cookies to help us remember and process the items in your shopping cart, understand and save your preferences for future visits, keep track of advertisements and compile aggregate data about site traffic and site interaction so that we can offer better site experiences and tools in the future. We may contract with third-party service providers to assist us in better understanding our site visitors. These service providers are not permitted to use the information collected on our behalf except to help us conduct and improve our business. If you prefer, you can choose to have your computer warn you each time a cookie is being sent, or you can choose to turn off all cookies via your browser settings. Like most websites, if you turn your cookies off, some of our services may not function properly. However, you can still place orders by contacting customer service. Google Analytics We use Google Analytics on our sites for anonymous reporting of site usage and for advertising on the site. If you would like to opt-out of Google Analytics monitoring your behaviour on our sites please use this link (https://tools.google.com/dlpage/gaoptout/)

Do we disclose any information to outside parties?

We do not sell, trade, or otherwise transfer to outside parties your personally identifiable information. This does not include trusted third parties who assist us in operating our website, conducting our business, or servicing you, so long as those parties agree to keep this information confidential. We may also release your information when we believe release is appropriate to comply with the law, enforce our site policies, or protect ours or others rights, property, or safety. However, non-personally identifiable visitor information may be provided to other parties for marketing, advertising, or other uses.

Registration

The minimum information we need to register you is your name, email address and a password. We will ask you more questions for different services, including sales promotions. Unless we say otherwise, you have to answer all the registration questions. We may also ask some other, voluntary questions during registration for certain services (for example, professional networks) so we can gain a clearer understanding of who you are. This also allows us to personalise services for you. To assist us in our marketing, in addition to the data that you provide to us if you register, we may also obtain data from trusted third parties to help us understand what you might be interested in. This ‘profiling’ information is produced from a variety of sources, including publicly available data (such as the electoral roll) or from sources such as surveys and polls where you have given your permission for your data to be shared. You can choose not to have such data shared with the Guardian from these sources by logging into your account and changing the settings in the privacy section. After you have registered, and with your permission, we may send you emails we think may interest you. Newsletters may be personalised based on what you have been reading on theguardian.com. At any time you can decide not to receive these emails and will be able to ‘unsubscribe’. Logging in using social networking credentials If you log-in to our sites using a Facebook log-in, you are granting permission to Facebook to share your user details with us. This will include your name, email address, date of birth and location which will then be used to form a Guardian identity. You can also use your picture from Facebook as part of your profile. This will also allow us and Facebook to share your, networks, user ID and any other information you choose to share according to your Facebook account settings. If you remove the Guardian app from your Facebook settings, we will no longer have access to this information. If you log-in to our sites using a Google log-in, you grant permission to Google to share your user details with us. This will include your name, email address, date of birth, sex and location which we will then use to form a Guardian identity. You may use your picture from Google as part of your profile. This also allows us to share your networks, user ID and any other information you choose to share according to your Google account settings. If you remove the Guardian from your Google settings, we will no longer have access to this information. If you log-in to our sites using a twitter log-in, we receive your avatar (the small picture that appears next to your tweets) and twitter username.

Children’s Online Privacy Protection Act Compliance

We are in compliance with the requirements of COPPA (Childrens Online Privacy Protection Act), we do not collect any information from anyone under 13 years of age. Our website, products and services are all directed to people who are at least 13 years old or older.

Updating your personal information

We offer a ‘My details’ page (also known as Dashboard), where you can update your personal information at any time, and change your marketing preferences. You can get to this page from most pages on the site – simply click on the ‘My details’ link at the top of the screen when you are signed in.

Online Privacy Policy Only

This online privacy policy applies only to information collected through our website and not to information collected offline.

Your Consent

By using our site, you consent to our privacy policy.

Changes to our Privacy Policy

If we decide to change our privacy policy, we will post those changes on this page.
Save settings
Cookies settings