ElasticSearch Sharding Yapısı ve Routing Mekanizması

Elastik search dağıtık mimarisi nedeniyle oldukça ölçeklenebilirdir. Bunun en önemli konseptlerinden birisi de shardingtir.

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.

***
Shardlarla ilgili harika olan şey, cluster içindeki herhangi bir nodeda barındırılabilmeleridir. Bununla birlikte, clusterınızdaki node sayısına bağlı olduğundan, bir indexin parçalarının birden çok fiziksel veya sanal makineye dağıtılması gerekmez. Dolayısıyla, önceki örnekte, 1 terabaytlık indexi her biri 256 gigabayt veri içeren dört parçaya bölebiliriz ve bu parçalar daha sonra iki düğüm arasında dağıtılabilir, yani bir bütün olarak dizin artık sahip olduğumuz disk kapasitesi.
***
Shardingin önemli olmasının iki ana sebebi vardır. Birincisi verinizi dağıtarak scale etmenizi sağlar. Eğer ki sürekli büyüyen bir datanız varsa,  sharding sayesinde darboğazlarla karşılaşmazsınız. Shardingin ikinci önemi ise operasyonları multiple nodelar üzerine dağıtıp paralelize edebiliriz. Bu da performansı artırır.
Bir indexin kaç tane shardı olabilir? Bunu opsiyonel olarak index yaratımı sırasında belirlenebilir olmakla beraber default sayısı 5tir. Eğer çok büyük datalarla uğraşmıyorsanız, default olarak gelen 5 shard sizin için yeterli olabilir ve sharding konseptiyle ekstra ilgilenmenize gerek kalmaz. Ancak diyelim ki bir indexteki shardın sayısını artırmamız gerekti ancak index zaten yaratılmış durumda. Bu gibi durumlarda shardların sayısını artıramazsınız. Bunun yerine istediğiniz sayıda sharda sahip yeni bir index yaratıp datanızı yeni indexe taşımalısınız ya da farklı sharding stratejilerini araştırıp uygulayabilirsiniz
Sonuç olarak toparlarsak, sharding dediğimiz kavram indexlerin data hacimlerini yatayda parçalara ayırmak demektir. Bu da verinizi multiple nodelar arasında distribute etmenizi sağlar. Nodeunuzun kapasitesi tüm veriyi tutmaya yetmediğinde ya da, performansı arttırmak gibi durumlarda kullanılabilir..
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.
Bu değer daha sonra bir hash fonksiyonuna bölme için kullanılmak üzere  sayı üretmesi için geçer. Bu sayının kalanı shard sayısını veririr. Bu elastic searchin specific dokumanlarının yerini nasıl belirlediğidir. Search query çalıştırıldığında, süreç farklıdır. Query tüm shardlara paylaştırılır.

Bu default davranış documanların shardlara eşit olarak paylaştırılmasını sağlar. Tabi ki bu default gelen özellik olmakla birlikte değiştirilebilir. Eğer dökümanların nasıl dağıtılacağını kendiniz ayarlamak isterseniz, custom routing value belirleyebilirsiniz. Her customer için bir dökümanınız olması buna bir örnek olabilir, bu durumda shard customerin ülkesine göre belirleyebilirsiniz. Bu durumda, potansiyel bir sorun, müşterilerinizin çoğunluğunun aynı ülkeden olması olabilir, çünkü bu durumda belgeler primary shardlara eşit bir şekilde dağıtılmayacaktır. Bundan bahsetmemin nedeni, özel yönlendirmenin biraz ileri bir konu olması. Yapması kolay olsa da, bazı genel tuzaklar ve farkında olunması gereken şeyler vardır, bu nedenle yalnızca ne yaptığınızı biliyorsanız bir production cluster kullanılmalıdır. Bu yüzden şimdilik bu konuya girmeyeceğim. Ama şimdi olasılığın var olduğunu biliyorsunuz.

Bir index oluşturulduktan sonra bir indexin shard sayısının değiştirilemeyeceğini nasıl söylediğimi hatırlıyor musunuz? Routing formülünü göz önünde bulundurarak, neden böyle olduğuna dair cevabımız var. 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, documan aslında Shard A’da saklansa bile formül Shard B’ye yönlendirilebilir. Bu, documanın 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. Varsayılan routing formülü kullanılarak yönlendirilen dökümnları içeren mevcut bir index’e özel yönlendirme eklerseniz aynı sorun ortaya çıkabilir, bu yüzden buna dikkat edin!

Öyleyse, hikayenin ahlaki yönü, varsayılan routing formülünün, dökümanları bir idnexin birincil shardlarına eşit olarak dağıtmasıdır. Routingi değiştirmek mümkündür, ancak bu sorunlara neden olabilir, bu yüzden şu anda girmeyeceğim daha ileri bir konu. Yönlendirme ayrıca, az önce bahsettiğim nedenlerle zaten oluşturulmuş bir indexin shard sayısını değiştiremememizin nedenidir.

You may also like...

Bir Cevap Yazın

E-posta hesabınız yayımlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir