Elasticsearch, Lucene kütüphanesine dayalı bir arama motorudur. Özellikle full text search yani tam metin aramalarında kullanılabilecek en iyi alternatiftir. Elasticsearch, Java’da geliştirilir ve Apache Lisansı koşulları altında açık kaynak olarak yayınlanır.

Elasticsearch, hızlı ve büyük miktarlarda veriyi dizinleme, arama ve analiz etmek için kullanılır. Logları, belgeleri ve diğer yapılandırılmış ve yapılandırılmamış veriyi dizinleme, arama ve analiz etmek için kullanılabilir. Elasticsearch, Logstash (veri işleme borusu) ve Kibana (görselleştirme aracı) gibi diğer yazılımlarla birlikte kullanılır ve Elastic Stack (önceki adıyla ELK Stack) olarak adlandırılır.

Elasticsearch, arama ve analiz için güçlü bir araç olmasını sağlayan birçok özelliğe sahiptir, bunlar arasında:

• Dağıtık mimari: Elasticsearch, çoklu sunuculara yatay olarak ölçeklendirilebilir. Bu, büyük miktarlarda veriyi işlemeyi ve hızlı arama sonuçları vermeyi mümkün kılar.
• Tam metin arama: Elasticsearch, tam metin arama özelliğine sahiptir, yani belge gövdesinde veya metadatada bulunan kelimeleri arayabilir.
• Elasticsearch, kategori, tarih veya konum gibi çeşitli şekillerde veriyi gruplamaya ve özetlemeye izin verir.
• Gerçek zamanlı arama: Elasticsearch, yakın gerçek zamanlı olarak veriyi dizinleme ve arama için tasarlandığından, hızlı arama sonuçları gerektiren uygulamalar için uygundur.
• Esnek şema: Elasticsearch şema-özgürdür, yani verinizin yapısını önceden belirtmeniz gerekmez. Bu, farklı türdeki ve formatlardaki veriyi dizinleme ve arama konusunda kolaylık sağlar.

Ancak uzun yıllar boyunca elasticsearch yönetmiş birisi olarak dezavantajlarının da oldukça fazla olduğunu söyleyebilirim. Aslında bu dezavantajlar sizin kullanımınız ile alakalı. ElasticSearchten bir ilişkisel veri tabanı gibi davranmasını bekleyemezsiniz. Temelde bir indexleme mekanizması olduğunu da unutmamak lazım. Genelde şöyle bir yanlış görüyorum: “nasıl olsa hızlı, tüm verilerimi elasticsearch içerisine aktarayım ve oradan sorgulayayım” düşüncesinde olunuyor. Özellikle kritik diyebileceğimiz verilerin sadece elasticsearch içerisinde tutulmasını kesinlikle tasvip etmiyorum. Neticede ACID yapısını desteklemiyor ve transactional bir yapıda değil. Ancak hali hazırda kullandığınız bir ilişkisel veri tabanı yanında indeksleme mekanizması olarak kullanacaksanız çok doğru ve yerinde bir kullanım yapmış olursunuz ve dakikalarca süren raporlarınızı saniyeler içerisinde elde edebilirsiniz.

Nasıl çalıştığı konusunda çok fazla detaya girmeyi düşünmüyorum ama temelde tüm full-text search mekanizmaları benzer çalışır. İnsert edilen her bir kelime için bir pointer kullanılır ve keyword listesindeki bu kelime arandığında, aslında gerçek verinin içerisinde o pointer aranır.

Dağıtık bir mimaride çalışabilir, yani 10 sunucuyu bir elasticsearch kümesi yapabilir ve her birinin içerisinde aynı veriler olmasına gerek yoktur verileri dağıtır. Bu sunucuların iş ve kaynak yönetimini master sunucu yapar ve gelen her isteği data nodelara dağıtır. Data nodelar gelen isteğe uygun veriyi tarar ve buldukları sonuçları master’a gönderir. Master sonuçları toplayıp cevap olarak geri döner. Üstelik sorgunun master sunucuya yapılması da gerekmez. Herhangi bir data node’a sorgu atılabilirsiniz o sorgu tüm nodelara dağıtılır.

192.168.1.50 Master
192.168.1.51 DataNode1
192.168.1.52 DataNode2

Dersek eğer. Sorgumuzu datanode2 ye de atsak master’a da atsak datanode1 de bulunan veriler içerisinde arama yapmış oluruz. Hatta ben genelde sistemlerimde ayrıca bir node oluşturur ve cordinating node olarak bırakırım. Yani ne datanode ne masternode hiç bir görev vermem. İçerisinde veri tutmam (masterda olduğu gibi). Boş bir düğüm anlayacağınız. Tek görevi ise dışardan gelen sorgulara cevap vermektir.

Verileri nasıl depolar nerelerde depolar?

ElasticSearch içerisindeki veri tabanlarına index denir. Her index shard adı verilen veri parçalarından oluşur. Bunu Sql Serverda bulunan file group ve filelara benzetebilirsiniz. Ancak Tek bir fark ile bu shard adı verilen parçaların sayısı sonradan değiştirilememektedir. ElasticSearch her bir shardın maksimum 50GB olması gerektiğini tavsiye eder ama bunun belirli bir best practice’i yoktur döküman sayınıza veya veri boyutuna göre kendi tecrübelerinize göre karar vereceğiniz bir seçenektir. Aşağıda kendi tecrübelerime göre örnek bir cluster oluşturuyorum.

Elimde yoğun miktarda kitap özetlerinin yer aldığı bir veri tabanı olduğunu düşünüyorum. Bu veri tabanının boyutu 80GB olsun. Sürekli yoğun sorgular geliyor diyelim.

Kaynak sıkıntım yoksa eğer 5 adet sanal sunucu yada güçlü bir fiziksel sunucu üzerinde docker container’ı oluştururum.

Çok yüksek özelliklere ihtiyacım yok. 16GB ram 4  sanal processor benim için yeterli olur.

1 masternode 4 adet datanode oluştururum.

Oluşturacağım indexte 8 shard 2 replika yaparım. Parent-Child tarzında bir mapping hazırlarım. Kitap yazarlarını parent, kitap ile alakalı diğer bilgileri child yaparım. Kitap özeti fieldına turkish analayzer eklerim. Tabii ki aynı işi tek node üzerinde de yapabilirsiniz veya daha fazla node ile de yapabilirsiniz.

İlerleyen zamanlarda elasticsearch indeks oluşturma, mapping ayarlamaları gibi bir çok konuda daha makale yazmayı düşünüyoruz. Merak ettiğiniz konular olursa yorumlarda bize bildirebilirsiniz.