Aslında hepimizin de bildiği gibi elasticsearch’ün en güçlü yanı milyonlarca data içerisinde milisaniyeler içerisinde sorgulama yapabilmesidir. Bunu sağlayan; arkasında dönen algoritma, elasticsearchün indexleme mekanizması vs gibi birçok etken mevcut. Bunlardan bitanesi de çok da fazla üzerine konuşulmayan elasticsearchün cacheleme mekanizmasıdır. Eğer ki elasticsearch’ü sık kullanıyorsanız datayı indexledikten sonra, ikinci querynin birinciden çok daha hızlı geldiğini fark etmişsinizdir. Bu zaten temel bir caching mekanizmasından beklediğimiz bir şey.
Üzerinde konuşabileceğimiz 2 cache yapısı var. Bunlar filter cache ve shard query cache.
Filter cache, sorgulama yaparken filtreleri ve queryleri kombinleyerek yaptığınız sorgulama sonuçlarınızı hızlandırmada önemli bir rol oynar.
Shard query, overall resultı cacheldiğinden static indisler üzerinde aggregation çalıştırdığınız zaman faydalı olacaktır.
Detaylarına girerek başlayalım.
1.Filters and filter caches
Elasticsearchte dökümanlarınızı belli koşullar üzerinden sorgulayabilir bunu yaparken de range query ya da eşdeğeri range filteri kullanabilirsiniz. Bu ikisi arasında seçim yaparken, filterları kullanmak yerinde olacaktır. Çünkü filterlar cachlenebilir yapıdadırlar ve range filter default olarak cachlenir. Ancak isterseniz cachlenip cachelenmeyeceğini kendiniz de configler üzerinden (_cacheflag) ayarlayabilirsiniz.
1.1 Node Query Cache (Filter Cache)
Cache’e alınan bir filtrenin sonuçları filtre cache denen yapıda saklanır. Bu cache, node levelde tahsis edilir. Boyutu varsayılan olarak % 10’dur, ancak ihtiyaçlarınıza göre elasticsearch.yml’den değiştirebilirsiniz. Filtreleri çok kullanır ve cachlerseniz alırsanız, boyutu artırmak mantıklı olabilir.
1.2 Cachlerin Eviction
Cache eviction, cache fullendiğinde elastic searchün last recently used (LRU) entry’i yeni yer açabilmek için düşürmesidir. Bazı zamanlarda, filter cachelerin kullanım süresi çok kısadır. Örneğin, siz filtreler kullanarak bir search yaparsınız. Aradığınızı bulursunuz ve sonra da bir daha o sorguyu kullanmazsınız. Eğer ki bir daha kimse o sorgu üzerinde bir kullanım yapmaz ise, cache entry, evicted edilene kadar hiç bir şey yapılmadan duracaktır. Ancak sürekli eviction yapılan full cache, performans açısından sıkıntı yaratır. Çünkü siz her search yaptığınızda en eski cache entrynizi yenisiyle değiştirmek için de CPU tüketecektir. Bu gibi durumlarda evictionu engellemek için cache entrylere TTL( time to live) koymak yerinde olacaktır. Bunu da index bazında yapabiliriz.
2.Shard Query Cache
Filter cache amacı filtre olarak adlandırılan search kısımlarını cachenebilir bir şekilde ayarlamak idi. Amacı searchün bir kısmını hızlı hale getirmek. Ayrıca filter cache segment-specifictir. Bazı segmentler merge process tarafından silinse dahi diğer cacheler bozulmamış kalır. Aksine, shard query cache tüm request ile onun shard levelinde resultı arasında bir mapping kurar. Eğer shard belirli bir requeste zaten cevap verdiyse, onu cacheten sunabilir.
The shard query cache entries bir istekten diğerine farklılık gösterir, bu nedenle yalnızca dar bir istek kümesine uygulanırlar. Farklı bir terim arıyorsanız veya biraz farklı bir aggregation için search yaparsanız, bu cache miss olacaktır. Ayrıca, bir reflesh gerçekleştiğinde ve shard içeriği değiştiğinde, tüm shard query cache entityleri geçersiz sayılır. Aksi takdirde, yeni eklenen döküman indexlenebilir ve siz yine de out of date data alabilirsiniz.
Aslında bu shard cache entrylerin darlığı shardın çok az değiştiği ve identical requestlerinizin olduğu durumlarda işe yarar. Örneğin loglarınızı indexlediğiniz bir yapınız olduğunu varsayalım ve bu indexingi time based yapıyorsunuz. Geçmiş indexler üzerinde de çok fazla arama yapmanız gerekir ve bu indexler değişmeden kalacaktır.