- Elasticsearch bir search ve analitic enginedir.
- Kullanımı ve ölçeklendirmesi kolaydır.
Use Cases
- Search işlemi gerektiren uygulamalarda sıklıkla kullanılır.
- Auto-complition web sitelerinde gördüğümüz otomatik tamamlamada kullanılır.
- Sistem loglarını, metriclerini depolayıp analiz etmede kullanılır.
- Elasticsearch ve Kibananın birlikte bize sunduğu Machine learning modelleriyle veriyi gerçek zamanlı analiz etmede kullanılır.
- Büyük ölçekli datalarda analiz işlemlerinde başarılıdır. Gerçekten terabytlarca datayı çok kolay bir şekilde indexleyip sorgulama performasnı yüksek şekilde hizmet veri
Elastic search faydaları
- Büyük bir veri yığını içerisinde hızlı search edebilme.
- Yazım yanlışı: biiskilet kelimesini arattığımızı düşünürsek bisiklet olduğunu anlayıp eşleştirebilir.
- Eş anlamlılar: Arattığımız cümlede "taşıt" kelimesi geçiyorsa "vasıta" kelimesi geçen sonuçları da bize getirebilir.
- Türetme ve Öneri:Kullanıcı search için kelime girerken daha o sırada onun populer searchleri görebilmesini sağlayabiliriz, suggestionlarla en çok arananlar popular sonuçlar ya da eşanlamlıları da search edebiliriz.
- İstatistik: Elimizdeki search verilerinden istatistiksel datalar da çıkarabiliriz.
Elasticserachü direkt olarak bir NoSQL veritabanı olarak görmek yanlıştır. Elasticsearchün geliştirilme amacı bir search ve analitic engine olarak kullanmaktır. Yani elasticsearchü docüment based bir veritabanı olarak kullanmamalıyız. Böyle bir ihtiyacımız var ise MongoDBye yönelmeliyiz.
Elastic Stack
Elasticsearch tarafından geliştirilen logstash, kibana, x-pack, beats gibi ürünleride kapsayan yapıya verilen isimdir. Bu ürünler genelde birlikte kullanılır.
Kibana: Elasticsearchün yönetimsel işlevlerini gerçekleştirebildiğimiz veri görselleştirme ile alakalı özellikleri kullanabildiğimiz ve cluster yönetimiyle alakalı işlerde kullandığımız yönetimsel web arayüzüdür.
Logstash: Uygulama loglarının elasticserache gönderilmesini sağlar. input,printer ve output olmak üzere üç tane ana yapısı vardır. Kaynaktaki veriyi input aşamasında alıp veriyi filtreden geçirir ve output alanında verdiğimiz hedefe datanın gönderilmesinden sorumludur.
X-pack: Elastic ve Kibanaya extra özellik kazandıran extension gibi düşünülebilir. Security, LDAP entegrasyonu, User Role tanımları, Elastic monitoring, Alerting gibi birçok özelliği x-pack aracılığıyla kullanıyoruz.
Beats: Datanın toplanmasını sağlar.Collect data. Filebeat en yaygın olarak kullanılanıdır. Genelde logstash ile çalışırlar. Toplanan data logstash aracılığıyla elasticsearche gönderilir.
Elastic’in FileBeat adlı ürünü, container loglarını yakalayabilme kapasitesine sahip bir ürün. Ayrıca yakaladığı logları diğer Elastic ürünlerine de direkt olarak iletebiliyor (Logstash’ iletmek ya da direkt olarak Elasticsearch’e yazmak gibi). Kibana ile de bu logları görselleştirebiliyorsanız, container olarak koşan her uygulama için ayrı bir log yapısı kurmaya gerek kalmadan bütün bu operasyonu tek bir merkezden yönetebilirsiniz.
Arthitecture
Node: Elasticsearch instance'larına verilen isimdir. Her node datanın bir parçasını depolar. Bu sayede distributed ve scaleable bir ortam sunar. Node kavramı direkt olarak server kavramına denk gelmez. Çünkü bir adet server üzerinde birden çok elacticsearch instancesi farklı portlarda çalışabilir. Fakat bu production ortamlarında önerilen bir yöntem değildir. Her nodun farklı bir serverlarda çalıştırılması önerilmektedir.
Cluster: Bir veya daha çok elasticsearch node'unun iletişim halinde çalışmasıyla ortaya çıkan yapıdır. Her node bir clustera aittir. Single node çalışan bir elasticsearchte bile bir Cluster kavramı vardır. Bir node başlatıldığında otomatik olarak configurasyonda tanımlanmış clustera dahil olur.
Document: Elasticsearchte datalar documentler halinde tutulur.Documentler RDBMS'te row alanına denk gelmektedir. Documentlerde içerisinde field denilen ve datayı tanımlayan alanları barındırır. Fieldlarda RDMBSteki kolonlara denk gelmektedir.
Index: Datalar elastic searchte document olarak depolanır. Her bir document bir index içerisinde depolanır. İndexlerde benzer yapıda olan document objelerinin oluşturduğu gruptur. İndexler bir veya daha fazla sharddan meydana gelen logical yapılardır. Birden çok node üzerine dağıtılırlar.
Shard:
Shardingin ne olduğuna girmeden önce, neden shardinge ihtiyacımız olduğu üzerine biraz konuşalım. Çok fazla dökümana sahip olan bir indexiniz olduğunu ve totalde 1 terabyte boyutu olduğunu düşünelim. Ancak elinizde iki adet makinanız yani nodeunuz var. Her biri de 512 GB bilgi store edebiliyor. Açıkça hiç bir nodeunuz dökümanı komple taşıyacak kadar kapsamlı değil. Bu durumda dataları bölmemiz gerekecektir. Ve burada sharding konsepti imdadımıza yetişir. Sharding indexleri adı shard olan daha küçük parçalara böler. Bir veri bütününün yatayda bölümlenmiş halidir. Yani her shard indexin bir subsetini taşır ve kendi içinde bağımsızdır. Yani shardı bağımsız index olarak düşünebiliriz.
Sharlar büyük ölçekli dataların dağıtık mimaride depolanmasını sağlayan yapılardır. İndex datası shard adı verilen daha küçük parçalara bölünerek depolanır. Bir indexsin shardları clusterda birden çok node üzerinde dağıtılır. Primary ve replica olmak üzere iki tip shard vardır. Bir indexte yer alan her document bir primary sharda ait olmak zorundadır. Replica shardlar ise primary shardların kopyasıdır. Replica shardlar sayesinde diğer veritabanlarında olduğu gibi datanın bir kesinti yada hata durumda kaybolmamasını sağlar. Bunun dışında replica shadrlar üzerinde readonly işlemler yapılarak okuma işlemi yapılır ve performans arttırılır. Replicalar esasen bir kaç ana amaca hizmet eder. İlki high avalibilityi sağlayabilmektir. Yani node ya da shard fail olduğunda bu shardın eksikliğini replikasyon ile tamamlayabiliriz. Diğer bir amaç ise search performansını artırmaktır. Çünkü searchler replika serverlarda da paralelde çalıştırılabilir. Yani aslında replikalarda cluster’in search gücünün bir parçasıdır. Bir diğeri de load balancingi sağlayabilmesidir.
Dökümanları Shardlara Dağıtmak – Routing mekanizması
Peki elastik search bu shard yapısını nasıl yönetir. Dökümanın hangi shardda olacağını, dökümanların shardlara eşit olarak dağıtılmasını vs random yapmayacağı aşikar. Döküman boyutları eşit olmalı. Bu sürece routing denir ve routing süreci defaultta otomatik işler. Çoğu kullanıcı da bunu manuel yönetmek istemez.
Shard sayısını değiştirirsek, routing formülünü çalıştırmanın sonucu dökümanlar için değişir. Beş shard varken bir belgenin Shard A’da depolandığı bir örneği düşünün, çünkü o sırada routing formülünün sonucu buydu. Shard sayısını değiştirebildiğimizi ve onu yedi olarak değiştirdiğimizi varsayalım. Dökümanı id’ye göre aramaya çalışırsak, routing formülünün sonucu farklı olabilir. Şimdi, document aslında Shard A’da saklansa bile formül Shard B’ye yönlendirilebilir. Bu, document hiçbir zaman bulunamayacağı ve gerçekten bazı baş ağrılarına neden olacağı anlamına gelir. Bu nedenle, bir index oluşturulduktan sonra shard sayısı değiştirilemez, bu nedenle yeni bir index oluşturmanız ve dökümanları ona taşımanız gerekir
Type: Benzer documentleri tanımlar.
Mapping: Indexlenecek doumentte yer alan fieldların yapısını belirler. Mapping işlemi otomatik yapılabilceği gibi manuelde yapılabilir.
Çalışma Prensibi
Aşağıdaki görselde node-1, node-2 ve node-3 nodelarının birleşimiyle Elastic_Prod_Cluster1 clusteri oluşturulmuştur.Toplamda index A, index B ve index C olmak üzere üç adet indeximiz bulunmaktadır. Her bir indexte üç adet sharda bölünmüştür. Her shardında bir adet replicası bulunmaktadır. index A için incelersek P1, P3 ve P3 index A için oluşturulmuş shardlardır. R1, R2 ve R3 te bu shardların replicalarıdır.
Bir shardın primarysi ve replicası aynı node üzerinde olamaz. Yani P1 ve bunun shardı olan R1 aynı node üzerinde olmaz. Görsele bakarsak P1 node-1 üzerindeyken R1 node-3 üzerindedir.Diyelimki node-1 de bir arıza çıktı. Böyle bir durumda node-3 üzerinde bulunan R1 replica shardı artık primary olacak ve artık read dışında write işlemide yapılabilecek. Aksi durumda eğer P1 ve R1 node-1 üzerinde olsaydı ve herhangi bir nedenle node-1e erişim sağlanamasaydı shard ve replica aynı anda kaybolmuş olcaktı. index A p1,p2 ve p3 shardlarından oluştuğu için index A nın p1 shardında bulunan dataları kaybetmiş olacaktık.
1 shardımız var ve 5 ayrı replikasını oluşturduk. Bu 5 ayrı replika nasıl orjinal sharda paralel update olacak? Yani aslında sistem nasıl çalışıyor?
Elastic search primary backup adında bir modeli data replikasyonu için kullanır. Yani replika grubunun primary shardı index operasyonları için entry point görevi görür. Yani biraz daha türkçeleştirirsek insert update delete gibi tüm operasyonlar primary sharda gider. Primary shard operasyonların validationu ve herşeyin doğru olduğunundan emin olmakla sorumludur. Bu görev, object beklenen bir alana number yollamaya çalışmak gibi her requestin yapısal olarak doğruluğunu denetleme gibi işleri de içerir. Operasyon primary shard tarafından kabul edildiğinde yine primary shard tarafından çalıştırılır. Operasyon tamamlandığında, aynı operasyon her replikaya yollanır. Eğer birden fazla replika varsa bu replikalar üzerinde paralel çalıştırılır. Yani güncel verinin snapshotı yerine operasyon elden ele taşınır. Bu operasyon tüm replikalarda doğru bir şekilde çalıştığında ve replikalar primary sharda response döndüğünde, primary shard da clienta operasyonun tamamlandığına dair response döner.
Elasticsearchün Sorgulamadaki Hızı
Elasticsearch veriyi indexlerken inverted index denilen bir indexleme mekanizması kullanır. Bu sayede çok hızlı bir şekilde text search işlemleri gerçekleştirilir.
Yukarıdaki görseli incelersek inverted indexler document içerisinde yer alan terimlerin hangi documentle ilişkisi olduğunu tutan yapılardır. örneğin yukarıdaki gibi she likes winter ve Wheather is too cold in winter olmak üzere iki adet documentimiz olsun. Bu documentler çeşitli filtrelerden geçirilerek termlere ayrılacaktır. Daha sonra termler hangi dökümanda hangi sırada ise ona göre inverted indexe kaydedilecektir. Termler tabloya sıralı bir şekilde kaydedilmektedir. Büyük küçük harf duyarlı olduğu için yukarıdaki tabloda ona göre sıralanmıştır.
örneğin
She termü 1. documentin 1. sırasındadır. Doc_Id 1 ve inverted Index 1,1
winter termü hem 1. documentte hemde 2. documentte yer almaktadır. Doc_ID 1,2 ve inverted indexi
{1,3} Yani 1. documenti 3. kelimesi winterdır. {2,6) Yani 2.documentin 6. kelimesi winterdır.
Elastic Search Scaling
Elasticsearchin en önemli ve güzel özelliklerinden biri de scale out bir çözüm olmasıdır. Günden güne çok büyük verilerle uğraştığımız için scaling önemli bir faktör çünkü kimse o milyonlar boyutunda verileri tek bir makinada yani tek bir elasticsearch nodeunda karşılamak istemez.
Elasticsearch Clustera Node Ekleme
- Clustera node eklemek search ve indexing performansını artırır çünkü queryler paralelde hem shardlar hem de replika shardlar tarafından çalıştırılabilir. (Performance) ;
Bu kısmı biraz daha açarsak elinizde 900.000 documentlik bir elasticsearch nodeu olduğunu varsayalım. Bu tek node üzerinde bir request gönderdiğiniz zaman 900.000 adet döküman search edilecektir. Ancak eğer 3 node’unuz varsa 900.000 document bu nodelara 300k 300k 300k olarak dağılacaktır. Attığınız search requesti de paralelde 300k lık bir bütün içerisinde search yapacaktır. - Bir query üzerinden out of memory sorunu yaşıyorsa bu da node eklenerek önlenebilir.
Bu şekilde datayı scale etmek bir bütün olarak cluster’a daha fazla memory eklemek anlamına da gelir yani çok fazla vakit alan veya out of memory memory veren intensive searchler ve aggregationlar için çözüm daha fazla node eklemek olabilir. - Replication konsepti ile herhangi bir sebepten bir node’ın çökmesinin veri kaybına yol açması önlenir. (Avalibilty, Fault tolerance system)
Normal şartlarda elastic search clusterimiza eklediğimiz her yeni node için elasticsearch otomatik olarak shardları eşit dengeleme eğilimine girer. Eğer ki replika ayarlarınız da yapılıysa ki default olarak yapılı gelir, elasticsearch otomatik olarak replikaları da dağıtır. Böylece herhangi bir sebepten sizin primary shardınızın bulunduğu node’unuz çökerse, client tarafında hiç bir sıkıntı yaşanmadan replica shard üzerinden veriye erişim sağlayabilirsiniz.
Node Discovery
Clusterımıza yeni bir node daha ekledik. Peki ama eski node ile yeni node nasıl tanışacak yani birbirlerini nasıl bulacaklar . Aslında sadece Elasticesearch’ün değil tüm dağıtık sistemlerin bir konusu olan, clustera bir node katıldığında bu node’un nasıl discover olacağı ve eski nodelarla iletişim kuracağıdır. Elasticsearch’ün bunun için multicast ve unicast olarak adlandırılan iki farklı yöntemi vardır. İki yöntemi beraber de kullanabildiği gibi, default olarak multicast yöntemini kullanır.
- multicast : Multicast networkteki diğer tüm nodelara, “benimle aynı clusterda olan var mı?” diye ping gönderip, response almasına dayanır. Aynı networkde çalışan çok sık IP eklenip çıkarılan esnek sistemlerde kullanışlı bir yöntemdir.
- unicast: Unicast discovery elasticsearche bağlanmak ve cluster hakkında daha fazla bilgi sahibi olabilmek için host list’i kullanır. Bu IP adreslerinin çok sık değişmeyeceği production ortamları için idealdir. Örneğin elasticsearch.yml içerisinde discovery.zen.ping.unicast.hosts : [“10.0.0.3”, “10.0.0.4:9300”,”10.0.0.5[9300-9400]] gibi bir listemiz olabilir.
Master Node Election
Elasticsearchümüz ayakta, nodelar birbirini buldu tanıştı. Şimdi sırada ne var? Master nodeun seçimi Elasticsearch clusterında nodelar birbiriyle iletişim kurduğunda ikinci aşama olarak kimin master node olacağı konusunda uzlaşırlar. Peki master node neden var? nedir? ne iş yapar?. Master node ise cluster’in statetinden, shardlarının stateinden, indexten yani genel anlamda slave nodelardan sorumlu olan nodedur. Eğer clusterınız tek nodedan oluşuyorsa bu node kendi kendini master node olarak seçer.
Master node belirlendikten sonra, ilk icraatı olarak tüm clustera ping atarak clusterin durumunu alive olup olmadığını belirlemeye calismaktır :). Bu duruma da fault detetion denir. Peki bir diğer klasik soru, madem master node diğer nodelar üzerinde yönetici rolune sahip, master node down olursa ne olur. Aslında elastic search’e göre tüm nodelar eğer ki settinglerindeki node.master’ı false’a set etmezseniz master eligible yani master çöktüğünde yerine geçebilecek node’tur.
Clusterdan Node Silme
Clusterımızı oluşturduk. Nodelarımızı ekledik. Bu nodelar birbirini tanıdı. Masterlarını seçti vs vs. Peki ya clusterdan bir node inerse yahut sen bir nodeı kapatırsan ne olur?. İnen shardın replikaları otomatik olarak primary sharda döner. Bu elastic searchin yapacağı ilk şeydir. Çünkü indexin ilk olarak primary shardlara gider. Yani elasticsearch herhangi bir replicayı seçerek bunu primary sharda çevirebilir. Daha sonra elasticsearch kalan nodelar arasında replikalarını oluşturup dağıtır
Elastic Search Kullanım Örneği
Mysql ile birlik elastic searchün full text search özelliği kullanılacaktır.
Bir kayıt yukarıdaki gibi save edilip veritabanına kaydediliyorken aynı zamanda elastic searchede kaydedilmesini sağlayacağız.
Paginationı, filter ve search özellikleriyle beraber tüm fieldlarda search yaparak pagination işlemini elastic searchd üzerinde yapacağız. MySql bizim persistence veritabanımız olacak ve onun üzerinde sadece save,update ve getById işlemleri yapılabilecek. Elastic search üzerinde ise sadece full-text search yapacağız. Burada diyelimki elastic search insatncemiz down oldu. ozaman bizim MySql persistence dbsinden dataları tekrar elastic search üzerinde indexleyecek bir yapı kurmamız gerekir.
Hiç yorum yok:
Yorum Gönder