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.
Dökümanları Shardlara Dağıtmak – Routing mekanizması
hash değeri 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 yukarıda anlatmıştım. 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 olması gereken 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.
