Üretimde Elasticsearch - En İyi Dağıtım Uygulamaları
Elasticsearch inanılmaz bir gerçek zamanlı arama ve analiz motoru. Apache Lucene üzerine inşa edilmiştir. Dağıtılmış, RESTful, kullanımı kolay ve yüksek oranda kullanılabilir. Elasticsearch kullanım durumları aramaya güç vermeyi, işlem izlemeyi ve hata saptamayı, içerik keşfetmeyi, günlük analitiğini, bulanık aramayı, olay verilerini birleştirme, veri görselleştirmeyi içerir. Elasticsearch ve Elastic Stack'ın geri kalanının son derece çok yönlü olduğu kanıtlanmıştır ve yukarıdaki kullanım durumlarını görebileceğiniz gibi, Elasticsearch'ü bugünün ürününüze sunduklarınıza entegre etmenin ve ona daha fazla fikir katmanın birçok yolu vardır.
Botmetric'te arama ve analitik için yoğun bir şekilde kullanıyoruz, günde yaklaşık bir milyar dokümanı dizine alıyoruz ve gerçek zamanlı olarak veri görselleştirmesi için çok karmaşık toplamaları kullanıyoruz.
Bununla birlikte, bir uygulamanın önyüklenmesi ve üretimde çalıştırılması ve sürdürülmesi tamamen farklıdır. Bu aricle, gerçek yaşam deneyimlerinden bu faktörlerin birçoğunu kapsar ve Elasticsearch'ü üretimde yürütmek için göz önünde bulundurmanız gereken temel ortak öğelerdir.
Bellek:
Elasticsearch ve Lucene, Java dilinde yazılmıştır, bu da boş alan ve JVM istatistiklerine bakmanız gerektiği anlamına gelir. Elasticsearch için ne kadar fazla yığın varsa, sorgu performansını artırmak için filtre ve diğer önbellekleme için o kadar fazla bellek kullanır. Ancak, çok fazla yığının sizi uzun çöp toplama duraklamalarına maruz bırakabileceğini unutmayın. Xmx'i, JVM'nin sıkıştırılmış nesne işaretçileri (sıkıştırılmış ayraçlar) için kullandığı sınırın üstüne ayarlamayın; kesin kesim değişir ancak 32 GB civarındadır.
Yaygın bir sorun, çok büyük bir yığını yapılandırmaktır. 64 GB'lık bir makineniz var - ve neyse ki, Elasticsearch'e 64 GB'lık bir bellek vermek istiyorsunuz. Daha fazlası daha iyi! Yığın Elasticsearch için kesinlikle önemlidir. Hızlı işlem sağlamak için birçok bellek içi veri yapısı tarafından kullanılır. Ancak bununla birlikte, kapalı olan başka bir büyük bellek kullanıcısı daha var: OS dosya önbelleği
Lucene, bellek içi veri yapılarını önbelleğe almak için temel işletim sisteminden yararlanmak üzere tasarlanmıştır. Lucene segmentleri ayrı dosyalarda saklanır. Segmentler değişmez olduğundan, bu dosyalar asla değişmez. Bu onların önbellek dostu olmasını sağlar ve altta yatan işletim sistemi, daha hızlı erişim için bellekte bulunan sıcak segmentleri mutlu bir şekilde tutar. Bu segmentler hem ters indeks (tam metin arama için) hem de doc değerlerini (toplamalar için) içerir. Lucene’in performansı, işletim sistemi ile bu etkileşime dayanmaktadır. Ancak, mevcut tüm belleği Elasticsearch’ün öbeğine verirseniz, OS dosya önbelleği için hiçbir şey kalmaz. Bu, performansı ciddi şekilde etkileyebilir. Standart öneri, mevcut hafızanın% 50'sini Elasticsearch yığınına verirken diğer% 50'sini boş bırakmaktadır. Kullanılmayacak; Lucene dosya önbelleği için kalanları mutlu bir şekilde tüketecektir. Elasticsearch yığını aşağıdaki yollarla yapılandırılabilir,
ihracat ES_HEAP_SIZE = 10g
veya
ES_JAVA_OPTS = "- Xms10g -Xmx10g" ./bin/elasticsearch
İŞLEMCİ:
Elasticsearch, toplamaları ve filtrelenmiş sorguları destekler. Karmaşık filtreli sorguların çalıştırılması, yoğun endeksleme, süzülme ve endekslere karşı sorgulamalar için yoğun CPU gereklidir, bu nedenle doğru olanı seçmek çok önemlidir. İşlemci özelliklerini ve JVM'de çalışan sorgular gibi Java ile nasıl davrandıklarını anlamak gerekir.
Her havuz, yapılandırılabilen ve bir kuyruğa sahip bir dizi iş parçacığı çalıştırır. Elasticsearch'in çekirdekleri dinamik olarak tahsis ettiği için, çok özel bir gereksiniminiz olmadıkça, bunun değiştirilmesi önerilmez.
İplik havuzu tipleri:
Elasticsearch, 3 tip Thread havuzuna sahiptir.
- Önbelleğe Alınmış: Önbelleğe alınmış iş parçacığı havuzu, bekleyen isteklerin olması durumunda iş parçacığının ortaya çıkmasına neden olacak sınırsız bir iş parçacığı havuzudur. Bu iş parçacığı havuzu, bu havuza gönderilen isteklerin engellenmesini veya reddedilmesini önlemek için kullanılır. Bu iş parçacığı havuzunda kullanılmayan iş parçacığı, bir canlı tutma süresi dolduktan sonra sona erer (varsayılan olarak beş dakika). Önbelleğe alınmış iş parçacığı havuzu, genel iş parçacığı havuzu için ayrılmıştır.
- Sabit: Sabit iş parçacığı havuzu, istekleri işlemek için iş parçacığı olmayan beklemedeki isteklerin bir sırasına (isteğe bağlı olarak bağlı) sahip işlemek için sabit bir iş parçacığı tutar. Size parametresi, iş parçacıklarının sayısını kontrol eder ve varsayılan olarak çekirdek sayısı 5'e karşılık gelir.
- Ölçeklendirme: Ölçeklendirme iş parçacığı havuzu, dinamik sayıda iş parçacığı tutar. Bu sayı iş yüküyle orantılıdır ve 1 ile boyut parametresinin değeri arasında değişir.
Elasticsearch, CPU kullanımını çeşitli tipteki iplik havuzlarına ayırır:
- genel: keşif ve iş parçacığı havuzu türü gibi standart işlemler için önbellekte saklanır.
- index: index / delete işlemleri için. İplik havuzu tipi sabittir.
- arama: sayım / arama işlemleri için. İplik havuzu tipi sabittir.
- almak: işlemleri almak için. İplik havuzu tipi sabittir.
- bulk: bulk indexing gibi toplu işlemler için. İplik havuzu tipi sabittir. Toplu belgelerin en iyi yapılandırması küme yapılandırmasına bağlıdır, bu birden çok değer denenerek tanımlanabilir.
- perkolat: süzülme için. İplik havuzu tipi sabittir.
- Yenileme: Yenileme işlemleri için. İş parçacığı havuzu türü ölçekleniyor.
Belirli bir iş parçacığı havuzunun değiştirilmesi, türüne özgü parametreleri ayarlayarak yapılabilir.
Daha fazla oku https://www.elastic.co/guide/tr/elasticsearch/reference/2.2/modules-threadpool.html#types
Shard boyutu:
Parça, Elasticsearch'ün küme içindeki verileri dağıttığı ünitedir. Elasticsearch'ün verileri yeniden dengeleme sırasında parçaları hareket ettirme hızı; Bir hatanın ardından ağ ve disk performansının yanı sıra parçaların boyutuna ve sayısına bağlı olacaktır.
Elasticsearch'te her sorgu, parça başına tek bir iş parçacığında yürütülür. Bununla birlikte, çoklu parçalar, aynı parçaya karşı birden fazla sorgulama ve toplama yapabildiği gibi paralel olarak da işlenebilir.
Bu, herhangi bir önbellekleme söz konusu olmadığında minimum sorgu gecikmesinin verilere, sorgu türüne ve kırığın boyutuna bağlı olacağı anlamına gelir. Çok sayıda küçük parça sorgulamak, parça başına işlem hızını daha hızlı hale getirir, ancak daha fazla işin sırayla sıralanması ve işlenmesi gerektiğinden, daha az sayıda daha büyük parçaların sorgulanmasından daha hızlı olması gerekmez. Çok sayıda küçük parçaya sahip olmak, aynı anda birden fazla sorgu varsa, sorgu verimini de düşürebilir.
Her bir parça, bellekte tutulması gereken ve yığın alanı kullanan verilere sahiptir. Bu, verilerin diskte nerede bulunduğunu tanımlamak için parça seviyesinde ve ayrıca segment seviyesinde bilgi tutan veri yapılarını içerir. Bu veri yapılarının boyutu sabit değildir ve kullanım durumuna bağlı olarak değişecektir. Bununla birlikte, bölümün genel giderine ilişkin önemli bir özellik, bölümün büyüklüğü ile kesinlikle orantılı olmamasıdır. Bu, daha büyük bölümlerin, küçük bölümlere kıyasla veri hacmi başına daha az ek yüke sahip olduğu anlamına gelir. Fark önemli olabilir. Doğru sayıda parça seçmek karmaşık bir işlemdir çünkü başlamadan önce kaç tane belge alacağınızı asla bilemezsiniz. Çok sayıda parçaya sahip olmak bir küme için hem iyi hem de korkunç olabilir. Endeksler ve kırıklar yönetimi, ana düğümün aşırı yüklenmesine neden olabilir; bu da yanıt vermeyebilir ve garip ve kötü davranışlara yol açabilir. Ana düğümlerinize küme boyutuyla başa çıkmak için yeterli kaynak tahsis edin.
Kötü olan şey, kırık sayısının değişmez olması ve indeksi oluşturduğunuzda tanımlanması. Dizin oluşturulduktan sonra, kırık sayısını değiştirmenin tek yolu dizinlerinizi silmek, yeniden oluşturmak ve yeniden dizine eklemektir.
kopya
Elasticsearch, çoğaltmayı destekler, veriler veri düğümleri arasında çoğaltılır, böylece bir düğüm kaybı veri kaybına yol açmaz. Varsayılan olarak, çoğaltma faktörü 1'dir, ancak ürün gereksinimlerinize bağlı olarak arttırılabilir. Ne kadar çok kopya olursa, felakete karşı dirençli olan verileriniz o kadar fazla olacaktır. Daha fazla kopyaya sahip olmanın bir başka avantajı da, her düğümün, sorgulamalar için kopyalar da kullanıldığı için sorgu performansını artıran bir çoğaltma parçasına sahip olmasıdır.
Elasticsearch tarafından tutarlılık için kullanılan replikasyon formülü,
(birincil + number_of_replicas) / 2 + 1
Tahsisi optimize etme
Ürün veri gereksinimlerine dayanarak, verileri sıcak ve soğuk olarak sınıflandırabiliriz. Diğerlerine göre daha sık erişilen endekslere daha fazla veri düğümü tahsis edilebilirken, daha az erişilen endekslere daha az kaynak ayrılabilir. Bu strateji özellikle uygulama günlükleri gibi zaman serisi verilerinin depolanması için kullanışlıdır (örneğin: ELK).
Bu, endeksleri düzenli aralıklarla farklı düğümlere taşıyan bir cronjob çalıştırılarak elde edilebilir.
Sıcak düğüm, kümedeki tüm dizinlemeyi gerçekleştiren bir tür veri düğümüdür. Ayrıca, genellikle en sık sorgulanan eğilim gösterdikleri için en son endekslere sahiptirler. Endeksleme CPU ve IO yoğun bir işlem olduğundan, bu sunucuların bağlı ve SSD depolama ile desteklenmesi gerekir. Yüksek kullanılabilirlik için en az 3 Hot node çalıştırmanızı öneririz. Yine de toplamak ve sorgulamak istediğiniz son veri miktarına bağlı olarak, performans hedeflerinize ulaşmak için bu sayıyı arttırmanız gerekebilir.
Sıcak düğüm, sık sık sorgulanması muhtemel olmayan çok sayıda salt okunur endeksi işlemek için tasarlanmış bir veri düğümü türüdür. Bu endeksler salt okunur olduğundan, ılık düğüm SSD'ler yerine büyük ekli diskleri (genellikle dönen diskleri) kullanma eğilimindedir. Sıcak düğümde olduğu gibi, yüksek kullanılabilirlik için en az 3 Sıcak düğüm öneririz. Ve daha önce olduğu gibi, daha büyük miktarlarda veri, performans gereksinimlerini karşılamak için ek düğümler gerektirebilir. Ayrıca, CPU ve bellek yapılandırmalarının çoğu zaman sıcak düğümlerinizinkini yansıtması gerekeceğini unutmayın. Bu, yalnızca üretim durumunda yaşayacağınıza benzer sorgularla test edilerek belirlenebilir.
Sıcak ve ılık düğüm hakkında daha fazla bilgi için buraya bakın.
Uyarlayabileceğiniz bir diğer strateji ise endeksleri s3'e arşivlemek ve bu endekslerden veriye ihtiyacınız olduğunda geri yüklemek. Buradan daha fazla okuyabilirsiniz.
Düğüm Topolojisi:
Elasticsearch düğümleri, ana düğüm, veri düğümü, istemci düğümü olmak üzere üç kategoriye ayrılabilir.
- Ana düğüm: Ana düğüm, herhangi bir dizin / parça saklamadığı için bir Veri düğümü değilse de küçük olabilir. Sorumluluğu, ayrıntılı küme durumunu saklamak ve veri ve diğer düğümlerin indeksler / shards meta-veri aramasında yardımcı olmasıdır. Elasticsearch, ayrık beyin probleminden kaçınmak için çoklu ana düğümlere sahip olmalıdır.
- Veri düğümü: Veri düğümü, gerçek dizin verilerinin depolanmasından / sorgulanmasından sorumludur.
- İstemci düğümü: İstemci düğümü, dizin oluşturma ve arama için bir vekil olarak kullanılır. Agregalar yoğun olarak kullanılıyorsa, bu şiddetle tavsiye edilir. Bunlar, veri ya da ana uzman olmayan özel ElasticSearch düğümleridir. İstemci düğümleri kümenin farkındadır ve bu nedenle akıllı yük dengeleyici görevi görebilir. Sorgularınızı istemci düğümlerine gönderebilirsiniz; bu da daha sonra her bir veri düğümünden gelen sorgu sonuçlarına yanıt toplamak için pahalı bir görevi üstlenebilir.
bu ayarları ilgili düğümlerin elasticsearch.yml dosyasına ekleyin.
Ana düğüm: node.master: true node.data:false Veri düğümü: node.master: false node.data:true İstemci düğümü: node.master: false node.data:false
Sorun giderme ipuçları:
Elasticsearch performansı, yüklü olduğu makineye bağlıdır. CPU, Bellek Kullanımı ve Disk G / Ç, her Elasticsearch düğümü için temel işletim sistemi ölçümleridir. CPU kullanımı arttığında Java Sanal Makinesi (JVM) metriklerine bakmanız önerilir. Aşağıdaki örnekte, çivinin nedeni daha yüksek çöp toplama aktivitesiydi.
- Yığın basıncı: Yüksek bellek basıncı, küme performansına karşı iki şekilde çalışır: Bellek basıncı% 75 ve üstüne çıktığı için, daha az bellek kalır ve kümenizin artık, çöp toplama işlemi sırasında belleği geri kazanmak için bazı CPU kaynaklarını harcaması gerekir. Bu CPU döngüleri, çöp toplama açıkken kullanıcı isteklerini yerine getirmek için kullanılamaz. Sonuç olarak, kullanıcı talepleri için yanıt süreleri, sistem gittikçe daha fazla kaynak kısıtlı hale geldikçe artar. Hafıza basıncı artmaya devam ederse ve% 100'e yaklaşırsa, daha fazla agresif bir çöp toplama biçimi kullanılır ve bu da kümelenme yanıt sürelerini önemli ölçüde etkiler. Endeks Tepkisi Times ölçüsü, yüksek bellek baskısının önemli bir performans etkisine yol açtığını gösteriyor.
- JVM’nin yığın olmayan belleğindeki büyüme, sayfa önbelleği için tasarlanmış belleği yiyor ve muhtemelen çekirdek düzeyinde OOM’in artmasına neden oluyor.
- Bölünmüş beyin probleminden kaçının. Bölünmüş beyin, kümenin dağıldığı bir senaryodur. Örneğin, 6 düğüm kümeniz var. 2 düğüm kümeden bağlantısını keser, ancak yine de birbirlerini görebilirler. Bu 2 düğüm daha sonra başka bir küme oluşturur. Hatta kendi aralarında yeni bir efendi seçecekler. Şimdi, biri 4 düğümlü diğeri 2 düğümlü aynı ada sahip iki kümemiz var. Her birinin de bir ana düğümü vardır. Bu, ES kümeleriyle bölünmüş beyin sorunu olarak adlandırılır. Bundan kaçınmak için, ES parametresini discovery.zen.minimum_master_nodes değerini +1 düğüm sayısının yarısına ayarlayın.
- Elasticsearch, depolama aygıtlarını yoğun bir şekilde kullandığından, disk G / Ç'nin izlenmesi bu temel ihtiyacın karşılanmasını sağlar. Disk G / Ç’inin azaltılmasının birçok nedeni vardır, bunun birçok sorunu önceden tahmin etmek için anahtar bir ölçüt olduğu düşünülmektedir. İndeksleme ve sorgu performansının etkinliğini kontrol etmek iyi bir ölçümdür. Okuma ve yazma işlemlerini doğrudan analiz etmek, sistemin belirli kullanım durumlarında en çok ihtiyaç duyduğu şeyi belirtir. Disk G / Ç için işletim sistemi ayarları, diğer tüm optimizasyonlar için bir temeldir; disk G / Ç'yi ayarlamak olası sorunları önleyebilir. Disk G / Ç hala yeterli değilse, parça sayısını ve büyüklüğünü optimize etmek, birleştirme yapmak, yavaş diskleri değiştirmek, SSD'lere taşımak veya daha fazla düğüm eklemek gibi önlemler G / Ç'ye neden olan koşullara göre değerlendirilmelidir. darboğazları.
- Aramaya dayanan uygulamalar için, kullanıcı deneyimi, arama isteklerinin gecikmesiyle büyük ölçüde ilişkilidir. Oluşturulan sorgular, yanlış yapılandırılmış Elasticsearch küme, JVM bellek ve çöp toplama sorunları, disk GÇ vb. Gibi sorgu performansını etkileyebilecek birçok şey vardır. Sorgu gecikmesi, kullanıcıları doğrudan etkileyen metriktir, bu nedenle bazı uyarılar koyduğunuzdan emin olun.
- Elasticsearch'teki filtrelerin çoğu varsayılan olarak önbelleğe alınır. Bu, filtrelenmiş bir sorgunun ilk yürütülmesi sırasında, Elasticsearch'ün filtreyle eşleşen belgeleri bulacağı ve bu bilgiyi kullanarak “bitset” adı verilen bir yapı oluşturacağı anlamına gelir. Bit setinde depolanan veriler bir belge tanımlayıcı ve belirli bir belgenin filtreyle eşleşip eşleşmediğini içerir. Aynı filtreye sahip olan sorguların daha sonraki yürütmeleri, bit setinde depolanan bilgileri yeniden kullanacak, böylece G / Ç işlemlerini ve CPU döngülerini kaydederek sorgu yürütmeyi daha hızlı hale getirecektir. Sorgudaki filtrenin kullanılması önerilir. Daha fazla ayrıntı için buraya bakın.
- Yenileme süresi ve birleştirme süresi, dizin oluşturma performansıyla yakından ilgilidir, ayrıca genel küme performansını da etkiler. Yenileme süresi, Lucene endeksi (kırığı) için dosya işlemlerinin sayısıyla artar.
- Yavaş sorgu günlüğünün etkinleştirilmesi, hangi sorguların yavaş olduğunu ve bunları geliştirmek için neler yapılabileceğini, özellikle de joker karakter sorguları için yararlı olduğunu belirlemede yardımcı olacaktır.
- Azami dosyalara izin vermek için ulimit boyutunu artırın.
- İşletim sistemi kullanılmayan uygulama hafızasını değiştirmeye karar verdiğinde ElasticSearch performansı düşebilir. İşletim sistemi düzeyindeki ayarları ayarlayarak değiştirmeyi devre dışı bırakın veya ElasticSearch config bootstrap.mlockall'da aşağıdakileri ayarlayın: true
- Tüm dizinleri joker sorgusu ile silmeyi devre dışı bırakın. Birisinin tüm dizinlerde (* veya _all) bir DELETE işlemi yapmadığından emin olmak için action.destructive_requires_name öğesini true olarak ayarlayın.
Bitirmeden önce, metrikleri izlemek için yararlı olan URL'lerin listesi.
- / _cluster / health? pretty: Küme sağlığı göstergesi için.
- / _status? pretty: Tüm endeksler hakkında tüm bilgiler için.
- / _nodes? pretty: Düğümler hakkındaki tüm bilgiler için.
- / _cat / master? pretty: Ana düğüm için.
- / _stats? pretty: Zorluk tahsisi için endeks istatistikleri.
- / _nodes / stats? pretty: Bağımsız düğüm istatistikleri için, buna düğümün jvm, http, io istatistiklerini dahildir.
Elasticsearch'ün metrik toplama, Datadog, TICK gibi çoğu sistem izleme aracı tarafından desteklenmektedir. Bu tür araçların kullanılması tavsiye edilir ve Elasticsearch'ün sürekli izlenmesi için huni oluşturulması şiddetle önerilir.
Sonuç:
Elasticsearch, birden fazla kiracının tüm veri kümelerinde, boyutuna bakılmaksızın, eşi benzeri görülmemiş hızlarda arama yapmasını sağlayan dağıtılmış bir tam metin arama ve analiz motorudur. Tam metin arama yeteneklerine ek olarak, ElasticSearch bir analitik sistemi ve dağıtılmış veritabanı olarak ikiye katlanır. ElasticSearch'ün başlamak için harika varsayılanları var. Ancak, ilk deneme aşamasını geçtikten sonra, gereksinimlerinize yönelik ayarları değiştirmek için biraz zaman harcamanız gerekir. Kümenizin ihtiyaçlarınızı karşılayacak şekilde yapılandırıldığından emin olmak için daha sonra resmi belgelerle birlikte yapılandırmanızı tekrar ziyaret etmeniz önerilir.