Elasticsearch’ün Yapısı
Bu yazıda elasticsearch kavram ve konseptleri üzerinde duracağım. Elasticsearch için kullanılan kavramları logical ve physcial layout olarak 2ye ayıraibiliriz.
Logical layout : Elastic search uygulamasındaki document, type ve index kavramıdır. Aslında search applicationunun elastic searche dair bildiği kısımlardır.
1.Document
Elasticsearch document oriented bir search enginedır. Yani indexlediğiniz ve aradığınız datanın en küçük birimi documenttir. Relational database ile karşılaştırdığınızda documentlar rowlara karşılık gelir. Ancak rowlardan farklı olarak documentlerin kendileirne özgü özellikleri vardır.
- Self-contained’tırlar. Her document hem fieldi hem de propertyi kendi içerisinde bulunduran jsonlardır.
- Hiyerarşiklerdir. Bir documentin içerisinde başka bir document olabilir.
- Esnek bir yapıya sahiplerdir. Sıkı sıkıya bağlı oldukları bir şema yoktur. Bir document’da olan bir property diğer documentte olmayabilir. Elasticsearch arkada fieldları ve typearını ve diğer settingleri tutan bir mapping tutar. Bu her indexe özeldir. Bu yüzden bazen typeların mapping olarak adlandırıldığını görebilirisniz.
2. Types
Type’ı documanlar için logical bir konteyner olarak düşünülebiliriz. Relational databaselerdeki tablo gibi de düşünebiliriz. Herbir type’taki alanların tanımı mapping olarak adlandırılır.
Burada akla gelmesi gereken ilk soru. Elasticsearch schema-free bir yapıda iken neden her doküman bir type’a ait ve her type shcema gibi bir mapping içerir? olabilir. Elasticsearch schema-free’dir çünkü hiç bir şemaya sıkı sıkıya uymak durumunda değil ve tüm alanları içermek zorunda değildir.Üstüne üstlük documenetlar schemada olmayan bir alan da içerebilirler. Mapping ise o ana kadar indexlenmiş datalardaki en geniş property kapsamını tanımlar ve yeni bir alan geldiğinde elasticsearch otomatik olarak yeni alanı mappinge ekler. Bunu yaparken kendisi alanın tipini belirleyip daha doğrusu tahmin edip o şekilde ekler. Örneğin, değer 7 ise bunu long olarak varsayar. Ancak bu bazı durumlarda sıkıntı çıkarır. Aslında alan string ise ve ilerleyen zamanda “hello world” eklemeye kalkarsanız fail olur. Bu sebeple productiondaki en safe yol mappingi indexlemeden önce belirlemek olacaktır.
3. Indices
Indexler mapping typelar için containerlardır. Relational databasedeki database konseptine benzetilebilir. Her index diskte file setleri olarak store edilir. Her aynı database gibi index kendine özgü ayarlara sahiptir.
Örneğin refresh_interval yani yeni indexlenen dökümanları searche hazır hale getirirme aralığı indexe özgü bir ayardır. Bu reflesh operasyonu performans açısından oldukça maliyetlidir. Bu da neden her döküman eklendiğinde değil de interval olarak yapılmadığını gçsterir. Yani aslında elastic search real time değil near-real-time bir yapıdadır. Bunun yanında Index specific settinge bir diğer örnek de shard sayısıdır ve index yaratıldıktan sonra bir daha değiştirilemez.
4. Alias
Alias aslında tam olarak adından da anlaşılacağı üzere indexlere verilebilen takma isimdir. Bir alias bir ya da daha çok index için kullanılabilen bir pointer gibidir. Clusterin ölçeklenmesi ve yönetilmesi sırasında çok kullanışlıdır. Aliasın lifescopeu cluster statedir. Master node tarafından yönetilir. Overheadi düşüktür. Aliaslar reindexing durumunda çok fazla esneklik sağlamaktadırlar. Örneğin, tek bir primary shardlı bir indexiniz olduğunu varsayalım ve sonradan indexteki kapasiteyi arttırmak istiyoruz. Eğer alias kullanıyorsak, tek yapmamız gereken aliası yeni yaratılan indexe de pointlemektir.
Physical Layout : Elasticsearchün donanımsal yapıdaki kavramlarının ele alındığı kısımdır. Aslında elasticsearchü kullanan bir client bu kısma dair herhangi bir şey bilmez.
1. Elasticsearch Node
Dağıtık yapılarda node bir makina anlamına gelir. 5 makinanız varsa 5 node’unuz var diyebilirsiniz. Elasticsearch için düşündüğümüzde de içerisinde elasticsearch kurulu olan her makina bizim için elasticsearch node’dur. Bir bilgisayara elasticsearch ayağa kaldırırsınız, bir nodeunuz olur. Aynı küme içerisinde başka bir bilgisayar içinde bunu yaparsanız 2. bir elasticsearch node’unuz olur. Hatta aynı serverda yani aynı makinada birden fazla elasticsearch ayağa kaldırırsanız yine birden fazla nodeunuz olur.
2. Elasticsearch Clusterı
Nodeler birbirleriyle haberleşebilir durumda aynı kümedeyse bu kümeye de cluster deriz.
Elasticsearch için cluster ve node kavramını biraz daha somutlaştırmak adına bir örnek üzerinden gidelim. Diyelim ki elinizde 900.000 adet documenttan oluşan bir veri var. Bu verileri yatayda 300 K, 300 K, 300 K olarak bölebilir ve böldüğünüz her bir veriyi farklı bir bilgisayardaki elasticsearche atabilirsiniz. Bu durumda 3 adet elasticsearch nodeunuz olmuş olur. Bu nodelar da birbirleriyle haberleşibilir durumda ise 3 nodeluk bir elasticsearch clusterınız olmuş olur.
Peki elasticsearchün bu distributed yapısı bize ne avantaj sağlar?
- İş yükünü birden fazla server’a dağıtacağımız için ciddi anlamda bir performans sağlar.
- Shard ve Replica yapısıyla herhangi bir sistem çökmesi durumunda fault tolerance bir sistem, reliability ve Availibilty sağlar.
- Tabi bu faydalarının yanında dikkatlı olmakta fayda var çünkü eğer ki nodelarınız yeterince hızlı iletişime girmiyorsa SPLIT BRAIN olabilir.
3. Shard
Sharding aslında bir data partitioning yönteminidir. Datanızı yatayda parçaladığınızda, her bir parçayı shard olarak adlandırabiliriz. Yine örnek üzerinden gitmek gerekise elasticsearch üzerinde 900Klık bir datanız var ise bu dataları 300K 300K 300K olarak yatayda 3 parçaya böldüğünüzde 3 shardınız var demektir. Bu shardları da farklı nodelara dağıtıp yukarıda sağdığımız faydaları elde edebilirsiniz.
Elasticsearch index vs Lucene idex
Elastic sarchte diğer bir karıştırılan kavram da Elasticsearch index ile lucene indextir. Elasticsearch indexi yatayda bölümlenir, buna da shard denir. Her bir shard da bir lucene indextir. Yani elasticsearch index birden fazla lucene indexten oluşur. Lucene index de aslında interved intexdir. bu yüzden lucene index orjinal dökümanın yanında TF , IDF gibi ek bilgiler de tutar.
Bir Document Indexlendiğinde Ne Olur?
Elasticsearche attığınız bir dokumanın aranabilir olması için ilk olarak elasticsearchün bu dökümanı indexlemesi gerekir. Süreç şöyle işler, öncelikle, document primary shardlardan birine gönderilir. Bu seçimde aslında dokuman IDsinin hashine göre yapılır. Bu primary shard farklı bir node da olabilir. Ama bu da uygulamaya transparentter yani uygulama bunu bilmez. İlgili shard indexlenecek node’a requesti yollar.Daha sonra aynı document primary shardın tüm replikalarına da indexlenmek üzere gönderilir. Bu da replkaları shardlarla scyn tutar. Searche hazır ve primary shard yerine geçebilecek durumda
Bir indexte arama yaptgınızda ne olur?
Bir search yaptınızda elasticsearch bu index için tümshardlara bakmak zorunda. Bu uygun shardlar ya replica ya primary shard olabilir. Round robin ile belirlenir. Elastic search yükü primary ve replica shardlara dağıtır bu da performance ve fault tolerance için önemlidir. Daha sonrasında elasticsearch kendi arama şekliyle bu shardlarda hızlıca arama yapar. Bulduğu sonuçları tek bir shardda toplar ve tek bir result yapar ve uygulamaya geri yollar.