Ajánljatok Solr/Elastic Search tanfolyamot

Közösségi kerekasztal

Sziasztok!

 

Kollégáimat szeretném megismertetni a szabadszöveges keresés örömeivel. Tudtok ajánlani jó képzést a témában? Árban 300-500e +áfa sávba be kéne férjen. On-site tantermi preferált, de online is lehet viszont dedikált oktatóval mindenképpen. (Mostanában volt konzultációs tréning aminek az a lényege, hogy mindenki videózott de más-más témában és aztán lehetett kérdezni. Ez a visszajelzések alapján annyira nem volt eredményes.)

 

Köszi!

( golgota | 2024. 02. 26., h – 14:24 )

Szerkesztve: 2024. 02. 26., h – 14:26

Oszinte leszek. En projekten tanultam meg 2014-ben es azota astam bele magam. Ezt javaslom. Iszonyat jo a dokisja. A legjobb amit valaha olvastam. Szoval at kell ragnia magat az embernek rajta.

Amugy az ElasticSearch Inc.-nek vannak trainingjei, arat mondjuk nem tudok.

Solr meg szinten a doksibol. Nem tudom van e hivatalos trening belole. Annyi hogy Solr eseten kicsit bonyolultabb a helyzet a zookeeper es tarsai miatt.(query, aggregation, stb), vagy hogy hogyan adminisztralj egy clustert (sharding, data mapping, data/index management). Mert nem ugyanaz. En azt mondanam mind a ketto kulon szakma. :D

Vagy Udemy, Coursera

( carlcolt | 2024. 02. 26., h – 14:58 )

Szerkesztve: 2024. 02. 26., h – 14:59

Felig off, de tud valaki csak egyetlen olyan use case-t mondani (pl. hanymilliard sor, milyen tipusu es gyakorisagu query-k, stb.), ahol a solr/elastic search valamit olyan hatekonyan old meg, hogy annak nincs SQL nyelvet is ismero (!= relacios adatbazisos, "ugymond NoSQL" db-ket is lehet nehol SQL-lel is query-zni ma mar) alternativaja?

Úgy értettem, hogy ha csak az benne a trúváj, hogy geo spatial adatot lehet tárolni és lekérdezni, akkor olyan van sql földén is elég régen. Mivel nem értek hozzá (csak érintőlegesen szoktam találkozni ezzel a világgal), ezért nem tudom eldönteni, hogy ezek szarabbak-e valamiben, mint amit linkeltél, vagy csak neked nem volt meg ez a feature a másik oldalról.

Kepzeld el, hogy az adatod nem rendelkezik schema-val. Igen tudom, hogy akkor basszuk bele egy JSON mezobe az RDBMS-be. Azt is lehet

Mi peldaul 37 TB-os clustert uzemeltettunk az egyik cegnel, ahol nagyjabol 150K+ dokumentum ment bele masodpercenkent es mondjuk 50K+ lekerdezes volt (jo vannak sajat query cache implementacionk is, szoval ezert csak ennyi). Igazabol a shard mereteket volt nehez eltalalni. Hogy stabilla tegyuk az egeszet. 

Na mikor kieserr egy-ket node (ami elofordult viszonylag gyakran), akkor szepen kavet zsurcsolgetve mosolyogva beallitottunk helyettuk node-okat mintha mi sem tortent volna. Menet kozben meg is szoktuk updatelni azt a majd 100 node-ot minden gond es leallas nelkul, mert az ES szepen kezeli.

Ezen felul voltak warm es cold node-jaink, ahol automatikusan rontottuk a granuralitast (a masodperces adatokat egy het utan percesse alakitva taroljuk ott, harom havonta napra rontjuk, stb stb)

Van hogy neha szarul kuldtek az adatot es a mapping nem megfelelo volt, akkor hozza kellet nyulni (ment egy reprocess az eppen aktualis index shardjara), de amugy szepen tette/teszi a dolgat az egesz hobelebanc.

Amugy ES-nek is van SQl query nyelve, meg meg piped is a JSON/KQL/EQL-en es a Lucene-en kivul.

Hat a semamentesseget nem tartom nagy gyakorlati elonynek (sot).

Viszont a mosolyogva node-inditgatas meggyozo, azt bevallom. A 150k write/sec is egy jo kezzel foghato metrika.

De ezek is olyan metrikak, ahol kivancsi lennek, hogy van-e ennel jobban performalo NoSQL.

Mert en eddig barmilyen ES-sel talalkoztam, tetulassu volt.

Fura lenne, de hiszek neked. Milyen az a barmilyen ES? Amugy nagyon sokat szamit a mapping, illetve hogy milyen shard meretet valasztasz a replikacional, hogy egy index tobb shardra van e szetszedve vagy egy shard csak, meg rengeteg fine-tun lehetoseg van. Millio kis szir szar cache-t lehet allitgatni a useage-pattern szrint.

Aztan lehet kulon ingest nodeokat csinalni az irasokhoz (shard routing), meg regebben voltak coordinacios node-ok is, stb stb.

En eleg sok noSQL-el dolgotam mar, de az ES mindent vitt. Plane hogy a beleben nem csak reverse index van, hanem megy a columnar es egyeb tipusu store-ok is, attol fuggoen milyen tipusu az adat. Eegebben pl a mettikus adatok tarolaa elegge lassu volt a reverse index miatt, de ma mar van columnar backend benne. 

A 6 es 8-as verziok kozott meg valami brutalis melot csinaltak es olyan optimalizalt az egesz hogy beszaras. Ja es atom stabil. Meg ongyogyito. Ezek ahol en dolgozom es amilyen projekteken nagyon fontos szempont. Mondjuk rengeteg PostgreSQL is szolgalatban van de azokhoz sajna nincs kozom igy nem tudok nyilatkozni ott mi a stajsz :D (pedig erdekelne) 

Mondjuk most kezdtunk Clickhouse-ozni, na az vagy 5-10szer gyrosabb meg az ES-nel is bizonyos esetekben. Csak nem olyan jo a managementje es az ongyogyito kepessege (agyrem a replicatedmergetree tablakk kezelese :D). 

Hat a semamentesseget nem tartom nagy gyakorlati elonynek (sot).

2012-ben neztunk ra eloszor (talan a MongoDB-re) noSQL adatbazisra az akkori fonokommel, azota gondolkozom ezen, hogy jo-e. Meg nem dontottem el. :)

A mostani projektemen is van egy tetu nagy adathalmaz, ami elvileg semamentes, es be van szorva egy collectionbe, de a gyakorlatban szabad szemmel ranezve szet tudnam osztani 5-6 kulonbozo sema-archetipusra a teljes halmazt, egy-ket kiveteles elterest nem szamitva, amit azert szinten meg lehetne oldani mashogy, pl. metaadatokkal.

Szerintem valahol az adatfeldolgozas soran elobb-utobb ugyis valamilyen semara huzod a rekordot, csak itt ez nem az adatbazisban tortenik, hanem valahol fentebb.

Ma mar a PostgreSQL eleg sok mindent nyujt, ha nem akarsz noSQL-t kezelni hanem inkabb a noSQL datat akarod kezelni benne. Szepen mehet bele a columnar store, a inverted indexing a documentekre meg minden. Meg az elosztast es sharding-ot es replikaciot is meg lehet benne oldani.

Mi peldaul gondolkudtunk es gondolkodunk is abban, hogy egyes dolgokat "visszamigraljunk" postgresql-be. Majd meglatjuk. A legnagyobb baj vele, hogy nem olyan konnyen self-healingel mint az ES. Nehezkesebb uzemeltetni, ha ugyanazt szeretned elerni vele.

Amugy az utolso megjegyzeseddel nem ertek annyira egyet, ha a seman ugyanazt ertjuk. De ez egy izgalmas beszelgetes lehetne mashol. :D

  • search aggregation  (ezt probaltam postgresql-ben es mssql-ben is replikalni... eleg nagy szopas volt.. persze nem vagyok sql guru)
  • vector search
  • ingest pipelines

 

Tulajdonkeppen szinten mindent meg lehet oldani mas technologiaval is, csak eleg macerasan. A legnagyobb elony szerintem ha nem csak elasticsearch-t nezed magaban, hanem a full elastic stack-et. Kibana-t nalunk a business nagyon szereti, mindenfele szines szagos dashboardokat kernek benne logokra, meg statisztikakra. (Ebben az esetben viszont nagyon jol jon hogy Logstash-al szinten mindenhonnan tudsz adatot integralni elastic-ba)

Ami szinetn konnyen megoldott az a backupok kezelese a clustering es a data lifecycle management.

 

Ami a traininget illeti: https://www.elastic.co/events van egy csomo ingyenes webinarium. Az elastic certified engineer tanfolyam az szerintem nagyon jo. Nekem a ceg finanszirozta egy ElasticOn conferenciaval egybekotve. Igaz egy csomo mindennel mar tisztaba  voltam mire odakerultem, de igy is tudtak ujat mondani. A legnagyobb elony viszont az volt, hogy vegig gyakorlatias volt az ido nagyreszet tenyleg lab-ban feladatokon keresztul tanitottak.  
Amit azonban kiemelnek, hogy 2 nap nem volt eleg arra, hogy mindent megtanulj elastisearch-rol.  A legtobbet ugyis akkor fogsz tanulni, ha konkret problemara keresel majd megoldast es kozben nyalazod at a dokumentaciot.

Support Slackware: https://paypal.me/volkerdi