Newsletter 7.0.5: May update

Hello!

We are coming back with new set of information regarding Energy Logserver – starting with currently latest version - 7.0.5. This time we would like to turn your attention to some new data management capabilities we’ve introduced as well as our response to CentOS 7&8 dispute. Hope you will find it helpful!

 

Data Management Capabilities

SUPPORT OF ARCHIVING SELECTED FIELDS

While log retention due to regulatory compliance is something we see in almost every organizations we work with – the scope of what part from log message to store - varies.

With newly introduced „archiving the selected fields” you are able to select the exact fields from the log message, which you would like to save in your storage.

Just create new „Archive” task and filter the names you want to include in the report:

This way you can seriously optimize you log storage & archives searching speed!

 

OBJECT PERMISSION – DELETING RELATING OBJECTS
Now, when deleting an object, in “object permission” you can mark related objects to be deleted at the same time. This is made to ease-up the governance time with our solution. Remember when you had to manually remove each visualization from saved dashboard?

It is not the case anymore!

No when you go to each:
Saved search -> Visualization -> Dashboard  - you can delete dashboard with all related objects.

 

SCHEDULER FOR „DATA EXPORT”

Newly added scheduler helps you to stay compliant with re-occurring reporting requests. This feature is helpful when you are looking to:

Automate certain reporting task (e.g. monthly application performance report)

Prepare report from certain upcoming date (with scheduler, you don’t have to remember)

Dump the raw data in scheduled manner

This feature can be a great addition to both – compliance and governance related function set.

 

Deployment updates

DEPLOYMENT NOW POSSIBLE FOR ORACLE LINUX 7/8, CENTOS STREAM & SCIENTIFIC LINUX

Our installation support is now additionally possible for Oracle Linux7/8, Scientific Linux 7, Centos Stream (and also originally for Centos7/8 and RedHat7/8). We decided to introduce new implementation possibilities due to recent issues with Linux Centos distribution. You can see more in following article: CentOS Linux is dead—and Red Hat says Stream is “not a replacement"

 

As your fellow technical team – we will be happy to discuss this ground-breaking announcement and help you prepare for the future!

Newsletter 7.0.5: Update majowy

Witajcie!

Powracamy z nowym zestawem informacji dotyczących Energy Logserver i jego aktualnej wersji - 7.0.5. Tym razem pragniemy zwrócić Waszą uwagę na nowe możliwości zarządzania danymi oraz naszą reakcję na obecne problemy z CentOS 7&8. Mam nadzieję, że poniższa wiedza będzie dla Was przydatna!

 

Możliwości zarządzania danymi

ARCHIWIZACJA WYBRANYCH PÓL

Podczas gdy przechowywanie logów ze względu na zgodność z przepisami jest czymś, co widzimy w prawie każdej organizacji, z którą współpracujemy – zakres dokumenty logu, który chcą przechowywać - jest różny. Dzięki nowo wprowadzonemu „archiwizowaniu wybranych pól” możesz wybrać dokładnie te pola z logu, które chcesz zapisać na swoim dysku. Po prostu utwórz nowe zadanie „Archive” i przefiltruj nazwy, które chcesz uwzględnić w raporcie:

W ten sposób może znacząco zoptymalizować swoją przestrzeń dyskową i szybkość wyszukiwania!

 

OBJECT PERMISSION - USUWANIE POWIĄZANYCH OBIEKTÓW

Teraz, usuwając obiekt, w polu „Object Permission” możesz zaznaczyć powiązane obiekty do usunięcia w tym samym czasie. Ma to na celu skrócenie czasu zarządzania dashboardami dzięki naszemu rozwiązaniu. Pamiętasz, kiedy trzeba było ręcznie usuwać każdą wizualizację z zapisanego dashboardu?

To już nie problem!

Nie, kiedy robisz to następująco:
Saved search à Visualization à Dashboard  -  Możesz usuwać dashboardy wraz z wszystkimi powiązanymi obiektami.

 

HARMONOGRAMOWANIE EKSPORTU DANYCH

Nowo dodany harmonogram pomaga zachować zgodność z powtarzającymi się żądaniami raportowania. Ta funkcja jest przydatna, gdy chcesz:

  1. Zautomatyzować określone zadania raportowania (np. Miesięczny raport wydajności aplikacji)
  2. Przygotować raport z określonej nadchodzącej daty (z harmonogramem nie musisz o tym pamiętać)
  3. Zrzucić surowe dane w zaplanowany sposób

Ta funkcja może być doskonałym dodatkiem zarówno do funkcji związanych ze zgodnością z regulacjami, jak i zarządzaniem danymi.

 

Aktualizacje techniczne

 IMPLEMENTACJA MOŻLIWA DLA ORACLE LINUX 7/8, CENTOS STREAM & SCIENTIFIC LINUX

Nasze implementacje są teraz dodatkowo możliwe dla Oracle Linux 7/8, Scientific Linux 7, Centos Stream (a także pierwotnie dla Centos 7/8 i RedHat7 / 8). Zdecydowaliśmy się na wprowadzenie nowych możliwości wdrożeniowych ze względu na ostatnie problemy z dystrybucją Linux Centos. Więcej w poniższym artykule: CentOS Linux is dead—and Red Hat says Stream is “not a replacement

 

Jako Twoje techniczne wsparcie - z przyjemnością omówimy tą sytuację i pomożemy Ci przygotować się na przyszłość!

Newsletter 7.0.5: Nowa wersja i ulepszone raportowanie

Witajcie.

Nadeszła nowa wersja! Energy Logserver jest obecnie w wersji 7.0.5. Planowaliśmy, że ta aktualizacja będzie mniejsza, obejmująca głównie zmiany w zakresie optymalizacji i stabilizacji. Okazało się jednak, że dodaliśmy istotne funkcje, nad którymi pracowaliśmy już przez jakiś czas. Poniżej znajduje się kilka najważniejszych informacji.

 

Główne zmiany

SUNBURST IOC

Dodaliśmy wykrywanie SUNBURST IOC do Energy Logserver. SUNBURST to poważne zagrożenie, które może zostać wykorzystać do wykradania poufnych informacji z organizacji, a nawet przejęcia kontroli nad zainfekowanymi systemami. Atak ten jest bardzo poważny i warto monitorować jego aktywność. Energy Logserver został wyposażony w predefiniowane alerty, których można użyć do wykrywania SUNBURST. Możesz przeczytać więcej tutaj https://energylogserver.pl/pl/detekcja-sunburst/

Alert przez syslog

Dodano funkcję do interfejsu alertów. Możesz wybrać metodę alarmowania jako wiadomość syslog. Jest to bardzo przydatne do integracji Energy Logserver z wieloma różnymi rozwiązaniami, które mogą odbierać dane lub sygnał za pośrednictwem syslog. Możesz wybrać hosta, port, protokół, severity i facility tej metody powiadamiania.

Obsługa znaków narodowych

Energy Logserver ma teraz pełne wsparcie dla znaków narodowych. Dzięki temu jest całkowicie gotowy na wszelkie niestandardowe dane z nietypowych źródeł. Każdy moduł Energy Logserver jest przygotowany do przetwarzania i działania ze 100% wydajnością z takimi danymi.

Ulepszone raportowanie

Raporty i eksporty zostały wzbogacone o dodatkowe informacje. Teraz możesz zobaczyć, kto i kiedy utworzył raport lub zadanie eksportu. Harmonogram raportów został zoptymalizowany i przeniesiony do tej samej karty, co twórca raportów. Dzięki tej aktualizacji masz jeszcze większą kontrolę i informacje o użytkownikach Energy Logserver. To kolejny krok w kierunku, aby zarządzanie użytkownikami Energy Logserver było tak łatwe i przejrzyste, jak to tylko możliwe.

 

Zajęliśmy się również jednym z najbardziej zagmatwanych tematów w elasticsearch: Keyword i Text - jaka jest różnica.

Zapraszam do przeczytania krótkiego artykułu tutaj: https://energylogserver.pl/pl/roznica-miedzy-text-a-keyword/

Jeśli cię to zaintereoswało, to kilka słów o optymalizacji powinno być czymś, o czym chcesz się dowiedzieć 🙂

Przeczytaj więcej na naszym blogu: https://energylogserver.pl/pl/slow-kilka-o-optymalizacji/

 

Bądźcie bezpieczni i szczęśliwego wyszukiwania!

Zespół Energy Logserver

Newsletter 7.0.5: New version and enhanced reporting

Welcome.

New version has arrived! Energy Logserver is currently at version 7.0.5. We've planned this update to be smaller one, with mainly optimization and stabilization changes. But it turned out that we’ve added significant features on which we were working for some time. Below are some of highlights.

 

Major changes

SUNBURST IOC

We’ve added SUNBURST IOC detection to Energy Logserver. SUNBURST is serious threat that can be used to steal sensitive information from organization and even take control of infected systems. This attack is very serious and it is worth to monitor it’s activity. Energy Logserver has been equipped with predefined alerts that can be used to detect SUNBURST. You can read more here https://energylogserver.pl/en/sunburst-detection/

Alert through syslog

Feature has been added to Alert UI. You can select alerting method as syslog message. This is very useful for integrating Energy Logserver with many different solutions, which are capable of receiving data or signal through syslog. You can select host, port, protocol, severity and facility of this notification method.

National character support

Energy Logserver has now full national character support. This makes it completely ready for any custom data from uncommon sources. Every module of Energy Logserver is prepared to process and function with 100% efficiency with such data.

Reporting enhanced

Reports and exports has been enhanced with additional information. Now you can see who created report or export task and when. Report scheduler has been optimized and moved to the same tab as report creator. With this update you have even more control and information about Energy Logserver users. This is next step in our direction to make Energy Logserver user management be as useful and easy as possible.

 

We’ve also tackled one of most confusing topics in elasticsearch: Keyword and Text string types – what is the difference.

Feel free to read short article here: https://energylogserver.pl/en/text-vs-keyword/

If you find that interesting, then few words about optimization should be something you want to know 🙂

Read more on our blog: https://energylogserver.pl/en/few-words-about-optimization/

 

Stay safe and happy searching!

Energy Logserver team

Detekcja SUNBURST

SUNBURST to zagrożenie, które wykorzystuje oprogramowanie SolarWinds. Zagrożenie uzyskuje dostęp się do infrastruktury poprzez fałszywą aktualizację oprogramowania. Malware skonstruowany został tak dobrze, że pozostawał niewykryty przez długi czas. Bardzo sprytnie maskuje swoją komunikacje, udając prawdziwe połączenia. Wykorzystuje nawet natywne dla kraju adresy IP, celem uniknięcia rozpoznania anomalii.

Co nam grozi? Przede wszystkim ten wyrachowany atak ma na celu przekazanie informacji personalnych, loginach i hasłach użytkowników, danych osobistych, ale również – wgląd w tajemnice organizacji
i własności intelektualne, takie jak technologie i projekty. Finalnie SUNBURST pozwala osobom nieautoryzowanym na przejęcie kontroli nad systemem. Zagrożenie ze strony tej podatności jest bardzo poważne.

W Energy Logserver zebraliśmy dużą ilość informacji o tym zagrożeniu, a na ich bazie przygotowaliśmy zestaw reguł, pozwalających wykryć obecność SUNBURST w naszym środowisku.

Chociaż aktywność SUNBURST jest dobrze zamaskowana, nie jest niewykrywalna. Wbudowany w Energy Logserver system Threat Intelligence, po skonfigurowaniu jest w stanie łatwo zaobserwować ślady tej podatności. Agenci po dodaniu przynajmniej dwóch obiektów monitoringu mogą wysłać kluczowe informacje, które pomogą zidentyfikować zagrożenie.

Obiekty do monitoringu mogą być tak podstawowe, jak podsystem Windows Defendera oraz TaskScheduler. Zarówno Windows Defender jak i TaskScheduler mogą dostrzec próby charakterystyczne dla aktywności SUNBURST.

Ponadto nasza baza Threat Intelligence zawiera ponad 2100 charakterystycznych obiektów, które są identyfikowane z aktywnością SUNBURST lub malware związanych z SolarWinds. Ich typy dotyczą m.in. hashów plików, adresów IP, domen, itd.

Energy Logserver może zostać wzbogacony o paczkę predefiniowanych alertów dotyczących detekcji SUNBURST. Dodatkowo, wykorzystując metody dostępne w Energy Logserver, jesteśmy w stanie dokonać ulepszenia parserów celem precyzyjnej detekcji aktywności malware w środowiskach SolarWinds.

SUNBURST detection

SUNBURST is a threat that uses SolarWinds software. The threat accesses the infrastructure via a fake software update. The malware was constructed so well that it went undetected for a long time. He disguises his communications very cleverly, pretending to be real connections. It even uses country-specific IP addresses to avoid being recognized as anomaly.

What is the risk? First of all, this calculated attack is aimed at transferring specific information, user logins and passwords, personal data, but also - insight into the secrets of the organization and intellectual property such as technologies and designs. Finally, SUNBURST allows unauthorized persons to take control of the system. The threat posed by this vulnerability is very serious.

At Energy Logserver, we have collected a large amount of information about this threat, and based on it, we have prepared a set of rules that allow us to detect the presence of SUNBURST in our environment.

While SUNBURST activity is well masked, it is not undetectable. The Threat Intelligence system built into Energy Logserver, when configured is able to easily observe traces of this vulnerability. After adding at least two monitoring objects, Agents can send key information that will help identify the threat.

Objects for monitoring can be as basic as the Windows Defender subsystem and TaskScheduler. Both Windows Defender and TaskScheduler can spot attempts specific to SUNBURST activity.

In addition, our Threat Intelligence database contains over 2,100 characteristic objects that are identified with SUNBURST activity or SolarWinds related malware. Their types concern, among others hashes of files, IP addresses, domains, etc.

Energy Logserver can be enriched with a package of predefined alerts related to SUNBURST detection. Additionally, using the methods available in Energy Logserver, we are able to improve parsers in order to precisely detect malware activity in SolarWinds environments.

Few words about optimization

While working with elasticsearch it’s impossible to avoid the topic of shard optimization. Sooner or later every user of a more complex system will have to take up this topic. An unoptimized elasticsearch environment can result in slow data indexing, returning responses, and even unstable performance of the entire environment.

The sooner we understand where this problem comes from and the sooner we address it, the better. Planning elasticsearch shard policies is essential to ensure a long-lasting and stable cluster performance. It is also worth remembering that shards are nothing else than the Lucene engine on the basis of which elasticsearch was created.

 

What is shard?

Index is built with shards and we divide them into primary and replica. Each shard holds some part of the data stored in the index, so the set of primary shards in the index will act as RAID 0. Additionally, each primary shard can have its 1:1 replica. This guarantees data availability in the event of a cluster failure. If any primary shard becomes unavailable, its replica takes his place.

 

Disks

Often times, the elasticsearch environments that receive the data are not properly managed in terms of space. This means that the data released into the environment remain there for a long time, somehow forgotten. Indexing large amounts of data without proper management can quickly consume even huge disk resources. The reason for this is that the replicas are 1: 1 copies of the primary shards.

Holding an index (e.g. 100GB) of 4 shards and each of them has its own three replicas means that we have a total of 15 shards (4 primary + 12 replicas) and 400 GB of data. It is not hard to see how inattention can lead to a quick full disk in such a scenario.

Optimization consists in categorizing data and assigning them an appropriate number of shards and replicas. Of course, each replica taken means a greater susceptibility to permanent data loss in the event of a failure. It is known, however, that not every index is critical and for those with lower priority it is worth considering how many replicas they require.

 

Memory

Elasticsearch is software made in java. The assigned heap is therefore crucial for the proper functioning of the environment. Incorrectly scheduling the server's memory resources can contribute to a serious failure due to insufficient memory.

How to judge how much memory an elasticsearch node requires It depends on the size of the cluster and the amount of data we collect. Elasticsearch holds a lot of data in memory for quick access. It is recommended that an elasticsearch node does not have more than 25 shards (primary and replicas) per 1 GB of memory in the heap. It is worth noting that elasticsearch is not able to limit this for us. This is one of the fundamental steps of an administrator to monitor the number of shards per heap memory.

 

Performance

When it comes to query optimization, there is no secret that the main element is the structure of the query and the scope of data on which the query is triggered. In other words: 100GB data will be responded faster than 500GB data.

The more complicated the query and the more data is run, the later we will get the answer. Therefore, it is important to balance the relationship between the number of shards and their size.

It is recommended that one shard contains between 20GB and 40GB of data. Therefore, if we have an index of 100GB of data, it is worth allocating a total of 4 shards primary. Replicas are not included in this optimization procedure as they hold 1: 1 copies of the data of the primary shards.

 

Summary

The above aspects show that although elasticsearch is a powerful tool and one of the best engines for managing large amounts of data, it still needs careful attention in terms of optimization. Good planning of the indexes and shards structure will allow you to enjoy a stable and very efficient cluster environment.

Słów kilka o optymalizacji

Pracjąc z elasticsearch nie sposób jest ominąć tematu optymalizacji shardów. Prędzej czy później każdy użytkownik bardziej rozbudowanego systemu będzie musiał podjąć się tego tematu. Niezoptymalizowane środowisko elasticsearch może skutkować powolnym indeksowanie danych, zwracaniem odpowiedzi, a nawet niestabilnym działaniem całego środowiska.

Im szybciej zrozumiemy skąd ten problem się bierze i im szybciej go zaadresujemy tym lepiej. Planowanie polityk shardów elasticsearch jest niezbędne aby zapewnić długotrwałe i stabilne działanie clustra. Warto też pamiętać, że shardy są niczym innym jak silnikiem Lucene, na bazie którego elasticsearch powstał.

 

Czym jest shard?

Index składa się z shardów i dzielimy je na primary i replica. Każdy shard trzyma jakąś część danych zgromadzonych w indexie, więc zbiór shardów primary w indexie będzie działał jak RAID 0. Dodatkowo każdy shard primary może mieć swoją replikę 1:1. Gwarantuje to dostępność danych w przypadku awarii clustra. Jeśli któryś shard primary przestanie być dostępny, jego replika go zastępuje.

 

Dyski

Często zdarza się, że środowiska elasticsearch, które odbierają dane nie są poprawnie zarządzane pod względem przestrzeni. Oznacza to, że dane wpuszczone do środowiska tam zostają na długi czas, niejako zapomniane. Indeksowanie dużej ilości danych bez odpowiedniego zarządzania szybko może pochłonąć nawet ogromne zasoby dyskowe. Powodem tego jest fakt, że repliki są kopiami 1:1 shardów primary.

Trzymając index (np. 100GB) z 4 shardów i każdy z nich ma swoje trzy repliki oznacza, że w mamy w sumie 15 shardów (4 primary + 12 replik) i 400 GB danych. Nietrudno zauważyć jak nieuwaga może doprowadzić do szybkiego zapełnienia dysku w takim scenariuszu.

Optymalizacja polega na kategoryzowaniu danych i przypisywaniu im odpowiedniej ilości shardów oraz replik. Oczywiście, każda replika zabrana oznacza większa podatność na permanentną utratę danych w przypadku awarii. Wiadome jest jednak, że nie każdy index jest krytyczny i dla tych o mniejszym priorytecie warto rozważyć jakiej ilości replik wymagają.

 

Pamięć

Elasticsearch jest oprogramowaniem stworzonym w java. Przypisany heap jest więc kluczowy dla poprawnego działania środowiska. Niepoprawne zaplanowanie zasobów pamięci serwera może przyczynić się do poważnej awarii wynikającej z braku dostępnej pamięci.

Jak ocenić ile pamięci węzeł elasticsearch wymaga? To zależy od wielkości clustra i ilości danych, które gromadzimy. Elasticsearch przetrzymuje dużo danych w pamięci, celem szybkiego dostępu. Rekomendowane jest, by węzeł elasticsearch nie posiadał więcej niż 25 shardów (primary jak i replik) na 1 GB pamięci w heap. Warto zaznaczyć, że elasticsearch nie jest w stanie tego limitować za nas. Jest to jedna z fundamentalnych czynności administratora, aby monitorować ilość shardów per pamięć heap.

 

Performance

Jeśli chodzi o optymalizację zapytań, tuta żadną wiedzą tajemną nie jest fakt, że głównym elementem jest struktura zapytania i zakres danych, na których te zapytanie jest wyzwolone. Innymi słowy: szybciej zwrócona zostanie odpowiedź z danych o wielkości 100GB niż z danych o wielkości 500GB.

Im bardziej skomplikowane zapytanie i na większej ilości danych zostanie uruchomione tym później otrzymamy odpowiedź. Dlatego ważne jest wyrównanie zależności pomiędzy ilością shardów, a ich rozmiarem.

Rekomendowane jest, by jeden shard zawierał pomiędzy 20GB a 40GB danych. Dlatego jeśli mamy index o wielkości 100GB danych, warto przydzielić mu sumarycznie 4 shardy primary. Repliki nie są wliczane do tego zabiegu optymalizacji, jako że trzymają one kopie danych 1:1 shardów primary.

 

Podsumowanie

Powyższe aspekty pokazują, że chociaż elasticsearch jest potężnym narzędziem i jednym z najlepszych silników do zarządzania dużą ilością danych, to wciąż wymaga dokładnej uwagi pod względem optymalizacji. Dobre zaplanowanie struktury indexów i shardów pozwoli cieszyć się stabilnym i bardzo wydajnym środowiskiem clustra.

Text vs Keyword

There are two types of data in elasticsearch that are often troublesome for people inexperienced in working with the system - Keyword and Text. Both types are a kind of string, but elasticsearch interprets them differently, so you can perform different operations on them.

 

How file type is made?

In general, the type of field is determined by the template. It is a instruction for creating indexes in elasticsearch - including field mappings. If a given template does not clearly specify what type of field the given field should be, elasticsearch will by default create dynamic mapping for both Keyword and Text. However, it is not recommended to work in that manner, due to the disk space that can be saved by planning assigned types to fields.

 

Inverted index

To understand the importance of the problem, look at the inverted index in elasticsearch[1] . It is a specific way in which the system saves data and thanks to this solution, elasticsearch is very fast in returning large amount of dokuments even on a big time scale.

The inverted index is similar to the index in some books. At the end of the book you can find a list of words with information on which pages these words appear on. Elasticsearch does exactly the same for each word that mentions which document it is in.

Example

For example. let's look at document with id "my-document". It has a field of "address" with value of "Wiejska 20, Warsaw".
POST "localhost:9200/my-index/_doc/my-document" -d'
{
"address" : "Wiejska 20, Warsaw"
}'

Below is a presentation of how elasticsearch sees it in the inverted index for both types

Difference in query

Elasticsearch first checks the inverted index for a match when it receives a query. If it finds them, it displays the documents that match that query. Therefore, if we query elasticsearch for the value "Warsaw", a document with the Keyword type may not return the result because the value is literally "Wiejska 20, Warsaw". The opposite is true in the case of the Text type - because the field content has been analyzed, elasticsearch is able to find single words in the inverted index and return the answer in the form of a document.

Of course, there are still different kinds of search queries to Elasticsearch, and depending on which ones are used, you may get different results. This point, however, does not directly touch upon the differences in the field types themselves.

 

Summary

The differences between the two types are significant. We generally use keyword types for constant values in the data that we do not want to analize, eg country name, application name, etc. We use the Text type when we need to use the full text search power, eg in the message field that contains the original message from the system.

 

[1] In truth, the inverted index is a aspect of the Apache Lucene engine on which Elasticsearch was developed. A shortcut was used to make understanding of the problem easier.

Różnica między Text a Keyword

W elasticsearch występują dwa typy danych, które często bywają kłopotliwe dla osób niedoświadczonych w pracy z systemem – Keyword i Text. Oba typy są rodzajem stringa, ale elasticsearch inaczej je interpretuje, przez co można na nich wykonać inne operacje.

 

Skąd się bierze typ pola?

Ogółem, to jakim typem jest pole, określa template. Jest to wzorzec tworzenia indexów w elasticsearch – w tym mapowania pól. Jeśli dany template nie określa jasno jakiego typu ma być dane pole, elasticsearch domyślnie stworzy dynamiczny mapping dla typów Keyword i Text. Nie jest jednak to rekomendowane ze względu na przestrzeń dyskową jaką można zaoszczędzić poprzez planowanie przypisanych typów do pól.

 

Index odwrócony

Aby zrozumieć wagę problemu, należy spojrzeć na odwrócony index elasticsearch[1].  Jest to specyficzny sposób w jaki system zapisuje dane i to dzięki temu rozwiązaniu elasticsearch jest bardzo szybki w zwracaniu odpowiedzi nawet w dużej skali czasu.

Odwrócony index działa podobnie do indexu w niektórych książkach. Na końcu książki można znaleźć listę wyrazów z informacją na których stronach się te wyrazy pojawiły. Elasticsearch robi dokładnie to samo dla każdego wyrazu z informacją w którym dokumencie się znajduje.

Przykład dokumentu

Dla przykładu spójrzmy na dokument o id "moj-dokument". Ma on pole "adres", a wartość tego pola to "Wiejska 20, Warszawa".
POST "localhost:9200/moj-index/_doc/moj-dokument" -d'
{
"adres" : "Wiejska 20, Warszawa"
}'

Poniżej prezentacja, jak widzi to elasticsearch w odwróconym indexie dla typów

Keyword

 

Text

Różnica w zapytaniu

Elasticsearch po otrzymaniu zapytania najpierw sprawdza index odwrócony pod względem dopasowania. Jeśli je znajdzie, wyświetla dokumenty, które odpowiadają temu zapytaniu. Dlatego jeśli odpytamy elasticsearch o wartość „Warszawa”, dokument z typem Keyword może nie zwrócić rezultatu, ponieważ wartość to dosłownie „Wiejska 20, Warszawa”. Odwrotnie jest w przypadku typu Text - ponieważ zawartość pola została przeanalizowana, elasticsearch jest w stanie odnaleźć pojedyncze wyrazy w odwróconym indexie i zwrócić odpowiedź w postaci dokumentu.

Oczywiście istnieją jeszcze różne rodzaje zapytań do Elasticsearch i w zależności od tego, które zostaną użyte, można otrzymać różne wyniki. Ta kwestia jednak nie dotyka bezpośrednio różnic w samych typach pól.

 

Podsumowując

Różnice między tymi dwoma polami są znaczące. Generalnie używamy typów keyword dla stałych wartości w danych, których nie chcemy analizować, np. nazwa kraju, aplikacji, itp. Typu Text używamy, kiedy musimy skorzystać z mocy przeszukiwania pełnotekstowego, np. w polu message, które zawiera oryginalną wiadomość z systemu.

 

 

 

[1] Po prawdzie, odwrócony index jest właściwością silnika Apache Lucene, na bazie którego powstał Elasticsearch. Celem ułatwienia zrozumienia problemu, użyto skrótu myślowego.