Oryginalny tekst datowany jest na 4.11.2015, a uzupełniony w lipcu 2016

ElasticSearch jest takim samym systemem wyszukiwania, jak każdy inny powstały w przeciągu ostatnich kilkudziesięciu lat. Indeks ma sztywną strukturę i nic tego nie zmieni. Jedyna różnica polega na tym, że tenże indeks jest modyfikowany w locie / w tle, co niesie za sobą sporo, czasem przykrych konsekwencji, choć na początku może wydawać się to świetnym pomysłem.

Nie-typy, czyli "mappingi"

ElasticSearch posiada tzw. "mappingi". Niektórzy mogą uważać, że są to typy indeksowanych dokumentów. Słowo "typ" z resztą pada w dokumentacji. Ale to nie są typy. Są to elementy grupujące kolumny indeksu w pewne logiczne klasy, które mogą posłużyć jako dodatkowy filtr lub zbiór definicji o analizerach i tokenizerach, oraz mogą mieć znaczenie wydajnościowe (operujemy na jakimś podzbiorze). Można je porównać do widoków znanych z RDBMS.

Należy jednak pamiętać, że kolumny (tudzież pola) w "mappingach" należą do zbioru kolumn (pól) całego indeksu. Zatem kolumny o tych samych nazwach, mimo że należą do różnych "mappingów", muszą być tego samego typu. I mimo że interfejs ElasticSearch umożliwia rozłączne definiowanie "mappingów", to próba użycia tej samej nazwy z różnymi typami spowoduje wygenerowanie błędu.

Efektem ubocznym nieuważnego stosowania mappingów są przerośnięte i niewydajne indeksy. Istnieje zalecenie niemodyfikowania "mappingów", lub ich bardzo rzadkiego modyfikowania.

Plusy? Może jakieś są, ale jestem zwolennikiem rozłącznych indeksów (z powodów wydajnościowych i architektonicznych) wraz z multiindex query.

Nie-dynamiczna struktura

Tu należy wrócić do udawanego dynamizmu ElasticSearch. Otóż dodanie pierwszego dokumentu o niby-dowolnej strukturze powoduje automatyczne rozszerzanie mappingu, indeksu, oraz zgadywanie typu kolumny (pola). To pierwszy krok do problemów z mappingami i typami, które jeśli zostaną zaniedbane mogą kończyć się żmudnym maintenance indexu a w najgorszym razie jego całkowitym usunięciem oraz zasileniem od nowa po wprowadzeniu zmian.

Podczas dynamicznego mappingu typ pola jest określany na bazie pierwszej indeksowanej wartości tego pola. Z tego wynika, że w niektórych przypadkach to los określa, kiedy nastąpi awaria - wystarczy indeksować dokumenty w nieokreślonej kolejności. A oddawanie działania systemów w ręce losu jest skrajnie nieodpowiedzialne.

Nie-RESTful API

Innym ważnym aspektem jest fakt, iż ElasticSearch nie posiada RESTful API. Autorzy mylnie lub z powodów marketingowych używają tego określenia. ElasticSearch posiada API oparte o HTTP i dokumenty JSON, ale nie jest to interfejs RESTful, przez co jest nieintuicyjny i bez dokumentacji nie da się go "konsumować". Sens interfejsu RESTful dla Elastica jest raczej znikomy, wprost przeciwnie do marketingu.

Natomiast same kwerendy JSON, mimo że potrafią być skomplikowane, są bardzo elastyczne. Wiele poziomów zagnieżdżania JSON utrudnia czytanie i pisanie kwerend, ale najważniejsza jest ich skuteczność. Zapytać można praktycznie o wszystko, także za pomocą własnych skryptów.

Skalowalność

Na koniec zwrócę uwagę na fakt, że ElasticSearch jest silnikiem skalowalnym. Oznacza to, że jego instalacja jest tożsama z wdrożeniem pewnego rodzaju klastra. Bez przemyślenia architektury tego klastra i odpowiednich kroków związanych z jego deploymentem, narażamy się na potencjalnie dużą awarię systemu, łącznie z utratą danych.

Należy także zwrócić uwagę na (write/read) consistency level. Są to parametry często występujące przy zapisie i odczycie danych. Ich nieprawidłowe użycie (w stosunku do wdrożonego klastra) może skutkować utratą danych lub ich niespójnością.

Język polski

ElasticSearch nie wspiera natywnie j. polskiego, ale istnieje do niego plugin do analizy leksykalnej - Stempel, który jest rozszerzeniem silnika Lucene.

https://github.com/elastic/elasticsearch-analysis-stempel

Podsumowanie

ElasticSearch jest ciekawym narzędziem, prostszym w konfiguracji i pierwszej instalacji niż Apache SOLR, jednakże należy używać go z głową, ostrożnie, i najlepiej unikać "dynamizmu" poprzez skrupulatną walidację danych wejściowych w części klienckiej.

Żałuję, że walidacji danych wejściowych nie robi sam silnik, tak jak to miało miejsce w przypadku Apache SOLR. Ta odpowiedzialność została przeniesiona na klienty, a w praktyce na programistów. A ponieważ nie da się wszystkiego przewidzieć, to bezrefleksyjne użycie Elastica może skończyć się nieprzewidzianą katastrofą działającego systemu.

ElasticSearch nie dysponuje narzędziami typu "DataSource". W Apache SOLR można było zdefiniować źródło danych będące zwykłym SQL-em, co umożliwiało budowanie optymalnych kwerend i zasilanie indeksu bez rozbudowywania warstwy aplikacji klienta. I choć nie zawsze jest to wygodne, to w wielu przypadkach wystarczało, oraz miało jedną istotną zaletę - zawsze działało.

ElasticSearch posiada biblioteki dla wielu języków programowania. Biblioteki dla Pythona są względnie kiepskie poza oficjalną-podstawową, która jest już dosyć rozwinięta lecz nie wolna od wad. Ponieważ odpowiedzialność za błędy mappnigów została przeniesiona na klienty, to jako programista potrzebuję biblioteki, która uniemożliwi lub utrudni mi strzelenie sobie w stopę.

Wokół ElasticSearch widzę bardzo dużo ciekawych narzędzi. Stał się też bardzo popularny. To są niewątpliwie spore zalety, bo społeczność wydaje się większa niż w przypadku Apache SOLR, i produkt ma lepsze wsparcie. Jednak wyczuwam też sporą dawkę "marketing bullshitu", o którym czuję się zobowiązany wspomnieć.

Myślę jednak, że to nie koniec moich przygód z ElasticSearch. Jak do tej pory wady nie przesłaniają zalet. Nie trzeba grzebać po plikach XML, konfigurować instalacji multicore, ani generować schematów indeksów w XML. Wszystko jest do załatwienia przez HTTP. Biblioteki, choć nieidealne, są i działają. Funkcjonalność silnika jest mocna (wszak to Lucene, tak samo jak w Apache SOLR), oraz jest sharding bez ręcznych robótek z tzw. dekompozycją obiektową.

Uzupełnienie (4.11.2015)

Nowy SOLR

Najnowsza wersja Apache SOLR również wspiera model "schemaless", tj. dynamiczne konstruowanie indeksu. Z tą różnicą, że po "zabawie" developerskiej można przełączyć się na "configured schema", aby zachować stabilność środowiska. Nie bedzie mowy o tym, że ktokolwiek (jakikolwiek klient) przypadkowo czy intencjonalnie "rozwali" indeks.

Do tego nowa wersja zapewnia skalowanie w oparciu o sprawdzony Apache Zookeeper i przedkłada spójność danych ponad inne aspekty, co zapobiega tzw. split brainowi.

Ponieważ mam jakieś tam doświadczenie z Apache SOLR (tyle że starszą wersją), wiem że język zapytań spełnia wszystkie oczekiwania, wsparcie facetingu jest więcej niż poprawne, wpływ na indeksowanie mam praktycznie nieograniczony, dostaję do tego stabilność oraz gwarancję spójności danych, a teraz jako bonus łatwiejszy sposób konstruowania indeksu, to najprawdopodobniej pozostanę zwolennikiem SOLR-a. Jest to produkt starszy i bardziej dojrzały, oraz nie sterowany sprzedażą i marketingiem. Mniej popularny? Python też jest mniej popularny. I całe szczęście.

Porównanie

Znalazłem przed chwilą porównanie SOLR z ElasticSearch: http://www.datanami.com/2015/01/22/solr-elasticsearch-question/

Polecam przeczytać.

Oprócz technicznych różnic istnieją nieco odmienne cele oraz podejście do open-source. W skrócie:

• SOLR jest nakierowany na Full Text Search, ElasticSearch głównie na filtrowanie i agregacje
• SOLR jest prawdziwym open-source budowanym przez community, Elastic rozwija jedna firma i jej pracownicy, którzy decydują o kierunku rozwoju
• SOLR opiera się o Apache Zookeeper, co daje pewną gwarancję, lecz także trudność we wdrożeniu; ElasticSearch z kolei jest prostszy we wdrażeniu klastra, lecz cierpi na różne problemy "wieku dziecięcego" związanego ze spójnością danych
• Wydajność obu jest porównywalna
• Wsparcie obu jest porównywalne

Oraz ważne wg mnie:

• SOLR umożliwia przełączenie się na klasyczną "sztywną" strukturę (wyłączenie pseudo-dynamizmu), co jest ważne dla utrzymania stabilności
• SOLR dostarcza dodatkowe narzędzia pomocne przy konstruowaniu systemów wyszukiwania
• SOLR nie przenosi odpowiedzialności za poprawność danych oraz wydajność indeksu na klienty

Uzupełnienie (12.07.2016)

ElasticSearch 2.x oferuje bogate możliwości wyszukiwania i indeksowania geospatial, z którego zaczynam korzystać w jednym z projektów. Mimo wspomnianych wcześniej wad decyduję się po raz kolejny na ElasticSearch, lecz z całą świadomością i należytą ostrożnością.

Awaria

Znajduję ponad to w sieci historię fuckupu systemu live spowodowanego przez Elastic, właśnie z powodów opisywanych wcześniej. Awaria nastąpiła niecały miesiąc po napisaniu przeze mnie pierwszej wersji tekstu. Oczywiście te dwie sprawy związku ze sobą nie mają, ale ciśnie mi się na usta klasyczne "a nie mówiłem?"

Wyłączanie zgaduj-zgaduli

Zalecam wyłączenie automatycznego mappingu, za który odpowiada parametr w elasticsearch.yml:

"index.mapper.dynamic": false

Nie można jednak zagwarantować, że jest to w 100% skuteczne w każdej wersji Elastica, bo znany jest błąd: https://github.com/elastic/elasticsearch/issues/15381

Można także wyłączyć automatyczne tworzenie indeksu:

"action.auto_create_index": false

Ostrożnej zabawy!

Tak twierdziłem wiele lat temu i tak twierdzę teraz. Jira to system, który jest nieopłacalny w utrzymaniu (nie tylko w zakupie), bardzo skomplikowany i trudny w użyciu. Niby są pluginy, niby są opcje do skonfigurowania, ale i tak istotne rzeczy są albo niemożliwe (tickety wiszące po 10 lat), albo trzeba dłubać w bazie danych.

Niespójny interfejs, denne rozwiązania UI (edit in place i zapis onblur), powolność działania (Java, żre zasoby), nieczytelne maile z notyfikacjami i podatność na uszkodzenia sprawiają, że pracuje się z Jirą źle. Ma kiepską nakładkę Agile. Może do Scruma jeszcze jakoś się nadaje, ale dla Kanbana to jest tylko słabiutka tablica. No dobra - jest jeszcze wykres CFD (wow!). Z Kanbanem ma to niewiele wspólnego.

Najgorsze jest to, że ciągle ktoś jest angażowany do naprawiania, konfigurowania, korygowania właściwie podstaw, i ciągle próbuje się coś zrobić, ustawić, opierając się na micie "wszystko w Jirze da się zrobić". No i dupa, szanowni czytelnicy, właśnie że się nie da. Jeśli kiedykolwiek ten mit od kogokolwiek usłyszycie, wspomnijcie moje słowa. Przed zakupem i wdrożeniem sprawdźcie dokładnie, czy spełni wasze oczekiwania (będą mówić, że spełni - ale to handlowcy).

Używałem przez dłuższy czas mojego własnego softu, który oczywiście ma większe braki i którego nie mam kiedy skończyć na jakimś sensownym etapie, ale pracowało mi się o wiele lepiej. Może dlatego, że soft jest tworzony pod konkretny workflow i z rozwiązaniami customowymi, których niekiedy próżno szukać nawet w takich kobyłach jak Jira.

Zmiana nazwy klastra Cassandry może być nieciekawa w skutkach, ponieważ klaster dokonuje dodatkowej weryfikacji węzłów po zadeklarowanych w nich nazwach klastra, a zmieniając nazwę trzeba wykonać rolling restart każdego węzła i w tym czasie węzły będą zgłaszały błędy niespójności nazw (ergo - klaster będzie niekompletny). Operację trzeba przeprowadzić z zachowaniem należytej ostrożności.

Procedura dla każdego węzła :

 $ zmienić nazwę w `cassandra.conf`
 $ cqlsh
 $ > UPDATE system.local SET cluster_name = '<NOWA NAZWA KLASTRA>' where key='local';
 ^D
 $ nodetool flush
 $ sudo service cassandra restart

Dodatkowo w OpsCenter trzeba zrobić sobie rename w UI, bo OpsCenter wyświetla swego rodzaju alias.

Być może lepszą sekwencją będzie nawet wykonanie zmian nazw w column family system.local dla każdego node po zmianie wszystkich cassandra.yaml, i dopiero po tym zrobić flushe na każdym node i zrestartować usługi tak, aby nie było downtime.

Bo to jeden z droższych acz małych komputerków (lub jak kto woli - przenośnych telefonów stacjonarnych), naszpikowany duperelami po to, żeby zżerać baterię i napędzać rynek power banków oraz obudów z bekonu. Komputerek z systemem, który zadręcza na "dzień dobry" koniecznością podłączenia się do WIFI lub GSM bez aktywnej karty SIM tylko po to, abyś nie mógł odczytać MAC-a potrzebnego do whitelisty WIFI. System, który po upgrade przyspiesza wysysanie baterii i jeszcze bardziej napędza rynek power banków (i obudów, kiedy już zaczynasz nim ciskać o ziemię lub ściany). System, który wiesza się akurat przy wyłączaniu automatycznie włączanych usług inwigilacyjnych srajGlaude. Oraz w końcu sklep z milionem aplikacji bez możliwości zakupu. Oraz w końcu "intuicyjny" UX, który nakazuje mi się domyślać, że karta kredytowa == jakakolwiek karta płatnicza. Skąd ta popularność - nie rozumiem. Podoba się kobietom.

Aktualizacja 19.03.2017 - a jednak kupiłem

Niemal rok temu dałem szansę Nokii z Windows Phone. Przekonały mnie dobre opinie o wytrzymałości baterii, stabilności i płynności działania. Jak słuchawka sprawuje się w praktyce?

Wymagania

Uznałem, że telefon powinien oferować:

• prostotę użytkowania, szczególnie podczas rozmów, gdyż telefon służy do dzwonienia
• dostęp do internetu, głównie e-mail oraz WWW, Skype
• względnie długi czas działania na baterii
• płynność i stabilność działania

Rozmowy

Jakość rozmów jest bardzo wysoka, szczególnie gdy aktywny jest HD Voice. Tylko znajomi początkowo mówili, że mnie nie poznali po głosie. Żadnego zrywania połączeń, żadnego zawieszania się oprogramowania przy odbieraniu lub podczas rozmów. Długie konwersacje na słuchawkach - czysta przyjemność.

Jedyny defekt to przerywanie dłuższych rozmów policzkiem. Ekran dotykowy jest czuły, włącza się czasem podczas rozmów i niestety policzek sobie coś tam klika. Być może źle trzymam słuchawkę. Ale ponieważ dłuższe rozmowy prowadzę głównie na słuchawkach, to ten problem nie jest bardzo uporczywy.

Sieć i internet

WIFI i internet GSM generalnie działają dobrze. WIFI mam praktycznie stale włączone, bo nie wysysa baterii. GSM włączam okazjonalnie. Niestety od początku użytkowania, mimo kolejnych aktualizacji zdarza się, że sieć w Windowsie "zacina się". Albo nie działa GSM, albo nie funkcjonuje WIFI. Włączanie i wyłączanie usług nie odnosi skutku, a w przypadku WIFI - nie da się go wyłączyć (ciągle oczekuje na wyłączenie). Wygląda to niestety na problem OS-a lub drivera. Pomaga dopiero restart telefonu. Duży minus.

Z e-maliami nie ma problemu. Wbudowany klient obsługuje Gmail i inne konta IMAP. Synchronizacja kontaktów i kalendarza działa OOTB.

Przeglądanie WWW jest słabe. Dostępne są tylko przeglądarki z jedynie słusznym silnikiem - Trident. Internet Explorer jest kiepski, lubi się zacinać, jest niewygodny w obsłudze. Nie jest źle, ale jednak męczy. Opera na WP jest kiepska (wolna), a UC Browser wiesza się na potęgę. Alternatyw w praktyce brak.

Skype działa bez zarzutu.

Bateria

Przy moim stylu użytkowania wytrzymuje do około 3 dni. Gdy gadam więcej lub korzystam z internetu GSM - oczywiście znacznie krócej. Ekran telefonu jest duży, więc biorąc to pod uwagę jest na prawdę nieźle. Mam aktywną funkcję oszczędzania baterii przy poziomie <20%. Wydłuża to trochę czas oczekiwania, co bywa bardzo przydatne.

Płynność i stabilność

Oprogramowanie telefonu działa szybko. UI jest responsywne, nie ma przycięć. Telefonem operuje się komfortowo. Nawet jeśli część operacji jest przykryta pod animacjami (takie pojawiają się głosy), to wrażenie jest na prawdę bardzo dobre. A to chodzi, bo po prostu użytkownik nie irytuje się.

Przez cały okres użytkowania telefon chyba nigdy się nie zawiesił, albo wystąpiło to może raz. Zamulać mogą tylko otwarte (aktywne) aplikacje, ale kiedy idą w tło - oprogramowanie działa znowu normalnie. Aplikacje w tle są wstrzymywane.

Ergonomia i wygląd

Względnie duża cegła - niczym nie wyróżniający się klocek z aluminiowym i chyba solidnym wykończeniem. Parę razy zaliczył glebę (w etui) i nic się nie stało. Ekran duży, jasny, czytelny nawet w słońcu.

Interfejs Metro jest minimalistyczny, czytelny i intuicyjny. Kafelki są wygodne i nie potrzeba dziesięciu pulpitów. W ogóle nie czuję takiej potrzeby (latami na Androidzie miałem co najmniej dwa).

Klawiatura ekranowa jest wyśmienita, a szczególnie tryb swipe, Na prawdę swipe świetnie działa i pozwala szybko pisać bez większych pomyłek.

Pozostałe uwagi

App store jest względnie skromny. Jest sporo zamienników, ale wielu ważnych aplikacji nie ma. Korzystanie z aplikacji Googla jest przeciętne (nie ma oficjalnych portów, trzeba wybierać zamienniki). Jest też mniej specjalistycznego oprogramowania. Jeśli ktoś korzysta intensywnie z usług Google (szczególnie związanych z chmurą), to z Windows Phone będzie bardzo niezadowolony (ja nie korzystam).

Aparat fotograficzny dosyć dobry. Kamerką też da się coś zrobić. Nie jest to ekstraklasa, ale jakość wystarczająca do szybkiego uwiecznienia jakiejś chwili. Pokusiłem się nawet na zrobienie krótkiego filmu - tu jednak brakuje lepszego oprogramowania, które wyeliminuje automatykę.

Windows to Microsoft - uczucie niesmaku i podejrzeń co do jakości softu jest stale obecne. Rekompensuje to trochę logo Nokii i brak sytuacji denerwujących, które serwował mi dotychczas Android. Na plus warto odnotować koniec zabaw z Cyanogemod`ami - nie ma oczywiście takiej opcji, ale w praktyce nie ma takiej potrzeby. To oszczędza dużo czasu. Warto wspomnieć bardzo dobrze przygotowywane aktualizacje oprogramowania.

Kolejny minus za brak funkcji "Godziny ciszy". Przed WP 8.1 można było zainstalować dodatkową aplikację, ale w nowszych wersjach jest ona wbudowana w system. Niestety jest dostępna tylko tam, gdzie Cortana (czyli w PL - nie!). I tak oto ani nie ma możliwości skorzystania z wbudowanej funkcji, ani nie można zainstalować aplikacji zewnętrznej.

Cena w stosunku do możliwości i jakości - bardzo dobra.

Ocena ogólna

Czwórka, może czwórka z plusem. Kupiłbym ponownie? - raczej tak, choć zaczekam na nowe Nokie z innym OS-em lub wypróbuję iPhone ze względu na bogatszy AppStore. Zdecydowanie jest to produkt dla węższej grupy świadomych użytkowników, którzy potrzebują telefonu przede wszystkim do dzwonienia i zajęciu się w życiu czymś ciekawszym niż wgrywanie ROM-ów.